search

mozilla / webxr-polyfill

A polyfill and example code for building augmented reality (AR) and virtual reality (VR) applications using WebXR.
Mozilla Public License 2.0
260 stars 67 forks source link

Raycasting is incorrect in mobile AR #88

Open RSpace opened 6 years ago

RSpace commented 6 years ago

I posted this issue as a question on Stack Overflow as I was unsure of whether it was a bug in this polyfill, three.xr.js or aframe-xr:

https://stackoverflow.com/questions/49009873/why-is-raycast-direction-calculated-incorrectly-in-webxr

However, the recent pointer with SITTING_EYE_HEIGHT and the fact that changing this constant to 0 goes some way to fix the raycasting issue has led me to believe that this is an issue that should be fixed in this polyfill.

What is the rationale for having a fixed eye height, as was introduced (or refactored) in this commit: https://github.com/mozilla/webxr-polyfill/commit/2a6b4e00c6e39cc8a91939c9662e3cba10be2c12

Why would the raycast direction still be off on the x-axis when setting SITTING_EYE_HEIGHT to 0?

blairmacintyre commented 6 years ago

Hi, I know there's been discussion on the AFrame slack about this, but I thought I'd follow up here.

The idea behind the SITTING_EYE_HEIGHT was to provide some notion of a "floor" for systems that don't have it (since VR devices have a stage / floor). But, I think the idea is fundamentally flawed: such assumptions will always be "not quite right".

So, I think I'm going to change the polyfill to get rid of it, and keep the little utility function to create a "floorAnchor" (since our samples use it). So, I'll be changing the SITTING_EYE_HEIGHT to 0 (or removing it).

BUT, that doesn't explain your X offset. I don't see that, although I haven't tried the AFrame raycaster.