VR: Controller cursor is on a plane beyond the content quad - creates a corner |
||
Issue descriptionChrome Version: Pixel XL with 60.0.3110.0 OS: Android What steps will reproduce the problem? (1) In the VR browser, move the controller cursor left or right of content quad by about half the width of the content quad, then further. What is the expected result? The cursor is consistently facing the user. What happens instead? The cursor runs along a plane extending from the content quad then suddenly turns to face the user, as if there was a corner. It maintains this all the way around until it hits the corner on the other side of the quad. Please use labels and text to provide additional information. There is a similar corner where the "wall" that the quad is on meets the "floor." This one is probably more expected if you understand that there is a floor and wall. However, the cursor is cut off slightly near the floor then suddenly turns to be on the floor.
,
May 29 2017
This isn't so much a bug as intended behaviour. We've had this discussion many times now :P The reason we have a plane at the content quad depth is we didn't want your cursor jumping a lot in the z-axis when using the UI elements, as your eyes don't adjust to depth changes in the cursor very quickly, and a planar depth limit works well for 2D UI. The reason the cursor doesn't always face the user is that it's very strange when your cursor hovers above the 2D plane you're trying to target. The cursor facing the user makes perfect sense in a curved UI, but for targeting web contents it's just weird. We would also have make sure that the cursor doesn't cut into the thing you're targeting, which it would if you drew it at the element's depth, but not on the same plane. The reason there's a corner is at some point the plane has to merge with either a spherical distance limiter, the floor, or the ceiling (though we should maybe make the ceiling not hit-testable?).
,
May 29 2017
The cursor already doesn't behave like a laser or flashlight, and you can see that's the case using Daydream home. This is probably because humans are really bad at pointing at objects in 3-space with a 3-dof controller. The cursor cheats and loosely approximates a laser, but instead computes the intersection between your eye and where the laser would be at a fixed depth, rather than where the laser would actually intersect. This allows the reticle to move consistently across your fov through depth changes, while the laser jumps around, instead of the laser moving consistently and the reticle jumping around. The laser really only exists to help you find the reticle if you forget where it is.
,
Aug 11 2017
Based on this discussion, the cursor is currently Working as Intended, correct? The UI work Ian's pushing will rework the sorting and rendering of elements, and will totally change how reticle is drawn. Based on this, I believe we should close this.
,
Aug 11 2017
David, if you object, please reopen. Otherwise, we have nothing to do here. |
||
►
Sign in to add a comment |
||
Comment 1 by ddorwin@chromium.org
, May 26 2017