Mixed reality features

[dmarcos]

New an exciting features on the WebXR side that we should integrate in A-Frame. @diarmidmackenzie has done amazing work already https://diarmidmackenzie.github.io/aframe-components/#mixed-reality--physics

Relevant presentation from Meta Connect:

https://www.youtube.com/watch?v=M2QTwirp-B8&ab_channel=MetaDevelopers

[diarmidmackenzie]

If you want to bring most MR features into A-Frame, I'd recommend building on ratk. It's not perfect, and might need some improvements, but the Meta team seem to be committed to maintaining it, and they are happy to merge PRs.

In that case, my anchored component could come into A-Frame core more-or-less as is (with some translation into ES5),

The room layout/physics stuff is a little more complex as physics isn't part of A-Frame core, so it's probably more appropriate to provide an A-Frame abstraction that exposes the xr-planes, without the physics bits. I don't yet have a good picture of what that would look like. The ratk abstractions themselves might not be the best start-point as I didn't find them very nice to work with when building this component, so some thought needed here.

If you only wanted anchors in A-Frame core, without the other mixed reality stuff, then it might be better to build directly to the WebXR APIs without ratk. But I suspect the desire is for A-Frame to offer a full complement of MR features, in which case I think there's a good case for including ratk as a new dependency.

[dmarcos]

If you want to bring most MR features into A-Frame, I'd recommend building on ratk. It's not perfect, and might need some improvements, but the Meta team seem to be committed to maintaining it, and they are happy to merge PRs.

ratk is awesome but prefer to avoid an external dependency for something that is core value prop of A-Frame. Gotta have direct in-house knowledge and control of the WebXR APIs vs taking on a new abstraction that might or might not fit in A-Frame code base. The WebXR spec is not that complicated after all.

In that case, my anchored component could come into A-Frame core more-or-less as is (with some translation into ES5)

Thanks. I'll look into it.

[dmarcos]

Merged anchor support https://github.com/aframevr/aframe/commit/da1ad3c483a4e292c4df92679306e3daa0cf81a7

[diarmidmackenzie]

Worth you beng aware of this issue, which will probably arise in your implementation as well. https://github.com/meta-quest/reality-accelerator-toolkit/issues/8

When exiting and re-entering XR, it's necessary to drop any retained state about anchors (the anchor stored at this.anchor which originates from the previous session will become stale and unusable, leading to an exception), and make another call to restorePersistentAnchor().

I think there is an issue for non-persistent anchors here as well. Non-persistent anchors will be lost not only on browser refresh, but also on exiting / re-entering VR, and there's probably some state clean-up required on re-entering VR to avoid hitting exceptions.

[dmarcos]

https://github.com/aframevr/aframe/commit/4fdcb0cd6402cd221f8de89226e54439218b0bec should fix all the kinks when entering / exiting immersive mode. Thanks for pointing it out!

[dmarcos]

Anchors Demo: https://glitch.com/edit/#!/sticky-massive-thorium?path=index.html%3A4%3A127

[dmarcos]

Support for WebXR Planes and Meshes just landed. I'm closing this for now and can follow up with more targeted issues for specific features. thanks for the feedback