Additional Hit Test Use Cases?
bricetebbs opened this issue · comments
The Hit-Test explainer lists 2 use cases for the Hit-Test API
- Show a reticle that appears to track the real world surfaces at which the device or controller is pointed.
- Place a virtual object in the real world
We should consider (or affirmatively reject) some other user cases. Hit testing / ray casting can be used for a variety of things in a 3D system.
For example, virtual object visibility testing to determine if a virtual object is occluded from the POV of the camera. Occlusion came up in #13 but that was focused on the hit testing of the real world objects.
An application could try to use the hit-test API to determine if a virtual object that it is drawing in the scene should be visible or not. This would be done by firing a ray from the camera towards the current position of a virtual object and seeing if there is a hit of some real world geometry that is closer than the virtual objects known position.
The result will be crude for sure and it may require multiple rays being cast at different parts of the virtual object to get a better estimate but it is something people could try to do.
Is this a use case we want to support? The answer has implications for things like rate limiting #6.
Other uses for hit testing could involve something like virtual game objects that need some kind of “AI” to act in the scene. The code for them may want to perform a hit test to see if the object can “see” another object or do some kind of path planning around the real objects in the world.
Many of these use cases would work better if the application has access to the full world geometry but that won’t stop people from trying using just hit test.
I would say that we don't intend to support use-cases like this with hit-test - we are optimizing for reticles and placing objects. That said, it would be nice if we didn't have to limit hit-test via forcing only device-relative tests or rate-limiting so that developers can be creative.
I think this depends entirely on how the privacy conversation shakes out. I am of the opinion that any of these half-measures like rate-limiting will not substantially improve the privacy situation and so we might as well provide the maximum functionality since we will have to get a permission to do any of this anyway. If that proves true, we should consider these use-cases and make sure we are making choices that make the API as broadly applicable as possible without sacrificing the main use-cases.
Closing - we don't plan on supporting those use cases explicitly but we are also not planning on blocking them. The application already needs to have appropriate permissions granted by the user.