search

immersive-web / webxr

Repository for the WebXR Device API Specification.
https://immersive-web.github.io/webxr/
Other
3k stars 386 forks source link

XRInputSource related "required" features #755

Open NellWaliczek opened 5 years ago

NellWaliczek commented 5 years ago

One idea that I've been toying with (but am not 100% certain how I feel about) is adding the ability to restrict a session from being created if certain input-related features aren't supported. For example, perhaps my experience requires a headset which supports XRInputSources with non-null gripSpace because it's a painting app. Or perhaps it needs the gamepad to be populated because a thumbstick and/or touchpad is required to fly a drone. Or in the future, maybe it could depend on articulated hand tracking because it's about AR finger puppets (I can already hear my kids giggling about that one)

Part of why I've hesitated to pursue this deeply is that there's a number of things that make doing it difficult and/or potentially not a great idea:

  1. At session creation time, there's no guarantee that an XRInputSource meeting the requirements is present. This means that the developer is actually "requiring" that the XR device be capable of connecting such an input source, but may discover none connected after the session is created.
  2. It may not be possible for the UA differentiate it being "possible" to connect a "required" type of input source depending on the underlying XR platform. Without having looked into it too deeply, is this something OpenXR would be able to do?
  3. What sort of granularity would we want to be enabling here? It seems like potentially overkill to allow developers to require a specific input source "profile", but if they really need a thumbstick maybe that's what we need to do for this to be useful? Would it be enough to let them request "gripSpace" available and "gamepad" available?

Anyway, just a few thoughts I wanted to get down in an issue before I forgot about them.

NellWaliczek commented 5 years ago

Paging @thetuvix for an opinion

NellWaliczek commented 5 years ago

Unless anyone objects, I'm inclined to say this isn't a requirement for the first version of WebXR and that we can discuss viability in a future version. Shout if we should pull it back in.

thetuvix commented 5 years ago

Regarding #2 above, when an app negotiates an OpenXR interaction profile with the underlying runtime, we expect most OpenXR runtimes to cache the last-observed /user/hand/left and /user/hand/right interaction profiles. That way, an app can know what controllers it's most likely to observe once they're turned on again.

However, even in OpenXR, you can only know that after you've already started a session, which would then start rendering in the headset. Unless the UA itself had cached its understanding from the last time a headset was attached, it couldn't fulfill the requirement check correctly.

Especially if the data will be noisy in this way, I'd hold off on having apps set out elaborate restrictions ahead-of-time. Especially in a future world of XR-to-XR navigation, you may already be in an XRSession when navigating to a given page, and so sites will need to gracefully display an in-XR error message anyway to users - perhaps that's good enough here as well.