[osg-users] R: R: multiple matrix transfromations cause severe slowness in performance

Gianluca Natale natale at europe.altair.com
Wed Oct 9 00:26:39 PDT 2019


Hi Chris,
first of all, thanks for helping.

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.
The drawable that renders each arrow is a custom drawable that I derived from osg::drawable, where I’ve overridden the drawImplementation.
Internally my drawable allocates a VBO for the geometry, and sends it directly to OpenGL for rendering in drawImplementation.
My drawable provides a consistent bounding box that OSG uses to cull the drawable when outside of the viewing volume.
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).
So, it is OSG that during rendering traversal computes the scale factors of that autotransform, to keep the constant size.
Note that I’m not using shaders at the moment, but still the ffp.

At the beginning I had thought that my drawImplementation was the bottleneck in redrawing, but even if I comment its code completely
(making drawImplementation an empty function), still the redraw takes a considerable time.
It looks like most of the time was taken to traverse the scenegraph, apply the transformation and culling the drawables.

I’m still investigating, and trying to isolate the issue.

Thanks,
Gianluca

Da: osg-users <osg-users-bounces at lists.openscenegraph.org> Per conto di Chris Hanson
Inviato: martedì 8 ottobre 2019 15:51
A: OpenSceneGraph Users <osg-users at lists.openscenegraph.org>
Oggetto: Re: [osg-users] R: multiple matrix transfromations cause severe slowness in performance

I believe most computations you could imagine doing could be performed in the vertex shader during draw rather than by the CPU during cull.

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.

On Tue, Oct 8, 2019 at 7:36 AM Gianluca Natale <natale at europe.altair.com<mailto:natale at europe.altair.com>> wrote:
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.
So, the transformation has to be computed by OSG out of my vertex shader. Am I wrong?

Da: osg-users <osg-users-bounces at lists.openscenegraph.org<mailto:osg-users-bounces at lists.openscenegraph.org>> Per conto di Chris Hanson
Inviato: martedì 8 ottobre 2019 14:42
A: OpenSceneGraph Users <osg-users at lists.openscenegraph.org<mailto:osg-users at lists.openscenegraph.org>>
Oggetto: Re: [osg-users] multiple matrix transfromations cause severe slowness in performance

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?

On Tue, Oct 8, 2019 at 6:20 AM Gianluca Natale <natale at europe.altair.com<mailto:natale at europe.altair.com>> wrote:
Hi all,
I have a performance issue in my scenegraph that I cannot completely understand.
My scenegraph is made by a main matrix transform, with these 2 children:

  *   One geode that renders a big object on screen (the geometry in the drawable can take up to several thousands vertices);
  *   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)
It seems that this configuration allows me to have at most 50 fps.
I feel that this should be rendered much faster.

So I made some experiment. If I remove the 200 matrix transform attached to the group node I mentioned above,
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.
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).
How can you explain such an improvement?

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.
But if I do that, I cannot remove the 200 transformations at all, and I’ll end up with a bad performance.
Any idea about what I can try to make rendering of my scenegraph faster?

Thanks,
Gianluca
_______________________________________________
osg-users mailing list
osg-users at lists.openscenegraph.org<mailto:osg-users at lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org<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>


--
Chris 'Xenon' Hanson, omo sanza lettere. Xenon at AlphaPixel.com<mailto:Xenon at AlphaPixel.com> http://www.alphapixel.com/<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>
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Legal/IP • Forensics • Imaging • UAVs • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile • iPhone/iPad/iOS • Android
@alphapixel<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> facebook.com/alphapixel<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> (775) 623-PIXL [7495]
_______________________________________________
osg-users mailing list
osg-users at lists.openscenegraph.org<mailto:osg-users at lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org<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>


--
Chris 'Xenon' Hanson, omo sanza lettere. Xenon at AlphaPixel.com<mailto:Xenon at AlphaPixel.com> http://www.alphapixel.com/<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>
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Legal/IP • Forensics • Imaging • UAVs • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile • iPhone/iPad/iOS • Android
@alphapixel<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> facebook.com/alphapixel<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> (775) 623-PIXL [7495]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20191009/e79e1250/attachment.html>


More information about the osg-users mailing list