Page 1 of 1

Different behaviour of ONETEXTURE_BLEND textures in 1.9

Posted: Sat Jun 12, 2021 11:00 am
by edo9300
In 1.8 a material with material type of EMT_ONETEXTURE_BLEND was considered to be not transparent, whereas in 1.9 that material is considered transparent.
This breaks (at least from what it happened in my scenario) the usage of the depth buffer to draw those materials, as the drivers when ZWriteEnable is set to EZW_AUTO (thus the default that should have the same behavior as irrlicht 1.8) would check for the material's transparency to toggle the depth buffer.
Idk if the wrong check was in irrlicht 1.8 and thus in 1.9 the behavior is right, but I think mentioning this behavior change in the changelog might be a good thing.

Re: Different behaviour of ONETEXTURE_BLEND textures in 1.9

Posted: Sat Jun 12, 2021 12:47 pm
by CuteAlien
That stuff was changed a lot a few years ago. Then around maybe 1-2 years ago I tried to get back to old behavior as default as much as possible and fixed a bunch of problems caused by the changes. Might not be the same in all cases, but generally z-buffer should give same results and can be controlled more now on top of that.

There are a _lot_ of different cases for all this and it's a bit complicated, so if I missed something and it causes problems I need a test-case please. This might depend on the driver as well as on the way the material is used (for example when it's used in combination with shaders). This can even depend on the node-type it's used in as different node-types do check that stuff. So for example if you have a custom-node it might still use the old style (and that never was correct in many cases).

Thought most likely the important decision is made in the needsTransparentRenderPass function for the corresponding driver.

Note: It's not the SMaterial::isTransparent function - I think I reverted that completely. This is more likely about alpha transparency and nodes deciding if they need the transparent render pass.

But all just guessing - really, really need a very concrete test-case for this or I have no chance finding out what the problem is.

edit: The note in the changes.txt is mainly this one: "- Unify checks if materials should use transparent render pass with new IVideoDriver::needsTransparentRenderPass function." Thought the ones before/after it are also related.