Thanks Robert! Works fine here as well, and I think the line of least
resistance was the right way this time.
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...
/Andreas
On 2017-11-27 17:25, Robert Osfield wrote:
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.ekstr...@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.
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
