[osg-users] First steps to improve culling

[Christian Buchner]

If you have lots of similar objects (crates boxes and whatnot), maybe GPU
instancing would be a way to speed up draw calls. We've managed to get
15000 cars on screen at high frame rates using OpenGL instancing, with
several hundred polys per instance.

Christian


2015-11-13 10:09 GMT+01:00 Robert Osfield <robert.osfield at gmail.com>:

> Hi Alexandre,
>
> On 12 November 2015 at 20:30, Alexandre Vaillancourt <
> alexandre.vaillancourt.list at gmail.com> wrote:
>
>> Thanks for your reply, and of course I should have specified the version.
>> It's 3.2.0, we're planning to update to the most recent one within the next
>> 3 months.
>>
>> I have attached the screenshot. I'm not authorized to post anything not
>> approved by the higher end so the visuals have been "painted", but the
>> stats are there.
>>
>
> From the screenshots the cull and draw dispatch don't look particular
> high, but the draw GPU is clear bottleneck and will be the primary cause of
> slow down.
>
> The number of objects that the OSG and hence OpenGL is dealing with isn't
> massive so optimizing the scene graph structure probably won't gain you too
> much.  Not to say you might not be able to optimize things further but for
> now I'd suggest you best spend your efforts looking at how to optimize what
> is happening on the GPU.
>
> You could look at threading - CullThreadPerCameraDrawThreadPerContext
> would be worth trying just to see how it changes things.  As you are GPU
> limited I don't expect this to make a big differents but since calling
> "viewer.setThreadingModel(osgViewer::Viewer::CullThreadPerCameraDrawThreadPerContext"
> is single line addition to your app it shouldn't take to long to test out.
>
> On the GPU optimization side there are lots of different things that can
> cause bottlenecks, each one will have a different set of solutions.  It's
> rather open ended topic, so you'll need to do a range of benchmark tests to
> find out what is the main bottleneck on the GPU.  One easy test would be to
> change the resolution of the different windows - such as half in each
> dimension to cut the fill requirements to a 1/4.  If you run the benchmarks
> in this configuration and look at how the GPU stats change you'll get an
> idea of relative load on vertex vs fragment processing.  For instance if
> the performance doesn't change much when you change resolution then you are
> likely to be vertex processing limited, while if the performance does vary
> significantly then you'll be fill limited.
>
> Robert.
>
>
> _______________________________________________
> 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/20151113/00ed87ce/attachment-0003.htm>