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

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

On Thu, Jul 5, 2018 at 8:49 PM James Davis <davisjamesf at gmail.com> wrote:

> 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
>
>
>
>
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20180706/4fe23cb3/attachment.html>