[x3d-public] PR with new X3D field: Appearance.alphaMode
Don Brutzman
brutzman at nps.edu
Mon Feb 1 08:39:04 PST 2021
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