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.osfi...@gmail.com>: > Hi Alexandre, > > On 12 November 2015 at 20:30, Alexandre Vaillancourt < > alexandre.vaillancourt.l...@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@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org