osgGA::SimpleViewer
Hi All,
As many will know I've been pontificating on the future of viewer classes in the OSG for well over a year now, but other than a few additions like osgGA::EventQueue and EventVisitor have done little concrete in this direction. My recent work on osgText::FadeText brought forward the need for me to think about it some more as I needed a generic means of logically grouping different cameras into associated views - so that fades of overlapping/abutting windows could be synchronized. This introduced the osg::View class, which certainly helped progress things for osgText::Text and potentially for other tasks that require an overall view point to control things like per view settings or LOD ranges (for instance shadow technique). There is also another aspect to it - would such as class be useful for a general purpose viewer?
i.e. a viewer has one or more views etc...
This general purpose viewer would be a viewer with one or more views, with each view having one or more associated cameras, and the viewer having one or more windows, with each window having one or cameras, and then viewer could have an optional event queue, and each window would have it own event queue, and there would be a optional mechanism for passing events from event queue to event queue filtering then when required, then there would be an optional graphics thread for each window, and potentially a set of threads to do cull traversals per camera too... OK... very flexible, scalable and powerful, perhaps to a bit closer to ideal vis-sim or VR power users scene graph viewer but not a simplification of what we have already.
Anyway on the Sunday evening the weekend before last (8 days ago) it occurred to me
a general purpose viewer class would be overkill for what many OSG
users want - to just open up a single 3D window in an application, for it to be event driven and single threaded, and just a couple of lines of code to create and use. For this modest but common need perhaps having several viewer classes, and simple off the shelf one, moving up to highly configurable ones would be appropriate. So that Sunday evening I sat down to design a SimpleViewer class to flesh out this possibility, and on the following Monday morning and half afternoon I wrote osgGA::SimpleViewer. I also had time to port osgsimple and osgkeyboardmouse examples over from using osgUtil::SceneView to using the new osgGA::SimpleViewer. I then checked in the work in progress and then heading off on my five day road trip. Alas I didn't quite check in all the neccessary updates to keep the changes in osgGA:::GUIEventAdapter & osgProducer::KeyboardMouse in sync, which unfortunately lead to users see problems with osgviewer's camera manipulators not updating correctly, so sorry about that.
On my trip away I took my laptop with me so was able to do a little coding, adding support for DatabasePager into osgGA::SimpleViewer, this allowed osgsimple and osgkeyboardmouse to automatically be able to handle paged database with no changes. Over the this weekend I had a bash at making a series of osgsimpleviewer examples that implement this simple viewer in a range of 3rd Party windowing toolkits. If you do a cvs update -Pd you'll find:
osgsimpleviewerFLTK
osgsimpleviewerGLUT
osgsimpleviewerProducer
osgsimpleviewerQT3
osgsimpleviewerQT4
osgsimpleviewerSDL
There aren't any VS projects for them yet, nor Xcode project etc. To enable there build under unices you'll have to modify your own Make/dependencies file - make a copy or it somewhere, and then tell the build system where to find it via export OSG_DEPDENDENCIES=/home/me/my_dependencies. In the my_dependencies you just set things like FLTK_INSTALLED=yes.
All the examples are between 100-140 lines long, a chunk of thus code relates to adaption of events, one you've done it once you'll never need to do it again. Actually creation and use of the viewer is pretty straight forward as you'll see from the examples. SimpleViewer is written specifically to make it easier to integrate with windowing toolkits, and provides users with a high level support then you get previously when you wanted to roll you own viewer with osgUtil::SceneView - the SimpleViewer adds event handling, and database paging while keeping the public interface simple - much simpler than SceneView in fact.
SimpleViewer also automatically updates the osg::State::ContextID so should, in theory, cope with opening/closing multiple windows automatically, there is also a cleaup() method to help in this direction. It is, however, not yet tested at all in this usage style. Also if you want to share a single scene graph between multiple windows then we'll also need to do some work to share DatabasePager's and synchronize the FrameStamps between them as well as update traversals. All this does start to get complicated, and probably pushing such a simple viewer class beyond what we should expect it to handle. I think its probably important to keep its role quite humble, and push these more complex usage models on to other sets of viewer classes, either existing ones like Producer or new ones that we'll develop in the future.
I have tackled a number of 3rd party windowing toolkits, and have briefly looked at Fox, and WxWindows but these were just a bit too new and big for me to bite of in a days coding, and as I don't have a Mac or a Windows build machine I can't tackle Win32/MFC/ActiveX or AGL/CGL etc. So.. I was hoping that members of the community could review the existing osgsimpleviewer* examples and add ones for their own favoured API 
Right now I consider osgGA::SimpleViewer a quick experiment in writing a simple viewer class to aid 3rd party windowing library integration. You may well have views of whether it should exist at all, or what it should look like, for instance Don takes a different approach with his recent OsgViewer Producer example, please feel free to express what you think are the strong points/weak points etc, this can help inform how it should develop if at all. osgGA::SimpleViewer also relies upon other osgGA and osgUtil components that really need a rewrite too, you are wlecome to comment on which ones work for you, how they might be improved, or how you'd rather present the functionality. Perhaps we should leave some of this for different threads and weeks as there is clearly a lot to talk about
w.r.t viewers.
Longer term I'd like see good support for a wide range of windowing toolkits out of the bag, but the thought of having dozens of osgFLT, osgQT, osgMFC, osgWin32, osgMFC etc troubles me, especially considering the code base in each lib might well just be a hundred or so lines of code. We could maintain these on the wiki as separate projects, but perhaps another route might be to try and put all the implementations of the glue code into headers and place them all in a single library's headers. Putting implementation into headers would allow users to explicitly include an class into their app without the actual library needing to compile it.
Thoughts?
Robert.
<div><p>Hi All,<br><br>As many will know I've been pontificating on the future of viewer classes in the OSG for well over a year now, but other than a few additions like osgGA::EventQueue and EventVisitor have done little concrete in this direction. My recent work on osgText::FadeText brought forward the need for me to think about it some more as I needed a generic means of logically grouping different cameras into associated views - so that fades of overlapping/abutting windows could be synchronized. This introduced the osg::View class, which certainly helped progress things for osgText::Text and potentially for other tasks that require an overall view point to control things like per view settings or LOD ranges (for instance shadow technique). There is also another aspect to it - would such as class be useful for a general purpose viewer?
i.e. a viewer has one or more views etc...<br><br>This general purpose viewer would be a viewer with one or more views, with each view having one or more associated cameras, and the viewer having one or more windows, with each window having one or cameras, and then viewer could have an optional event queue, and each window would have it own event queue, and there would be a optional mechanism for passing events from event queue to event queue filtering then when required, then there would be an optional graphics thread for each window, and potentially a set of threads to do cull traversals per camera too... OK... very flexible, scalable and powerful, perhaps to a bit closer to ideal vis-sim or VR power users scene graph viewer but not a simplification of what we have already.
<br><br>Anyway on the Sunday evening the weekend before last (8 days ago) it occurred to me
a general purpose viewer class would be overkill for what many OSG
users want - to just open up a single 3D window in an application, for it to be event driven and single threaded, and just a couple of lines of code to create and use. For this modest but common need perhaps having several viewer classes, and simple off the shelf one, moving up to highly configurable ones would be appropriate. So that Sunday evening I sat down to design a SimpleViewer class to flesh out this possibility, and on the following Monday morning and half afternoon I wrote osgGA::SimpleViewer. I also had time to port osgsimple and osgkeyboardmouse examples over from using osgUtil::SceneView to using the new osgGA::SimpleViewer. I then checked in the work in progress and then heading off on my five day road trip. Alas I didn't quite check in all the neccessary updates to keep the changes in osgGA:::GUIEventAdapter & osgProducer::KeyboardMouse in sync, which unfortunately lead to users see problems with osgviewer's camera manipulators not updating correctly, so sorry about that.
<br><br>On my trip away I took my laptop with me so was able to do a little coding, adding support for DatabasePager into osgGA::SimpleViewer, this allowed osgsimple and osgkeyboardmouse to automatically be able to handle paged database with no changes. Over the this weekend I had a bash at making a series of osgsimpleviewer examples that implement this simple viewer in a range of 3rd Party windowing toolkits. If you do a cvs update -Pd you'll find:
<br><br> osgsimpleviewerFLTK<br> osgsimpleviewerGLUT<br> osgsimpleviewerProducer<br> osgsimpleviewerQT3<br> osgsimpleviewerQT4<br> osgsimpleviewerSDL<br><br>There aren't any VS projects for them yet, nor Xcode project etc. To enable there build under unices you'll have to modify your own Make/dependencies file - make a copy or it somewhere, and then tell the build system where to find it via export OSG_DEPDENDENCIES=/home/me/my_dependencies. In the my_dependencies you just set things like FLTK_INSTALLED=yes.
<br><br>All the examples are between 100-140 lines long, a chunk of thus code relates to adaption of events, one you've done it once you'll never need to do it again. Actually creation and use of the viewer is pretty straight forward as you'll see from the examples. SimpleViewer is written specifically to make it easier to integrate with windowing toolkits, and provides users with a high level support then you get previously when you wanted to roll you own viewer with osgUtil::SceneView - the SimpleViewer adds event handling, and database paging while keeping the public interface simple - much simpler than SceneView in fact.
<br><br>SimpleViewer also automatically updates the osg::State::ContextID so should, in theory, cope with opening/closing multiple windows automatically, there is also a cleaup() method to help in this direction. It is, however, not yet tested at all in this usage style. Also if you want to share a single scene graph between multiple windows then we'll also need to do some work to share DatabasePager's and synchronize the FrameStamps between them as well as update traversals. All this does start to get complicated, and probably pushing such a simple viewer class beyond what we should expect it to handle. I think its probably important to keep its role quite humble, and push these more complex usage models on to other sets of viewer classes, either existing ones like Producer or new ones that we'll develop in the future.
<br><br>I have tackled a number of 3rd party windowing toolkits, and have briefly looked at Fox, and WxWindows but these were just a bit too new and big for me to bite of in a days coding, and as I don't have a Mac or a Windows build machine I can't tackle Win32/MFC/ActiveX or AGL/CGL etc. So.. I was hoping that members of the community could review the existing osgsimpleviewer* examples and add ones for their own favoured API
<br><br>Right now I consider osgGA::SimpleViewer a quick experiment in writing a simple viewer class to aid 3rd party windowing library integration. You may well have views of whether it should exist at all, or what it should look like, for instance Don takes a different approach with his recent OsgViewer Producer example, please feel free to express what you think are the strong points/weak points etc, this can help inform how it should develop if at all. osgGA::SimpleViewer also relies upon other osgGA and osgUtil components that really need a rewrite too, you are wlecome to comment on which ones work for you, how they might be improved, or how you'd rather present the functionality. Perhaps we should leave some of this for different threads and weeks as there is clearly a lot to talk about
w.r.t viewers.<br><br>Longer term I'd like see good support for a wide range of windowing toolkits out of the bag, but the thought of having dozens of osgFLT, osgQT, osgMFC, osgWin32, osgMFC etc troubles me, especially considering the code base in each lib might well just be a hundred or so lines of code. We could maintain these on the wiki as separate projects, but perhaps another route might be to try and put all the implementations of the glue code into headers and place them all in a single library's headers. Putting implementation into headers would allow users to explicitly include an class into their app without the actual library needing to compile it.
<br><br>Thoughts?<br>Robert.<br></p></div>
RSS Feed