Hi Simon, On Fri, Jul 3, 2009 at 11:35 AM, Simon Loic<[email protected]> wrote: > Thanks Robert for trying to get into the problem. > I wanted to let it "opened" in order to get as many opinion/possible > oprimizations as possible.
I'm afraid we don't all have to time to write treaties on the topics of performance optimization - it's a huge topic. > To be truly honest I have a real problem with specific conditions. > Many instances refers to hundreds of them. OK, so traversals shouldn't be too slow then, so you shouldn't need to batch more coasely. It might be that you might want to divide your scene graph up more for better culling performance, and a existing modest number of scene graph nodes will give you scope to do this. > Large geometries are about 10 000 to 100 000 vertices. > All the instances have the same geometry (which is static), and the same > stateset. The data being shared and static makes things pretty easy. 100,000 vertices will comfortable sit on the graphics card, and VBO's would be able to handle it. The modest number of instances of this geometry would mean that the cost overhead of traversal and dispatch to OpenGL will be low so there is no need to resort to instances, it simply won't be required. The only thing you might want to look at is breaking up your geometries spatially to keep the vertex count a bit more modest and the geometry chunks smaller to aid view frustum culling. If you expect to see a big percentage of your geometries on screen at one time and this breaks frame then you should consider using LOD's to manage scene complexity. The other thing to look at is make your geometry efficient by using DrawElementsUShort/DrawElementUInt where possible, remove duplicate vertices's, tri-strip the geometry etc. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
