<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi,<br>
<br>
Some more results from my investigations:<br>
<br>
Back in February, the MergeGeometryVisitor was changed to be applied
on Group instead of Geode by Jannik Heller (in CC). This has
resulted in substantially longer optimization time of my loaded
OpenFlight files with a large number of polygons. I assume it's a
general performance problem with many geodes/geometries.<br>
<br>
The removeChild call from MergeGeometryVisitor ::mergeGroup is the
main culprit and takes about 87% of the time:<br>
group.removeChild(*ditr);<br>
<br>
Does Robert or Jannik have any idea about this? I don't feel
comfortable enough with the code to make any changes, but this
prevents me from upgrading my software to the latest OSG version,
while I can't go back either since I need other fixes in 3.5.8. So
I'm a bit stuck and would appreciate any help!<br>
<br>
Regards,<br>
Andreas<font size="2" color="black"><span
style="font-size:0.8em;color:black"><br>
<br>
</span></font><font size="2" color="black"><span
style="font-size:0.8em;color:black"></span></font>
<div class="moz-signature"><font size="2" color="black"><span
style="font-size:0.8em;color:black"><br>
</span></font>
</div>
<div class="moz-cite-prefix">On 2017-11-19 17:13, Andreas Ekstrand
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:65935751-a1e5-008d-177f-07aeb1f67e53@remograph.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
Hi Robert,<br>
<br>
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.<br>
<br>
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):<br>
<tt><br>
3.5.8: TOTAL: 121.4s<br>
</tt>
<ul>
<li><tt>Registry::read -> Optimizer::optimize ->
MergeGeometryVisitor::mergeGroup -> Group::removeChildren
-> OpenThreads::Atomic::operator++ (78.5s)</tt></li>
<li><tt>Registry::read -> Optimizer::optimize ->
MergeGeometryVisitor::mergeGroup -> Group::removeChildren
-> OpenThreads::Atomic::operator-- (27.4s)</tt></li>
</ul>
<tt>3.5.1: TOTAL: 12.7s<br>
</tt>
<ul>
<li><tt>Registry::read -> Optimizer::optimize ->
Optimizer::StateVisitor::optimize -> Node::setStateSet
-> StateSet::~StateSet -> StateSet::clear ->
StateAttribute::removeParent (2.4s)</tt></li>
<li><tt>Registry::read -> Optimizer::optimize ->
Optimizer::MergeGeodesVisitor::mergeGeodes -> Node::~Node
-> Node::setStateSet -> StateAttribute::removeParent
(2.2s)</tt></li>
</ul>
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.<br>
<br>
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.<br>
<br>
Regards,<br>
Andreas<font size="2" color="black"><span
style="font-size:0.8em;color:black"><br>
<br>
</span></font><font size="2" color="black"><span
style="font-size:0.8em;color:black"></span></font>
<div class="moz-signature"><font size="2" color="black"><span
style="font-size:0.8em;color:black"><br>
</span></font> </div>
<div class="moz-cite-prefix">On 2017-11-19 16:28, Robert Osfield
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAFN7Y+VZf3Fy9gD0KnudHv7on4EaSYQBfvztWaQ1SHEnfY+hGQ@mail.gmail.com">
<pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:osg-users@lists.openscenegraph.org" moz-do-not-send="true">osg-users@lists.openscenegraph.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" moz-do-not-send="true">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
osg-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.openscenegraph.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a>
</pre>
</blockquote>
<br>
</body>
</html>