Re: Modules split

Ah, I think I may have figured out a possible disconnect here that resulted
from the spec split.

Currently, the core spec still describes all the blend modes, and this is a
read-only attribute that's implicitly set based on the requested mode and
device type. Now that "immersive-ar" is no longer in the core spec, this is
a bit confusing and may be open to misinterpretation, where developers may
think they need to request a specific blend mode to do AR. For example:

Note: Most Virtual Reality devices exhibit "opaque"
> <https://immersive-web.github.io/webxr/#dom-xrenvironmentblendmode-opaque> blending
> behavior. Augmented Reality devices that use transparent optical elements
> frequently exhibit "additive"
> <https://immersive-web.github.io/webxr/#dom-xrenvironmentblendmode-additive> blending
> behavior, and Augmented Reality devices that use passthrough cameras
> frequently exhibit "alpha-blend"
> <https://immersive-web.github.io/webxr/#dom-xrenvironmentblendmode-alpha-blend> blending
> behavior.


As far as I know there's currently no way to get "alpha-blend" in the core
spec, that only makes sense for "immersive-ar". The blend mode is
read-only, and "immersive-vr" would never be intended to use alpha
blending. It should be opaque, but an AR headset with transparent optics
that can't do that would report "additive" blending to inform an app about
this. But this would be more along the lines of a compatibility mode to
allow use of VR experiences on an AR headset, where a developer might use
this blend mode information to avoid unintentionally-invisible black UI
elements, but it would not be intended to be used for actual AR
applications.

I think this note and the blend modes in general need a clarification that
this is functionality is primarily intended for future additional modes
(even if not explicitly naming "immersive-ar" here). "immersive-vr"
applications should expect "opaque", but should be aware that they may get
"additive" on some devices that don't support opacity, and are encouraged
to use a color scheme that works in this context if applicable. But make it
clear that applications should not use "immersive-vr" for AR applications,
and a note that "alpha-blend" is not used with "immersive-vr"?

I agree that we shouldn't end up with developers using "immersive-vr" to
write AR apps that then only work on AR headsets with "additive" blending
behavior, for example these apps would not work for smartphone AR which
uses "alpha-blend".




On Sat, Aug 3, 2019 at 11:39 AM Klaus Weidner <klausw@google.com> wrote:

> 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.?
>
>>