TwoSidedMaterial renders unlit white

[andreasplesch]

https://castle-engine.io/x3d_implementation_shape.php#section_supported_nodes

says that TwoSidedMaterial is somewhat supported.

But

http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter05AppearanceMaterialTextures/TwoSidedMaterial.x3d

(https://x3dgraphics.com/examples/X3dForWebAuthors/Chapter05AppearanceMaterialTextures/TwoSidedMaterialIndex.html)

renders white in view3dscene 3.18

(see also paulmasson/mathcell#15)

[splace]

FWI when i try the first one, i get this....

1 warnings:

TwoSidedMaterial X3D node (TwoSidedMaterial) with SeparateBackColor = true is not supported yet

this is with a build from last week.

[michaliskambi]

Tl;dr: Get view3dscene from http://michalis.ii.uni.wroc.pl/view3dscene-snapshots/ , it supports TwoSidedMaterial as documented.

Details:

The documentation on https://castle-engine.io/ right now refers to the "snapshot" version of view3dscene, which you can get from http://michalis.ii.uni.wroc.pl/view3dscene-snapshots/ . Not to the last stable view3dscene 3.18.0.

<sidenote>
This is not how I usually do things. Usually the documentation on https://castle-engine.io/ documents the stable release of view3dscene, stable release of Castle Game Engine etc. But, due to my own lack of time (and a huge number of CGE 7.0 features , https://github.com/castle-engine/castle-engine/wiki/New-Features-in-Castle-Game-Engine-7.0 ), it's been quite a while since the last stable release of view3dscene/CGE, and right now the website sometimes documents some features from unstable view3dscene/CGE without mentioning it explicitly (because there are just so many new features that at some points it was really complicated trying to explain clearly what works in stable, what works in unstable).
</sidenote>

So, please bear with me :) -- the docs right now describe the unstable view3dscene/CGE, and it will be fixed with new release of both view3dcene and CGE really soon now.

Opening with latest view3dscene results in correct two-sided rendering:

Some more notes about this test file:

1. Indeed we don't support separateBackColor='true' in view3dscene/CGE (this is documented on https://castle-engine.io/x3d_implementation_shape.php#section_supported_nodes ). And the X3D has this: <TwoSidedMaterial backDiffuseColor='1 0.5 0' backTransparency='0.5' diffuseColor='1 0 0' separateBackColor='true' transparency='0.5'/> .

2. Note that there are rendering artifacts due to the sphere being partially-transparent (using blending). It's normal (and unavoidable with standard blending), in CGE and most other renderers I suppose. Complicated (concave) shapes should be split into convex shapes, or use BlendMode where the order doesn't matter ( https://castle-engine.io/x3d_extensions.php#section_ext_blending ), i.e. with destFactor "one".

3. If you are interested in keeping the TwoSidedMaterial with separateBackColor=TRUE still possible (and not deprecated) in future X3D, please voice this on the x3d-public mailing list. We were wondering with Don whether to simplify things: http://web3d.org/pipermail/x3d-public_web3d.org/2019-December/011594.html . This would mean adding SFBool [] twoSided field to the regular material, and deprecating TwoSidedMaterial.

   This discussion occurred because for PBR (PhysicalMaterial) this matter needs to be solved too. My PR about PBR proposes TwoSidedAnyMaterial (like a more generalized version of TwoSidedMaterial), but if we can instead simplify things by having just a trivial boolean field twoSided then it's even better.

   So: Input from both authors and implementors is welcome, especially if you have a strong use-case for TwoSidedMaterial with separateBackColor=TRUE.

4. Note: in the test file, initial Viewpoint places the viewer outside of the box, but uses WALK navigation. This means that right after opening the file, viewer falls down continuously.

   Long time ago (and in last stable view3dscene) I had some "precaution" from it, but removed it recently, as it was causing other problems/surprises. Perhaps I should reinstate this "precaution".

[michaliskambi]

AD 4 above - fixed in latest CGE/view3dscene, you will no longer fall down infinitely.

[andreasplesch]

The snapshot view3dscene also works with paulmasson/mathcell#15.

I think I would vote for keeping a version of TwoSidedMaterial since it is something normal users would expect. Moving it into a twoSided field would be better, but then there needs to be way define the color of the backSide for regular Material.

Help me understand: what is difference between separateBackColor='false', and normal Material with solid='false' ?

[michaliskambi]

I think I would vote for keeping a version of TwoSidedMaterial since it is something normal users would expect. Moving it into a twoSided field would be better, but then there needs to be way define the color of the backSide for regular Material.

Indeed.

See http://web3d.org/pipermail/x3d-public_web3d.org/2019-December/011594.html : the conversion path for people using TwoSidedMaterial with separateBackColor=TRUE is to duplicate the geometry, using solid=TRUE in both cases, but in one case set ccw=TRUE, in the other case set ccw=FALSE. This effectively achieves two-sided material that can look differently from both sides.

This "conversion path" is admittedly not trivial. So if many people use TwoSidedMaterial with separateBackColor=TRUE then we could instead keep this node (and even add TwoSidedAnyMaterial to make it also possible for PBR).

Note that this is only for TwoSidedMaterial with separateBackColor=TRUE. If case of TwoSidedMaterial with (default) separateBackColor=FALSE, the conversion is trivial and painless (just use Material.twoSided=TRUE).

Help me understand: what is difference between separateBackColor='false', and normal Material with solid='false' ?

With solid = false, back faces are rendered. But how is lighting computed on these back faces?

• With one-sided Material, the back faces should be pure black, following the lighting equations. https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/lighting.html#Lightingmodel , it looks at normal vector, and uses special dot product: "if dot product < 0, then 0.0, otherwise, dot product". In effect, the diffuse factor of the back face is always zero.

• With TwoSidedMaterial, the back faces are rendered in more sane fashion: when looking at back face, we actually perform lighting calculation using inverted normal vector.

The first case ("one-sided Material being black from the back side") sounds weird. Why would anyone want that? But for some reason, it works like that, in X3D and also in fixed-function OpenGL (where backface culling was independent from two-sided lighting).

Note that in CGE implementation, I actually sometimes do "two-sided lighting" (invert normal) even in case of Material. I'm not sure whether this contradicts the spec or not, but noone complains, since obviously noone actually desires to see the blackness on the back faces :) In CGE, with Phong shading, I always do two-sided lighting (for both Material and TwoSidedMaterial). Only with Gouraud shading, I perform only one-sided lighting for Material. See https://castle-engine.io/x3d_implementation_shape_extensions.php#section_ext_shading . So in CGE, it's actually like this:

• With Material, it is undefined how back faces look. Maybe pure black, maybe reasonable color calculated by inverting normal.

• With TwoSidedMaterial, it is defined how back faces look: always have reasonable color calculated by inverting normal.

IOW, I understand your confusion. In my eyes, if you would implement Material in the same way as TwoSidedMaterial with separateBackColor=FALSE, then your implementation would also be OK. You would just always do two-sided lighting.

[andreasplesch]

Thanks for pointing out the Lighting equation with the special dot product N dot L where N is the normal and L is the Light vector. Lets just look the diffuse contribution.

Setting otherwise negative products to 0 means that lights on the other side of a triangle cannot suck light contributions from other lights back out, in my mind. Such lights just do not contribute.

So back faces may or may not be black, depending on the light vector for a given light.

separateBackColor=false still needs solid=false to render back faces at all. So at first glance it should mean the same as a regular Material. But I think what twoSidedMaterial changes is that back faces are now treated as second front faces, eg. with an outward pointing normal.

Sorry for thinking aloud. Let me read again.