Hi John, Modern hardware generally is best driven with a modest number of quite large batches of geometry, rather than a large number of small batches of geometry. Exactly where the balance will lie with your database will depend upon your hardware and drivers, and also how efficiently you are setting up your scene graph and passing of geometry to OpenGL.
Some general notes, try for a quad tree structure to your scene graph, a single flat osg::Geode containing all your geometry is BAD for performance as the OSG isn't able to cull efficiently. Also use large tiles, 17x17 vertices is smaller than what is likely to be most efficient. I can't say too much more as I really don't know enough about your "terrain engine". I would also add that the OSG has tools for doing paged databases that are well balanced for modern hardware and can happily scale up to handling whole earth terrabyte databases at 60Hz. It may well be that you don't need your own terrain engine as the OSG already has very scalable support already built in. Robert. On Sat, Sep 24, 2011 at 8:16 AM, John Water <akin...@hotmail.com> wrote: > Hi, all > > maybe this is a old topic , but I can't find answer in lots of forum, so I > have to ask for help . > > I write a terrain engine mostly like interlocking terrain; there are 32x32 > tiles for whole terrain, and 17x17 vertexs for one tile. every tile has one > vertexarray, I use osg to realize it. > > all terrain is treated as one geode. and one drawable represents one tile.so > I have one geode, and 1024 drawables.( I'm not sure if the structure is good > ). but I met problem now: > > when see terrain on the fly,(all tiles are show in eye-views), the draw time > is much more than on the ground(a few tiles are show); ofcourse, it should be > certainly because of culling. now I want to reduce draw time on the fly. I > think that maybe more draw calls make draw time high because one tile > represent one drawable(one draw call, is that right?). and more worse: tile > is dealed by LOD. > > when tile' lod level is lowest, it only has few vertices and indices, it > could be very inefficient when one draw call only for the tile under the > situation. should I batch several tile' vertexs into vertexarray?? but what > to do this in osg-node-system, and it should be influence to culling?? > > anyone can explain how to do banlance between batch and cull in tiled terrain > system ? thianks in advance. > > of course, it 's my thought about high draw time on the fly is because more > draw calls( i'm not sure if 32x32=1024 draw calls are high?). my another > thought about bad performance on the fly is that my lod tile'vertexarry is > big. I don't design: > > lod3 vertexarray3 indicearray3 > lod2 vertexarray2 indicearray2 > lod1 vertexarray1 indicearray1 > ( numbers of vertexarray: vertexarray3>vertexarray2>vertexarry1, decrease by > lod level), > > I design simply: > lod3 vertexarry indicearry3 > lod2 vertexarry indicearry2 > lod1 vertexarry indicearry1 > > every tile in different lod level has same vertexarray( most high vertex > varry), it make me only dirty inidices varray every frame, but even if in > lowest lod level, draw call still send lots of vertices(is that right?). > > now I'm not sure what real reason make high draw time on the fly view? > 1: more draw calls in one frame > 2. more vertices transfer in one frame > > anybody help, very appreciate! > > thanks again. > > > > > > Thank you! > > Cheers, > John > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=42990#42990 > > > > > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
