BastiaanOlij
commented
8 months ago @BastiaanOlij @Malcolmnixon As a follow-up to this PR, we'll need to evaluate how we want to expose this functionality on the Godot side in a manner that's consistent.
In Godot 3 we introduced Anchors based on how ARKit solved this, most of this logic is still in place but not all.
Whether detected by plane detection or otherwise detected, any location that was tracked in space was created as an XRPositionalTracker with the type set to XRServer::TRACKER_ANCHOR. While this location was mostly static, ARKit would update locations as it learned more about its surroundings. It would even merge or split anchors when needed.
So that part of the solution I think is sound and we should apply here too. I don't know the details of the flow Meta currently has but if any spatial location is detected, we should create a positional tracker and register it with the XRServer by calling XRServer::add_tracker. The XRServer already emits signals so the game can react to the creation of a new tracker and make any additions to the scene. This entails adding an XRAnchor3D node to the scene that is bound to the newly created tracker.
Using XRAnchor3D also ensures that the location is adjusted when we recenter the player.
What is missing is what to do after this, I wasn't at all happy with how we did things in Godot 3 so I left this out in the conversion to Godot 4. We need a mechanism to expose further meta data about the anchor and provide a collision shape and/or occlusion mesh.
These could become OpenXRCollisionShape and OpenXRMesh classes where you specify the tracker, the problem is that this would suggest this would also apply for other trackers such as controllers.
This is how we did it in Godot 3 where OpenVR also allowed us to provide render models in this fashion however with OpenXR this is no longer sufficient. With OpenXR the vendor render model APIs are all GLTF based and it looks like this is a trend. We could paint ourselves in a corner if this trend continues into a more generic AR solution.
maunvz
m4gr3d
As title, following the pattern from the fb_scene_capture extension wrapper, I've added wrappers for the 4 extensions mentioned. They don't yet expose useful functionality to godot projects (beyond getting the singletons and checking if the extensions are supported), but provide most of the openxr related boilterplate so a later change can add an "XR Scene" abstraction that expresses a physical room's layout and surfaces to the a Godot scene.