When a user has several unrelated overlay applications open which implement their own laser behavior using ComputeOverlayIntersection, interaction passes through to all overlays which are along that path even if one is visually occluding another. This is very confusing for users and makes it difficult to build applications which play nice with each other.
It would be nice if ComputeOverlayIntersection defaulted to taking occlusion by other overlays into account. In this mode, no intersection would be returned if another overlay closer to the controller is also intersecting the laser. This would allow implementing this behavior with no apparent change to how the API behaves. Opting back into the current passthrough behavior could be done with a flag, similar to how the back face was added while allowing applications to opt back into the old behavior. (Though I have never encountered any applications making use of it on purpose.)
While I know most work is going towards OpenXR, overlays are still mostly stuck on the OpenVR API until someone picks up a replacement for XR_EXTX_overlay so it would be nice to keep improving their behavior (and even if it is standardized this behavior would still be useful).
When a user has several unrelated overlay applications open which implement their own laser behavior using
ComputeOverlayIntersection, interaction passes through to all overlays which are along that path even if one is visually occluding another. This is very confusing for users and makes it difficult to build applications which play nice with each other.It would be nice if
ComputeOverlayIntersectiondefaulted to taking occlusion by other overlays into account. In this mode, no intersection would be returned if another overlay closer to the controller is also intersecting the laser. This would allow implementing this behavior with no apparent change to how the API behaves. Opting back into the current passthrough behavior could be done with a flag, similar to how the back face was added while allowing applications to opt back into the old behavior. (Though I have never encountered any applications making use of it on purpose.)While I know most work is going towards OpenXR, overlays are still mostly stuck on the OpenVR API until someone picks up a replacement for
XR_EXTX_overlayso it would be nice to keep improving their behavior (and even if it is standardized this behavior would still be useful).