Re: [osg-users] Best practices for dealing with complex scene graph

Hi Andrew, How best to go about this type of task will depend upon what exactly is being rendered and how it's updated if ever. If the geometries are all the same then you could use geometry instancing combined with a Uniform Array or a Texture2DArray to store data that is indexed via the

Re: [osg-users] Best practices for dealing with complex scene graph

I think if you could describe more of your problem domain, we might have better suggestions. Like, what do all of these geometries actually represent? I know you're trying to generalize the problem, but sometimes knowing the specifics of the problem allows us to make domain-specific suggestions.

Re: [osg-users] Best practices for dealing with complex scene graph

I think if you could describe more of your problem domain, we might have better suggestions. Like, what do all of these geometries actually represent? I know you're trying to generalize the problem, but sometimes knowing the specifics of the problem allows us to make domain-specific suggestions.

Re: [osg-users] Best practices for dealing with complex scene graph

I found a reasonably good generic solution to flatten any part of my scene graph. - Use a visitor pattern to collect all my osg::Geometry into a set of geometries starting at the osg::Group in question - do a clone of the geometries into a new set with (osg::CopyOp::DEEP_COPY_PRIMITIVES |

Re: [osg-users] Best practices for dealing with complex scene graph

Hi Armin, Essentially the scene graph is a one-for-one representation of my DOM. Each individual object can be edited, or its attributes changed. The DOM can be a small number of geometrically "complex" objects - this causes no performance problems as the geometry "leafs" are large

Re: [osg-users] Best practices for dealing with complex scene graph

Iterating over the 5000 children would be pretty slow - what if you could discard some of these children without even looking at them? A hierarchy of sorts, where you can ignore large swaths of those children, would help... Consider, for example, using a k-d tree:

[osg-users] Best practices for dealing with complex scene graph

Hi, I was wondering what the best practices are for dealing with a complex scene graph where a single osg::Group might have , say, 5000 children where each child is fairly simple osg::Geom geometry. Clearly, this is inefficient and draws slowly. So obviously, compiling/collecting the geometry