[osg-users] Slow down with shared nodes

Andre Normann andre.normann at gmail.com
Wed Mar 8 00:43:03 PST 2017 

Hi Robert,

I am using a GeForce 1080 and driver is 378.66. Windows 7 64Bit.

-André


2017-03-08 9:40 GMT+01:00 Andre Normann <andre.normann at gmail.com>:

> Hi Robert,
>
> hopefully I am getting closer. I find out, that the source model might be
> the problem. I exported an obj file from Bentley Microstation and imported
> into OpenSceneGraph. When I now export the scene into an osg file, I see a
> lot of PrimiteSets (e.g. > 1000). So I will end up with a lot calls to
> DrawElementsUShort. When I load the obj file into 3dsmax convert it into a
> fbx file and reexport it from OpenSceneGraph into an osg file, I have only
> one PrimitiveSet with one DrawArrays call. This file is working well in
> 3.4.0 with sharing nodes.
>
> So I guess there might be a problem with sharing osg::Geometry which has a
> lot of primitive sets. In 3.2.3 it was working well. What do you think?
>
> André
>
>
> 2017-03-08 8:59 GMT+01:00 Andre Normann <andre.normann at gmail.com>:
>
>> Hi Robert,
>>
>> when I use display lists instead of vertex buffer objects
>> (using osgUtil::GLObjectsVisitor), everything is fine with 3.4.0.
>>
>> André
>>
>>
>> 2017-03-08 8:40 GMT+01:00 Andre Normann <andre.normann at gmail.com>:
>>
>>> Hi Robert,
>>>
>>> attached you will find two screenshots while running in
>>> SingleThreaded-Mode. Using osgUtil::Optimizer does not make any big
>>> difference. I will try to create an example, so that you can test it on
>>> your computer.
>>>
>>> André
>>>
>>>
>>> 2017-03-07 18:10 GMT+01:00 Robert Osfield <robert.osfield at gmail.com>:
>>>
>>>> Hi André,
>>>>
>>>> Thanks for the screenshots.  They tells us it's the draw dispatch that
>>>> is gating performance, so the question now moves to why draw dispatch
>>>> is so slow in this case.
>>>>
>>>> Are you running the osgUtil::Optimizer on your scene graph?
>>>>
>>>> Could you run the tests with SingleThreaded threading model?
>>>>
>>>> There may be chance that a bug fix to the OSG somewhere has tightened
>>>> up the assumptions it makes about threading.  That's just a guess
>>>> though, there still is too few titbits of information to know what the
>>>> cause is.
>>>>
>>>> Robert.
>>>>
>>>>
>>>>
>>>> On 7 March 2017 at 16:40, Andre Normann <andre.normann at gmail.com>
>>>> wrote:
>>>> > Hi Robert,
>>>> >
>>>> > some more screenshots. This time without any other model.
>>>> >
>>>> > 3.2.3_1: My application using 3.2.3 and sharing nodes
>>>> > 3.4.0_1: My application using 3.4.0 and sharing nodes
>>>> > 3.4.0_2: My application using 3.4.0 without sharing nodes
>>>> >
>>>> > Best regards,
>>>> > André
>>>> >
>>>> >
>>>> > 2017-03-07 17:27 GMT+01:00 Andre Normann <andre.normann at gmail.com>:
>>>> >>
>>>> >> Hi Robert,
>>>> >>
>>>> >> I attached two screenshots. As you can see, I am doing nothing fancy
>>>> here.
>>>> >> There is a VirtualPlanetBuilder model present in the scene, but this
>>>> model
>>>> >> is hidden for my test case. The test scene contains only some
>>>> thousand
>>>> >> triangles and I am using a GeForce 1080 which can handle much more.
>>>> >> Currently I have no idea what is going wrong here.
>>>> >>
>>>> >> -André
>>>> >>
>>>> >>
>>>> >> 2017-03-07 11:33 GMT+01:00 Robert Osfield <robert.osfield at gmail.com
>>>> >:
>>>> >>>
>>>> >>> Hi André,
>>>> >>>
>>>> >>> I can't think of any changes between 3.2.x and 3.4.0 that would
>>>> cause
>>>> >>> a slow down like you are describing.
>>>> >>>
>>>> >>> The best way to start looking at what might be the cause would be to
>>>> >>> isolate what part of the application is the bottleneck, the first
>>>> step
>>>> >>> would be to use on the on screen stats and then look at the costs of
>>>> >>> the update, event, cull, draw dispatch and draw GPU phases.
>>>> >>>
>>>> >>> Also have a look at the full stats with to see if there is a
>>>> different
>>>> >>> number of nodes or state being rendered in the two cases.
>>>> >>>
>>>> >>> Robert.
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> On 7 March 2017 at 08:21, Andre Normann <andre.normann at gmail.com>
>>>> wrote:
>>>> >>> > Hi,
>>>> >>> >
>>>> >>> > I am currently migrating from OpenSceneGraph 3.2.3 to 3.4.0. In my
>>>> >>> > application I get a significant slow down, when I share nodes.
>>>> Here is
>>>> >>> > a
>>>> >>> > quick example layout of my scenegraph:
>>>> >>> >
>>>> >>> >
>>>> >>> > Parent
>>>> >>> >   |
>>>> >>> >   + ---> MatrixTransform1 --> Node1
>>>> >>> >   |
>>>> >>> >   + ---> MatrixTransform2 --> Node1
>>>> >>> >   |
>>>> >>> >   ...
>>>> >>> >   |
>>>> >>> >   + ---> MatrixTransform3 --> Node1
>>>> >>> >
>>>> >>> > I have a root node with several MatrixTransforms. The nodes below
>>>> the
>>>> >>> > MatrixTransforms are shared. In 3.2.3 everything works well and I
>>>> have
>>>> >>> > a
>>>> >>> > framerate of 60 Hz. In 3.4.0 the framerate drops with each new
>>>> added
>>>> >>> > MatrixTransform. But when I do not share the nodes and instead
>>>> create
>>>> >>> > clones
>>>> >>> > with a DEEP_COPY_ALL flag, everything is well in 3.4.0.
>>>> >>> >
>>>> >>> > So what could cause the slow down in 3.4.0 with node sharing?
>>>> >>> >
>>>> >>> > I am using OpenSceneGraph 3.2.3/3.4.0 with a release build on
>>>> Window 7.
>>>> >>> >
>>>> >>> >
>>>> >>> > Best regards,
>>>> >>> > André
>>>> >>> >
>>>> >>> >
>>>> >>> > _______________________________________________
>>>> >>> > osg-users mailing list
>>>> >>> > osg-users at lists.openscenegraph.org
>>>> >>> >
>>>> >>> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-opens
>>>> cenegraph.org
>>>> >>> >
>>>> >>> _______________________________________________
>>>> >>> osg-users mailing list
>>>> >>> osg-users at lists.openscenegraph.org
>>>> >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-opens
>>>> cenegraph.org
>>>> >>
>>>> >>
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > osg-users mailing list
>>>> > osg-users at lists.openscenegraph.org
>>>> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-opens
>>>> cenegraph.org
>>>> >
>>>> _______________________________________________
>>>> osg-users mailing list
>>>> osg-users at lists.openscenegraph.org
>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-opens
>>>> cenegraph.org
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20170308/07259a57/attachment-0003.htm>

More information about the osg-users mailing list