[x3d-public] PR with new X3D field: Appearance.alphaMode

[Michalis Kamburelis]

New PR to Web3d spec: https://github.com/Web3DConsortium/X3D/pull/12

1. Added Appearance.alphaCutoff

2. Improved the wording to clarify what "AUTO" does (auto-detects) and
"BLEND" (uses blending algorithm, which has a specific meaning in case
of real-time graphics). Don, I think I understand how you would be
confused about "AUTO" and "BLEND" equivalency: well, in an ideal
world, "BLEND" would "just do what's necessary to display partially
transparent object*. But the world is not perfect :), the "blending"
algorithm on GPU comes with its advantages and disadvantages to cope
with depth buffer (typically requires sorting, and even then may fail
in case of self-intersecting shapes due to z-buffer turned off).

    That is one reason why glTF (and now X3D) has this "alphaMode"
field, so that blending algorithm can be requested (by BLEND) or
forbidden (by OPAQUE or MASK) explicitly.

    See also how glTF deals with it --
https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#alpha-coverage
, "Implementation Note for Real-Time Rasterizers" and "BLEND - Support
for this mode varies. There is no perfect and fast solution that works
for all cases. ...". This is an honest and valid statement. You have
to mention that blending technique comes with problems, and some
browsers may attempt to minimize them (e.g. by sorting) but there's
just no perfect solution in real-time graphics.

Regards,
Michalis

pt., 29 sty 2021 o 21:38 Michalis Kamburelis
<michalis.kambi at gmail.com> napisał(a):
>
> We need "AUTO" definitely IMHO. It is not equivalent to "BLEND".
>
> "AUTO" means that the browser automatically detects whether it should
> actually use one of the 3 algorithms --- "OPAQUE", "MASK", "BLEND".
> "AUTO" is what makes new X3D 4 still compatible to X3D 3.
>
> Without "AUTO", we break compatibility very harshly, causing all the
> X3D 3 authors to rethink what alpha mode they need for their shaders.
> Automatically using any algorithm (OPAQUE, MASK, BLEND) for existing
> X3D 3 would be bad --- you either lose transparency support, or you
> render things incorrectly.
>
> glTF was able to go without "AUTO", because they started "fresh", so
> they could require all authors to mark the shapes with appropriate
> algorithm (e.g. Blender has a dedicated UI to indicate this, and it
> exports to X3D).
>
> Regards,
> Michalis
>
> pt., 29 sty 2021 o 19:29 Don Brutzman <brutzman at nps.edu> napisał(a):
> >
> > Thanks for discussion today Michalis, very helpful.
> >
> > Group review comment today: can we omit mode "AUTO" ?  glTF doesn't have it, using "BLEND" as default seems equivalent.  Is that OK?
> >
> > Cross-check: if you think we must retain "AUTO" then we likely need better spec prose clarifying the distinction.
> >
> >
> >
> > On 1/29/2021 5:14 AM, Michalis Kamburelis wrote:
> > >
> > > Don Brutzman <brutzman at nps.edu> wrote:
> > >>
> > >> Sounds good - now 9 pacific.  You can call me directly if you were thinking it is earlier.
> > >
> > > 9 AM Pacific seems to match what I had in my calendar (5 PM Polish
> > > time) :) I'll be there.
> > >
> > >>
> > >> Questions please:
> > >>
> > >> a. Wondering if this applies to all of the various texture nodes used in physically based materials?  Any issues in that direction?
> > >
> > > No issues.
> > >
> > > Note that the formulation of "alphaMode" doesn't talk about specific
> > > textures (and it's not about textures only). The "alphaMode" says what
> > > to do with "final alpha value". And the "final alpha value" is
> > > calculated using lighting equations, that already specify what
> > > textures affect/don't affect this.
> > >
> > > In case of PhysicalMaterial, the final alpha depends on
> > > PhysicalMaterial.transparency and the alpha channel of
> > > PhysicalMaterial.baseTexture . The other textures (like
> > > PhysicalMaterial.normalTexture or PhysicalMaterial.emissiveTexture) do
> > > not affect the "final alpha value" following the lighting equations.
> > >
> > >>
> > >> b. Shouldn't we add the alphaCutoff field?  Seems like an important parameter for image analysis.
> > >>
> > >>          SFInt32 [in out] alphaCutoff 0.5   [0,1]
> > >>
> > >> alphaCutoff is glTF name, "Alpha Clip (clip threshold)" is terminology used by Blender.
> > >
> > > I think yes, good point. This is trivial to add, and it's a good time
> > > to add it now. I'll do it ASAP today.
> > >
> > > Note that it's SFFloat, not SFInt32 :) Any float value between 0 and 1
> > > makes sense, the default 0.5 matching both glTF and CGE.
> > >
> > > Regards,
> > > Michalis
> >
> > all the best, Don
> > --
> > Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
> > Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
> > X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman