add support for inline-stereo - #1436
Conversation
toji
left a comment
toji
left a comment
There was a problem hiding this comment.
I think we're trending in the right direction! Bunch of comments, and I want to follow up in a bit with some more detailed discussion of what the reference space for stereo inline sessions should be.
| - The string representation of any {{XRReferenceSpaceType}} enum value | ||
| - The string "<dfn for="feature descriptor">tracked-sources</dfn>" | ||
| - The string "<dfn for="feature descriptor">multi-view</dfn>" | ||
| - The string "<dfn for="feature descriptor">head-tracked</dfn>" |
There was a problem hiding this comment.
I'm going to push back on this one. having a head-tracked feature can make it look like you need to request that feature with any session type in order to get head tracking. I think that the way you opt-in to tracking should be through requesting a non-viewer reference space. (Which is already behavior described by the spec.)
On top of that, as I've been thinking about it I suspect we need to add a new reference space type for this usage, because your average stereo inline canvas will have different needs than every other reference space. I'll try to dig up some older docs I wrote on the matter, but either way I'll follow up with more thoughts soon.
There was a problem hiding this comment.
+1 but why wouldn't simply the local reference space be sufficient here @toji ?
There was a problem hiding this comment.
Could we change the meaning of "local" in inline mode and/or with inline stereo? We already have "swimminess" issues on headsets with "local" and "inline" as it is?
There was a problem hiding this comment.
We could. But local has a pretty clear definition now and I do wonder if we might find more uses for that in this context?
In any case, we probably don't want to change the definition of viewer here, and so redefining anything that describes itself in terms of relationship to the viewer might get confusing. I feel like adding a new reference space (local-page?) that's explicitly about the position of the canvas in space is valuable and consistent with how we treat other spaces in the spec. It makes getViewerPose(localPageRefSpace) very intuitive in terms of what it's going to tell you.
There was a problem hiding this comment.
I think 'local' does what we want. The spec already states that for 'local space' "Inline sessions require consent" so it sounds like what we want instead of 'head-tracking'.
I think this means that I can remove all mention of 'head-tracking' from the spec and just rely on 'local' instead
| NOTE: the {{XRSystem}} MAY use this as a hint to temporarily disable passthrough. On devices with see-through optics, the user will continue to see their environment and this flag will have no effect. | ||
|
|
||
| The <dfn attribute for="XRRenderState">inlineVerticalFieldOfView</dfn> attribute defines the default vertical field of view in radians used when computing projection matrices for {{XRSessionMode/"inline"}} {{XRSession}}s. The projection matrix calculation also takes into account the aspect ratio of the [=XRRenderState/output canvas=]. This value MUST be `null` for [=immersive sessions=]. | ||
| The <dfn attribute for="XRRenderState">inlineVerticalFieldOfView</dfn> attribute defines the default vertical field of view in radians used when computing projection matrices for {{XRSessionMode/"inline"}} {{XRSession}}s. The projection matrix calculation also takes into account the aspect ratio of the [=XRRenderState/output canvas=]. For [=inline sessions=] with [=feature descriptor/multi-view=] and [=feature descriptor/head-tracked=] enabled, the user agent MUST compute per-view projection matrices using the [=viewer=] pose and the physical relationship between the [=viewer=] and the [=XRRenderState/output canvas=]. For [=inline sessions=] with [=feature descriptor/multi-view=] enabled but without [=feature descriptor/head-tracked=] enabled, the user agent MUST compute per-view projection matrices without using the user's head pose. This value MUST be `null` for [=immersive sessions=]. |
There was a problem hiding this comment.
Tying into the comments about using a new reference space, we really ought to describe how projections/view matrices are computed in this case. And beyond that, I can actually see a couple of plausible ways that developers might want to have those values computed. Basically, do you want this canvas to look into a full-sized 1:1 world that exists behind the page? For that you might want to use one of the existing reference spaces. Or do you want it to (more likely?) describe a space that works like the proposed CSS "portal", where the content scale doesn't have to be 1:1 and the space is described in relation to the canvas size and surface? That would probably need a new reference space.
There was a problem hiding this comment.
I think you want to the content to display as if it was a regular canvas but then in stereo. Isn't it already specified for 'inline'?
alcooper91
left a comment
alcooper91
left a comment
There was a problem hiding this comment.
Agree with Brandon that I'm a little confused about the exceptions and/or need for head-tracked.
I got rid of all the head-tracked weirdness in the spec. The author can decide if they want stereo to be required or optional. |
toji
left a comment
toji
left a comment
There was a problem hiding this comment.
This feels better (and simpler!) to me now, thanks!
I think we can move ahead with this as the basis, but I still think there's some additional issues we need to work out that probably ought to be filed separately and marked for discussion at an upcoming meeting.
- Is a UA allowed to advertise
immersive-stereobut only display one view (or report the same matricies for both views) for accessibility? We talked about it briefly at a previous meeting. - It's probably worth being more detailed about what the projection and view matrices should describe in the tracked inline stereo case. It's an area where I could easily see implementations diverging.
- Is the information being provided sufficient to display the type of content that developers want, which is likely a diorama-style scene that fits into the canvas regardless of scale (like the model tag). That would make it one of the first situations with WebXR where content isn't displayed with a 1 unit == 1 meter scale. Do we need to do anything different to account for that?
SHA: f19a6dd Reason: push, by cabanier Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Yes, we discussed this. In the previous proposal, it was allowed but now it's not. Developers can make 'inline-stereo' optional if they want to support that.
Yes, definitely.
Maybe a note? Otherwise, it would be a bunch of spec text with SHOULDs. |
SHA: f19a6dd Reason: push, by cabanier Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
|
The Model Element uses the page scale as its source of truth which helps it scale with page content. E.g. 1cm on the page is 1cm in the space |
4 participants
This proposal adds a new session mode "inline-stereo"
When requested from a user action, the UA MAY show a permission prompt asking for spatial permissions. If those are denied, the request was from a non-user action or if the UA decides to not allow head tracking, the browser MAY choose to display the content in fixed stereo.
Preview | Diff