Hi Viggo, I really can't comment without the actual problem and solutions in front of me, it's just too complex a topic to accumulate a whole thread and then generate in my head what the possible code and scene graph you have going on at your side.
One thing I can say is that the number of nodes you are playing with looks pretty excessive. I have no clue what type of application you have and what you are trying to do, but there may well may a wholly better way of tackling your problem than throwing a massive scene graph at it. Robert. On Fri, Nov 21, 2008 at 1:07 PM, Viggo Løvli <[EMAIL PROTECTED]> wrote: > Hi Robert, > >> The most general approach is the best, and the performance differences >> will almost certainly be negligible between your suggest >> SwitchStateSetNode and my suggest Layer node with nodemask. Feel free >> to implement both and test them against each other w.r.t cull >> traversal time and overall framerate. >> > > I implemented the LayerNode approach and tested both versions using a > composite viewer. > The StateSetSwitchNode is a tiny bit faster as predicted, but I agree with > you that the difference is negligible. > > The other penalty that I worte about earlier is however large. > > My scene: > ========== > - My scene contains 40308 nodes. > - A full traverse results in visiting 380941 nodes (lot of reused geometry). > > Pre-processing the scene with LayerNodes: > ========================================== > - 2356 LayerNodes are inserted. > - Each LayerNode is one Group node with 5 child Group nodes. > - Each child node share the same children as the other child nodes. > - I apply optimizations from osgUtil::Optimizer. > - Result: > - 54444 nodes totally in the scene. > - 11446441 visits during a full traverse. > > Pre-processing the scene with StateSetSwitchNode: > ================================================== > - 2356 StateSetSwitchNodes are inserted. > - This is one Group node that has 5 Group nodes embedded. > - All 5 embedded nodes share the same children as the StateSetSwitchNode. > - None of the 5 embedded nodes has any parents. > - I use the same optimizations as above. > - Result: > - 42664 nodes totally in the scene. > - 540844 visits during a full traverse. > > The penalty: > ============= > Our viewer is a osgViewer::CompositeViewer. > Calling the run function of the osgViewer::CompositeViewer is quite > dramatically different from the LayerNode to the StateSetSwitchNode > approach. > The LayerNode approach use approximately 20 times longer time from we call > run until the scene appears on screen. > 11446441 divided by 540844 = 21. > > > Conclusion after this testing: > =============================== > - We do not need the StateSetSwitchNode if the viewer initialization penalty > is somehow fixed. > > New questions: > =============== > - What does the osgViewer::CompositeViewer do when we call run and until > render starts? > - Is this something that would be possible to do in a pre-processor and save > in a .ive file? > - Other ways to get around this problem? > > > Regards, > Viggo > > > ________________________________ > Få Hotmail du også. Windows Live Hotmail med 5000 MB gratis lagringsplass. > _______________________________________________ > 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
