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

[Michalis Kamburelis]

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