[osg-users] Slow optimization and OpenFlight

[Robert Osfield]

Hi Andreas,

I have checked in a refactor of MergeGeometry visitor that makes it
work properly with groups containing any type of nodes, and avoids the
O(N^2) removChild() usage.  In the end I took the line of least
resistance and just used the approach of removing all children and
adding back the ndoes.

On 27 November 2017 at 15:56, Andreas Ekstrand
<andreas.ekstrand at remograph.com> wrote:
> Yes, you can argue that the dataset is awful, but it's actually just storing
> 150k triangles on one graph level, as separate OpenFlight face records,
> which is what the OpenFlight file format offers if you don't use its
> specific mesh nodes that aren't supported by all tools and don't offer full
> control of each triangle. OpenFlight is a modeling file format which is
> surely not visualization-friendly. I think the OpenFlight plugin simply uses
> the Optimizer to convert this to a dataset for effective visualization
> instead of converting to a more optimal scene graph to start with - a choice
> that I can't really say if it's good or bad, but the Optimizer should of
> course handle bad data in the best way possible.

No need to argue whether it's awful or not, there isn't any debate
when it comes to real-time performance : this particular database is
stored in the worst possible way for memory utilization and
performance

Use of the osgUtil::Optimizer is a very crude fix for bad databases.
It's far better to just create a scene graph in an efficient form
right from the start.  Optimizing bad databases at best leads to
fragment memory, it really is just papering over cracks and is
unlikely to ever produce optimal databases.


> The main issue for me though, is that OSG handles this dataset in a much
> slower way than before, hence my re-introduction of the previous
> optimization. But you're completely right, and I realize now, that other
> nodes than drawables aren't handle correctly. I haven't gotten used to
> drawables being nodes yet...
>
> So the fact that the OpenFlight plugin creates a non-optimal scene graph and
> then uses the Optimizer itself to fix this is probably a separate and larger
> problem - if it indeed is a problem.

Yep, big topic.  I'm familiar with the problems that the OpenFlight
loader generates, but less so with Creator or other tools that
generate the content.  I'd much rather the OpenFlight loader builds
more efficient database to start with rather than rely upon the
Optimizer to fix problems once the data is loaded.

> But I believe it's necessary to at
> least get MergeGeometryVisitor to behave as fast as before, either by
> modifying my fixes or by rewriting parts of it. I hope you will find the
> time to decide on this soon, and please let me know if I can help!

The fix I have checked in master:

    https://github.com/openscenegraph/OpenSceneGraph/commit/bc4a9d9dd0158e1e99d0ca1d1d95ef204220a560

With performance testing of just the merge geometry on your house
dataset I saw a 70sec merge geometry before, and 0.1 sec merge after
my changes.

I've got plenty of other stuff to get on with so I'll assume this
issue is now resolved.

Cheers,
Robert.