Controller and ray position are UA dependent

[cabanier]

Someone reported an issue on twitter where the pointing ray was intersecting the model that was posted on the WebXR profiles repo.

We addressed that problem but then started thinking if this is something we should have done. Basically, we fixed the problem by changing hardcoded offsets to the positions that were returned by the OS so that the standard controller model and the ray appear in the right location.
However, by adding these offsets on the C++ side, we just changed the location of the pointing rays on experiences that use a different controller.
Moreover, if someone creates a WebXR experience with their own controller model, they will have to test on each platform and keep a list of each platform with different offsets.

/agenda Should there be a standard model that is correct across UAs? Should the WebXR profiles repo also supply correct offsets for position and ray?

[toji]

This is a good topic to discuss, because it's pretty intractable to try and account for every possible custom controller model. Worth pointing out in this case that the primary issue being reported (in my mind) was that the pointer ray in WebXR was noticeably offset from the same ray used by the home screen and other Oculus apps. I'd argue that consistency with the native system is worth making the change regardless of potential issues with custom controller visualizations. The fact that it also happens to fix some clipping issues when using the standard controller model is a pleasant bonus.

[cabanier]

I don't remember exactly what the conclusion was on this topic.
Were we going to wait and see if it was a significant problem down the road and then address it?

[toji]

I don't recall that we had any strong conclusions from this discussion, but I think the general leaning was that this should probably still be allowed to be platform dependent and encourage them to match the platform's native apps whenever possible. Especially given that it's relatively easy to use your own pointer ray when appropriate, but we should also consider advertising the expected pointer ray offset in the webxr-input-profiles entries.

[cabanier]

I don't recall that we had any strong conclusions from this discussion, but I think the general leaning was that this should probably still be allowed to be platform dependent and encourage them to match the platform's native apps whenever possible.

At least for the Oculus case, we don't return the native platform coordinates. We fiddled with them so the controller from the webxr-input-profiles lines up.

[cabanier]

FYI, having the quest browser fiddle with the native origin was a mistake on our part. The profiles on webxr-input-profiles should always assume that the native origin.