[osg-users] Model(s) load ~10 times longer in 3.6.x than 3.4.x series in osgviewer (and my in-house software)

[James Davis]

I wanted to see if anyone had a chance to come up with some test code I might could try out. Sorry if I sound like I'm nagging. :?

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74363#74363

[Robert Osfield]

Post by James Davis
I wanted to see if anyone had a chance to come up with some test code I might could try out. Sorry if I sound like I'm nagging. :?

I haven't personally looked at the code since I last replied. Perhaps
others have.

You have full access to the source code so no need to wait on others,
you can dive in a make ammendments, if they are sound then I'd be
happy to review and merge them in appropriate.

As a general note, till the end of August my main focus is on the
Vulkan Exploration Phase, I did a major push on OSG bug fixes for
3.6.2 and for the time being will be taking a back seat on non
critical OSG bugs.

Cheers,
Robert.

[James Davis]

After changing two files, I have ive files loading very fast AND osgconv converting obj files to osg and ive files very fast.

You'll have to forgive my lack of understanding a lot of the internals of OSG. The code I changed was due to noticing where bottle necks (for loops) were occurring when loading .ive files in my program. Once I changed the code and created new libraries, I tested them on the osgconv with speed success.

The code I changed was NOT in the obj plugin but in the osg library itself. I changed a few lines to previous changes compared to 3.4.1. Note that I did attempt at trying to use the 3.4.1 obj plugin, but quickly found it was not the problem.

The two files I changed were Geometry.cpp and Drawable.cpp, and I'll need some help understanding why my changes really made a difference.

When I would 'break' in my debugger when loading an ive file, most of the time the process ended up on a for loop in Geometry.cpp (line 582) in the getOrCreateElementBufferObject method. The callstack was Geometry::read, Geometry::addPrimitiveSet, Geometry::addElementBufferObjectRequired.

I decided to make the change line 28 to #if 1 and add back all the if conditions of _useVertexBufferObjects. This fixed the load .ive issue but still did not fix the osgconv. I had to change Drawable.cpp line 229 to #if 1 to make _userVertecBufferObjects = false.

Can someone take a look at the impact _useVertexBufferObjects has on certain files being loaded. It seems a check needs to be before the for loop of traversing through the drawElementList if it really doesn't need to be called.

Thanks!

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74366#74366

[Robert Osfield]

Hi James,

The checks are needed in Geometry,cpp and Drawable.cpp, if you've
changed these you will likely be breaking something else. You might
not be see any issues yet, and might not ever, but as I don't know
exactly what you've changed I can't say. All I can say it's not
really fixing the problem, it's fixing a symptom and likely to have
un-intended consequences.

As I said previous the problem is the obj plugin loading meshes with a
single triangle per PrimitiveSet. This is the absolutely worst/least
efficient way to create a mesh in the OSG and OpenGL. If you want an
example of how not to do things this would be a classic example.
Expecting the OSG to patch up a bad scene graph after it's been
creating is only hiding where the problem is.

Trust me, the problem is the obj plugin, this needs fixing.

Robert.

Post by James Davis
After changing two files, I have ive files loading very fast AND osgconv converting obj files to osg and ive files very fast.
You'll have to forgive my lack of understanding a lot of the internals of OSG. The code I changed was due to noticing where bottle necks (for loops) were occurring when loading .ive files in my program. Once I changed the code and created new libraries, I tested them on the osgconv with speed success.
The code I changed was NOT in the obj plugin but in the osg library itself. I changed a few lines to previous changes compared to 3.4.1. Note that I did attempt at trying to use the 3.4.1 obj plugin, but quickly found it was not the problem.
The two files I changed were Geometry.cpp and Drawable.cpp, and I'll need some help understanding why my changes really made a difference.
When I would 'break' in my debugger when loading an ive file, most of the time the process ended up on a for loop in Geometry.cpp (line 582) in the getOrCreateElementBufferObject method. The callstack was Geometry::read, Geometry::addPrimitiveSet, Geometry::addElementBufferObjectRequired.
I decided to make the change line 28 to #if 1 and add back all the if conditions of _useVertexBufferObjects. This fixed the load .ive issue but still did not fix the osgconv. I had to change Drawable.cpp line 229 to #if 1 to make _userVertecBufferObjects = false.
Can someone take a look at the impact _useVertexBufferObjects has on certain files being loaded. It seems a check needs to be before the for loop of traversing through the drawElementList if it really doesn't need to be called.
Thanks!
------------------
http://forum.openscenegraph.org/viewtopic.php?p=74366#74366
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[James Davis]

Thanks Robert,

I suppose my confusion comes from the original issue I was seeing... the very slow loading of ive and osg files (even though obj's are slow too)

So.....When osgconv creates an ive and/or osg formats from a obj, does the obj information remain wrapped up in the ive/osg formats and the obj plugin still used when loading? That would make sense that the obj plugin is the problem when loading.

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74369#74369

[Robert Osfield]

Hi James,

Post by James Davis
I suppose my confusion comes from the original issue I was seeing... the very slow loading of ive and osg files (even though obj's are slow too)
So.....When osgconv creates an ive and/or osg formats from a obj, does the obj information remain wrapped up in the ive/osg formats and the obj plugin still used when loading? That would make sense that the obj plugin is the problem when loading.

The obj plugin is creating an osg::Geometry with a separate
PrimitiveSet per triangle, once it's created this monster of a scene
graph it pollutes whatever else touches it. It's technically is a
valid scene graph, the OSG won't fail to load and save it or render
it, but you should expect such a scene graph to be inefficient. You
can fix it with optimizers but this is trying to put the horse back in
the stable once it's bolted.

As I said already several times, the problems stems from the obj
plugin, this is where the fix needs to be made.

Robert.