Should XRHitTestResult return an XRTransform instead of an XRPose?
toji opened this issue · comments
Apologies that this feedback is coming a bit late, but I only thought about it within the last couple of days while utilizing the API.
XRPose currently only contains a transform and a boolean to indicate that the position was based on emulated data, the latter of which doesn't seem to apply to hit tests? (I can't imagine what it would mean in this context.) In the future, the pose may be extended to include the velocity of the tracked object, which also seems irrelevant in this context. As a result, it seems like we could return just a transform and it would still provide all the necessary information with less overhead?
TL;DR: I think it makes sense to keep it an XRPose, but let me know if I'm missing something here. More detailed response below.
My understanding is that the emulatedPosition is more an attribute of the relationship between the spaces used to obtain the pose, not of the pose itself - I think it might still make sense to include it in the results obtained from hit test for that reason (i.e. setting it to true or false still has some meaning for poses obtained from hit test result - e.g. local-floor is emulated and the hit test results are given relative to it, so they are marked as emulated). In order to obtain the result, the application still needs to pass a reference space, and if the hit test result is viewed as an XRSpace that's valid only for a single frame (this is actually the reason why we're returning separate type instead of just returning XRSpaces), then performing hitTestResult.getPose(refSpace) is equivalent to performing xrFrame.getPose(hitTestResult, refSpace) - ISTM that all the same considerations of obtaining poses between 2 spaces are still applicable (e.g. are the poses limited between those 2 spaces?).
Additionally, XRPose has some additional meaning attached to it ("An XRPose describes a position and orientation in space relative to an XRSpace."), whereas XRRigidTransform does not - the XRPose's description seems to precisely match what the hit test API is returning.
As for extending poses in the future, I'd imagine that we'd still have to have a mechanism to say that the velocity is not present/unknown in the pose (I don't think we'd be able to make every pose contain a valid velocity - there might just be no runtime support for that in some cases), so poses returned from hit test results could then use that mechanism. And in some cases, velocity may be known and meaningful (e.g. if we'll track the velocity of a plane and hit test result was computed based on the intersection of that plane with the ray, we will actually know the velocity of the intersection point and might want to return it in the result?).
XRPose has some additional meaning attached to it ("An XRPose describes a position and orientation in space relative to an XRSpace."), whereas XRRigidTransform does not - the XRPose's description seems to precisely match what the hit test API is returning.
Your full response is well reasoned, but this was the thing that tipped the scales for me. I agree that in the context of the stated purpose of the interfaces XRPose is best suited. Thanks for taking the time to walk through it!