https://immersive-web.github.io/dom-overlays/#onbeforexrselect
An XRSessionEvent of type beforexrselect is dispatched on the DOM overlay element before generating a WebXR selectstart input event if the input source’s targetRaySpace intersects the DOM overlay element at the time the input device’s primary action is triggered.
This will have the same problem as immersive-web/layers#21 , this is enforcing a particular choice of pointing ray (the -Z axis of the targetRaySpace). In general while targetRaySpace is the preferred pointing ray, applications are free to offset it and render whatever they like.
As in immersive-web/layers#21 it might be worth having an XRRay field on XRInputSource that defaults to a ray at the origin along -Z (i.e. the default XRRay) that defines what the pointing ray is.
I feel like overall this doesn't impact the transient screen input case because the orientation doesn't matter when your ray is directly on the UI element, but if anyone implements floating DOM overlays for HMDs applications may want control over this. This can be added backwards compatibly, so it might be worth waiting for layers to figure this out and piggyback on the solution. Filing an issue here as well to just keep track.
(There's also a slight issue here in that we should define this as intersecting with the -Z axis of the target ray space, there is no such thing as "space intersects element", but that's a minor change: #30)
https://immersive-web.github.io/dom-overlays/#onbeforexrselect
This will have the same problem as immersive-web/layers#21 , this is enforcing a particular choice of pointing ray (the -Z axis of the targetRaySpace). In general while targetRaySpace is the preferred pointing ray, applications are free to offset it and render whatever they like.
As in immersive-web/layers#21 it might be worth having an
XRRayfield onXRInputSourcethat defaults to a ray at the origin along -Z (i.e. the default XRRay) that defines what the pointing ray is.I feel like overall this doesn't impact the transient screen input case because the orientation doesn't matter when your ray is directly on the UI element, but if anyone implements floating DOM overlays for HMDs applications may want control over this. This can be added backwards compatibly, so it might be worth waiting for
layersto figure this out and piggyback on the solution. Filing an issue here as well to just keep track.(There's also a slight issue here in that we should define this as intersecting with the -Z axis of the target ray space, there is no such thing as "space intersects element", but that's a minor change: #30)