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

Don Brutzman brutzman at nps.edu
Sun Jan 31 12:14:46 PST 2021 

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

More information about the x3d-public mailing list