BastiaanOlij
commented
3 months ago Need to see how this works together with #107
Also, I really want to get rid of exposing the wrapper objects, that is a path we should never have gone down.
Godot users work with nodes and resources. We'd probably want to extend on the work in #107 where anchors that have been created previously are retrieved and added, but now you can create additional anchors or update existing anchors and their new location is communicated back to the XR runtime for storage.
One option is to introduce a new XRPersistantAnchor3D node (or subclass from XRAnchor3D) for this where any change in the transform of the node (we can detect this through notifications), we copy this transform into the associated XRPositionalTracker. We can connect to this signal from the plugin to trigger storing the new transform in the anchor storage.
Similarly creating a new anchor that needs to be stored is as simple as creating a new XRPersistantAnchor3D node and instead of setting a tracker, we tell it to create a new tracker.
The problem is that we now get bi directional communication:
- The plugin can create/update anchors when we start or when the user recenters, resulting in the
XRPositionalTrackergetting updated and as a result aXRPersistantAnchor3Dnode being created/updated, - Or the godot side can create/reposition an
XRPersistantAnchor3Dnode, resulting in theXRPositionalTrackergetting created/updated and as a result a store anchor gets created/updated.
So we need some way to prevent this pingponging and thus have a clear way of ensuring the communication goes in the desired direction.
cc @dsnopek
dsnopek
This commit adds a way to create, persist, and load spatial anchors. An anchor represents a real world point in stage space and will remain there even if the user recenters. It is created from a Transform3D and represented as an XRPositionalTracker (with a user provided name and runtime provided uuid).
TODO: Add example to demo project