Consolidate reference space types and interfaces #587

toji · 2019-04-12T22:51:51Z

Since #574 leaves XRStationaryReferenceSpace with nothing else in it, taking the opportunity to consolidate it and XRUnboundedReferenceSpace into XRReferenceSpace, as was discussed in #514.

Originally was part of #574 but separated the consolidation out at Nell's request.

Manishearth · 2019-04-13T02:21:51Z

index.bs

-An {{XRReferenceSpace}} is obtained by calling {{XRSession/requestReferenceSpace()}}, which creates an instance of an interface extending {{XRReferenceSpace}}, determined by the {{XRReferenceSpaceOptions/type}} value of the {{XRReferenceSpaceOptions}} dictionary passed into the call:
+An {{XRReferenceSpace}} is obtained by calling {{XRSession/requestReferenceSpace()}}, which creates an instance of an {{XRReferenceSpace}} or an interface extending it, determined by the {{XRReferenceSpaceOptions/type}} value of the {{XRReferenceSpaceOptions}} dictionary passed into the call. The {{XRReferenceSpaceOptions/type}} indicates the tracking behavior that the reference space will exhibit:
+
+  - Passing a {{XRReferenceSpaceOptions/type}} of <dfn enum-value for="XRReferenceSpaceType">identity</dfn> creates an {{XRReferenceSpace}} instance. It represents a reference space without any tracking behavior. The {{XRPose/transform}} of any {{XRPose}} queried from an {{identity}} reference space MUST be an [=identity transform=] offset by the {{originOffset}}.


Given the discussion in #565 this characterization seems inaccurate? The pose queried changes based on the base space used, a more accurate characterization is that "getViewerPose" should always return the identity transform (potentially offset with originOffset).

Reworked this text, though I think it's going to need to be updated again when we land some of the planed changes re: describing these spaces in terms of the native origin as you've started looking at.

toji · 2019-04-26T23:23:50Z

Combined this PR with another one that I had in progress to consolidate the reference space type and subtype enums because @NellWaliczek and I both think these changes make the most sense when taken together. As a result this PR now fully fixes #514 and fixes #542.

NellWaliczek

I'm on board with this approach. A few minor nits to fix and then I'll sign off!

index.bs

NellWaliczek · 2019-04-29T23:49:31Z

index.bs


-  - Passing a {{XRReferenceSpaceOptions/type}} of <dfn enum-value for="XRReferenceSpaceType">unbounded</dfn> creates an {{XRUnboundedReferenceSpace}} instance if supported by the [=/XR device=] and the {{XRSession}}.
+  - Passing a type of <dfn enum-value for="XRReferenceSpaceType">eye-level</dfn> creates an {{XRReferenceSpace}} instance. It represents a tracking space with it's origin near the user's head at the time of creation. The exact position and orientation will be initialized based on the conventions of the underlying platform. When using this reference space the user is not expected to move beyond their initial position much, if at all, and tracking is optimized for that purpose. For devices with [=6DoF=] tracking, {{eye-level}} reference spaces should emphasize keeping the origin stable relative to the user's environment.


The exact position and orientation will be initialized based on the conventions of the underlying platform.

Should we change this to say that the originOffset should be set such that the behavior is always the same?

This actually raises a good question about our understanding of the native origin: I guess I had been viewing it as the "base" origin for a reference space, regardless of if the UA had to apply some internal tweaks to get it there. This comment suggests you see the native origin as a function of the underlying XR backend and completely out of the UAs control, with origin offsets being applied in any case where the desired reference space does not already happen to match the platform-provided one. I'm fine with that interpretation, though if that's the case we should not land this PR until after #612 lands and removes the originOffset attribute.

I've been viewing it the same way (and in fact Nell's comment didn't initially make sense to me since I wasn't sure what the behavior was supposed to be the same to).

Her interpretation makes sense too, though it surprises me a bit.

I guess I'm unclear on when such a situation can occur.

I'm not sure it really strongly matters either way, but the term "native" origin implies to me that it's the origin as defined by the underlying tracking system...

index.bs

spatial-tracking-explainer.md

toji · 2019-04-30T06:12:02Z

Made a few tweaks in response to Nell's comments, but had an open question about the native origin/origin offset thing.

NellWaliczek

Given that all my remaining comments would more appropriately be addressed in the next milestone when we fix #597, i'm good to merge as is.

NellWaliczek · 2019-04-30T17:58:10Z

index.bs

@@ -766,21 +766,21 @@ Each {{XRReferenceSpace}} has a <dfn for="XRReferenceSpace">type</dfn>, which is

 An {{XRReferenceSpace}} is obtained by calling {{XRSession/requestReferenceSpace()}}, which creates an instance of an {{XRReferenceSpace}} or an interface extending it, determined by the {{XRReferenceSpaceType}} enum value passed into the call. The type indicates the tracking behavior that the reference space will exhibit:

-  - Passing a type of <dfn enum-value for="XRReferenceSpaceType">identity</dfn> creates an {{XRReferenceSpace}} instance. It represents a reference space where the [=viewer=] is always at the origin (prior to applying the {{originOffset}}). Only the {{XRSession/viewerSpace}} and {{XRInputSource/targetRaySpace}}'s of {{XRInputSource}}'s with an {{XRInputSource/targetRayMode}} of {{XRTargetRayMode/screen}} can be spatially related to an {{identity}} reference space.
+  - Passing a type of <dfn enum-value for="XRReferenceSpaceType">identity</dfn> creates an {{XRReferenceSpace}} instance. It represents a reference space where the [=viewer=] is always at the [=native origin=]. Only the {{XRSession/viewerSpace}} and {{XRInputSource/targetRaySpace}}'s of {{XRInputSource}}'s with an {{XRInputSource/targetRayMode}} of {{XRTargetRayMode/screen}} can be spatially related to an {{identity}} reference space.


It represents a reference space where the [=viewer=] is always at the [=native origin=]

And that the [=native origin=] is a constant.. or doesn't vary.. or something?

Does that matter, in this case, if it can't relate to anything else?

NellWaliczek · 2019-04-30T20:14:42Z

index.bs

-  - Passing a type of <dfn enum-value for="XRReferenceSpaceType">unbounded</dfn> creates an {{XRReferenceSpace}} instance if supported by the [=/XR device=] and the {{XRSession}}. It represents a tracking space where the user is expected to move freely around their environment, potentially even long distances from their starting point. Tracking in an {{unbounded}} reference space is optimized for stability around the user's current position, and as such the tracking origin may drift over time.
+  - Passing a type of <dfn enum-value for="XRReferenceSpaceType">unbounded</dfn> creates an {{XRReferenceSpace}} instance if supported by the [=/XR device=] and the {{XRSession}}. It represents a tracking space where the user is expected to move freely around their environment, potentially even long distances from their starting point. Tracking in an {{unbounded}} reference space is optimized for stability around the user's current position, and as such the [=native origin=] may drift over time.
+
+Devices that support any of the following {{XRReferenceSpaceType}}s MUST support all three: {{XRReferenceSpaceType/position-disabled}}, {{XRReferenceSpaceType/eye-level}}, {{XRReferenceSpaceType/floor-level}}. The minimum sensor data necessary for supporting all three reference spaces is the same.


The minimum sensor data necessary for supporting all three reference spaces is the same.

Not necessarily the case for the floor-level type, yes?

The word "minimum" is doing a lot of lifting in that sentence. You can get an emulated floor-level with nothing but orientation data and a static offset.

Manishearth · 2019-04-30T23:22:22Z

Btw, I've rebased this over #612 in https://github.com/Manishearth/webxr/tree/consolidate, feel free to use.

(I need this to start working on https://github.com/immersive-web/editor-collab/pull/38 )

toji · 2019-05-01T00:14:42Z

Apologies, @Manishearth. I actually merged this in the opposite order (resolving the conflicts along the way.) Hopefully you can rebase your change onto the new master without much trouble?

Manishearth · 2019-05-01T00:17:11Z

Oh, that's fine, I hadn't made any major changes yet :)

toji requested a review from NellWaliczek April 12, 2019 22:51

toji added this to the May '19 Working Draft milestone Apr 12, 2019

toji mentioned this pull request Apr 12, 2019

Remove attribs that only reflect requested values #574

Merged

Manishearth reviewed Apr 13, 2019

View reviewed changes

toji force-pushed the remove-echoes branch from e92d238 to 704be91 Compare April 15, 2019 22:16

toji force-pushed the remove-empty-ref-spaces branch from e6159ee to 7a51b4e Compare April 15, 2019 22:17

Manishearth mentioned this pull request Apr 16, 2019

We should distinguish viewerSpace from other XRSpaces #581

Closed

toji force-pushed the remove-echoes branch 3 times, most recently from a3341f2 to 6714aa2 Compare April 18, 2019 18:26

toji force-pushed the remove-empty-ref-spaces branch from 7a51b4e to e8828d1 Compare April 19, 2019 17:58

Manishearth mentioned this pull request Apr 20, 2019

Explicitly spec out "native origin" behind each XRSpace #597

Closed

toji force-pushed the remove-empty-ref-spaces branch from e8828d1 to 8c0b47e Compare April 26, 2019 21:41

toji changed the base branch from remove-echoes to master April 26, 2019 21:42

toji changed the title ~~Consolidate reference space interfaces~~ Consolidate reference space types and interfaces Apr 26, 2019

NellWaliczek reviewed Apr 29, 2019

View reviewed changes

NellWaliczek mentioned this pull request Apr 30, 2019

Make origin offset immutable #612

Merged

toji added 5 commits April 29, 2019 22:29

Consolidate reference space interfaces

39a109c

Merge reference space type and subtype dictionaries

13f1dbe

Address Manish's feedback

75ea421

Updated the explainer

397813c

Addressing some feedback

ff5a111

toji force-pushed the remove-empty-ref-spaces branch from 1001365 to ff5a111 Compare April 30, 2019 06:04

NellWaliczek approved these changes Apr 30, 2019

View reviewed changes

toji merged commit 4b44c1a into master May 1, 2019

toji mentioned this pull request May 1, 2019

Combine XRStationaryReferenceSpaceSubtype into XRReferenceSpaceType #514

Closed

This was referenced May 1, 2019

Consider primary type plus options bag pattern in request methods #542

Closed

Does originOffset behave differently for identity reference space? #477

Closed

toji deleted the remove-empty-ref-spaces branch May 2, 2019 18:07

AdaRoseCannon added ed:explainer Include in newsletter, explainer change ed:spec Include in newsletter, spec change labels May 8, 2019


		- Passing a {{XRReferenceSpaceOptions/type}} of <dfn enum-value for="XRReferenceSpaceType">unbounded</dfn> creates an {{XRUnboundedReferenceSpace}} instance if supported by the [=/XR device=] and the {{XRSession}}.
		- Passing a type of <dfn enum-value for="XRReferenceSpaceType">eye-level</dfn> creates an {{XRReferenceSpace}} instance. It represents a tracking space with it's origin near the user's head at the time of creation. The exact position and orientation will be initialized based on the conventions of the underlying platform. When using this reference space the user is not expected to move beyond their initial position much, if at all, and tracking is optimized for that purpose. For devices with [=6DoF=] tracking, {{eye-level}} reference spaces should emphasize keeping the origin stable relative to the user's environment.

Consolidate reference space types and interfaces #587

Consolidate reference space types and interfaces #587

Uh oh!

Conversation

toji commented Apr 12, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

toji commented Apr 26, 2019

Uh oh!

NellWaliczek left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

toji commented Apr 30, 2019

Uh oh!

NellWaliczek left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Manishearth commented Apr 30, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

toji commented May 1, 2019

Uh oh!

Manishearth commented May 1, 2019

Uh oh!

Uh oh!

Manishearth commented Apr 30, 2019 •

edited

Loading