<div dir="ltr"><div>Hi Anders,</div><div><br></div><div>I have just run the program and model on my Linux system and it works OK with the 3.6 branch.  I haven't compared to 3.5.1 yet as this would require a rebuild.  While there are other things to look at first.</div><div><br></div><div>I had a look at the o.osgt and note that there are a large number of triangle strip primitive sets in the geometry, this is inefficient for modern hardware, if one uses display lists then it hides this inefficiency, but when using VBO or even VAO as required by modern OpenGL performance will be poor with a high CPU overhead for the amount of vertex/polygon data.</div><div><br></div><div>One change between 3.5.1 and 3.6.x was the change to using VBO's by default - to fit better with OpenGL ES and OpenGL 3.x usage.  This will have meant that by default VBO's will be preferred over display lists where supported, so poorly optimized meshes will become more obvious.</div><div><div><br></div><div>To improve performance with modern hardware/OpenGL the best thing is to run the osgUtil::MeshOptimizers to sort out the meshes,</div><div><br></div></div><div>A snippet of the differences below:<br></div><div><br></div><div>> git diff OpenSceneGraph-3.5.1 Drawable.cpp<br></div><div><br></div><div>Drawable::Drawable()<br> {<br>-    _boundingBoxComputed = false;<br>-<br>     // Note, if your are defining a subclass from drawable which is<br>     // dynamically updated then you should set both the following to<br>     // to false in your constructor.  This will prevent any display<br>@@ -286,33 +226,58 @@ Drawable::Drawable()<br>     _useDisplayList = false;<br> #endif<br> <br>+#if 0<br>     _supportsVertexBufferObjects = false;<br>+    //_useVertexBufferObjects = false;<br>     _useVertexBufferObjects = false;<br>-    // _useVertexBufferObjects = true;<br>+#else<br>+    _supportsVertexBufferObjects = true;<br>+    _useVertexBufferObjects = true;<br>+#endif<br>+<br>+    _useVertexArrayObject = false;<br> }<br></div><div><br></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 9 Jan 2020 at 11:45, Anders Backman <<a href="mailto:andersb@cs.umu.se">andersb@cs.umu.se</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">The biggest issue here is that two windows (without vsync) now h<i>eavily affects each other</i>, which they did not in OSG 3.5.1. That is certainly a big difference between the two versions.<div>The performance difference remains after writing a osgt file in 3.5.1<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 8, 2020 at 5:04 PM Robert Osfield <<a href="mailto:robert.osfield@gmail.com" target="_blank">robert.osfield@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Anders,</div><div><br></div><div>Try exporting the .obj file to .osgb or .osgt from 3.5.1 and then compare the performance between 3.5.1 and 3.6.4.  This would check whether the .obj loader is a variable.</div><div><br></div><div>As a general comment, frame rates many times higher than vsync should be treated careful, the frame time can be so small that small overheads elsewhere can lead to large % changes that appear significant but once you start using normal workloads these small differences no longer have an outsized % difference.</div><div><br></div><div>I would check other OS's to see see if the differences apply there too.</div><div><br></div><div>Robert.<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 8 Jan 2020 at 15:56, Anders Backman <<a href="mailto:andersb@cs.umu.se" target="_blank">andersb@cs.umu.se</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi all.<div><br></div><div>Windows 10.</div><div>NVida GeForce RTX 2080.</div><div><br></div><div><br></div><div>I recently switched to 3.6.4 from 3.5.1 and noticed a huge drop in performance, especially when running with two separate windows (two applications).</div><div><br></div><div>1. I use <b>SingleThreaded mode</b></div><div>2. I use  <b>m_viewer->setReleaseContextAtEndOfFrameHint(false);</b></div><div>3.  I use <b>window->setSyncToVBlank(false);</b></div><div><br></div><div>The above attributes are quite tightly connected to my issues.</div><div><br></div><div>But first, running osgViewer with those settings I get using a simple obj file. Details not important, see below.</div><div>When loading a simple .obj file (couple of hundred triangles) into osgViewer:</div><div><br></div><div><b>> osgViewer --window 0 0 1280 720</b></div><div><br></div><div>3.5.1: 1900 fps. Draw 0.08ms</div><div>3.6.4: 2500 fps Draw 0.05ms<br clear="all"><div><div><br></div><div>Now this already show something different between the two versions, although perhaps not so relevant.</div><div><br></div><div><img src="cid:ii_k550ypo20" alt="image.png" width="412" height="129"><br></div></div><div><br></div><div>But if I start two instances of the viewer at the same time, I get a HUGE difference.<br><br></div><div>3.5.1: Two windows, both run in ~2000fps, smoothly.</div><div>3.6.4: Two windows, fps varies between 80-1200fps. Animations are not smooth at all (when spinning the model).</div><div><br></div><div>I also have a few more issues, but I have not been able to pin them down yet:</div><div><br></div><div>I get small objects culled at a certain distance although they where not culled in previous version.</div><div>Might be some change in how bounding volume update is handled in 3.6.4, will know more later.</div><div><br></div><div>Anyone else noticed the performance drop/change in 3.6.4?</div><div><br></div><div>/Anders</div><div><br></div><div><br></div><div><br></div>-- <br><div dir="ltr">__________________________________________<br>Anders Backman, HPC2N<br>90187 Umeå University, Sweden<br><a href="mailto:anders@cs.umu.se" target="_blank">anders@cs.umu.se</a> <a href="http://www.hpc2n.umu.se/" target="_blank">http://www.hpc2n.umu.se</a><br>Cell: +46-70-392 64 67</div></div></div>
_______________________________________________<br>
osg-users mailing list<br>
<a href="mailto:osg-users@lists.openscenegraph.org" target="_blank">osg-users@lists.openscenegraph.org</a><br>
<a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" rel="noreferrer" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
</blockquote></div>
_______________________________________________<br>
osg-users mailing list<br>
<a href="mailto:osg-users@lists.openscenegraph.org" target="_blank">osg-users@lists.openscenegraph.org</a><br>
<a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" rel="noreferrer" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr">__________________________________________<br>Anders Backman, HPC2N<br>90187 Umeå University, Sweden<br><a href="mailto:anders@cs.umu.se" target="_blank">anders@cs.umu.se</a> <a href="http://www.hpc2n.umu.se" target="_blank">http://www.hpc2n.umu.se</a><br>Cell: +46-70-392 64 67</div>
_______________________________________________<br>
osg-users mailing list<br>
<a href="mailto:osg-users@lists.openscenegraph.org" target="_blank">osg-users@lists.openscenegraph.org</a><br>
<a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" rel="noreferrer" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
</blockquote></div>