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

Fri Jan 29 13:56:36 PST 2021

Oh, and testcase for Appearance.alphaCutoff is in the same directory
as Appearance.alphaMode testcase:

https://github.com/michaliskambi/x3d-tests/blob/master/alpha_mode/

The correct rendering is in
https://raw.githubusercontent.com/michaliskambi/x3d-tests/master/alpha_mode/alpha_cutoff_correct.png
. This is a screenshot from latest view3dscene that supports
Appearance.alphaCutoff already. (you can get it from
https://castle-engine.io/view3dscene.php , after giving Jenkins a few
hours to rebuild it).

Regards,
Michalis

pt., 29 sty 2021 o 22:51 Michalis Kamburelis
<michalis.kambi at gmail.com> napisał(a):
>
> 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