Hi Wojciech, On Sat, May 10, 2008 at 4:23 PM, Wojciech Lewandowski <[EMAIL PROTECTED]> wrote: > Realize in Producer::Viewer was usually explicitly called before entering > update/event/cull/render loop. osgViewer::Viewer::Realize can still be > called by user before main loop. I believe this makes first solution pretty > tricky, one would need to sync return from Viewer::Realize with completion > of GL compile operations. I don't know if this is simple task considering > number of Threading modes.
Actually osgViewer::Viewer::realize() is little different than the old Producer::CameraGroup::realize()/osgProducer::Viewer::realize() in terms of order of operations. osgViewer::Viewer::realize() will be called automatically on the first frame is it hasn't already been called by the user, so this is the only real difference in terms of order. osgProducer/Producer based apps did have a sync() at the begining of each frame, something that osgViewer doesn't have, rather then sync() of threads in done internally in renderingTraversals() at the end of the frame. This change makes it simpler to use osgViewer based apps as one doesn't need to worry about sync. One could still keep the external API simple by placing a barrier at the end of startThreading() in a similar way to renderinTraversals() does. However, while the API would not change, the internal implementation would be more complicated. > Second solution does not differ so much from what we have now with this > exception that lengthy compilation would be invoked after first > update/event/cull traversal. Currently its done before these traversals. But > from timing perspective it would not change much. Am I right ? The difference is the order of when the compile is done, and where the compile is instigated. The first frame which contains the compile does have a big hit - it's frame time will be higher than all subsequent frames, so we'll see a hesitation on first frame then the app will get going smoothly. I have gone ahead an implemented this approach, extending osgViewer::Renderer so it now has a compile() method that gets called automatically on the next draw, but once called won't get called again unless explicitly requested to do so. An svn update will get this change. In osgViewer::Renderer there is now a s/getCompileOnNextDraw() method to control when the compile is done, I've modified osgViewer::View::setSceneData() so that it now will reset the CompileOnNextDraw() so it'll now do a compile when you load new models, so this is nice little bonus from this change. In testing with your modified osgprerender things are now working smoothly. Could you let me know how you get on at your end. Robert. > > Wojtek > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
