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

Sun Jan 31 05:17:41 PST 2021

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AlphaBlendModeTest_0.png
Type: image/png
Size: 520891 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20210131/a0dfffd1/attachment-0001.png>