Open speigg opened 6 years ago
Can you take a look at the evolving proposal for the w3c WebXR (https://github.com/immersive-web/webxr) and see what they are doing there? (Sorry, I don't have time right now, so it'll be faster for you to look).
Note: we aren't making any dramatic changes to the polyfill right now, as the WebVR community is moving the WebVR2.0 proposal to be WebXR. After the initial transition stabilizes, we'll want to start following what the standard is doing.
There seems to be a lot of complexity created by having the
XRAnchor
creation/finding methods insideXRPresentationFrame
.For example, in the example code, we have to keep track of whether or not we already requested the floor anchor, since we can only get the floor anchor via the frame instance, and thus inside the frame callback:
More so, this logic is incorrect, since it does not handle the case when the reality is changed, which would cause all the XRAnchors to become invalid (right?).
Can we just expose the various Anchor-related properties and methods (
anchors
,getAnchor
,findAnchor
,findFloorAnchor
, etc.) in theReality
class so that these things don't have to be called within a frame callback that is executed repeatedly, thus eliminating the need for things like therequestedFloor
flag above? For example, the anchor can easily be requested every time the Reality changes, which is the proper way to do it (assuming all anchors are invalid after a reality changes):More so, we see this pattern of delaying the creation of anchors in the anchor sample:
This can be simplified to: