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
