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

[Michalis Kamburelis]

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