Closed maunvz closed 7 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.
addressed the formatting nits (now using tabs throughout, turned on whitespace rendering in my editor to catch these sooner lol). Is there / should there be a linter for this project?
addressed the formatting nits (now using tabs throughout, turned on whitespace rendering in my editor to catch these sooner lol). Is there / should there be a linter for this project?
We use clang-format
in most of our projects but doesn't look like we set that up here. Probably worth doing.
Added an export option to request the USE_SCENE permission as per https://developer.oculus.com/documentation/native/native-spatial-data-perm/
From a discussion in #68 the permission is already auto-requested by GodotActivity's existing logic
updated to remove unused constants, request the scene permission manually, based on #71, and use reigster_singleton(...) in the new additions.
updated XrSpace usage, removed unnecessary godot:: prefixes, switched to Godot types throughout, and switched to new singleton registration
addressed final type nits, added missing SCENE_MESH semantic label
Thanks for the contribution!
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.