Thanks Robert for the detailed answer, I see the point of incremental compilation now but for my particular use case where I basically load everything at the beginning (but hide some things from the camera) I think my magic wand still is this "Performer parading trick". I'm happy to break many frames as long as I can make it happen in the beginning, so compile time is not a major issue here.
I just did some initial "parade tests" and I can confirm the stalls are gone now so it seems to work out great. Still this solution is a bit hacky, so if Carl or somebody else proceeds with the incremental path I'm curios to see an example of how complex it gets. /Per On 2 September 2014 16:02, Robert Osfield <[email protected]> wrote: > Hi Per, > > > On 2 September 2014 14:18, Per Nordqvist <[email protected]> wrote: > >> >> Thanks guys for the answers! I guess it's OK to take a hit at the >> beginning if things run smoothly afterwards, >> so I don't think I need a incremental compilation. >> >> Based on your answers I found a similar question here >> http://forum.openscenegraph.org/viewtopic.php?t=4997 >> >> So I tried this: >> osgViewer::Renderer* renderer = >> >> dynamic_cast<osgViewer::Renderer*>(viewer->getCamera()->getRenderer()); >> renderer->setCompileOnNextDraw(true); >> >> > This simply runs the GLObjectVisitor on the next frame to run GL object > compile on objects in scene graph, which, if you have lots of new GL > objects to be compiled will result in a frame stall. > > which is promising beacuse it creates exactly the same stall that I was >> seeing before. >> > > Best case is setCompileOnNextDraw(true) will perform the same as just > rendering it without if everything is on screen, if some elements would > otherwise be culled the frame time will actually be longer as all the GL > objects that need to be compiled will be compiled at the same time. The > advantage comes in subsequent frames as no new objects will enter the view > frustum and then have to be compiled. > > However, if I have hidden objects under a switch or if it's outside the >> frustum, I still see a recompilation >> triggered automatically once it is in the frustum and visible under the >> switch. >> So how to compile the _entire_ scene? >> > > You need to slow down and understand the basic mechanics of what is going > on. The OSG has lots of features to help with these issues but it's an > advanced topic with no magic wand so best take bit by bit. > > Part of the solution will be use of the > ogUtil::IncrementalCompileOperation as it designed to load balance the > number of GL compilations and deletes that happen each frame so that no one > frame gets overload and causes a frame break. The OSG's DatabasePager > utilizes the ogUtil::IncrementCompileOperation to avoid frame breaks, and > osgViewer::Viewer/CompositeViewer have support for > IncrementalCompileOperation built in, so the infrastructure is all there > waiting to be utilized. > > When you incremental compile objects you have to submit a subgraph to be > compiled and this is done by bit until all parts are compiled and when they > are these subgraphs are placed in a ready to be merged list, you can also > get a callback to get informed that a subgraph is ready. There are lots of > controls in the IncrementalCompileOperation to tune how quickly GL objects > get compiled - you can balance the speed of compilation vs the risk of > breaking frame. > > Another part of the work to make this efficient is make sure that the GL > objects in the scene graph are efficient to compile. Various drivers have > different strengths and weakness so what might be slow on one > driver/hardware might be fast on another. There are however general > rules. For instance generating of texture mipmaps can be a bottleneck so > precomputing mipmaps and storing them on disk can help, compressing imagery > in an OpenGL native compression format can also be very helpful. > > Robert. > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
