[osg-users] Best ways to render "FE" models with millions of tris and quads
aburnettthompson at googlemail.com
Mon Nov 16 12:38:18 PST 2009
>From my (short) experience with OSG, to reduce memory consumption, get the
number of vertices down (Optimise geometry using TRI_STRIP), share state
sets (or just use vertex colours for shading) and as you said turn off
display lists. Also reduce (or remove) Transform nodes.
As for optimisation, yes you say that you will lose the ability to pick a
primitive, but could you perhaps write your own picking IntersectionVisitor
that first picks by Geode, then drills down into the triangle and updates
the vertex colours just for that tri?
Take a look at IntersectionVisitor, SmoothingVisitor, TriangleFunctor as
these deal with triangle-level geometry.
Hope that is helpful,
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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the osg-users