[x3d-public] Updated summary of my changes to X3Dv4, and reasoning "why do we need UnlitMaterial"
Michalis Kamburelis
michalis.kambi at gmail.com
Thu Mar 12 05:27:21 PDT 2020
If you render exactly the same coordinates (equal binary data on GPU)
under the exact same transformations (again, precisely equal data
passed to GPU) with exactly the same shader (same calculations along
the way) then they really have to hit the same pixels. GPUs
guarantee that.
The possibility of having some problems due to round-off errors occurs
only if you calculate the positions/transformations differently, or
pass them differently (e.g. with different precision) in each pass.
Various multi-pass rendering techniques rely on it. E.g. shadow
volumes that work in CGE.
And note that in Unity3d, this is the standard way to render 2-sided
shapes. I.e. you do a shader that performs 2-pass rendering, once
culling back, once culling front faces.
We'll have testcases for it of course :) I'll adjust
https://github.com/michaliskambi/x3d-tests/blob/master/pbr/one_and_two_sided_materials.x3dv
-- right now it uses GenericTwoSidedMaterial , I'll replace that
approach with backMaterial.
Regards,
Michalis
czw., 12 mar 2020 o 12:20 Don Brutzman <brutzman at nps.edu> napisał(a):
>
> 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
More information about the x3d-public
mailing list