Hi Wojtek,
You have not mentioned which lispsm is used but if thats DrawBounds (flavour) it does 2 extra cull & render passes.
No, we use the ViewBounds type. and I forgot to mention in my arguments to reproducing the results in the osgshadow example that I also used ViewBounds. Sorry about that, seems even with my very long post I was still missing some specifics :-)
Our DBs are also made from small batches. My observations were that not only the size of primitive sets but small state attribute changes between them were hitting hard as well.
Yeah, I had also noticed the large number of state sets and state graphs, and Tim remarked this in his reply too. I'll have a look at reducing that in the next few days.
I once did an experiment. We had a DB that was suffering from small batches problem. I have built Texture Atlases, then put all the scene Textures into single Texture2DArray (yes it was huge). Then I removed Statesets and created only one StateSet at scene root with Shaders to use Texture2DArray I built. I think I have not done anything to primitve sets they were the same as before only StateSets were gone. And framerate went up 2 times.
Very interesting results. I guess I could make a simple test of traversing our scene graph removing all statesets after loading the scene, and seeing if the framerate improves significantly then. That would at least tell me I'm on the right track with attacking the number of statesets.
One problem unfortunately is that some textures could not be included in the atlases (because they are set to REPEAT), and sometimes not only textures change, but also some render state such as cull face (some fences made with a single polygon set to render both sides, for example). I'll have to get our artist to model these kinds of things as boxes, and replace the textures set to REPEAT.
Thanks for your insight, J-S -- ______________________________________________________ Jean-Sebastien Guay [email protected] http://www.cm-labs.com/ http://whitestar02.webhop.org/ _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
