Cursor component: fixes for WebXR mode

[JL-Vidinoti]

Description:

This PR fixes a couple of small issues when using the cursor component with rayOrigin: xrselect.

Changes proposed:

• If the cursor component is attached to an entity other than a-scene, an error occurs.
• The XR Session events are not unregistered when the cursor attribute is removed.

[mrxz]

While I'm not entirely sure about the history of the cursor component, it seems to me that the original intent was for cursors with rayOrigin: xrselect to be defined on <a-scene>. I don't think there is any harm in making it work on any arbitrary entity, but more changes might be needed. Looking through the code it seems that rayOrigin: xrselect actually causes the underlying raycaster to not use world coordinates, meaning incorrect results can happen when the entity is translated or rotated.

As for the event listeners, the change looks good, but addEventListeners should be amended as well. In case the cursor component is added during an XR session (or when calling .pause()/.play()) there won't be an enter-vr event, but the relevant listeners should still be added.

[JL-Vidinoti]

I am doing some tests with the Vision Pro. The cursor component works with the mode xrselect using eye gaze (see the new input mode Apple introduced https://webkit.org/blog/15162/introducing-natural-input-for-webxr-in-apple-vision-pro/).

If we use a camera rig like below, it is necessary to add the cursor component to the rig (not to the scene) otherwise the computed eye gaze origin is wrong when moving the rig.

<a-entity id="rig" cursor="rayOrigin: xrselect;">
    <a-entity id="camera" camera look-controls position="0 1.6 0" ></a-entity>
</a-entity>

I see your point with the addEventListener, should I update the PR?

[mrxz]

If we use a camera rig like below, it is necessary to add the cursor component to the rig (not to the scene) otherwise the computed eye gaze origin is wrong when moving the rig.

I see, I still think this is something that the cursor component could and should handle internally. The ray's origin and direction retrieved from the WebXR API is relative to the reference space, and it should be translated to world space based on the camera parent's transform. Requiring the user to place the cursor on the rig just opens the possibility of users either forgetting it or placing it on the wrong entity. Not to mention situations where the camera is changed to a different camera/rig.

Put differently, there is no meaningful reason to use a different entity than the rig. And since A-Frame knows the reference space and the relevant transform of the reference space (parent transform of the active camera), there's no reason to require the user to specify/configure it manually.

I see your point with the addEventListener, should I update the PR?

Updating the PR would be nice, it makes sense to have removeEventListener and addEventListener updated at the same time.

[JL-Vidinoti]

I updated the handling of the WebXR event listeners such that they are correctly registered/unregistered.
Concerning the cursor component, I think that is is up to the user whether he adds it to the scene or any other entity.