Clarify assumptions for local and local-floor tracking#648
Merged
toji merged 2 commits intoimmersive-web:masterfrom May 15, 2019
Merged
Clarify assumptions for local and local-floor tracking#648toji merged 2 commits intoimmersive-web:masterfrom
toji merged 2 commits intoimmersive-web:masterfrom
Conversation
toji
reviewed
May 15, 2019
spatial-tracking-explainer.md
Outdated
| Orientation-only experiences such as 360 photo/video viewers can also be created with an `local` reference space by either explicitly ignoring the pose's positional data or displaying the media "infinitely" far away from the viewer. If such position mitigation steps are not taken the user may perceive the geometry the media is displayed on, leading to discomfort. | ||
|
|
||
| It is important to note that `XRViewerPose` objects retrieved using `local` reference spaces may include position information as well as rotation information. For example, hardware which does not support 6DOF tracking (ex: GearVR) may still use neck-modeling to improve user comfort. Similarly, a user may lean side-to-side on a device with 6DOF tracking (ex: HTC Vive). The result is that `local` experiences must be resilient to position changes despite not being dependent on receiving them. | ||
| It is important to note that `XRViewerPose` objects retrieved using `local` reference spaces may include position information as well as rotation information. For example, hardware which does not support 6DOF tracking (ex: GearVR) may still use neck-modeling to improve user comfort. Similarly, a user may lean side-to-side on a device with 6DOF tracking (ex: HTC Vive). The result is that `local` experiences must be resilient to position changes despite not being dependent on receiving them. Experiences are encouraged to fully support head movement in a typical seated range. For some hardware the poses may even include substantial position offsets, for example if the user stands up from their seated position and walks around. The experience can choose to react to this appropriately, for example by fading out the rendered view when intersecting geometry. Overriding the pose's reported head position, for example clamping to stay within an expected volume, can be very uncomfortable to users and should be avoided. |
Member
There was a problem hiding this comment.
This is a great addition, but I feel like it would read a bit better if we put most of your added text in it's own paragraph. Maybe something like so:
... The result is that
localexperiences must be resilient to position changes despite not being dependent on receiving them, and are encouraged to fully support head movement in a typical seated range.For some hardware the poses may even include substantial position offsets, for example if the user stands up from their seated position and walks around....
Contributor
Author
|
This is a great addition, but I feel like it would read a bit better if
we put most of your added text in it's own paragraph. Maybe something like
so:
Done.
*From: *Brandon Jones <notifications@github.com>
*Date: *Wed, May 15, 2019 at 11:32 AM
*To: *immersive-web/webxr
*Cc: *Klaus Weidner, Author
*@toji* commented on this pull request.
… ------------------------------
In spatial-tracking-explainer.md
<#648 (comment)>:
> @@ -119,7 +119,7 @@ function onSessionStarted(session) {
Orientation-only experiences such as 360 photo/video viewers can also be created with an `local` reference space by either explicitly ignoring the pose's positional data or displaying the media "infinitely" far away from the viewer. If such position mitigation steps are not taken the user may perceive the geometry the media is displayed on, leading to discomfort.
-It is important to note that `XRViewerPose` objects retrieved using `local` reference spaces may include position information as well as rotation information. For example, hardware which does not support 6DOF tracking (ex: GearVR) may still use neck-modeling to improve user comfort. Similarly, a user may lean side-to-side on a device with 6DOF tracking (ex: HTC Vive). The result is that `local` experiences must be resilient to position changes despite not being dependent on receiving them.
+It is important to note that `XRViewerPose` objects retrieved using `local` reference spaces may include position information as well as rotation information. For example, hardware which does not support 6DOF tracking (ex: GearVR) may still use neck-modeling to improve user comfort. Similarly, a user may lean side-to-side on a device with 6DOF tracking (ex: HTC Vive). The result is that `local` experiences must be resilient to position changes despite not being dependent on receiving them. Experiences are encouraged to fully support head movement in a typical seated range. For some hardware the poses may even include substantial position offsets, for example if the user stands up from their seated position and walks around. The experience can choose to react to this appropriately, for example by fading out the rendered view when intersecting geometry. Overriding the pose's reported head position, for example clamping to stay within an expected volume, can be very uncomfortable to users and should be avoided.
This is a great addition, but I feel like it would read a bit better if we
put most of your added text in it's own paragraph. Maybe something like so:
... The result is that local experiences must be resilient to position
changes despite not being dependent on receiving them, *and are
encouraged to fully support head movement in a typical seated range.*
*For some hardware the poses may even include substantial position
offsets, for example if the user stands up from their seated position and
walks around.*...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#648?email_source=notifications&email_token=AAKT5X2EYNUPSKJJFEXKGLTPVRJKDA5CNFSM4HNFKIT2YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOBYXY7CI#pullrequestreview-237997961>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAKT5X7ZP3RYVTQXQWTIOV3PVRJKDANCNFSM4HNFKITQ>
.
|
Member
|
Thanks! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.