[x3d-public] PR with new X3D field: Appearance.alphaMode
Michalis Kamburelis
michalis.kambi at gmail.com
Mon Feb 1 10:01:06 PST 2021
Oh, I didn't see alphaFuncXxx fields in BlendMode before, thanks for
catching this. So it is also useful for alphaMode="MASK".
Anyway, yeah, the conclusion stands. I do not think that tweaking
these details is useful enough for adding to X3D spec.
Regards,
Michalis
pon., 1 lut 2021 o 17:39 Don Brutzman <brutzman at nps.edu> napisał(a):
>
> Thanks for posting about X3DOM BlendMode Michalis. Agreed.
>
> * https://doc.x3dom.org/author/Shape/BlendMode.html
>
> alphaFunc SFString "none"
> alphaFuncValue SFFloat 0 [none, never, less, equal, lequal, greater, notequal, gequal, always]
>
> While notionally interesting, and possibly of theoretical interest from a visualization-exploration perspective, I see no reason to deviate beyond glTF functionality.
>
> Additional opinions always welcome.
>
> On 2/1/2021 1:08 AM, Michalis Kamburelis wrote:
> >
> > 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
>
> 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
More information about the x3d-public
mailing list