Hi All, Paul, I think I've done some of the benchmark you're referring to on my end right before starting this thread =) In my example I replicate the same geometric primitive many times. The geometric object is a little cube counting 40 vertex and 66 triangles all rendered as a single drawElements in batch. I'm using a very basic toon shader to render them, passing vertices, normals and a vec4 attribute array.
Here's what I got when I test with 20.000 instances of the primitive when they are all in the view frustum, my box is Win7, i7 920 processor, nVidia 285GTX: 1) 20.000 separate drawables, each with its own VBO assigned. CULL: 11ms, DRAW: ~40ms, GPU: ~37ms Stats are very unstable with this scenario, even when I don't move and with all of the threading models. 2) 20.000 separate drawables, sharing underneath the same VBO and EBO (at least I hope I'm doing it the right way, check the code in my previous post) CULL: ~8ms, DRAW: ~36ms, GPU: ~35ms 3) A single geode+geometry in which I combine all of the instances, rendered in a single VBO + EBO CULL: 0.04ms, DRAW: 0.18ms, GPU: ~4.5ms Stats very stable, no differences among threading models. With this scenario the fragment opeations becomes the bottleneck when I look at the scene from a viewpoint that cause all the geometries to be rendered almost back to front, so that nothing is culled nor discarded by z test. So scenario 3 provides a huge boost as expected, while the difference between 1 and 2 is not as evident as I had hoped... I'll see if I'm able to to patch the osg code to achive what Robert suggests. Thanks, Ricky On Thu, May 5, 2011 at 20:47, Robert Osfield <[email protected]>wrote: > HI All, > > > Current the OSG does unbind VBO's at the end of > osg::Geometry::drawImplementation(..) so that VBO and EBO state > doesn't leak into adjoining Drawables. If an implementation is known > to only use VBO's, with no display lists then potentially we could not > bother with the unbind at the end of Geometry::drawImplemenation() and > use lazy state updating. > > 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
