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

Voerman, L. l.voerman at rug.nl
Wed Oct 9 00:39:22 PDT 2019


Maybe the datavariance on your drawables is not set to static?
Laurens.

On Wed, Oct 9, 2019 at 9:27 AM Gianluca Natale <natale at europe.altair.com>
wrote:

> 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>
> 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> *Per conto
> di *Chris Hanson
> *Inviato:* martedì 8 ottobre 2019 14:42
> *A:* OpenSceneGraph Users <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>
> 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
> 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
> 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
> 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
> 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]
> _______________________________________________
> 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/20191009/beca03e4/attachment.html>


More information about the osg-users mailing list