Suggest additional use case: "encapsulated XR apps"

[NellWaliczek]

From @JeroMiya on March 1, 2018 18:50

One very compelling use case I haven't seen featured in the WebXR materials I've browsed so far is any kind of standardization of what I'll call, for lack of a better term, "encapsulated XR apps". These are AR or VR apps which may be embedded into another environment. They are either pinned to the real world in the case of an AR headset like the Hololens, or pinned to a virtual world as is done with Windows Mixed Reality or the web-based enclosures supported in AltSpaceVR. Multiple encapsulated apps may be "pinned" simultaneously into the same environment.

Open question: What would be the requirements of such apps beyond typical WebXR applications? Enclosures? Additional coordinate spaces? Negotiating access to shared devices between multiple apps? Support for pinning enclosures into another web app?

Copied from original issue: immersive-web/webxr#327

[NellWaliczek]

From @speigg on March 1, 2018 22:18

This is one of the questions we have been exploring in the Argon platform (https://www.argonjs.io). In brief, I see such apps as being inherently AR apps, which can augment any type of “reality”, whether that is “physical reality” or “virtual reality”. The basic requirement for such apps is that the platform provide the pose of the device relative to a meaningful coordinate system within the presented “reality” (in addition to projection/view matrices, etc.). This is basically already possible with the current WebXR spec, assuming the UA has the freedom to define “reality”. For example, one can imagine that the UA can easily provide its own virtual environments (e.g., Google Earth) in which AR apps can be hosted.

In order for a VR app to become “augmentable” by AR apps, however, requires a bit more work for the developer of such a VR app: the app would have to expose it’s own internal coordinate system, and make it available to AR apps. This would require additional functionality in the WebXR spec, and is unlikely to happen any time soon, if at all (as far as I understand), for a number of reasons, including performance concerns.

I think the distinction between AR apps and VR apps is important here, primarily because VR apps define and have control over their own internal coordinate system and the user’s pose within that coordinate system (e.g. navigation via teleportation), while AR apps can only react to changes in the reported pose relative to the given coordinate system (they can’t “move” the user at all).

[NellWaliczek]

From @JeroMiya on March 2, 2018 0:56

Yeah, if the existing XR spec and API for AR apps serves this use case, that would be great. If so, I'd still like to get this use case added to the existing lists where use cases for WebXR are stated in the spec and other docs. Then, when changes to the spec are proposed, they can be evaluated to ensure it's suitable for this particular use case. This, as opposed to only supporting the use case where only one AR app is open at a time, either on a mobile device via ARCore/ARKit style AR or on a pass-through AR device, like hololens.

[NellWaliczek]

From @blairmacintyre on March 6, 2018 20:35

I think this is going to be beyond the scope of the initial WebXR Device API. However, the concept of being able to display multiple bits of content at once is something that keeps coming up, and many folks are interested in.

There is a tension, though, about how best to do it, and what kinds of restrictions to impose. Some folks, for example, are suggesting that a new declarative framework be defined that limits the kind of content, and thus allows more control over performance, etc.

I'd suggest tossing this question over in the https://github.com/immersive-web/proposals repository (the idea is that folks create issues there for things they'd like to see happen, and when there's enough interest in tackling one, people break off and work on them.)

[NellWaliczek]

Migrated this issue from the WebXR repo to the proposals repo as part of cleanup

[TrevorFSmith]

This is a duplicate topic for Issue #15