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

Sat Jan 30 12:06:09 PST 2021

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: Extensible 3D (X3D), ISO_IEC 19775-1_202x, 12 Shape componentAppearance_alphaCutoff_alphaMode.pdf
Type: application/pdf
Size: 147052 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20210130/0d0254b6/attachment-0001.pdf>