Ensure platform conventions remain consistent for XRReferenceSpaces #1180
Conversation
Now that we have got rid of defining Y axes of reference spaces through gravity, we should at least specify that conventions of the underlying platforms should remain consistent for XRReferenceSpaces created within a single XRSession. Y axis is important since it defines what "horizontal" and "vertical" means - this will be needed for plane detection API.
|
@toji, @Manishearth - please take a look & let me know what you think. |
|
I think it's OK to leave this unspecified & rely on the underlying conventions of the platform (which we don't say for "bounded-floor" spaces - should we?), but if you think we should strengthen this in some way, I can address it in this PR. |
index.bs
Outdated
| @@ -1247,6 +1247,8 @@ An {{XRReferenceSpace}} is most frequently obtained by calling {{XRSession/reque | |||
|
|
|||
| - Passing a type of <dfn enum-value for="XRReferenceSpaceType">unbounded</dfn> creates an {{XRReferenceSpace}} instance. 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. | |||
|
|
|||
| Note: it is assumed that the conventions of the underlying platform regarding Y axes of the reference spaces stay consistent across different types of {{XRReferenceSpace}}s. In other words, if an XR system supports multiple reference spaces, their Y axes will be parallel to each other and point in the same direction for the duration of the {{XRSession}} in which they were created. This does not apply to {{XRReferenceSpaceType/"viewer"}} reference space, which does not rely on the conventions of the underlying platform for its orientation. | |||
There was a problem hiding this comment.
Looks good! One suggestion we came up with in the editors meeting:
| Note: it is assumed that the conventions of the underlying platform regarding Y axes of the reference spaces stay consistent across different types of {{XRReferenceSpace}}s. In other words, if an XR system supports multiple reference spaces, their Y axes will be parallel to each other and point in the same direction for the duration of the {{XRSession}} in which they were created. This does not apply to {{XRReferenceSpaceType/"viewer"}} reference space, which does not rely on the conventions of the underlying platform for its orientation. | |
| Note: it is assumed that the conventions of the underlying platform regarding Y axes of the reference spaces stay consistent across different types of {{XRReferenceSpace}}s. In other words, if an XR system supports multiple reference spaces, their Y axes will be parallel to each other and point in the same direction for the duration of the {{XRSession}} in which they were created. This does not apply to {{XRReferenceSpaceType/"viewer"}}, which does not rely on the conventions of the underlying platform for its orientation. {{XRReferenceSpaceType/"unbounded"}} reference spaces should align their Y axes with other reference spaces when their origins are nearby, but may deviate if the user moves over large distances. |
There was a problem hiding this comment.
One question: all other reference spaces become practically non-functional in case the user moves far away from them (the poses must be limited algorithm ensures the poses won't be returned), so is this addition going to affect anything that is observable?
There was a problem hiding this comment.
Yes, imagine if I set up an unbounded reference space while at home, and then walk a mile. The local reference spaces will have y axes that are offset from mine by approximately a minute (1/60th of a degree)
There was a problem hiding this comment.
Hmm, but would that be observable through anything we expose on the API? Querying frame.getPose(local, unbounded) will give you null in that case, so any deviation between Y axes is not obtainable by the app and we do not really need to specify what happens in this case. & then when local space readjusts itself (via space reset event) to be closer to unbounded space, and any offset between Y axes of those 2 spaces disappears. I guess this addition is technically correct & it's not going to break anything, I'm just worried that it makes me go back to square one when trying to define what a "horizontal/vertical plane" is w/o also specifying a reference space through which those terms are defined.
There was a problem hiding this comment.
I think I may be able to either lean on "conventions of the underlying platform" and shift the responsibility to the platform to say what it thinks is horizontal/vertical. Alternatively, maybe I could go with sth along the lines of "horizontal plane is a plane whose normal is perpendicular to XZ plane of any reference space except 'local'", and since plane normal is obtainable via a call to getPose(), I may not need to worry about reference spaces deviating from each other across large distances. This may be workable...
There was a problem hiding this comment.
I'm approving the suggestion and keeping this conversation open, if you decide that the suggested addition is not needed after all, we can revert the commit. Otherwise, I'm OK to merge the PR so please merge it when you have a moment.
There was a problem hiding this comment.
Yes, should rely on conventions of the underlying platform.
I think we can define these things in terms of local, yes.
There was a problem hiding this comment.
In that case, I think we can either merge the PR as-is, or close it w/o merging, as I may not be able to lean on this note after all due to the reference space drift. I'll leave the decision up to you & @toji.
Additionally, I made a mistake, in the "(...) perpendicular to XZ plane of any reference space except 'local' 'viewer'".
Co-authored-by: Brandon Jones <[email protected]>
|
Post-merge LGTM here too. Thanks for taking the time to clarify this! |
Now that we have got rid of defining Y axes of reference spaces through
gravity, we should at least specify that conventions of the underlying
platforms should remain consistent for XRReferenceSpaces created within
a single XRSession. Y axis is important since it defines what
"horizontal" and "vertical" means - this will be needed for plane
detection API.
Preview | Diff