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 <[email protected]> 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 [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
