QuantumCoderQC
commented
2 years ago Okay, did some tests and this is the outcome:
The issue itself is that the inverting of the normal(when two sided is enabled) happened after the shading calculations were all done in the fragment shader. So essentially, the inversion never happened. This can be fixed** by changing the line https://github.com/armory3d/armory/blob/f22542a0b4d5400970cf4a4d1d3317fe24eb6de7/blender/arm/material/make_mesh.py#L238
to frag.write_attrib('if (!gl_FrontFacing) n *= -1;')
**
But there is another issue. The gl_FrontFacing seems to work differently on HTML and Krom. To test this I used a simple plane with a shader that had a color ramp node controlled by the Z value of the normal of the plane.
So, if the plane's normal along Z is positive, it will be shaded green. And, if it is negative, it will be shaded red. If two-sided is enabled, we expect the top of the plane be shaded green while the bottom of the plane be shaded red. This is also the case in Blender's viewport.
After making the one-line correction mentioned above, I tested this on Krom and Browser targets.
In Krom, the top of the plane is shaded Red, and the bottom Green. Whereas, in Browser, the top is shaded Green and the bottom red(as we actually expect).
When I researched a bit, I found many articles describing how gl_FronFacing did not work very well and was very hardware dependent. One article that described this in detail also provided few alternatives:
https://makc3d.wordpress.com/2015/09/17/alternative-to-gl_frontfacing/
Blend file used for testing: two-side-normal-color-test.zip
MoritzBrueckner
No print because i'm on a potato. Test file: two-sided-normals-test.zip