<div dir="ltr"><div dir="ltr" style="color:rgb(0,0,0);font-size:12.8px">Hi,<div><br></div><div>just one more remark. I have testet the model with the current master version. Everything is working well.</div></div><div class="gmail-yj6qo gmail-ajU" style="color:rgb(0,0,0);font-size:12.8px"><div id="gmail-:y9" class="gmail-ajR" tabindex="0"><img class="gmail-ajT" src="https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif" style="opacity: 0.3;"></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-03-08 15:45 GMT+01:00 Andre Normann <span dir="ltr"><<a href="mailto:andre.normann@gmail.com" target="_blank">andre.normann@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Robert,<div><br></div><div>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.</div><div><br></div><div>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.   </div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2017-03-08 15:35 GMT+01:00 Christian Buchner <span dir="ltr"><<a href="mailto:christian.buchner@gmail.com" target="_blank">christian.buchner@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>I've recently written some code to merge individual triangle strips<br></div><div>by joining them using some degenerate (zero area) triangles.<br></div><div><br></div>One issue that I've run into is that in wireframe mode this generated<br></div>some very odd looking artifacts.<br><br>Find the code here. It may need some adaptation for your use case.<br><a href="http://forum.openscenegraph.org/viewtopic.php?t=16412" target="_blank">http://forum.openscenegraph.or<wbr>g/viewtopic.php?t=16412</a><span class="m_9160228697086362610HOEnZb"><font color="#888888"><br><br></font></span></div><span class="m_9160228697086362610HOEnZb"><font color="#888888">Christian<br><br></font></span></div><div class="m_9160228697086362610HOEnZb"><div class="m_9160228697086362610h5"><div class="gmail_extra"><br><div class="gmail_quote">2017-03-08 15:32 GMT+01:00 Robert Osfield <span dir="ltr"><<a href="mailto:robert.osfield@gmail.com" target="_blank">robert.osfield@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Andre,<br>
<br>
Thanks for the file.  I've just tried it on my Kubuntu 16.04. NVidia<br>
760 with the OSG-3.4 branch and I see decent performance, the draw<br>
dispatch is bit more expensive than I'd usually expect for a model of<br>
this size but it's not widely expensive like you are seeing.<br>
<br>
The dataset itself looks like the large number of PrimitiveSets is<br>
very high for the number of vertices in each osg::Geometry.  The use<br>
of very short triangle strips rather than a single DrawElementsUShort<br>
GL_TRIANGLES is the core of what is wrong with how the osg::Geometry<br>
have been generated.<br>
<br>
The source of this issue may be down to the .obj or perhaps original<br>
data being very poorly set up.<br>
<span class="m_9160228697086362610m_-8145852851462943894HOEnZb"><font color="#888888"><br>
Robert.<br>
</font></span><div class="m_9160228697086362610m_-8145852851462943894HOEnZb"><div class="m_9160228697086362610m_-8145852851462943894h5"><br>
On 8 March 2017 at 09:39, Andre Normann <<a href="mailto:andre.normann@gmail.com" target="_blank">andre.normann@gmail.com</a>> wrote:<br>
> Hi Robert,<br>
><br>
> I used 3.2.3 to load the obj files and converted it into ive format. In<br>
> 3.2.3 I load the ive file, build my scenegraph and I get 60 fps. When I now<br>
> load the same ive file into 3.4.0, build my scenegraph, I get the slow down.<br>
><br>
> - There must be something which is causing the slow down in OpenSceneGraph<br>
> - The obj loader is creating a lot of primitive sets, which is not optimal.<br>
> In near future I will try to fix that issue.<br>
><br>
> I created a test file. Simply do an "osgviewer SlowDownTest.zip".<br>
><br>
><br>
><br>
> 2017-03-08 9:45 GMT+01:00 Robert Osfield <<a href="mailto:robert.osfield@gmail.com" target="_blank">robert.osfield@gmail.com</a>>:<br>
>><br>
>> Hi Andre,<br>
>><br>
>> On 8 March 2017 at 08:40, Andre Normann <<a href="mailto:andre.normann@gmail.com" target="_blank">andre.normann@gmail.com</a>> wrote:<br>
>> > hopefully I am getting closer. I find out, that the source model might<br>
>> > be<br>
>> > the problem. I exported an obj file from Bentley Microstation and<br>
>> > imported<br>
>> > into OpenSceneGraph. When I now export the scene into an osg file, I see<br>
>> > a<br>
>> > lot of PrimiteSets (e.g. > 1000). So I will end up with a lot calls to<br>
>> > DrawElementsUShort. When I load the obj file into 3dsmax convert it into<br>
>> > a<br>
>> > fbx file and reexport it from OpenSceneGraph into an osg file, I have<br>
>> > only<br>
>> > one PrimitiveSet with one DrawArrays call. This file is working well in<br>
>> > 3.4.0 with sharing nodes.<br>
>> ><br>
>> > So I guess there might be a problem with sharing osg::Geometry which has<br>
>> > a<br>
>> > lot of primitive sets. In 3.2.3 it was working well. What do you think?<br>
>><br>
>> It sounds like data import path is the crucial part, perhaps changes<br>
>> to the .obj plugin between 3.2.3 and 3.4.0 are what is causing the<br>
>> difference.<br>
>><br>
>> Doing an:<br>
>><br>
>>     osgconv myfile.obj myfile.osgt<br>
>><br>
>> In 3.2.3 and 3.4.0 will tell you the differences that the plugin and<br>
>> any optimization passes are making.<br>
>><br>
>> Is there any chance you could share an example of one of these .obj<br>
>> files that is causing the performance problems?<br>
>><br>
>> Robert.<br>
><br>
><br>
><br>
><br>
</div></div><div class="m_9160228697086362610m_-8145852851462943894HOEnZb"><div class="m_9160228697086362610m_-8145852851462943894h5">> ______________________________<wbr>_________________<br>
> osg-users mailing list<br>
> <a href="mailto:osg-users@lists.openscenegraph.org" target="_blank">osg-users@lists.openscenegraph<wbr>.org</a><br>
> <a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" rel="noreferrer" target="_blank">http://lists.openscenegraph.or<wbr>g/listinfo.cgi/osg-users-opens<wbr>cenegraph.org</a><br>
><br>
______________________________<wbr>_________________<br>
osg-users mailing list<br>
<a href="mailto:osg-users@lists.openscenegraph.org" target="_blank">osg-users@lists.openscenegraph<wbr>.org</a><br>
<a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" rel="noreferrer" target="_blank">http://lists.openscenegraph.or<wbr>g/listinfo.cgi/osg-users-opens<wbr>cenegraph.org</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
osg-users mailing list<br>
<a href="mailto:osg-users@lists.openscenegraph.org" target="_blank">osg-users@lists.openscenegraph<wbr>.org</a><br>
<a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" rel="noreferrer" target="_blank">http://lists.openscenegraph.or<wbr>g/listinfo.cgi/osg-users-opens<wbr>cenegraph.org</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>