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

[Don Brutzman]

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:
> NPS WARNING: *external sender* verify before acting.
> 
> 
> 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
-- 
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