Blair MacIntyre
Blair MacIntyre
As @speigg says, the polyfill is based on the experimental API we worked on last year (https://github.com/mozilla/webxr-api). Now that the WebVR community is moving to WebXR, and the new API...
We are not passing that info in; because of the slowness of the way data is injected into the WebXR Viewer, passing large amounts of data per frame is problematic,...
It's probably possible to retrieve the points asynchronously, the only (possibly big) issue is that the coordinate system for ARKit can change over time so there's no guarantee that the...
This also affects the people's demo. We need these demos to give some sort of feedback.
Chatting with NingXin Hu, he suggested mediacapture-worker (https://w3c.github.io/mediacapture-worker/) might be a good starting point for how to structure a vision worker. That is essentially what I have imagined: a worker-like...
Yes, I don't mean "use it": we don't want to use WebRTC at all, directly. What I envision, eventually, might be a way to "add in" WebRTC sources to the...
Switch to creating WebXRManager from WebVRManager, since Three.js is moving in this direction
I don't think there is a difference: an anchor (as we have it here) is a tracked location (likely supported by the underlying platform). There is no concept right now...
In argon.js, we did two things related to this. First, the call to determine the rendering coordinates of an anchor (which you should call each frame) would fail if the...