This morning I added a osgViewer::Viewer::run method, its purpose is
to run a main frame loop for you.
To help catch cases where the viewer has been set up prior to the run
call it also checks to make sure the viewer's windows are realized, if
not it realizes them, and if now cameras/windows are set up the
realize will open default ones for you. It also checks to see if a
camera manipulator is assigned, and if not it'll assign a
osgGA::TrackballManipulator for you.
The benefit for having the run and all the above automatically done
for you is that you can write the minimalist working application:
#include <osgViewer/Viewer>
#include <osgDB/ReadFile>
int main( int, char **)
{
osgViewer::Viewer viewer;
viewer.setSceneData(osgDB::readNodeFile("cow.osg"));
viewer.run();
}
This application could also load paged databases with just a filename
change, all the threading for the database pager is handled by
osgViewer. It'll also checks to see how many screens and processors
you have and create windows and single view across them, and if you
have multiple screens it'll assign multiple threads with and set
processor affinity if you have the processors available.
Now clearly this is a black box, lots of stuff being done for you
automatically, which is nice is some ways, but doesn't really provide
much insight in what is happening under the hood, or how to control
these items. One thing to note that while quite a bit is done for
you, it doesn't do all that osgProucer::Viewer does like
StateSetManipulator/ViewerEventManipulator.
osgViewer does allow you to build your viewer up incrementally and to
control the main loop entirely yourself, this obviously takes more
lines of code, but its all still reasonably straight forward. For
most application I'd expect you to need to do build things up much
more fine grained way, so the above tiny example wouldn't be normal
usage. The osgcamera.cpp example currently in CVS does currently
provide an example of setting things up more incrementally, and
I/we'll need to create other example to illustrate this - as per the
profiles that the other osgViewer thread will hopefully highlight.
When I port the OSG examples across I thinking in terms of some
fleshing out the viewer setup very specifically, with others to use
the above minimalist usage. The ones that I'm thinking about the
simple usage will be examples focused on other OSG tasks such as build
the scene graph.
My only concern about this approach is that users might try to over
use viewer.run() since they will see it in many examples. With better
documentation I don't think this should be a great problem though.
For instance we could have an example that contains the above code,
and the equivalent version but with the operations done incrementally.
Thoughts/reactions?
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
