<div dir="ltr">OK one more idea I haven't tried:Â <div>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?</div><div>If so then that would simplify supporting front/back materials.</div><div>-Doug</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 9, 2020 at 7:55 AM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com">michalis.kambi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">AD 1 - Yes, using backMaterial will require using containerField in X3D XML.<br>
<br>
AD 2 - The specification of backMaterial will deliberately contain<br>
wording to make implementation easier.<br>
<br>
Namely:<br>
<br>
- backMaterial can be <> NULL only if material <> NULL<br>
<br>
- when both material and backMaterial are <> NULL, they must indicate<br>
*the same* node class, IOW:<br>
<br>
  - they must both be Material<br>
  - or they must both be UnlitMaterial<br>
  - or they must both be PhysicalMaterial<br>
<br>
- moreover, when both material and backMaterial are <> NULL, they must<br>
have equal values for all xxxTexture and xxxTextureChannel fields.<br>
This means that the only difference can be in vector/scalar<br>
parameters. This means that e.g. you cannot use cubemap for<br>
diffuseTexture on front, and 3D texture for diffuseTexture on back.<br>
<br>
  (Browsers are of course free to "lift" this limitation and allow<br>
more. But I would prefer to keep the required functionality of it, in<br>
X3D 4.0, simple.)<br>
<br>
- Indeed we will add wording to prohibit placing TwoSidedMaterial in<br>
backMaterial :) Added to my TODO.<br>
<br>
- Note that the requirement to implement backMaterial will be rather<br>
high level of the appropriate component. I don't want to force all<br>
browsers to implement this. I doubt that CGE will actually implement<br>
it -- the use-cases for this are rather small, i.e. I never heard<br>
anyone ask me to support TwoSidedMaterial with separateBackColor=TRUE<br>
:)<br>
<br>
Regards,<br>
Michalis<br>
<br>
pon., 9 mar 2020 o 14:06 GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>> napisał(a):<br>
><br>
> 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.<br>
> -Doug<br>
> ...<br>
> my experience so far:<br>
> I'm planning to put Physical and Unlit into normal workflow in freewrl, and fixing old bugs and bad code in preparation.<br>
> Some gotchas:<br>
> a)Appearance.backMaterial: freewrl x3d parser needs containerField='backMaterial' on one material, to work generically<br>
> <Appearance><br>
> <Material ... /><br>
> <Material ... containerField='backMaterial'/><br>
> </Appearance><br>
> otherwise it seems to overwrite the material slot with the 2nd material<br>
> b) Appearance.backMaterial vs TwoSidedMaterial:<br>
> - TwoSided constrains to 2 'regular' materials<br>
> - Appearance.backside can sport new Unlit or Physical<br>
> - (gotcha: someone puts TwoSided in both material and.backMaterial )<br>
> So the shader workflow needs to support combinations of 2 material types at the same time and switch on something like gl_FrontFacing<br>
> (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 )<br>
><br>
> On Sat, Mar 7, 2020 at 4:32 PM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com" target="_blank">michalis.kambi@gmail.com</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> 1. I have improved a "summary page" documenting my proposed changes for X3D v4:<br>
>><br>
>>Â Â <a href="https://github.com/michaliskambi/x3d-tests/wiki/X3D-version-4:-New-features-of-materials,-lights-and-textures" rel="noreferrer" target="_blank">https://github.com/michaliskambi/x3d-tests/wiki/X3D-version-4:-New-features-of-materials,-lights-and-textures</a><br>
>><br>
>> That page is designed to be a quick introduction to all the changes.<br>
>> It will also serve as a summary of my talk on next Friday (13th of<br>
>> March) on Web3D teleconference.<br>
>><br>
>> 2. I wrote a dedicated page about "Why do we need UnlitMaterial<br>
>> node?". It's not so trivial question, and I gathered some arguments<br>
>> before I decided it's the right course of action. It's all documented<br>
>> on this page:<br>
>><br>
>> <a href="https://github.com/michaliskambi/x3d-tests/wiki/Why-is-UnlitMaterial-useful" rel="noreferrer" target="_blank">https://github.com/michaliskambi/x3d-tests/wiki/Why-is-UnlitMaterial-useful</a><br>
>><br>
>> Enjoy :),<br>
>> Michalis<br>
>><br>
>> _______________________________________________<br>
>> x3d-public mailing list<br>
>> <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
>> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
><br>
> _______________________________________________<br>
> x3d-public mailing list<br>
> <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div>