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

[Michalis Kamburelis]

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> 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> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200312/f02d3044/attachment-0001.html>