Clarify some things about native origins #1071
Conversation
| @@ -1223,7 +1227,7 @@ The <dfn method for="XRReferenceSpace">getOffsetReferenceSpace(|originOffset|)</ | |||
| <dt> Else | |||
| <dd> Let |offsetSpace| be a [=new=] {{XRReferenceSpace}} in the [=relevant realm=] of |base|. | |||
| </dl> | |||
| 1. Set |offsetSpace|'s [=native origin=] to |base|'s [=native origin=]. | |||
| 1. Set |offsetSpace|'s [=XRReferenceSpace/type=] to |base|'s [=XRReferenceSpace/type=]. | |||
There was a problem hiding this comment.
The changes higher up look fine, and mesh with my recollection of the intent behind these terms. I feel like this may have lost something, though. Shouldn't we be copying both the native origin and the type?
There was a problem hiding this comment.
The native origin is already defined for all XRReferenceSpaces above, it's not necessary to copy it, because we already define what it is in all cases
|
Oops, should not have been a draft, that was just a CLI reflex |
| @@ -1098,7 +1098,11 @@ An {{XRSpace}} represents a virtual coordinate system with an origin that corres | |||
|
|
|||
| Each {{XRSpace}} has a <dfn for="XRSpace">session</dfn> which is set to the {{XRSession}} that created the {{XRSpace}}. | |||
|
|
|||
| Each {{XRSpace}} has a <dfn for="XRSpace">native origin</dfn> that is tracked by the [=XRSession/XR device=]'s underlying tracking system, and an <dfn for="XRSpace">effective origin</dfn>, which is the basis of the {{XRSpace}}'s <dfn for="XRSpace">coordinate system</dfn>. The transform from the effective space to the [=native origin=]'s space is defined by an <dfn for="XRSpace">origin offset</dfn>, which is an {{XRRigidTransform}} initially set to an [=identity transform=]. | |||
| Each {{XRSpace}} has a <dfn for="XRSpace">native origin</dfn> which is a position and orientation in space. The {{XRSpace}}'s [=XRSpace/native origin=] may be updated by the [=XRSession/XR device=]'s underlying tracking system, and different {{XRSpaces}} may define different semantics as to how their [=native origins=] are tracked and updated. | |||
There was a problem hiding this comment.
"a position and orientation in space" - which space, & more importantly, at what time? Having a time-dependent property on objects that live outside of any particular time is surprising to me. This seems to make native origins not very useful since UAs will always have to query the XR systems about poses in a time-indexed manner (as per discussions in immersive-web/anchors#37, getPose() can be invoked on a historical frame), unless we specify exactly when the underlying system is supposed to update the native origins.
There was a problem hiding this comment.
"Real world space".
Yeah, this is supposed to be a quantity you can query for different times -- "natve origin at time T".
This led to some confusion in immersive-web/anchors#46.
Namely, native origins as a "type" are not some special tracked entity, rather, the object holding on to them has specal tracking behavior for updating them. Otherwise we are passing around types with spooky underspecified semantics.
This also corrects how origin offsets work, there is no point in copying the native origin, it's the type which must be copied.
Preview | Diff