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

[Don Brutzman]

OK thanks.  I'd still be concerned that inconsistent roundoff error (perhaps on mobile device) might lead to differences in how each pair of point sets was handled.  Likely a rare/inefficient case we don't have to worry about, but might be worth a test model for conformance someday.

On 3/12/2020 1:56 AM, Michalis Kamburelis wrote:
> Yes the Coordinate note could be shared by DEF / USE. There is no aliasing -- whether coordinates are shared by DEF / USE or just repeated precisely the same, it results in equal screen positions or pixels.
> 
> Regards,
> Michalis
> 
> W dniu czw., 12.03.2020 o 04:36 Don Brutzman <brutzman at nps.edu <mailto:brutzman at nps.edu>> napisał(a):
> 
>     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 <mailto: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 <mailto: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 <mailto: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