Re: [Flightgear-devel] VR support via OpenXR / osgXR

[James H. <ja...@al...>]

On 25 July 2021 18:37:09 BST, Julian Smith <ju...@op...> wrote:
>On Sat, 24 Jul 2021 18:03:01 +0100
>James Hogan <ja...@al...> wrote:
>
>> On 24 July 2021 15:03:49 BST, Julian Smith <ju...@op...> wrote:
>> >On Sat, 24 Jul 2021 07:28:20 +0200
>> >Fernando García Liñán <fer...@gm...> wrote:
>
>> >> It's an interesting idea, although I'd like to streamline the VR
>case
>> >> to be as much of a "special case" as possible. The whole
>> >> multi-window/multi-monitor is quite a mess already (and if we add
>> >> CompositeViewer to the soup, it gets even messier :) ), so I'd
>like  
>> >to
>> >
>> >If we are rendering for two eye points at the same time, doesn't
>that
>> >require CompositeViewer anyway?  
>> 
>> no, there are 4 ways I've identified so far (but only tried 1 & 2):
>
>Interesting. So what does CompositeViewer do that cannot be done using
>one of the 4 ways you describe?

from what i've read I think it allows for multiple views from different locations, presumably allowing each to have separate scenery loaded or something (someone correct me if i'm wrong there).

>
>And do you 4 ways make approximations that rely on the eye points being
>close together compared to the distances to the nearest object in the
>scene?

way 1 & 2 in normal viewer seems to allow them to be displaced a reasonable amount and pointing in different directions, but i haven't pushed the limits. I expect it'd mess with loaded scenery if they went too far from master camera.

Way 3 & 4 rely on a single cull pass and split the work fully on the gpu in shaders, so as long as the cull takes both views into account it should be fine (again within reasonable distance).

i still need to get my head around what culling is taking place now to understand what openmw-vr's "master cam frustum as union of eye frustums" does to the culling. i think at the moment i'm doing a cull pass per slave, but that openmw-vr's way will allow both slaves to be set to share a single cull pass. In neither case should it result in visual breakage (though if combined fov of eyes exceeds 180 degrees, openmw-vr's way 2 falls back to way 1 with fully separate traversals).

hopefully that makes sense.

cheers
James

>
>
>> 1) add separate slave cameras (i.e. separate simgear compositor
>pipelines) to the osgViewer::Viewer for each eye. this will work with
>unusual vr setups with more than 2 views (VR caves).
>> 2) use OSG's SceneView stereo, as fgfs' stereoscopic options uses. a
>single CameraInfo, single compositor pipeline, horizontal side-by-side.
>single scene traversal (iirc!), which i'm told allows update for next
>frame to proceed in parallel as soon as traversal is done if
>multithreading is in use (not sure how that'd interact with gui on top
>of vr mirror though).
>> 3) multiviewport geometry shader to duplicate geometry to multiple
>viewports of single fbo
>> 4) OVR_multiview2, apparently fast, requires updated OSG and custom
>shaders
>> 
>> since each pipeline has cascading shadow map prerender steps, i
>imagine there's space for optimisation where eye projections are
>similar.
>
>Thanks,
>
>- Jules
>
>-- 
>http://op59.net
>
>
>_______________________________________________
>Flightgear-devel mailing list
>Fli...@li...
>https://lists.sourceforge.net/lists/listinfo/flightgear-devel