Thanks for your suggestions Robert. I'm afraid we don't all have to time to write treaties on the topics > of performance optimization - it's a huge topic. >
Don't worry, I'm aware of that. Still I could give it a try and see if some knowledgeable folks could find time. Yet I guess the conclusion is clearly : they don't ;-). 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. > > 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. > Ok, I'll try it > > 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. In my case most of the geometries will be seen entirely. So I guess this won't help a lot. > 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. > Yes LODs should be a solution. Though I'm working on a research project in another field than graphics and I was looking forward something easier to settle. Actually I tried at some point to simplify the geometries (using osg::Simplifier) and used the results as low level LOD but it was destroying the visual aspect of the geometries. Then I gave up this track. > > 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. > I'll see if I can do that. Thanks a lot Robert. Loïc
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
