<div dir="ltr">Maybe the datavariance on your drawables is not set to static?<div>Laurens.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 9, 2019 at 9:27 AM Gianluca Natale <<a href="mailto:natale@europe.altair.com">natale@europe.altair.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 lang="IT">
<div class="gmail-m_-2136905288960285074WordSection1">
<p class="MsoNormal"><span lang="EN-US">Hi Chris,<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">first of all, thanks for helping.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Each of those 200 objects is simply the shape of an arrow (basically a cone and a cylinder), whose geometry takes no more than 100 vertices.<br>
The drawable that renders each arrow is a custom drawable that I derived from osg::drawable, where I’ve overridden the drawImplementation.<br>
Internally my drawable allocates a VBO for the geometry, and sends it directly to OpenGL for rendering in drawImplementation.<br>
My drawable provides a consistent bounding box that OSG uses to cull the drawable when outside of the viewing volume.<br>
Each drawable is inserted in a geode, that in its turn is attached to an autotransform matrix, because I need those shapes to be rendered at constant size on screen (70 pixels).<br>
So, it is OSG that during rendering traversal computes the scale factors of that autotransform, to keep the constant size.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Note that I’m not using shaders at the moment, but still the ffp.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">At the beginning I had thought that my drawImplementation was the bottleneck in redrawing, but even if I comment its code completely<br>
(making drawImplementation an empty function), still the redraw takes a considerable time.<br>
It looks like most of the time was taken to traverse the scenegraph, apply the transformation and culling the drawables.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">I’m still investigating, and trying to isolate the issue.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Thanks,<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Gianluca<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><b>Da:</b> osg-users <<a href="mailto:osg-users-bounces@lists.openscenegraph.org" target="_blank">osg-users-bounces@lists.openscenegraph.org</a>>
<b>Per conto di </b>Chris Hanson<br>
<b>Inviato:</b> martedì 8 ottobre 2019 15:51<br>
<b>A:</b> OpenSceneGraph Users <<a href="mailto:osg-users@lists.openscenegraph.org" target="_blank">osg-users@lists.openscenegraph.org</a>><br>
<b>Oggetto:</b> Re: [osg-users] R: multiple matrix transfromations cause severe slowness in performance<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">I believe most computations you could imagine doing could be performed in the vertex shader during draw rather than by the CPU during cull.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">To describe more we'd need a better idea of what those 200 objects are, how they behave, what they represent, and how auto transform is being used.<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Tue, Oct 8, 2019 at 7:36 AM Gianluca Natale <<a href="mailto:natale@europe.altair.com" target="_blank">natale@europe.altair.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal">As I said, I’d like to use auto-transformations for those 200 objects, so I need 200 transformations for sure, and those transformations are updated by OSG at rendering time.<u></u><u></u></p>
<p class="MsoNormal">So, the transformation has to be computed by OSG out of my vertex shader. Am I wrong?
<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"><b>Da:</b> osg-users <<a href="mailto:osg-users-bounces@lists.openscenegraph.org" target="_blank">osg-users-bounces@lists.openscenegraph.org</a>>
<b>Per conto di </b>Chris Hanson<br>
<b>Inviato:</b> martedì 8 ottobre 2019 14:42<br>
<b>A:</b> OpenSceneGraph Users <<a href="mailto:osg-users@lists.openscenegraph.org" target="_blank">osg-users@lists.openscenegraph.org</a>><br>
<b>Oggetto:</b> Re: [osg-users] multiple matrix transfromations cause severe slowness in performance<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">Can you find a way to perform the transform on each object in a vertex shader and not have a unique state have to be calculated for each of the 200 objects?<u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">On Tue, Oct 8, 2019 at 6:20 AM Gianluca Natale <<a href="mailto:natale@europe.altair.com" target="_blank">natale@europe.altair.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin:5pt 0cm 5pt 4.8pt">
<div>
<div>
<p class="MsoNormal">Hi all,<u></u><u></u></p>
<p class="MsoNormal">I have a performance issue in my scenegraph that I cannot completely understand.<u></u><u></u></p>
<p class="MsoNormal">My scenegraph is made by a main matrix transform, with these 2 children:<u></u><u></u></p>
<ul type="disc">
<li class="gmail-m_-2136905288960285074gmail-m3624598838946311341gmail-m2700963786699460416msolistparagraph">
One geode that renders a big object on screen (the geometry in the drawable can take up to several thousands vertices);<u></u><u></u></li><li class="gmail-m_-2136905288960285074gmail-m3624598838946311341gmail-m2700963786699460416msolistparagraph">
One group node that in its turn has 200 children, each made by a matrix transform and a geode. The drawable in each of those geodes is very simple (no more than 100 vertices)<u></u><u></u></li></ul>
<p class="MsoNormal">It seems that this configuration allows me to have at most 50 fps.<u></u><u></u></p>
<p class="MsoNormal">I feel that this should be rendered much faster.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">So I made some experiment. If I remove the 200 matrix transform attached to the group node I mentioned above,<br>
and directly apply the transformations to the vertices of the geometries in the 200 drawables of the small objects, performance improves a lot, till 100 fps.<br>
I investigatd a bit inside OSG code (I’m using OG ver.3.4.1), and apparently the only overhead due to the additional matrix transformations is a call to glLoadMatrix (I’m using the old ffp).<br>
How can you explain such an improvement?<br>
<br>
My real problem is that I would like to replace the 200 matrix transfromations with 200 auto-transform matrices, since I’d like those small objects to keep constant size on screen.<u></u><u></u></p>
<p class="MsoNormal">But if I do that, I cannot remove the 200 transformations at all, and I’ll end up with a bad performance.<u></u><u></u></p>
<p class="MsoNormal">Any idea about what I can try to make rendering of my scenegraph faster?<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
<p class="MsoNormal">Gianluca<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<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="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openscenegraph.org%2Flistinfo.cgi%2Fosg-users-openscenegraph.org&data=02%7C01%7Cnatale%40europe.altair.com%7Ce5a56a1a983b485f984b08d74bf68ed2%7C2bae5b570eb848fbba47990259da89d2%7C0%7C0%7C637061394638653731&sdata=Ucr17caFSHVZXJ58aCuCaXtIqEPR55rEX68o8iGCX04%3D&reserved=0" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<p class="MsoNormal">--
<u></u><u></u></p>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal" align="center" style="text-align:center">
Chris 'Xenon' Hanson, omo sanza lettere. <a href="mailto:Xenon@AlphaPixel.com" target="_blank">
Xenon@AlphaPixel.com</a> <a href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.alphapixel.com%2F&data=02%7C01%7Cnatale%40europe.altair.com%7Ce5a56a1a983b485f984b08d74bf68ed2%7C2bae5b570eb848fbba47990259da89d2%7C0%7C0%7C637061394638653731&sdata=Or0JG2UC9n2xnuF5%2FIoTDL8lvVxF1Hzad1YyHH%2FvZH4%3D&reserved=0" target="_blank">
http://www.alphapixel.com/</a><u></u><u></u></p>
<p class="MsoNormal" align="center" style="text-align:center">
Training • Consulting • Contracting<u></u><u></u></p>
<p class="MsoNormal" align="center" style="text-align:center">
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL<u></u><u></u></p>
<p class="MsoNormal" align="center" style="text-align:center">
<span style="font-size:9.5pt">Legal/IP • Forensics • </span>Imaging <span style="font-size:9.5pt">• UAVs • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile • iPhone/iPad/iOS • Android</span><u></u><u></u></p>
<p class="MsoNormal" align="center" style="text-align:center">
<a href="https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Falphapixel&data=02%7C01%7Cnatale%40europe.altair.com%7Ce5a56a1a983b485f984b08d74bf68ed2%7C2bae5b570eb848fbba47990259da89d2%7C0%7C0%7C637061394638663725&sdata=0W9mzPAV8ei6k%2F1%2FdPe4gp%2BQ9p7QC6AgWq19EG%2FGAxE%3D&reserved=0" target="_blank">@alphapixel</a>
<a href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Ffacebook.com%2Falphapixel&data=02%7C01%7Cnatale%40europe.altair.com%7Ce5a56a1a983b485f984b08d74bf68ed2%7C2bae5b570eb848fbba47990259da89d2%7C0%7C0%7C637061394638663725&sdata=ahAuQDQ6LMv3NuwNRoj%2BDIti7KG%2BtziyVOaoE7JppU4%3D&reserved=0" target="_blank">
facebook.com/alphapixel</a> (775) 623-PIXL [7495]<u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal">_______________________________________________<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="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openscenegraph.org%2Flistinfo.cgi%2Fosg-users-openscenegraph.org&data=02%7C01%7Cnatale%40europe.altair.com%7Ce5a56a1a983b485f984b08d74bf68ed2%7C2bae5b570eb848fbba47990259da89d2%7C0%7C0%7C637061394638673719&sdata=8LPvhljWGQjqrssrZHE%2BGwnG7ET3Z2qEQG1vOh%2BoRF0%3D&reserved=0" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">-- <u></u><u></u></p>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal" align="center" style="text-align:center">Chris 'Xenon' Hanson, omo sanza lettere.
<a href="mailto:Xenon@AlphaPixel.com" target="_blank">Xenon@AlphaPixel.com</a> <a href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.alphapixel.com%2F&data=02%7C01%7Cnatale%40europe.altair.com%7Ce5a56a1a983b485f984b08d74bf68ed2%7C2bae5b570eb848fbba47990259da89d2%7C0%7C0%7C637061394638673719&sdata=ANBohUXLHJTI5xhBVgvpg9dwbhaB6k9V3KAWQizoHm4%3D&reserved=0" target="_blank">
http://www.alphapixel.com/</a><u></u><u></u></p>
<p class="MsoNormal" align="center" style="text-align:center">Training • Consulting • Contracting<u></u><u></u></p>
<p class="MsoNormal" align="center" style="text-align:center">3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL<u></u><u></u></p>
<p class="MsoNormal" align="center" style="text-align:center"><span style="font-size:9.5pt">Legal/IP • Forensics • </span>Imaging <span style="font-size:9.5pt">• UAVs • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile •
 iPhone/iPad/iOS • Android</span><u></u><u></u></p>
<p class="MsoNormal" align="center" style="text-align:center"><a href="https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Falphapixel&data=02%7C01%7Cnatale%40europe.altair.com%7Ce5a56a1a983b485f984b08d74bf68ed2%7C2bae5b570eb848fbba47990259da89d2%7C0%7C0%7C637061394638683714&sdata=RpsWNoSX3Hs96xvhybs3Q%2BZcAbGvfFaTNgxJk1r7mZY%3D&reserved=0" target="_blank">@alphapixel</a>
<a href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Ffacebook.com%2Falphapixel&data=02%7C01%7Cnatale%40europe.altair.com%7Ce5a56a1a983b485f984b08d74bf68ed2%7C2bae5b570eb848fbba47990259da89d2%7C0%7C0%7C637061394638683714&sdata=hnABSO6gLf%2FdBDNeX06qQ9NlnHUg1D13Fxf%2F4yBuRcY%3D&reserved=0" target="_blank">
facebook.com/alphapixel</a> (775) 623-PIXL [7495]<u></u><u></u></p>
</div>
</div>
</div>
</div>
</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>