Hi James,

While dynamic drawables and statesets are usually the easiest, there are 
other approaches that can get the same results without blocking the next 
frame. For example, OpenMW double buffers drawables and statesets that 
would otherwise need to be dynamic, and selects alternating ones for each 
frame via cull/update callbacks etc.

Hope this helps,

Chris

On Saturday, 2 July 2022 at 11:47:48 UTC+1 James Hogan wrote:

> Hi Robert,
>
> On Wednesday, 29 June 2022 10:33:43 BST Robert Osfield wrote:
>
> > Hi James,
>
> > 
>
> > For performance improvements with VR applications it may be best to have 
> a
>
> > look at the OpenGL MultiView extension.  These are integrated with the
>
> > MultiView branch of the OSG that is built off the 3.6 branch.
>
> Thanks. Yes, I need to have a proper look at this.
>
> > The MultiView functionality requires use of shaders, but if your scene
>
> > graph is already shader based these could be tweaked to include the extra
>
> > uniforms required for the multiview.  Since most OSG/OpenGL applications
>
> > are CPU limited it's possible to add stereo rendering with very low
>
> > overhead, in the tests I've done with my Geforce 2060 system it's 
> possible
>
> > to do stereo with negligible slow down over normal rendering.
>
> > 
>
> > There also some work I've done on the VSG that could potentially 
> backported
>
> > to the OSG that would improve CPU performance such as the vsg::Allocator
>
> > work.
>
> > 
>
> > These approaches will likely give far better performance improvements 
> that
>
> > trying to be clever about traversals.
>
> Also, I eventually figured out that my flightgear LOD distances were dumb, 
> which seemed to be the cause of most of the cull traversal time. Resetting 
> those to default did improve things a bit and I was able to get it playable 
> on a newish PC, but I'm sure there's plenty more improvements to make.
>
> I think I understand a bit more about the dependencies between frames now 
> too. The issue I think is that there are quite a few dynamic objects which 
> delay the next frame from starting until all dynamic objects have been 
> drawn. Probably quite invasive to fix so I'll drop that idea for now.
>
> I wonder whether VSG takes the same approach to them? I imagine a buffered 
> / RCU style approach to dynamic draw data would be ideal for parallelism 
> but perhaps its not necessary since command buffers can be generated in 
> parallel anyway.
>
> Cheers
>
> James
>

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/01cd5d77-4006-4308-9ba4-9709074a30e9n%40googlegroups.com.

Reply via email to