[osg-users] Slow optimization and OpenFlight

[Andreas Ekstrand]

Hi Robert,

Yes, the model is ineffective in the sense that it has 150 000 separate 
triangles on the same level in the scene graph, that's the nature of 
basic usage of OpenFlight and I guess that's why the plugin applies an 
optimization of its own. But this could be optimized and merged much 
faster before and I'm just looking for a way to get it to behave like 
that again, to keep my software from being slower in a new version.

Some results from VTune, where I have manually filtered and presented 
the top two culprits in 3.5.1 compared to 3.5.8 (where I gave up after 2 
minutes):

3.5.8: TOTAL: 121.4s

  * Registry::read -> Optimizer::optimize ->
    MergeGeometryVisitor::mergeGroup -> Group::removeChildren ->
    OpenThreads::Atomic::operator++ (78.5s)
  * Registry::read -> Optimizer::optimize ->
    MergeGeometryVisitor::mergeGroup -> Group::removeChildren ->
    OpenThreads::Atomic::operator-- (27.4s)

3.5.1: TOTAL: 12.7s

  * Registry::read -> Optimizer::optimize ->
    Optimizer::StateVisitor::optimize -> Node::setStateSet ->
    StateSet::~StateSet -> StateSet::clear ->
    StateAttribute::removeParent (2.4s)
  * Registry::read -> Optimizer::optimize ->
    Optimizer::MergeGeodesVisitor::mergeGeodes -> Node::~Node ->
    Node::setStateSet -> StateAttribute::removeParent (2.2s)

The MergeGeometryVisitor was applied in 3.5.1 as well but didn't take 
more than about 0.06s. I guess the 3.5.1 results are generally less 
interesting but at least they show that MergeGeometryVisitor was not a 
problem there.

I don't know if this gives you some ideas directly or if we need to keep 
digging. I will have another look shortly either way, but of course 
hoping for you or someone else to come up with some bright ideas to 
shorten the time to fixing this problem.

Regards,
Andreas


On 2017-11-19 16:28, Robert Osfield wrote:
> HI Andreas,
>
> I haven't had a chance to dig further.
>
> One curious thing I noticed is that when I enabled verbose debug
> output there was lots of buffer objects being created and destroyed
> during the optimisation step.  osg::Drawable now assigns
> VetextArrayState and VBO's by default for osg::Geometry - this is
> required to make VAO support possible.  The large number of these
> operations suggest lots of creation and merging of osg::Geometry for
> this dataset.  There is chance tthat this change alone may be causing
> a performance slow down.
>
> However, I don't think creation/deletion of osg::Geometry is the crux
> of the problem, and may not even be the optimization step - it could
> well be down to the nature of the scene graph being created by the
> OpenFlight plugin for this dataset.  I suspect the source data is
> stored in a way that is really inefficient to handle for real-time.
> It might be that the OpenFlight plugin just isn't handling the data
> well.
>
> As a general rule, running the Optimizer is a last resort for fixing
> really bad datasets, ideally datasets should be created in a form that
> is appropriate for decent performance right from the start.
>
> Robert.
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20171119/df5a24b8/attachment.html>