IVROverlay::ComputeOverlayIntersection() returns incorrect results

[elvissteinjr]

Hello, I've been trying to implement a custom laser pointer system for non-blocking use during gameplay. Works well so far, but I've noticed two scenarios where the results coming from ComputeOverlayIntersection() were not quite what I'd considered expected.

First is VROverlayIntersectionResults_t::.vUVs.v[1] (the V coordinate) being inverted when there's no intersection. This one's not a real issue since I can just catch that and flip it around on my end, but still odd. Not even sure if results being usable without intersection is intended (not documented, but neither is much else), but it is immensely useful to allow drags outside the overlay surface while an input is down, like the dashboard laser pointer does.

The second issue is ComputeOverlayIntersection() not taking the overlay intersection mask into account (still returns true when the mask would exclude parts on the system laser pointer). This one is kind of a bother as not all overlays I want to compute overlay intersections for are owned by the same process and an overlay's intersection mask can't be accessed from the API to take care of that on my end.

Behavior is the same in current stable and beta version of SteamVR (1.19 / 1.20.3). Wouldn't be able to tell if this was ever different, though. Would love to at least see the second issue fixed. Fixing the first could break applications relying on that, I guess. Thanks for your time!