[osg-users] Best ways to render "FE" models with millions of tris and quads
robert.osfield at gmail.com
Tue Nov 17 01:07:18 PST 2009
For this type of task I would use VBO's and in conjunction with
DrawElementsUint() usage. Breaking up the model in to spatial zones
so that rather than having one very large osg::Geometry you have a
whole series of osg::Geometry each with a modest number of vertices -
I've found around 10,000 a pretty useful target of models with
millions of vertices on screen. The advantage of segmenting the model
in this way is that it aid view frustum culling and provides the
OpenGL driver and hardware the ability to manage the memory
asynchronously if and when it needs to copy the data.
W.r.t DrawElementUint() you may well find that just using single block
of DrawElementUint(GL_TRIANGLES) is sufficient, and the indices you'll
be able to map back to your original primitives.
On Mon, Nov 16, 2009 at 8:04 PM, Andrew Cunningham <osg at a-cunningham.com> wrote:
> I am struggling with the most efficient way to render "finite-element" models with the best speed/memory tradeoff. These models may have milllions of "nodes" and "elements" ( triangles and quads), with usually simple shading.
> I am replacing some custom OpenGL code (hard to maintain, not clean C++) with OSG ( easy to maintain, well written C++)
> For example, with one particular model, the old custom code which basically just held a vertex array and sent the primitives down the pipeline used about 650M of memory. The OSG version with no optimization of the primitives and using display lists used 1.3G of memory. Turning on optimization, and turning off display lists brought that down to 850M. Turning display lists back on, cost about 200M.
> The big problem with optimizing the geometry , is that one loses the ability to pick as all association of the primitive index with the original geometry is lost...
> Obviously there is always a memory/speed trade-off here, but perhaps someone has been this way before and has some best practices advice.
> Read this topic online here:
> osg-users mailing list
> osg-users at lists.openscenegraph.org
More information about the osg-users