[x3d-public] Updated summary of my changes to X3Dv4, and reasoning "why do we need UnlitMaterial"

[Don Brutzman]

Looking forward to unification of front and back Materials.

The use case translation is interesting.  For the second version, with two IFS nodes, am assuming you have consistent Coordinate nodes (hopefully via DEF/USE).  Not sure the browser would be expected to detect that they are identical however, especially if coordinate points are repeated.

Wouldn't aliasing effects be possible/likely if the two passes are performed independently?  Two passes as Doug proposes would be traversing the same geometry and so could avoid that problem.

On 3/9/2020 2:33 PM, Michalis Kamburelis wrote:
> Absolutely.
> 
> 2-pass rendering is a valid way to implement different front/back
> material parameters. Although it will not be as efficient as doing it
> in 1 pass (and checking gl_FrontFacing). But it's unsure whether the
> optimization matters (you would need a huge scene using extensively
> two-sided materials with different front/back parameters to feel the
> optimization).
> 
> Note that you don't need different shaders for front/back (unless you
> utilize some optimizations that assume knowledge about materials, e.g.
> CGE optimizes materials with specularColor = zero specially, by not
> including the specular computation). In normal case, you can use the
> same shader, just pass different parameters when it's front, different
> when it's back. Culling is done by glCullFace(GL_FRONT),
> glCullFace(GL_BACK), so it happens outside of the shader code.
> 
> I actually proposed this at some point as an upgrade path from
> TwoSidedMaterial, and then we would not even need to add
> "backMaterial". In CGE (we don't support TwoSidedMaterial with
> separateBackColor=TRUE, or backMaterial, for now), as well as in Unity
> and probably some others, it's a standard way to get 2-sided materials
> with different colors.
> 
> IOW, you can transform
> 
> """
> Shape {
>    appearance Appearance {
>      material Material { diffuseColor 1 1 0 }
>      backMaterial Material { diffuseColor 0 0 1 }
>    }
>    geometry IndexedFaceSet { ccw TRUE solid FALSE ... }
> }
> """
> 
> into this:
> 
> """
> Shape {
>    appearance Appearance {
>      material Material { diffuseColor 1 1 0 }
>    }
>    geometry IndexedFaceSet { ccw TRUE solid TRUE ... }
> }
> Shape {
>    appearance Appearance {
>      material Material { diffuseColor 0 0 1 }
>    }
>    geometry IndexedFaceSet { ccw FALSE solid TRUE ... }
> }
> """
> 
> Regards,
> Michalis
> 
> 
> 
> pon., 9 mar 2020 o 21:24 GPU Group <gpugroup at gmail.com> napisał(a):
>>
>> OK one more idea I haven't tried:
>> Could a browser loop on the CPU side, drawing the same object twice, once with front material the front facing fragments, once with back material drawing back facing fragments -different compiled shaders- and setting one uniform or #define in the shader to say to draw front or back side of fragments?
>> If so then that would simplify supporting front/back materials.
>> -Doug
>>
>> On Mon, Mar 9, 2020 at 7:55 AM Michalis Kamburelis <michalis.kambi at gmail.com> wrote:
>>>
>>> AD 1 - Yes, using backMaterial will require using containerField in X3D XML.
>>>
>>> AD 2 - The specification of backMaterial will deliberately contain
>>> wording to make implementation easier.
>>>
>>> Namely:
>>>
>>> - backMaterial can be <> NULL only if material <> NULL
>>>
>>> - when both material and backMaterial are <> NULL, they must indicate
>>> *the same* node class, IOW:
>>>
>>>      - they must both be Material
>>>      - or they must both be UnlitMaterial
>>>      - or they must both be PhysicalMaterial
>>>
>>> - moreover, when both material and backMaterial are <> NULL, they must
>>> have equal values for all xxxTexture and xxxTextureChannel fields.
>>> This means that the only difference can be in vector/scalar
>>> parameters. This means that e.g. you cannot use cubemap for
>>> diffuseTexture on front, and 3D texture for diffuseTexture on back.
>>>
>>>      (Browsers are of course free to "lift" this limitation and allow
>>> more. But I would prefer to keep the required functionality of it, in
>>> X3D 4.0, simple.)
>>>
>>> - Indeed we will add wording to prohibit placing TwoSidedMaterial in
>>> backMaterial :) Added to my TODO.
>>>
>>> - Note that the requirement to implement backMaterial will be rather
>>> high level of the appropriate component. I don't want to force all
>>> browsers to implement this. I doubt that CGE will actually implement
>>> it -- the use-cases for this are rather small, i.e. I never heard
>>> anyone ask me to support TwoSidedMaterial with separateBackColor=TRUE
>>> :)
>>>
>>> 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