I have established it's the osgUtil::optimizeMesh(geometry); call in
the 3.6 obj plugin that is causing the slow down in .obj loading.
When writing the model out to .osgt without the optimization you can
see the likely reason why this dataset might be triggering issues:
PrimitiveSetList 265486 {
osg::DrawArrays {
UniqueID 6
Mode TRIANGLE_FAN
Count 4
}
osg::DrawArrays {
UniqueID 7
Mode TRIANGLE_FAN
First 4
Count 4
}
..
So we have 265 thousand triangle fan DrawArrays that loader has
created. That's about as inefficient as you can get as it not only is
using lots separate primitives but also implies that non of the vertex
data is being shared either.
I'm not the author of the obj plugin so can't immediately pinpoint
what bit of code is responsible for creating this poorly structured
dataset. The .obj format presents the individual primitives one by
one so is the root cause of this, but the loader should probably not
be happing this verbatim.
At this point I don't have a clear suggestion of solution, I'm
inclined to think that the plugin shouldn't load the data verbatim as
it's doing right now, then trying to fix the problems this causes
after the fact.
Robert.
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
