We will want to allow people to write their own CV code and run it synchronously with WebXR. They may want to parallelize, but we might be able to just keep it simple.

For a while, we were talking about possibly exposing something like OpenVX (https://www.khronos.org/openvx/) so that apps could initialize native "CV graphics" in JS, but they would run nativing, with the option of adding "nodes" in JS/WebAssembly. We might still want to do that, but this might actually be a separate thing that somehow synchronizes with WebXR.

The basic requirement is that whatever data the platform can provide (and that the UA/user allows access to) gets passed to a method written in JS/WebAssembly. I'm not sure the "best" way to implement this (in polyfill or natively), but the idea of "Vision Workers" was floated by some folks. If we could have efficient shared buffers and worker sync, we could let users set up a worker, WebXR could pass it data and then call the program's rAF, the program would sync up with the worker as late as it can (allowing parallelization) and then get the data.

An initialize implementation would have us put JSARToolkit in a worker and pass WebRTC video frames to it.

In WebXR API.md the question is asked:

'exclusive' needs to be rethought given the new use of XRDisplay for magic window. Do we still need sessions that just wants sensor data?

I think the answer is yes, because we need a way for the UA to control if/when the display/app gets sensor data. This is a discussion in WebVR: how can "magic window" apps get sensor input that might be sensitive (i.e., can be used for user profiling, tracking, etc) with/without user acknowledgment.

So, I would think that app has to ask, and the UA can then mediate.

If we look at JSARToolkit, AR.js and argon.js's WebRTC reality, all attempt to constrain the selection of the reality. Mostly, they try to find a relatively low res (~320x240) if available. One question, of course, is if we need that: is it the case that we can render the video to any sized canvas we want, so we can display at high res and (if we want to do tracking) get the pixels at lower res?

This might (also) be an example of where we'd want to have a "platform specific extenstion API" to manager WebRTC video. In addition to choosing cameras or resolutions, this might also let us (for example) connect to a remote video stream and do AR on it, or run off a remote file. Neither of the later of these is urgent, but selecting cameras might be. And, more importantly, if continues to force us to deal with "platform specifics".

During a recent chat, we got to discussing Anchors and reference frames and the differences between how WindowsMR/Hololens does things and how more stationary VR devices (Vive, etc) think about this.

Here, we've been thinking about how all of these might be unified under some notions of Coordinate Systems and Anchors. We were thinking about having some "well defined" Anchors or coordinate frames, such as "stage" or "body" or perhaps "leftHand", for devices that support them. I'd really like to try and understand better how far folks think this can be pushed, and what the "minimums" need to support. It would be great if some others who've been thinking about this issue (@toji, @bferns, @judax, @NellWaliczek,@RafaelCintron, etc) might chime in. I'd like to capture some of it.

I'd like to put a dialog on top of the screen which says to move around until the system is fully initalized and found the floor anchor. Currently there is no API to get this. I can sort of do it by querying for the floor anchor and seeing what I get back, but this doesn't feel reliable becuase I can't tell if the anchor is valid. We should expose the state of the system through a series of events, similar to how XMLHttpRequest gives you detailed events for different parts of a request.

FYI: The following changes were made to this repository's wiki:

• defacing spam has been removed

• Restricting write access to contributors is strongly encouraged. Please make that change (documentation).

These were made as the result of a recent automated defacement of publically writeable wikis.

As of January 1 2019, Mozilla requires that all GitHub projects include this CODE_OF_CONDUCT.md file in the project root. The file has two parts:

1. Required Text - All text under the headings Community Participation Guidelines and How to Report, are required, and should not be altered.
2. Optional Text - The Project Specific Etiquette heading provides a space to speak more specifically about ways people can work effectively and inclusively together. Some examples of those can be found on the Firefox Debugger project, and Common Voice. (The optional part is commented out in the raw template file, and will not be visible until you modify and uncomment that part.)

If you have any questions about this file, or Code of Conduct policies and procedures, please see Mozilla-GitHub-Standards or email [email protected].

(Message COC001)

Do the ideas here include a declarative (HTML) language for 3D?

We've talked about it, here and there. Over time we will expose more and more "generic" APIs that we think can be supported in many places (e.g., perhaps plane detection).

But, to explicitly control the platform, there will be some custom APIs needed

• ADF control on Tango (and probably ARCore), similar but different ideas on WindowsMR, probably something similar when ARKit matures.
• loading image targets or models on platforms with those kinds of trackers.
• etc

Should we assume webxr.platform.name as a set of namespaces and go from there?