Best practices for dealing with complex scene graph

[AndrewC]

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 into one drawable would be much more efficient. osgUtil::Optimizer does not seem to do this for me, or am I missing something?

Andrew

[Armin Samii]

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: http://www.openscenegraph.org/index.php/documentation/user-guides/107-kdtrees

Or you can do this on your own, if you like, by grouping nearby nodes into their own osg::Group. Depends what your underlying data looks like.

I would not recommend combining the geometry into a single drawable unless you expect all of them to be visible at once, and that each piece of geometry is fairly small.

--
You received this message because you are subscribed to the Google Groups "OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osg-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osg-users/19df5325-01d5-4fa7-94d2-9c9560c92956%40googlegroups.com.

--

Armin Samii Visualization Software Engineer, Argo AI

CONFIDENTIALITY NOTICE: This e-mail and any files transmitted with it are confidential and designated solely for use of the individual(s) or entity to whom they are addressed. If you are not the named addressee, you are notified that disseminating, copying, disclosing or taking any action in reliance on its contents is strictly prohibited and could subject you to legal action by the sender. Please notify the sender immediately if you have received this e-mail in error and delete it from your system. Thanks for your cooperation.

[AndrewC]

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 geometrically, or the DOM might have a large number of simple objects.

A KD tree would be useful for removing "not visible" nodes, but in general they are all visible.

In "theory" the  whole scene graph geometry was flattened to one set of vertex, colors and normals for maximum efficiency - of course, updates to the scene graph would require this structure to be partially or fully rebuilt.

That's a bit of overkill for me, as I "know" the parent Group node in the scene graph that I want to make more efficient. Typically the objects under this node have the same attributes. 

I could flatten my nodes "manually", but flattening the scene graph seems a typical "use-case" that OSG users would want to do.

I have done some tests with osg::Optimizer with the MERGE_GEOMETRY option after collecting all the osg::Geometry nodes into a temporary group -  this does not do exactly what I want, as it only collects the osg::PrimitiveSets. Not merging the sets themselves.

Weirdly calling "optimize" also causes my scene graph to stop drawing for some unknown and very frustrating reason.

There is a lot of code in the OSG GLES plugin code that looks promising, but it's quite undocumented and I am having to guess about it's functionality.

Andrew

On Sunday, March 1, 2020 at 6:14:07 PM UTC-8, Armin Samii wrote:

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: http://www.openscenegraph.org/index.php/documentation/user-guides/107-kdtrees

Or you can do this on your own, if you like, by grouping nearby nodes into their own osg::Group. Depends what your underlying data looks like.

I would not recommend combining the geometry into a single drawable unless you expect all of them to be visible at once, and that each piece of geometry is fairly small.

On Sun, Mar 1, 2020 at 9:07 AM AndrewC <ad...@a-cunningham.com> wrote:

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 into one drawable would be much more efficient. osgUtil::Optimizer does not seem to do this for me, or am I missing something?

Andrew

--
You received this message because you are subscribed to the Google Groups "OpenSceneGraph Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to osg-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/osg-users/19df5325-01d5-4fa7-94d2-9c9560c92956%40googlegroups.com.

[AndrewC]

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 | osg::CopyOp::DEEP_COPY_ARRAYS) , then add them into a new osg::Group for the optimizer to work with.

- Use a osgUtil::MergeGeometryVisitor to collect all the primitive sets

- Then an osgUtil::IndexMeshVisitor to merge the primitive sets

[Chris Hanson]

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.

Like, sometimes the question is "how do I make my axe cut faster" but the real answer is "here, use a chainsaw instead".

On Mon, Mar 2, 2020 at 4:48 PM OpenSceneGraph Users <osg-...@lists.openscenegraph.org> wrote:

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 | osg::CopyOp::DEEP_COPY_ARRAYS) , then add them into a new osg::Group for the optimizer to work with.

- Use a osgUtil::MergeGeometryVisitor to collect all the primitive sets

- Then an osgUtil::IndexMeshVisitor to merge the primitive sets

On Sunday, March 1, 2020 at 9:07:42 AM UTC-8, AndrewC wrote:

--

You received this message because you are subscribed to the Google Groups "OpenSceneGraph Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to osg-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osg-users/81eebbe0-f14b-4aa4-9c09-8bed0152647b%40googlegroups.com.
_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

--

Chris 'Xenon' Hanson, omo sanza lettere. Xe...@AlphaPixel.com http://www.alphapixel.com/

Training • Consulting • Contracting

3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL

Legal/IP • Forensics • Imaging • UAVs • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile • iPhone/iPad/iOS • Android

@alphapixel facebook.com/alphapixel (775) 623-PIXL [7495]

[Robert Osfield]

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 index id.

If the geometries are very simple, such as can be represented by a sprite then using point sprites is a good way of scaling.

If you do go a batching route then the best way is batch by state and geographical position so each batch can use the same state and sit within a tight area so that culling is maximized.

Cheers,

Robert.