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

Mon Feb 1 01:08:23 PST 2021

As for X3DOM BlendMode: this X3DOM extension (also implemented in CGE
https://castle-engine.io/x3d_extensions.php#section_ext_blending ) is
still relevant.

BlendMode describes in detail *how* should the blending be done, *if*
it is done.

So Appearance.alphaMode now tells whether you should do blending (when
alphaMode=BLEND, or when alphaMode=AUTO and blending is most
suitable), and Appearance.blendMode specfies exact blending equation.

I do *not* think we should add Appearance.blendMode to X3D spec. It is
not critically needed, glTF also doesn't need it, letting
implementations choose it. There are not so many sensible options in
practice.

Regards,
Michalis

niedz., 31 sty 2021 o 21:14 Don Brutzman <brutzman at nps.edu> napisał(a):
>
> Thanks for improved wording, have refined and committed the specification prose accordingly.
>
> Also great that you have implemented directly/exactly, this all builds consistency for model presentation and conversion into X3D4.
>
> Of interest to X3DOM implementers is note on your page:
> ----
> Note: X3DOM Appearance.alphaClipThreshold
>         https://doc.x3dom.org/author/Shape/Appearance.html
> seems to provide a straightforward translation of this. (TODO: Not tested in X3DOM. Do linked X3DOM docs show good default (0.1)? CGE and glTF alphaCutoff is by default 0.5.)
> ----
>
> For those involved: there are also X3DOM dissimilarities for alphaMode (i.e. BlendMode).  Wondering if these specific issues need to be posted for X3DOM, or a future X3D4 refactoring of X3DOM will re-align it?
>
>
> On 1/31/2021 5:17 AM, Michalis Kamburelis wrote:
> >
> > BTW, view3dscene now uses alphaCutoff when importing glTF too.
> >
> > This means that this glTF testcase works 100% with view3dscene:
> > https://github.com/KhronosGroup/glTF-Sample-Models/tree/master/2.0/AlphaBlendModeTest
> > .
> >
> > I have also updated my wiki page "converting glTF to X3D" to mention
> > the new alphaMode, alphaCutoff fields as a way to express equivalent
> > glTF values: https://github.com/michaliskambi/x3d-tests/wiki/Converting-glTF-to-X3D#alphamode
> > .
> >
> > Regards,
> > Michalis
> >
> > niedz., 31 sty 2021 o 13:58 Michalis Kamburelis
> > <michalis.kambi at gmail.com> napisał(a):
> >>
> >> The rewording is OK for me, cool!
> >>
> >> The only suggestion is to change initial paragraph about alphaCutoff:
> >>
> >> """"
> >> The alphaCutoff field provides a threshold value for pixel rendering
> >> as either transparent or opaque, used when
> >> alphaMode has value MASK.
> >> """
> >>
> >> ->
> >>
> >> """"
> >> The alphaCutoff field provides a threshold value for pixel rendering
> >> as either transparent or opaque, used when
> >> alphaMode has value MASK, or when alphaMode has value AUTO and browser
> >> detects that the MASK mode is the most appropriate.
> >> """
> >>
> >> (this is consistent with the later description of MASK too).
> >>
> >> Regards,
> >> Michalis
> >>
> >> sob., 30 sty 2021 o 21:06 Don Brutzman <brutzman at nps.edu> napisał(a):
> >>>
> >>> Michalis, have added alphaCutoff descriptions and made slight wording edits to committed prose for alphaMode.
> >>>
> >>> Hoping that you, Dick and anyone else interested might check alphaCutoff/alphaMode using attached .pdf excerpt.
> >>>
> >>> Upon review am ready to close this issue.
> >>>
> >>> * Mantis 1340: add Appearance alphaMode, alphaCutoff for consistency with glTF
> >>>     https://www.web3d.org/member-only/mantis/view.php?id=1340#bugnotes
> >>>
> >>> p.s. what an excellent image linked below for this test case!  worth everybody looking at.  8)
> >>>
> >>>
> >>> On 1/29/2021 4:20 PM, Don Brutzman wrote:
> >>>> Thanks for rapid response.  Have accepted PR and will review prose.
> >>>>
> >>>> Dick please confirm that responses by Michalis provide a satisfactory answer to this question - thanks.
> >>>>
> >>>> On 1/29/2021 1:56 PM, Michalis Kamburelis wrote:
> >>>>>
> >>>>> 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
> >>>>
> >>>> all the best, Don
> >>>
> >>> 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
>
> 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