Alpha transparency bug

Forum thread reference: https://forums.armory3d.org/t/alpha-throws-error/5065
Discord thread reference: https://discord.com/channels/486771218599510021/1047945916411297872/1048010930379821179

To quote @ MoritzBrueckner:

I think the problem is related to this commit: https://github.com/armory3d/armory/commit/35274c86734c04a62c6cfa4836b00d9412c84f09.

The line was originally added to fix https://github.com/armory3d/armory/issues/1413 but to me it looks more like a workaround based on random user experiments (see the comments) than a proper fix. I think the offset might prevent a division by 0 somewhere, but then it should probably be fixed at whatever location the actual issue is happening.

The problem with this line is the following: if no value node is connected to the principled node, Armory knows that the material is fully opaque and only outputs a "regular" opaque shader (Material_002_mesh.frag.glsl) without transparency. But if a node is connected, it could happen that different transparency values are used at runtime and because of this there is a check in the opaque shader whether the fragment should be drawn with the generated translucency shader instead:

opacity = Value_Value_res - 0.0002; // Value_Value_res is 1.0 in this case
if (opacity < 0.9999) discard;

Because of the - 0.0002, the opacity now is 0.9998 ( < 0.9999) and thus the opaque shader returns without writing anything into the gbuffer and the translucency shader is used instead (Material_002_translucent.frag.glsl). In that shader, we obtain the same opacity of 0.9998 and thus we can see through the object. I think it's the weighting function used by the algorithm (see http://casual-effects.blogspot.com/2014/03/weighted-blended-order-independent.html for details) that makes the effect so prominent, but I think the actual fix would be to improve the handling of opacity values.

Maybe the weighting function also needs to be changed a bit so that the transition between opaque and transparent isn't so strong, but I know way too less about this technique/algorithm and the additive blending that's used might make a smooth transition impossible...

Special thanks to @ MoritzBrueckner and @ QuantumCoderQC for confirming the issue too.

Start by reproducing the reported material-node setup in Blender and inspect commit 35274c86734c04a62c6cfa4836b00d9412c84f09. Compare the generated Material_002_mesh.frag.glsl and Material_002_translucent.frag.glsl paths described in the report, then trace the opacity transition and weighting behavior. Done means an effectively opaque material remains visually opaque while runtime transparency still works.

Written by the indexing model from the issue text.