Webxr: Clarify whether each view is required to have the same z-axis as the viewer?

[asajeffrey]

Should content be allowed to assume that each of the views shares a z-axis with the viewer? Some content might, for example, z-sort surfaces according to their z-position in viewer space, then use that z-sorting to render to each eye. This is fine if sort order is consistent, but not if the views have different z-axes.

The spec is silent on this topic, though there is a note in https://immersive-web.github.io/webxr/#xrviewerpose-interface that says that spectator mode is supported, which implies that not all views share a z axis.

[asajeffrey]

In particular this affects content which uses z-axis sorting and multiview.

[blairmacintyre]

I can think of at least one VR display I've used that doesn't have have the view Z-Axes aligned with the viewer Z-axis. So I don't think this is a reasonable suggestion. I think it would be up to the client to look at the configuration and decide if something like multiview is appropriate, or if they have to z-sort per eye.

[asajeffrey]

Yes, my worry is that content providers will code for devices that are z-axis aligned, and won't realize that their content is broken on devices where that's not true. I suspect multiview will encourage that. Should we add a non-normative note making it more explicit that (e.g.) z-sorting and culling may need to be done differently for each eye?

[blairmacintyre]

We should add a note, and convince current libraries (ThreeJS, Babylon) to do the right thing (i.e., look at the various z-vectors before making assumptions about if they can do z-sorting once, or use multiview). Most content will be built on top of these (and similar) libraries.

[klausw]

I agree that the spec should make it explicit that apps shouldn't assume parallel Z axes for views. Chrome's implementation supports non-parallel Z axes as of https://crrev.com/c/1775229 , and we tested this using a Pimax headset whose preferred SteamVR operating mode is to expose its tilted screens as views with non-parallel Z axes.

(FWIW, there is an option in the Pimax tool to force parallel projections for compatibility, since unsurprisingly some native SteamVR applications also weren't ready to deal with that, leading to a range of odd effects from unusably non-converging views to headache-inducing special effects rendering inconsistently. The Index headset also has tilted screens, and chose to not make that visible to applications, but that's a much smaller angle where parallel projections don't cause much of a performance hit.)

WebXR should also be able to support CAVE systems where the user is surrounded by separately rendered monitor views, though I'm not aware of any current implementation for that. A CAVE would likely also break other application assumptions, for example the total FOV for that is greater than 180 degrees and can't be expressed as a culling frustum.

[asajeffrey]

I've vaguely been thinking about how to implement a CAVE back end for Servo, so far my thought is to render to a cubemap, by providing six views, each with 90 degree FOV. The webxr spec allows this, but I'm not sure how much content will break.

[toji]

For the record, I've always assumed that the views Z-axis could be non-parallel. I believe that the Hololens already does that. We just need to document explicitly that it's a possibility.

[cabanier]

For the record, I've always assumed that the views Z-axis could be non-parallel. I believe that the Hololens already does that. We just need to document explicitly that it's a possibility.

Magic Leap also has non-parallel Z-axis