IDL Proposal: Creating anchors from XRHitResult

[judax]

Should there be a way to create anchors from a XRHitResult directly? Is there value in this API option? Should there be more than one option to create anchors?

[blairmacintyre]

I think there is value in this.

On platforms like ARKit, a hit test can result in the platform saying "you hit at this point/orientation relative to this existing anchor". We may not be exposing that information yet, just the full world maxtrix (since we aren't exposing those plane anchors) but if we want to create an anchor based on that hit, the programmer probably wants it attached to that plane, not to absolute coordinates. Internally, that might be done in different ways (e.g., we might just keep track of a "fake" anchor and just store the offset from the existing anchor).

On the other hand, a programmer might want it to be in world coordinates and not attached to an anchor (ok, I don't know why, but perhaps ....). Those are different cases that a programmer can handle explicitly if they want, but only if there two ways to do it.

Clearly, we need to create free-standing anchors (put this model 1 meter in front of me), too.

So, I think "create an anchor at this pose in the current world coordinates" and "create an anchor from this hit test, as best you can" should both be options. They feel like different things with different uses.

[judax]

Do you think the current proposal:

XRSession.addAnchor(XRHitResult, ...);

does not support the use case you just described? I think the relationship can be still acquired internally in the User Agent from the XRHitResult. My personal opinion is that having:

XRHitResult.addAnchor(...);

has the benefit of making it more clear that there is a differentiation between creating an arbitrary anchor and creating it from the hit result, that might contain world understanding in the future.

I do not see any other rationale to have it (or even to have them both, which I think is more code to maintain TBH). But I am sure I could be missing something.

[blairmacintyre]

I think we need both versions; I don't care if they have the same name or not (I can see arguments either way). We will need the ability to create anchors that are not created from an XRHitResult, and I am not in favor of telling people to create synthetic XRHitResult objects; that seems counter intuitive to me.

I agree that we need to have the XRHitResult version, as it lets us manage the way platforms work more correctly.

For example, ARKit returns an anchor and an offset when a hit test resolves against a plane; the anchor is the plane's anchor, not a new one. Internally, we can store this information with the hitResult (even if we aren't exposing it) and let an anchor be created for it that does NOT create a new ARKit anchor, but rather uses the original anchor and offset. If a user uses the exposed "world" matrix to create the anchor using the matrix form, a new ARKit anchor would be created at the same location.

[judax]

I agree that having a way to create an anchor from a hit result is useful as the system is able to know the element the git is related to, thus the anchor can be related to it. I completely understand that and the proposed explainer supports the idea at all times (even with the current IDL proposal). The question behind the need for this issue is: What should the API look like?

XRSession.addAnchor(Float32Array, ...)
XRSession.addAnchor(XRHitResult, ...)

or

XRSession.addAnchor(Float32Array, ...)
XRHitResult.addAnchor(...)

or

XRSession.addAnchor(Float32Array, ...)
XRSession.addAnchor(XRHitResult, ...)
XRHitResult.addAnchor(...)

I hope this clarifies the question.

[blairmacintyre]

Ah, yes, sorry, that helps.

I'm not wed to either. I would choose the first if left to my own devices, since calling "addAnchor" on the XRHitResult seems like a weird use of "add" (adding an anchor to the hit test?). I guess if we wanted both, I'd opt for

XRSession.addAnchor(Float32Array, ...)
XRSession.addAnchor(XRHitResult, ...)
XRHitResult.createAnchor(...)

But, again, I don't feel strongly about this.

[judax]

This could be tied to the addAnchor Vs createAnchor discussion on issue #10

XRSession.createAnchor(Float32Array, ...)
XRSession.createAnchor(XRHitResult, ...)
XRHitResult.createAnchor(...)

Curious to know what other members of the community think.

[bialpio]

Closing old issue. WebXR has moved away from raw matrices (they are available if needed but buried a bit in the API). The currently proposed API is:

XRFrame.createAnchor(XRRigidTransform, XRSpace)
XRHitTestResult.createAnchor(XRRigidTransform)

Please open a new issue if you disagree with current approach to the API.