<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Thanks Robert! Works fine here as well, and I think the line of
least resistance was the right way this time.<br>
<br>
Any plans on a 3.5.9 release soon? I'm now facing the problem of
either waiting until the next release, or basing my software on
3.5.8 with this modification and thus implicitly recommending users
to use 3.5.8 to be compatible but with the implication that their
OpenFlight models might be load slowly...<br>
<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-27 17:25, Robert Osfield
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAFN7Y+Ujzn=Ka6LGnGss8a1ddK3zpo3+sftiBFR4URDLeM6jOA@mail.gmail.com">
<pre wrap="">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
<a class="moz-txt-link-rfc2396E" href="mailto:andreas.ekstrand@remograph.com"><andreas.ekstrand@remograph.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">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!
</pre>
</blockquote>
<pre wrap="">The fix I have checked in master:
<a class="moz-txt-link-freetext" href="https://github.com/openscenegraph/OpenSceneGraph/commit/bc4a9d9dd0158e1e99d0ca1d1d95ef204220a560">https://github.com/openscenegraph/OpenSceneGraph/commit/bc4a9d9dd0158e1e99d0ca1d1d95ef204220a560</a>
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.
_______________________________________________
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>