godotvr / tiltfivegodot Goto Github PK

Hey Patrick,

Just to dump this info here and give us a central place to talk, we talked about this some time ago on the Tilt5 discord but I'm more active on the Godot discord. After giving it some more thought this is the more advanced version of that :)

I think we're pretty much between a rock and a hard place with Godot 3 as it was never intended to support multiple HMDs on a single instance but looking at Godot 4 we have a very usable albeit workaroundish solution.

The rendering loop in Godot 4 has been enhanced so that it communicates to the XRInterface which viewport it is about to render XR content too. As there will be a separate Viewport for each glasses this will help us provide the right camera matrices and destination textures. What we need is a way to record which Viewports belong to which glasses.

Skipping ahead a bit, the node tree we'll want to create is something like this:

- T5Board <XROrigin3D>
  - T5Glasses01 <SubViewport>
    - Camera <XRCamera3D>
  - T5Glasses02 <SubViewport>
    - Camera <XRCamera3D>
  - T5Glasses03 <SubViewport>
    - Camera <XRCamera3D>
  - T5Glasses04 <SubViewport>
    - Camera <XRCamera3D>
  - T5Wand01 <XRController3D>
  - T5Wand02 <XRController3D>
  - T5Wand03 <XRController3D>
  - T5Wand04 <XRController3D>
- SpectatorCamera <Camera3D>

The first obvious problem with this approach is that the XROrigin3D and XRCamera3D nodes will start complaining that they are not setup correctly but that can be ignored. We can solve this by creating helper scenes in the plugin that embed the required logic and hide it from the developer. Here you can also embed logic that will automatically add subnodes for the glasses and wands when you detect new devices being connected/turned on.
Once you have your 4.0 port in a branch I'll gladly help you set those up.

The second problem is that our XRCamera3D nodes will now be positioned in global space, not in relation to the XROrigin3D, this will be mitigated in the renderer as the origin nodes position will be added to the new tracking data retrieved, but if you have 3D elements childed to the camera they will be positioned incorrectly. We can add a Node3D between the subviewport and the camera and add some logic that copies the origins placement to this node. Again I suggest hiding this away in scenes in the plugin.

Implementation wise the key element will be to create a subclass of SubViewport, say T5Viewport and add a property to this viewport for the glasses ID.
Then behind the scenes this viewport calls get_rid() to get the RID of the viewport, obtain the current camera for the viewport and stores this alongside the glasses ID in an array that the T5Interface has access too.
This array can then be used during the render loop to find out the camera and glasses ID that we're about to render a viewport for.