Entity translucency is still broken

[sorcerykid]

Minetest version

Minetest 5.3.0-f51cf7c (Windows)
Using Irrlicht 1.8.4
BUILD_TYPE=Release
RUN_IN_PLACE=1
USE_GETTEXT=1
USE_SOUND=1
USE_CURL=1
USE_FREETYPE=1
USE_LUAJIT=1
STATIC_SHAREDIR="."
Operating system

OS / Hardware

Microsoft Windows 10 Home Build 17134

GPU model:
OpenGL version:

Summary

I've read in several places that entities now support use_texture_alpha = true. So I installed the latest sfan5 build of Minetest a few weeks ago.

I can apply a simple translucent texture to a node (left), and everything looks fine. But when I apply that exact same texture to an entity (right), then the translucency only shows where the alpha channel value is > 50%. Both the entity and node are using the same ".obj" model, which is simply a cube. There is nothing unusual about the texture. In fact, I tried exporting the PNG from various graphic editors, and it doesn't make a difference.

I'm not an expert on shaders, but it appears this may be a regression of #9639. Or else that PR didn't fully or correctly resolve the issue.

[NetherEran]

I made a little mod to recreate this. Use /spawnentity translucency_test:trobj to spawn the testing object.
Its texture is half 50% transparent and half 51%. In game only the 51% transparent part of the texture is rendered. This seems to happen both when use_texture_alpha is set to true and false.

translucency_test.zip

[Df458]

This is not a regression, but rather an oversight. Irrlicht's EMT_TRANSPARENT_ALPHA_CHANNEL passes the value of MaterialTypeParam to glAlphaFunc, effectively using it as the alpha cutoff... and this is explicitly set to 0.5 in content_cao.cpp for some reason.

Git blame reveals that this was done in #8005 because providing no value led to GLES2 ignoring alpha(relevant issue: #5600), which leaves only one question: Why on earth was 0.5 used on materials that support translucency?!

[sorcerykid]

Just to make sure I understand (for someone that is not Irrlicht savvy) this basically a one-liner fix?

[Df458]

Just to make sure I understand (for someone that is not Irrlicht savvy) this basically a one-liner fix?

Close. It's a one-liner that needs to be repeated on several lines, or refactored into a function somewhere. We need to ensure that in places where models are translucent (ie. anywhere where TILE_MATERIAL_ALPHA is in use), MaterialTypeParam is set to 0 (or maybe a float that's extremely close to 0? This will need testing with GLES2). Right now I think it's 0.5 everywhere, so we just need to check each location and update the ones that support translucent textures.

EDIT: And just to be extra-clear, when translucency is disabled we need that value to still be 0.5.

[Wuzzy2]

This sounds like a new test case for devtest. :D

[oilboi]

Devtest Devtest Devtest Devtest! 0.5 is a fun setting for entities, like a light switch :D I'd like some spooky holographic entities

[copygirl]

Can confirm this is still an issue with Minetest 5.7.0.

Model with a texture that's supposed become more transparent towards the arrow's tail, is cut off at 50% alpha:

Same model with a texture that just uses a white-to-gray gradient:

[appgurueu]

Maybe a duplicate of #14204? Can this still be reproduced?

[SmallJoker]

#14204 was a duplicate of this one. Please leave a comment here if you can still reproduce the issue in latest Minetest master.

[sorcerykid]

While I'm very grateful to see this issue is finally resolved, it raises some serious concerns about the process of evaluating and prioritizing bug reports in Minetest.

1. Why was a duplicate issue even opened in the first place?
2. Why was the duplicate issue given High Priority status and resolved within a matter of 4 days by a core dev, even though this issue remained opened for 4 YEARS and never garnered the same degree of attention and special consideration from core devs?
3. Why did it take 5 weeks for this issue to be identified as the original issue and closed, despite the fact someone had confirmed that this bug was still outstanding as recently as last October (almost two months prior to the duplicate issue being opened)?

Checking the IRC logs provides some interesting clues:

https://irc.minetest.net/minetest-dev/2024-01-04

Notice the exchange of comments between Warr1024 and SmallJoker, both perplexed as to whether it was a "legit bug" and how to resolve it.

<warr1024> Well, at least, you've confirmed that this is a legit bug and it's not something we're doing wrong on either the game/mod or the player config side, right? 😅

<warr1024> I could swear that true always meant "blend" in the past ... I wonder if this is a regression or something...

The bug is being characterized as some sort of newly discovered breakage or regression -- even though the exact cause was determined and a resolution had been suggested right here in 2020, along with multiple screenshots and a downloadable mod for testing.

This is clearly evidence of a fundamental breakdown in the system of bug reporting. And what is most concerning is that I had foreseen this EXACT scenario happening, which is why I submitted a proposal in #10172 .

Yet despite justifying why it is crucial to properly document all known non-working features -- to mitigate situations just like this one -- I was informed that would an inefficient use of developer resources. Instead the focus should be on fixing bugs. I was also told that modders can easily use GitHub to search for bugs. Yet none of that proved to be the case.

1. This issue remained unresolved for four years across six "stable" versions of Minetest.
2. The PR amounted to a mere 11 lines of code, so it was a simple and straighforward fix.

Thus the real question is: How did not documenting this broken feature in any way prioritize it being fixed or help modders to discover it on GitHub? The answer: It didn't.

What instead resulted was game devs and core devs duplicating efforts to discover and resolve an already 4-years longstanding bug, thus leading to even more inefficient use of time and resources. This situation could have been avoided, had my proposal been considered. Moreover, it might have incentivized a quicker turnaround as well, since nobody wants to cite a list of bugs in their release notes. Indeed, NOT documenting broken features is what actually allows them to be ignored and forgotten, as occured in this case.

[SmallJoker]

Why was a duplicate issue even opened in the first place?
Why was the duplicate issue given High Priority status and resolved within a matter of 4 days

There's multiple aspects that play a role here:

1. No easy reproduction steps, hence no way to find out whether this is a mod issue or knowing how widespread (i.e. how important) the issue could be.
2. The title of this issue did not describe the problem very well.
3. There's 338 other "bug"-labelled issues that could be duplicates.

After all it might also just be a coincidence that I jumped onto that particular issue. I don't know.

[sorcerykid]

Thank you @SmallJoker , I always appreciate your taking the time to clarify the situation.