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