Re: [osg-users] Slow optimization and OpenFlight
Forgot to mention that the geometry before and after optimization is identical in the different OSG versions, so the optimizer accomplishes the same thing, it just takes about 10 times longer. /Andreas On 2017-11-24 14:10, Andreas Ekstrand wrote: Hi, Some more results from my investigations: 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. The removeChild call from MergeGeometryVisitor ::mergeGroup is the main culprit and takes about 87% of the time: group.removeChild(*ditr); 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! Regards, Andreas On 2017-11-19 17:13, Andreas Ekstrand wrote: Hi Robert, 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. 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): 3.5.8: TOTAL: 121.4s * Registry::read -> Optimizer::optimize -> MergeGeometryVisitor::mergeGroup -> Group::removeChildren -> OpenThreads::Atomic::operator++ (78.5s) * Registry::read -> Optimizer::optimize -> MergeGeometryVisitor::mergeGroup -> Group::removeChildren -> OpenThreads::Atomic::operator-- (27.4s) 3.5.1: TOTAL: 12.7s * Registry::read -> Optimizer::optimize -> Optimizer::StateVisitor::optimize -> Node::setStateSet -> StateSet::~StateSet -> StateSet::clear -> StateAttribute::removeParent (2.4s) * Registry::read -> Optimizer::optimize -> Optimizer::MergeGeodesVisitor::mergeGeodes -> Node::~Node -> Node::setStateSet -> StateAttribute::removeParent (2.2s) 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. 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. Regards, Andreas On 2017-11-19 16:28, Robert Osfield wrote: 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 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 ___ 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
Re: [osg-users] Slow optimization and OpenFlight
Hi, Some more results from my investigations: 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. The removeChild call from MergeGeometryVisitor ::mergeGroup is the main culprit and takes about 87% of the time: group.removeChild(*ditr); 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! Regards, Andreas On 2017-11-19 17:13, Andreas Ekstrand wrote: Hi Robert, 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. 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): 3.5.8: TOTAL: 121.4s * Registry::read -> Optimizer::optimize -> MergeGeometryVisitor::mergeGroup -> Group::removeChildren -> OpenThreads::Atomic::operator++ (78.5s) * Registry::read -> Optimizer::optimize -> MergeGeometryVisitor::mergeGroup -> Group::removeChildren -> OpenThreads::Atomic::operator-- (27.4s) 3.5.1: TOTAL: 12.7s * Registry::read -> Optimizer::optimize -> Optimizer::StateVisitor::optimize -> Node::setStateSet -> StateSet::~StateSet -> StateSet::clear -> StateAttribute::removeParent (2.4s) * Registry::read -> Optimizer::optimize -> Optimizer::MergeGeodesVisitor::mergeGeodes -> Node::~Node -> Node::setStateSet -> StateAttribute::removeParent (2.2s) 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. 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. Regards, Andreas On 2017-11-19 16:28, Robert Osfield wrote: 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 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] load a osg model with rigged animation (exported by 3dsmax)
Nice that it works. Thanks for the feedback. Cheers Raymond On 24/11/2017 13:50, Andrea Martini wrote: Hi to all, it seems that the problem is caused by 3DSmax exporter (both fbx and osgt). I used the blender exporter (fbx) and i was able to load animation. Thank you! Cheers, Andrea -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72449#72449 ___ 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
Re: [osg-users] load a osg model with rigged animation (exported by 3dsmax)
Hi to all, it seems that the problem is caused by 3DSmax exporter (both fbx and osgt). I used the blender exporter (fbx) and i was able to load animation. Thank you! Cheers, Andrea -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72449#72449 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] load a osg model with rigged animation (exported by 3dsmax)
Hi, Not knowing the details of your model and how it is setup, it is hard/impossible to make other suggestions. I do know that the fbx format does support skinned models and that the osg fbx plugin can load and render them properly. Fbx supports a lot of combinations so I suggest to look into details of the code and not only do quick tests with some standard examples. For specific solutions/in-depth help about specific models, it is best to contact me directly. Cheers, Raymond On 24/11/2017 12:47, Andrea Martini wrote: Hi Raymond, unfortunally also with fbx file, animationManager used in osganimationhardware is null. About step : 3DSMax→Blender→osgexport both with 3ds and fbx to blender, model appears very different from the original (mesh and controllers). Does exist other test that i should try? Thank you Andrea -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72447#72447 ___ 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
Re: [osg-users] load a osg model with rigged animation (exported by 3dsmax)
Hi Raymond, unfortunally also with fbx file, animationManager used in osganimationhardware is null. About step : 3DSMax→Blender→osgexport both with 3ds and fbx to blender, model appears very different from the original (mesh and controllers). Does exist other test that i should try? Thank you Andrea -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72447#72447 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] load a osg model with rigged animation (exported by 3dsmax)
Hi Andrea, I second Alberto's suggestion to use fbx when working with 3dsmax. Latest OSG versions are finding the latest FBX SDK versions correctly and the fbx plugin is built properly. At least, I can confirm this for Visual Studio on Windows. You did not write details about your code and therefore we can give you high level tips and tricks. Did you start with the example osganimationhardware? Cheers, Raymond On 24/11/2017 11:10, Alberto Luaces wrote: Hi Andrea, OSG is capable of that, but here the export plugin is likely to be blamed, since as you describe it is exporting the armature as a regular object. You can inspect the osgt file with any text editor to check that. Other users have reported to work with the FBX format. You could also take one more step, 3DSMax→Blender→osgexport and see if it fits your usage. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
