Exploring the use of traditional Three.js raycasting in a web-based augmented reality application, not focused on AR hit-testing on actual surfaces.
The web application integrates A-Frame with the aframe-xr component to enable WebXR support in the WebXR Viewer for iOS and WebARCore for Android, successfully incorporating augmented reality features in these experimental browsers.
However, an issue arises within aframe-xr or the included libraries like three.xr.js and WebXR polyfill, causing an incorrect projection of the raycast direction in the experimental browsers supporting WebXR. While the origin of the raycast is accurate (at the current camera position), the direction consistently deviates downwards (y-coordinate offset too low) and slightly to the left (x-coordinate offset too small).
Coincidentally, the y-offset aligns with the default 1.6 meters camera offset previously managed by A-Frame, now possibly handled by Three.js in the newest version of A-Frame, upon which aframe-xr relies for functionality.
This discrepancy does not exist universally across raycasting operations, as evidenced by this incident reproduction on Glitch, where test outcomes are detailed as follows:
Device/Example run | Normal 0.7.0 | WebXR | Normal 0.8.0 |
-----------------------|----------------|---------------|------------------|
Windows Chrome w/mouse | Correct | Correct | Correct |
S8 Chrome | Correct | Correct | Correct |
S8 WebARCore | Correct | Incorrect | Correct |
iPad Safari | Correct | Correct | Correct |
iPad WebXR Viewer | Correct | Incorrect | Correct |
In this comparison, "correct" indicates expected directional calculation with the sphere appearing appropriately underneath the cursor, while "incorrect" signifies erroneous direction vector output leading to misalignment of the sphere's visualization.
View the code for these instances here:
What causes the miscalculation of raycast direction in the WebXR libraries, and what corrective measures can be implemented?
Additional insight: Conducted tests utilizing the aframe-ar component showcased correct raycasting functionality in WebARCore on Android (potentially omitting the webxr polyfill), yet inconsistencies persisted with a distinct offset in WebXR Viewer on iPad (likely involving the utilization of the webxr polyfill).
Update: Per Roberto's feedback below, modifying the SITTING_EYE_HEIGHT constant in the webxr-polyfill by setting it to 0 offers some improvement but falls short of a comprehensive solution. With this adjustment - accessible here for testing - initial raycast direction accuracy is observed; however, any subsequent device movement or rotation results in direction miscalculations.