[osg-users] Slow optimization and OpenFlight

[Andreas Ekstrand]

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.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.
> _______________________________________________
> 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/20171127/60723b3c/attachment.html>