Conversation
|
I think this also fixes #478. |
NellWaliczek
left a comment
There was a problem hiding this comment.
I still want to think one more time to make sure we aren't accidentally removing a use case, but in the meanwhile, here's some feedback...
|
Updated to address all applicable feedback. Please take another look! |
|
|
||
| ### Stationary experiences | ||
| A _stationary_ experience is one which does not require the user to move around in space. This includes several categories of experiences that developers are commonly building today, and multiple reference space types are available to address each class of experience. "Standing" experiences can be created with a `floor-level` reference space. "Seated" experiences can be created with an `eye-level` reference space. | ||
| A _stationary_ experience is one which does not require the user to move around in space. This includes several categories of experiences that developers are commonly building today, and multiple reference space types are available to address each class of experience. "Standing" experiences can be created with a `floor-level` reference space. "Seated" experiences can be created with an `eye-level` reference space. Orientation-only experiences such as 360 photo/video viewers can also be created with an `eye-level` reference space, though in that case positional data should be ignored in order to display the media properly. |
There was a problem hiding this comment.
though in that case positional data should be ignored in order to display the media properly.
Is this actually the guidance? Thought it was to render the content on sufficiently far away surrounding geometry....
There was a problem hiding this comment.
Either approach works, and there's minor pros/cons to each but no so much that it really makes a difference in terms of guidance here.
There was a problem hiding this comment.
Then let's say something like this?
Orientation-only experiences such as 360 photo/video viewers can also be created with an
eye-levelreference space, and in that case one method would be to ignore the positional data in order to display the media properly.
There was a problem hiding this comment.
Did one better and expanded this into it's own paragraph to give both options and explain why.
|
|
||
| ### Viewer reference spaces | ||
| A _viewer_ reference space tracks the origin of the viewer. This type of reference space is primarily used for creating inline experiences with no tracking information. Instead, developers may use `XRReferenceSpace.originOffset` which is described in the [Application supplied transforms section](#application-supplied-transforms). An example usage of an _viewer_ reference space is a furniture viewer that will use [click-and-drag controls](#click-and-drag-view-controls) to rotate the furniture. It also supports cases where the developer wishes to avoid displaying any type of tracking consent prompt to the user prior while displaying inline content. | ||
| A _viewer_ reference space's origin is always at the position and orientation of the viewer device. This type of reference space is primarily used for creating inline experiences with no tracking of the viewer relative to it's physical environment. Instead, developers may use `XRReferenceSpace.originOffset` which is described in the [Application supplied transforms section](#application-supplied-transforms). An example usage of an _viewer_ reference space is a furniture viewer that will use [click-and-drag controls](#click-and-drag-view-controls) to rotate the furniture. It also supports cases where the developer wishes to avoid displaying any type of tracking consent prompt to the user prior while displaying inline content. |
There was a problem hiding this comment.
XRReferenceSpace.originOffset
Are we planning to fixing the explainer text about originOffset in a separate PR?
There was a problem hiding this comment.
Yeah, that's a large enough change that I'd feel more comfortable handling it separately from this issue.
There was a problem hiding this comment.
Fine by me. Can you file an issue to track that?
/Fixes #625 Removes the position-disabled reference space from the spec and explainers. Developers that wish to display the types of content this reference space supported (primarily 360 media) should instead manually zero-out the position of the XRView transforms when rendering.
|
Okay, remainder of Nell's comments are addressed or responded to. |
NellWaliczek
left a comment
There was a problem hiding this comment.
Thanks so much for working through the details of this (significant) simplification! Approving under the assumption that the remaining two minor items of feedback will be addressed :)
/Fixes #625
/Fixes #623
(Happy to split these two out, but it felt like it would be clearer to view
both changes at once.)
Removes the position-disabled reference space from the spec and
explainers. Developers that wish to display the types of content this
reference space supported (primarily 360 media) should instead manually
zero-out the position of the XRView transforms when rendering.
Also consolidates the
viewerSpaceattribute and theidentityreferencespace into a single new reference space called
viewer. This newspace is functionally equivalent to the previous
viewerSpacebutfetched via
requestReferenceSpace()with the same guarantee ofavailability as
identityhad previously. All other spaces relate to itlike any other space.