Different behaviour of ONETEXTURE_BLEND textures in 1.9

You discovered a bug in the engine, and you are sure that it is not a problem of your code? Just post it in here. Please read the bug posting guidelines first.
Post Reply
edo9300
Posts: 9
Joined: Sun Dec 29, 2019 10:09 pm

Different behaviour of ONETEXTURE_BLEND textures in 1.9

Post 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.
CuteAlien
Admin
Posts: 9643
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

Re: Different behaviour of ONETEXTURE_BLEND textures in 1.9

Post 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.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Post Reply