Should we expose an emulatedFloor for reporting when floor-level is emulated?

[thetuvix]

Here is the original discussion from https://github.com/immersive-web/webxr/issues/534#issuecomment-468125336. Resolving #559 resolved the first and third bullet, but not the second bullet. (unfinished business in bold)

These are interesting corner cases for emulatedPosition, especially given that apps will likely end up using it most of the time to reason about tracking state:

• For a 3DoF device, the distance from eye-level to floor-level may be fixed, in that it won't change its value. However, being fixed is separate from being tracked vs. emulated. For example, a 6DoF controller that leaves the FOV and drops to 3DoF may lock in place relative to the user's head. An app that relates the eye-level space and the controller's grip space might also get a quite fixed answer at that moment, but the emulated guess being fixed is precisely what the app wants to be warned about when they check whether the position is now emulated.
• Another interesting case is a 6DoF headset that can track the user's position changes accurately, but which has no calibrated or detected notion of floor. In that case, the UA may again run with an assumed floor height. In that case, we could credibly defend emulatedPosition as true for all relations to the floor-level space, since we don't have any actual data about the floor position. However, then the app has lost its ability to know when the headset itself moves from 6DoF to 3DoF tracking, since emulatedPosition would always be true unless the app separately checks the pose in the eye-level space.
• Regarding the relation between grip space and target ray space for a given controller, that feels like a clear case of emulatedPosition being false. In contrast to the emulated floor height, there is nothing unknown here - the fixed relation between those spaces is manufactured into the plastic, and so there's no ambiguity left.

Given the above, perhaps we just define emulatedPosition as relating to the current positional tracking state (and perhaps capabilities if maxing out at 3DoF) of the spaces in question:

• If the UA knows this space relation at a high accuracy, whether fixed or tracked, emulatedPosition is false.
• If the UA can only provide this space relation at approximate accuracy, or if true positional tracking is not possible for this relation, emulatedPosition is true.

We could then have a special callout in the spec for UAs making assumptions about things like floor height, and how that does not cause emulatedPosition to become true if positional tracking is otherwise available for the space being related to the floor. That definition might perhaps be a motivation for moving to the term estimatedPosition here instead, separating that notion from any emulation the UA elects to provide for the floor.

Originally posted by @thetuvix in https://github.com/immersive-web/webxr/issues/534#issuecomment-468125336

[jacobcdewitt]

@thetuvix , I agree with your reasoning that using an emulated height for floor-level space should not cause emulatedPosition for all the related poses to be true as that would defeat one of the main use cases of that property (recovering from tracking loss).

[toji]

I also agree with Alex and Jacob re: simply using an emulated floor level not being grounds for setting the emulatedPosition flag. The way I see it is this: emulatedPosition should indicate is the pose of the requested space is emulated relative to the base space. In the case of an emulated floor, and similarly with the case of a reference space with an origin offset applied, the position of the reference space origin is known and constant, even if it was originally derived from emulated data. If you can get an accurate 6DoF pose relative to that origin, you're not emulated. If you can't, you're emulated.

(Note that if there was a way of saying "I want the pose of the emulated floor-level ref space relative to the real floor" then THAT would probably qualify for emulatedPosition = true, but our API doesn't really have a mechanism for that.)

[Manishearth]

If someone can make a PR clarifying that emulatedPosition is not true if the floor (and only the floor) is emulated, then we can probably close this issue out, perhaps filing a separate one for emulatedFloor if people really want that.

[bialpio]

I think that we should have a way to communicate the fact that the floor space is entirely estimated, but I agree that emulatedPosition might not be the best attribute for that purpose. I'm not sure what the right terminology should be in this case, emulatedFloor is probably a good initial name (or maybe estimatedFloor - not sure what we're "emulating" here). It seems to me that it should be something that's exposed on an XRReferenceSpace - to me it's not really a property of XRPoses but I wonder what others think.

(...) perhaps filing a separate one for emulatedFloor if people really want that

It seems to me that if UAs are forced to come up with a number to create *-local spaces (see the discussion about local-floor for smartphone AR: immersive-web/webxr-ar-module#12), then the least we can do is to inform the application about that fact. Creating new issue is fine with me but I was under the impression that this one was created specifically to address the problem of notifying the app that *-floor spaces may be guesstimated.

[Manishearth]

Opened https://github.com/immersive-web/webxr/pull/871 to clarify that emulatedPosition is not affected by estimated height. We can continue discussing here if we want an emulatedFloor.