[osg-users] Best Practices and Switches

[Robert Osfield]

Hi David,

On Tue, 30 Apr 2019 at 20:52, David Heitbrink <david-heitbrink at uiowa.edu> wrote:
> In general my CPU load is pretty good, what I am really concerned about is reducing the number of OpenGL calls/driver overhead. If I have 200 signs all under there own switch, each sign is only 4-64 triangles each, and all the signs share the same texture mosaic.  Having 200 unique drawls can get expensive, especially for such a low poly objects. Ideally the 200 street signs would get combined in the same draw object. My assumption was this cannot happen with each sign being under its own switch.

Yes, you can't combine geometries and have primitives within them
controlled by a switch node.


> My second question is 2 part, if I remove the switches, would I want to then export the result to a file and reload the file run, then run the optimizer. Or would the performance of the optimizer be all the same if I ran it on a graph that I had just programmatically removed the switches from. I am basically concerned with running into "nodeWeCannotRemove".
>
> Also, the second part is......what criteria does the MERGE_GEOMETRY option use to merge geometry.

It's long enough ago that I worked on this area that I can't recall
off the top of my head.  The only way for me to answer definitively it
would be to review the code, which you can also do :-)

As a general note, the osgUtil::Optimizer classes attempt to fix
issues that commonly appear in loaded scenes, it's not perfect, or
even the best optimization that you can do, it's an imperfect scheme
for fixing even less perfect databases.  Think of the Optimizer as
trying to catch and tame a horse that has already bolted from the
stable.

It's far better to build efficient scene graphs from the start and not
use the Optimzer at all.   For your particular usage case it may be
best to write your own classes to analyze the scene graph and decide
what to do about them.  It might even be that you'd want to write a
custom osg::Drawable, or subclass from osg::Geometry to implement a
scheme where all the signs are in a single custom Drawable/Geometry
object which has a renders each sign as a separate PrimitiveSet (which
represents a quad) then in the drawImplementation() you step through
the PrimitiveSet deciding which ones to dispatch to OpenGL or not.
Such as scheme would be lighter weight than having lots of switches
and separate geometries.

Robert.