Move away from Stage coordinate system. Use floor anchors and a tracker coordinate system, instead.

[TrevorFSmith]

Starting this PR before it's ready to merge so that we have somewhere to discuss how to implement this Issue: #12

[TrevorFSmith]

This first commit is just getting rid of the stage XRCoordinateSystem type and replacing it (mostly internally in the polyfill) with the tracker type. We need to be able to reference the tracker coordinate system because other coordinate systems like the head and eye level as well as most anchors have poses relative to that coordinate system.

App scripts won't need to (and shouldn't) hold XRCoordinates in the tracker coordinate system, but there are cases (e.g. when figuring out how to use XRAnchor poses to pose their respective THREE.Groups) where it's necessary to reference the type.

Next I'm going to add API for getting anchors at the current floor level directly underneath the display and then change the examples to use those.

[joshmarinacci]

I’m glad that you got rid of the stage coordinate system. It was confusing. So it looks like you changed scene to stage and added the tracker coordinate system. All anchors are attached to that system, right?

Questions:

• where does the magic string ‘first-floor-anchor’ come from?
• What is ‘anchorOffset’? A Vector3?
• Will the anchor offset change only once the floor is found or could it potentially change multiple times?
• If the transformed coordinates weren’t in the tracker coordinate system, what system would they be in? I don’t understand the purpose of that ‘else’ clause in updateNodeFromAnchorOffset
• What is the ultimate goal of the floor anchor? I”m assuming ARKit will return a horizontal surface if we ask, but we won’t know if it’s actually the floor, right?

[TrevorFSmith]

Hey, @joshmarinacci thanks for taking a look and the questions. I'll answer them below.

where does the magic string ‘first-floor-anchor’ come from?

Anchor names are just opaque strings, so I just named it something somewhat legible. It would have had no effect if I had named it 'aslkdjasldkajsld'.

What is ‘anchorOffset’? A Vector3?

It's an XRAnchorOffset instance, which represents a pose in relation to an XRAnchor. Basically, the AR system creates anchors for a surface or feature point and then when we do a hit test it tells us the pose of the anchor and the relative pose of the hit intersection. So, the final pose of an XRAnchorOffset is the pose of the anchor plus the offset pose.

Will the anchor offset change only once the floor is found or could it potentially change multiple times?

Anchors can change over time, but the offset from the anchor doesn't. So, ARKit might decide that a surface (and thus its anchor) is actually a little lower than it was before, but that doesn't change the offset pose.

If the transformed coordinates weren’t in the tracker coordinate system, what system would they be in? I don’t understand the purpose of that ‘else’ clause in updateNodeFromAnchorOffset

Right now, all of the anchors end up using the tracker coordinate system type, but different systems may not do it that way. Whenever WebXR hands your script an XRCoordinates (like those in an XRAnchor) it's good to check what XRCoordinateSystem it's in and transform it if you need to.

What is the ultimate goal of the floor anchor? I”m assuming ARKit will return a horizontal surface if we ask, but we won’t know if it’s actually the floor, right?

The idea is that most scripts will want to place things around the user and have them stay there, even as the user moves. Since we dropped the stage coordinate system, it seemed like a good idea to make it easy for the app scripts to ask for an anchor that's at floor level below the current position of the user. Right now, the polyfill just guesses where the floor is below the head pose and returns an anchor at that pose. In the future, we might do something fancier like ask ARKit whether it knows about a surface in roughly the right position.