[osg-users] Fwd: Slow down with shared nodes

Andre Normann andre.normann at gmail.com
Thu Mar 9 00:19:16 PST 2017


Hi,

just one more remark. I have testet the model with the current master
version. Everything is working well.

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

> Hi Robert,
>
> thanks for your help. I think the problem is the obj loader. I have done a
> quick review of the source code and the loader seems to create for each "f"
> line an own primitive set. This can be optimized. I will try to fix this in
> near future.
>
> I can not understand the difference between 3.2.3 and 3.4.0 on my
> computer. Maybe indeed a driver problem. For now I have a working solution.
>
>
>
> 2017-03-08 15:35 GMT+01:00 Christian Buchner <christian.buchner at gmail.com>
> :
>
>> I've recently written some code to merge individual triangle strips
>> by joining them using some degenerate (zero area) triangles.
>>
>> One issue that I've run into is that in wireframe mode this generated
>> some very odd looking artifacts.
>>
>> Find the code here. It may need some adaptation for your use case.
>> http://forum.openscenegraph.org/viewtopic.php?t=16412
>>
>> Christian
>>
>>
>> 2017-03-08 15:32 GMT+01:00 Robert Osfield <robert.osfield at gmail.com>:
>>
>>> Hi Andre,
>>>
>>> Thanks for the file.  I've just tried it on my Kubuntu 16.04. NVidia
>>> 760 with the OSG-3.4 branch and I see decent performance, the draw
>>> dispatch is bit more expensive than I'd usually expect for a model of
>>> this size but it's not widely expensive like you are seeing.
>>>
>>> The dataset itself looks like the large number of PrimitiveSets is
>>> very high for the number of vertices in each osg::Geometry.  The use
>>> of very short triangle strips rather than a single DrawElementsUShort
>>> GL_TRIANGLES is the core of what is wrong with how the osg::Geometry
>>> have been generated.
>>>
>>> The source of this issue may be down to the .obj or perhaps original
>>> data being very poorly set up.
>>>
>>> Robert.
>>>
>>> On 8 March 2017 at 09:39, Andre Normann <andre.normann at gmail.com> wrote:
>>> > Hi Robert,
>>> >
>>> > I used 3.2.3 to load the obj files and converted it into ive format. In
>>> > 3.2.3 I load the ive file, build my scenegraph and I get 60 fps. When
>>> I now
>>> > load the same ive file into 3.4.0, build my scenegraph, I get the slow
>>> down.
>>> >
>>> > - There must be something which is causing the slow down in
>>> OpenSceneGraph
>>> > - The obj loader is creating a lot of primitive sets, which is not
>>> optimal.
>>> > In near future I will try to fix that issue.
>>> >
>>> > I created a test file. Simply do an "osgviewer SlowDownTest.zip".
>>> >
>>> >
>>> >
>>> > 2017-03-08 9:45 GMT+01:00 Robert Osfield <robert.osfield at gmail.com>:
>>> >>
>>> >> Hi Andre,
>>> >>
>>> >> On 8 March 2017 at 08:40, Andre Normann <andre.normann at gmail.com>
>>> wrote:
>>> >> > 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?
>>> >>
>>> >> It sounds like data import path is the crucial part, perhaps changes
>>> >> to the .obj plugin between 3.2.3 and 3.4.0 are what is causing the
>>> >> difference.
>>> >>
>>> >> Doing an:
>>> >>
>>> >>     osgconv myfile.obj myfile.osgt
>>> >>
>>> >> In 3.2.3 and 3.4.0 will tell you the differences that the plugin and
>>> >> any optimization passes are making.
>>> >>
>>> >> Is there any chance you could share an example of one of these .obj
>>> >> files that is causing the performance problems?
>>> >>
>>> >> Robert.
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > 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-openscenegraph.org
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20170309/8282113f/attachment-0003.htm>


More information about the osg-users mailing list