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

Mon Mar 9 14:33:54 PDT 2020

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
>>
>> pon., 9 mar 2020 o 14:06 GPU Group <gpugroup at gmail.com> napisał(a):
>> >
>> > I'm enjoying - a big help to have clear targets even if changed, and I've been refactoring old code to prepare. Thanks very much Michalis, very helpful.
>> > -Doug
>> > ...
>> > my experience so far:
>> > I'm planning to put Physical and Unlit into normal workflow in freewrl, and fixing old bugs and bad code in preparation.
>> > Some gotchas:
>> > a)Appearance.backMaterial: freewrl x3d parser needs containerField='backMaterial' on one material, to work generically
>> > <Appearance>
>> > <Material ... />
>> > <Material ... containerField='backMaterial'/>
>> > </Appearance>
>> > otherwise it seems to overwrite the material slot with the 2nd material
>> > b) Appearance.backMaterial vs TwoSidedMaterial:
>> > - TwoSided constrains to 2 'regular' materials
>> > - Appearance.backside can sport new Unlit or Physical
>> > - (gotcha: someone puts TwoSided in both material and.backMaterial )
>> > So the shader workflow needs to support combinations of 2 material types at the same time and switch on something like gl_FrontFacing
>> > (I need to refactor from #defines to uniforms for determining shader pathways, like we do with light types - ie FrontMaterial.type would indicate Unlit, Regular or Physical or None )
>> >
>> > On Sat, Mar 7, 2020 at 4:32 PM Michalis Kamburelis <michalis.kambi at gmail.com> wrote:
>> >>
>> >> Hi,
>> >>
>> >> 1. I have improved a "summary page" documenting my proposed changes for X3D v4:
>> >>
>> >>   https://github.com/michaliskambi/x3d-tests/wiki/X3D-version-4:-New-features-of-materials,-lights-and-textures
>> >>
>> >> That page is designed to be a quick introduction to all the changes.
>> >> It will also serve as a summary of my talk on next Friday (13th of
>> >> March) on Web3D teleconference.
>> >>
>> >> 2. I wrote a dedicated page about "Why do we need UnlitMaterial
>> >> node?". It's not so trivial question, and I gathered some arguments
>> >> before I decided it's the right course of action. It's all documented
>> >> on this page:
>> >>
>> >> https://github.com/michaliskambi/x3d-tests/wiki/Why-is-UnlitMaterial-useful
>> >>
>> >> Enjoy :),
>> >> Michalis
>> >>
>> >> _______________________________________________
>> >> x3d-public mailing list
>> >> x3d-public at web3d.org
>> >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>> >
>> > _______________________________________________
>> > x3d-public mailing list
>> > x3d-public at web3d.org
>> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org