Re: Modules split

On Sat, Aug 3, 2019 at 12:49 AM Rik Cabanier <rcabanier@magicleap.com>
wrote:

> On Sat, Aug 3, 2019 at 12:33 AM Klaus Weidner <klausw@google.com> wrote:
>
>> On Sat, Aug 3, 2019, 00:16 Klaus Weidner <klausw@google.com> wrote:
>>
>>> I'm not one of the spec editors, but is this really a blocking issue?
>>> The spec already says that *"Future specifications or modules may
>>> expand the definition of immersive session include additional session
>>> modes"*, and I think the initial AR module draft is starting
>>> imminently. Presumably the browser police won't be confiscating headsets
>>> for non-compliance if they implement a mode from a pending draft module
>>> that isn't in the draft core spec?
>>>
>>
>> Sorry, I didn't mean to imply that standards compliance is unimportant.
>> It would be unfortunate if there were an extended gap where core WebXR is
>> final but the AR module isn't ready yet even for minimal "poses only" use
>> cases, but my impression is that the editors and working group are trying
>> their best to avoid that. At this point it's all technically still in draft
>> status.
>>
>
> No worries! :-)
> Yes, I'd prefer if it goes in the spec since we don't know how long the AR
> module will take. We will be telling authors to use 'immersive-ar' and they
> might (rightly) be concerned that this is not in the standard.
>
> I'm concerned that the explainer is encouraging authors to request vr on
> ar devices and look at the environmentBlendMode attribute. We definitely
> don't want to support this and I suspect Microsoft will feel the same for
> the Hololens.
>
> What are '"minimal "poses only" use cases'?
>

(Standard disclaimer, these are my unofficial opinions and interpretations
of the spec and process.)

What I meant is that taking the current core spec and just adding an
"immersive-ar" mode results in an AR mode is extremely similar to
"immersive-vr" with a transparent background. Basically the app is just
getting poses relative to reference spaces but doesn't have any significant
real-world understanding. At most it can get a floor level by using a
"local-floor" reference space, but that's originally intended for a
limited-size space, not walking-around AR ("*the user is not expected to
move beyond their initial position much, if at all"*) and can't cope with
not-quite-flat environments. (I think issuing "reset" events when the floor
level changes wouldn't be in the spirit of the spec). In "unbounded" space,
there's no floor level available to the app. An app could request both
reference spaces and assume that the "local-floor" level is valid globally,
but that doesn't seem like a safe assumption.

I was under the impression that some form of hit testing or other
real-world understanding such as planes or meshes is fairly essential for
AR applications, i.e. to support interacting with tables or walls, so I
thought the AR module was aiming to have something along these lines
included. If you think that it would already be very useful for AR headsets
to have a minimal AR mode without real-world understanding to avoid being
in unspecified territory, would it help to start with a very small
"poses-only AR" module that basically just introduces "immersive-ar" and
explanations around environment blending etc., but skipping XRRay and
anything related to hit testing or other real-world understanding? If yes,
I think this would be a useful discussion to have.

It doesn't look good if a customer asks if we support WebXR and we say that
> it only works if they use a non-standard extension...
>

That's kind of the question here - would apps really be able to work just
with core WebXR + "immersive-ar" for poses, or would they need real-world
understanding in some form also, in which case they'd potentially be back
to using not-yet-standard extensions? Is your point that it would be
important to distinguish this, i.e. by being able to say that it is indeed
using standard core WebXR + a standard "poses-only AR" module that provides
"immersive-ar", and there's also separate support for draft
real-world-understanding modules such as hit testing, plane detection,
anchors, etc.?

>