Ray parameter as full matrix? #8
Comments
|
I think on the last call I was advocating for the point/vector, but I don't feel strongly either way. The argument that many libraries use matrices is compelling; three.js uses Ray's for it's intersection's, tho. So, it's unclear if that's a strong argument. It's a ray. Represent it as a ray! |
|
If we do end up finding that there are multiple patterns of usage, we could consider using an object or union as the input type. For now, we might start with consistency (and a single parameter), and see what feedback we get from authors. |
|
Aside from the issue of needing multiple sorts of hitTests (screen-based and ray-based) (e.g., #7), I'd tend to agree. |
…ction vectors.
pointerOrigin is now named 'targetRayMode' and can have values to { 'gazing', 'pointing', 'tapping' }.
pointerPose is now a ray consisting of two properties: 'targetRayOrigin' and 'targetRayDirection'.
This is to be in line with immersive-web/hit-test#8 until a final approach in immersive-web#339 is determined.
…ction vectors.
pointerOrigin is now named 'targetRayMode' and can have values to { 'gazing', 'pointing', 'tapping' }.
pointerPose is now a ray consisting of two properties: 'targetRayOrigin' and 'targetRayDirection'.
This is to be in line with immersive-web/hit-test#8 until a final approach in #339 is determined.
|
Closing as WebXR is now using XRRays directly so using a ray here is more consistent with the spec. |
To be consistent with the rest of WebXR, the ray should be specified as a full 4x4 matrix rather than a position/direction vector pair. This is technically over-specified for a ray and shearing a ray is not something that would be useful, however the argument could be made that it is more compatible with the math types that are acquired from other systems so you can just feed parameters in directly without having to generate a origin/direction.
The text was updated successfully, but these errors were encountered: