[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]

Hi,

The models I build and use are mainly jpeg UV textured obj files that have been osgconv'd into an ive. I have built OpenSceneGraph versions 3.6.0, 1 and 2, and they all display this issue on BOTH windows (10) and Linux (CentOS 7). Note that I also built the OSG 3.4.1

The issue is that I can open a model in osgviewer in 3.4.1 and the model loads in the window very, very fast. When I run osgviewer in 3.6.x, it is taking ~10 times longer to load the exact same model (somtimes 15+ seconds).

This is a major issue in the program I build that loads many, many different models.

Thanks for any help!
James

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

[L. Voerman]

Hi James,
Just a guess,
could the 3.4.1 version be using jpeg-turbo
<https://github.com/libjpeg-turbo/libjpeg-turbo> - while the other version
uses libjpeg?
Laurens.

Post by James Davis
Hi,
The models I build and use are mainly jpeg UV textured obj files that have
been osgconv'd into an ive. I have built OpenSceneGraph versions 3.6.0,
1 and 2, and they all display this issue on BOTH windows (10) and Linux
(CentOS 7). Note that I also built the OSG 3.4.1
The issue is that I can open a model in osgviewer in 3.4.1 and the model
loads in the window very, very fast. When I run osgviewer in 3.6.x, it is
taking ~10 times longer to load the exact same model (somtimes 15+ seconds).
This is a major issue in the program I build that loads many, many different models.
Thanks for any help!
James
------------------
http://forum.openscenegraph.org/viewtopic.php?p=74260#74260
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[James Davis]

Good guess, however, I'm linking both 3.4.1 and 3.6.x to the same 3rdParty libs.

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

[James Davis]

The image file the .obj and .ive converted uses is a .png

I did verify and both 3.4.1 and 3.6.x are linking to the x64\lib\libpng16.lib. But, perhaps this is a clue?

I'm doing some further investigating on a test model.

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

[James Davis]

Ok...did a little testing and found that loading speed does NOT depend on image textures.

I created a test plane and subdivided it to make many faces and extruded every other one to give it a little depth. The face count of my plane is ~43k faces. I UV textured the sample plane with a jpeg, one with a png, and one with no image. I converted each to a .obj. The no-image had about the same poor performance in loading as with the jpeg or png. Note that loading time doesn't matter if I convert to a osg or ive first and then load.

So, for some reason, OSG 3.6.x is taking a lot longer loading a higher faced/vert count .obj (or osg or ive) object than 3.4.1. This is a show stopper for my customer, and I'll have to stick with 3.4.1 until something is figured out.

Suggestions? Thoughts? Are there any optimization switches I've missed that was not default before building the 3.6.x series?

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

[L. Voerman]

Hi James,
I tried to replicate your problem, but fail to do so.
I tried this on a 110 MB .ive file (~3M vertices)

set OSG_OPIMIZER=OFF
SET OSG_NOTIFY_LEVEL=INFO
osgconv "testfile.ive" dummy.jpg | grep "Time to load"

results with osg 3.4.2: 95, 95, 92, 93 ms (win10 / visual studio 2015
Update 3)
results with osg 3.6.2: 92, 92, 93, 93 ms (win10 / visual studio 2017
15.7.4)

Can you see if your problem can be measured this way?
Regards, Laurens.

Post by James Davis
Ok...did a little testing and found that loading speed does NOT depend on image textures.
I created a test plane and subdivided it to make many faces and extruded
every other one to give it a little depth. The face count of my plane is
~43k faces. I UV textured the sample plane with a jpeg, one with a png,
and one with no image. I converted each to a .obj. The no-image had
about the same poor performance in loading as with the jpeg or png. Note
that loading time doesn't matter if I convert to a osg or ive first and
then load.
So, for some reason, OSG 3.6.x is taking a lot longer loading a higher
faced/vert count .obj (or osg or ive) object than 3.4.1. This is a show
stopper for my customer, and I'll have to stick with 3.4.1 until something
is figured out.
Suggestions? Thoughts? Are there any optimization switches I've missed
that was not default before building the 3.6.x series?
------------------
http://forum.openscenegraph.org/viewtopic.php?p=74266#74266
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Robert Osfield]

Hi James,

The file was too big to distribute on the osg-users mailing list that
mirrors the forum so I pulled down the data from the forum and can see
the loading performance issue when using OpenSceneGraph-3.6.2:

$ time osgconv SquareTest.obj test.osgb
Data written to 'test.osgb'.

real 5m2.443s
user 5m2.352s
sys 0m0.068s

The resulting test.osgb loads quickly and runs fine.

I will do a build of the OSG-3.4 branch and see what happens.

Robert.

[Robert Osfield]

Now tested the model with 3.4 - much faster:

$ time osgconv SquareTest.obj test_34.osgb
Data written to 'test_34.osgb'.

real 0m3.842s
user 0m3.112s
sys 0m0.728s

I've looked at the diffs between 3.4 and 3.6 for the obj plugin, the
only difference that stands out as a possible cause is the use of mesh
optimzer instead of the tri strip visitor. Mesh optimizer works much
better for modern graphics cards, I wouldn't have expected such a slow
down though, there must be something in the presentation of this
particular dataset that is cause issues.

Robert.

[Robert Osfield]

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.

[Robert Osfield]

I have other tasks to get on with today so I won't keep pursing this
loading speed regression right away, if others want to look at before
I come back to it then the way I think it should be tackled is be
changing the loader to so it creates a small set of primitives using
GL_TRIANGLES rather than many separate DrawArrays GL_TRIANGLE_FAN.

Robert.