Parts of slime entity model are not rendered anymore when shaders are turned on (regression from 5.4.1)

[erlehmann]

Minetest version

Minetest commit 80d12db
Minetest commit 76aa610

OS / Hardware

Operating system: Debian GNU/Linux
CPU: Intel Core i7-8565U

GPU model: Intel UHD Graphics 620 (Whiskey Lake) rev 02
OpenGL version: 3.0 Mesa 18.3.6

Summary

Eyes, interior and backside of slime entity from Mineclonia are not rendered.

This entity model works in both 5.4.1 and on my Thinkpad T60 with OpenGL 1.4.

Steps to reproduce

1. Spawn a slime in Mineclonia creative mode with a slime egg.
2. Watch.

Screenshot

https://mister-muffin.de/p/xShz.jpg

[erlehmann]

Mineclonia bug report: https://git.minetest.land/Mineclonia/Mineclonia/issues/211

[sfan5]

Do you have link to the model file and entity definition in Lua?

[erlehmann]

https://git.minetest.land/Mineclonia/Mineclonia/src/branch/master/mods/ENTITIES/mobs_mc/slime+magma_cube.lua line 58ff
https://git.minetest.land/Mineclonia/Mineclonia/src/branch/master/mods/ENTITIES/mobs_mc/models/mobs_mc_slime.b3d

[sfan5]

I cannot reproduce this by assigning the model to an entity individually.

Testing in Mineclonia was not possible for me because it crashes instantly on startup with not one but two errors. This makes your claim that you reproduced this bug with "Minetest commit 76aa610" appear dubious.

[erlehmann]

@sfan5 which errors does Mineclonia crash with?

[erlehmann]

@sfan5 just in case Mineclonia crashes due to #11828 then …

a) you introduced that bug – after I told you it would break stuff to not use proper boundaries for the check.

b) you can disable the mcl_selftests mod. It tests if the Minetest engine can find all nodes it has placed, by placing nodes at numerous positions and then trying to find them using minetest.find_nodes_in_area(). I still think it is ridiculous that Minetest will refuse to find nodes it has placed.

Anyways, please provide an error message instead of just writing “it crashes”.

I promise I will try to fix it so you can look at the slime.

[erlehmann]

Important new information: The bug only happens if shaders are turned on.

[sfan5]

2021-12-12 11:28:44: ERROR[Main]: ServerError: AsyncErr: Lua: Runtime error from mod 'mcl_selftests' in callback environment_Step(): .../games/Mineclonia/mods/MISC/mcl_selftests/init.lua:85: assertion failed!
2021-12-12 11:28:44: ERROR[Main]: stack traceback:
2021-12-12 11:28:44: ERROR[Main]: 	[C]: in function 'assert'
2021-12-12 11:28:44: ERROR[Main]: 	.../games/Mineclonia/mods/MISC/mcl_selftests/init.lua:85: in function 'func'
2021-12-12 11:28:44: ERROR[Main]: 	.../minetest/builtin/common/after.lua:20: in function <.../minetest/bin/../builtin/common/after.lua:5>
2021-12-12 11:28:44: ERROR[Main]: 	.../minetest/builtin/game/register.lua:425: in function <.../minetest/bin/../builtin/game/register.lua:409>
2021-12-12 11:28:45: ACTION[Main]: Server: Shutting down
2021-12-12 11:28:45: ACTION[Main]: [doc] Server shuts down. Player data is about to be saved.
2021-12-12 11:28:45: ACTION[Main]: [doc] Wrote player data into .../minetest/bin/../worlds/world2/doc.mt.
2021-12-12 11:28:45: ERROR[Main]: ModError: Runtime error from mod 'mcl_weather' in callback on_shutdown(): .../mods/ENVIRONMENT/mcl_weather/weather_core.lua:42: bad argument #2 to 'set_int' (number expected, got nil)
2021-12-12 11:28:45: ERROR[Main]: stack traceback:
2021-12-12 11:28:45: ERROR[Main]: 	[C]: in function 'set_int'
2021-12-12 11:28:45: ERROR[Main]: 	.../mods/ENVIRONMENT/mcl_weather/weather_core.lua:42: in function <...Mineclonia/mods/ENVIRONMENT/mcl_weather/weather_core.lua:40>
2021-12-12 11:28:45: ERROR[Main]: 	.../minetest/builtin/game/register.lua:425: in function <.../minetest/bin/../builtin/game/register.lua:409>

mcl_selftests can indeed be disabled and then the game runs but I don't want to hear any excuses. Reproduction steps must actually work.

Regardless, the slime model renders and is textured perfectly fine for me.
Are you sure you tested this on commit 76aa610? I am mentioning this again because if you are testing on a version that is 5 months out of date you will be missing commits that could have already fixed it.

[erlehmann]

the slime model renders and is textured perfectly fine for me

For me it does not. I also found out that it vanishes behind nodes with transparency (a different bug).

Screenshot as proof: https://mister-muffin.de/p/XAo_.png

[sfan5]

Can you answer my question?

Are you sure you tested this on commit 76aa610?

[erlehmann]

Oh sorry, yes. The screenshot https://mister-muffin.de/p/XAo_.png was taken with commit 76aa610.

I have built it completely anew to exclude any possibility of build system bugs being involved.

[sfan5]

Okay thanks.

I just remembered that I have my renderer set to ogles2 on my primary install.
Just retested on OpenGL and I couldn't reproduce it by manually spawning the model but inside Mineclonia it was indeed broken.

[sfan5]

I couldn't tell you why it presumably worked in 5.4.1 or with shaders disabled but this seems to be a texture coordinate-related error. If I color in these squares in the texture the eyes show up blue and the mouth red:

[paradust7]

@sfan5

I have an explanation.

The mesh is not just a cube, it is actually 5 cubes. An outer cube, inner cube, two eyes, and an off-center mouth.
Only the outer cube has non-blank texture, the other 4 cubes map to areas with rgba = 0.

The three fully-transparent cubes protruding from the front need to be discarded (not rendered) by the shader, or else they prevent the main cube from rendering under them (due to depth testing, presumably).

When GLES is enabled, there is an explicit discard at the beginning of the fragment shader:

minetest/client/shaders/object_shader/opengl_fragment.glsl

Lines 453 to 459 in e9e6710

	// If alpha is zero, we can just discard the pixel. This fixes transparency
	// on GPUs like GC7000L, where GL_ALPHA_TEST is not implemented in mesa,
	// and also on GLES 2, where GL_ALPHA_TEST is missing entirely.
	#ifdef USE_DISCARD
	if (base.a == 0.0)
	discard;
	#endif

This is why GLES is unaffected. Removing this discard causes the misrendering effect on GLES.

According to the comments, it is expected that GL_ALPHA_TEST will be used to do the discard on OpenGL. That is indeed what is done for the built-in renderer for EMT_TRANSPARENT_ALPHA_CHANNEL:

https://github.com/minetest/irrlicht/blob/24594ce2265800aa88e087d4e6f2d4a54a5f2eb8/source/Irrlicht/COpenGLMaterialRenderer.h#L368-L371

However, for custom shaders based on EMT_TRANSPARENT_ALPHA_CHANNEL, the driver sets the blending function, but doesn't set an alpha test:

https://github.com/minetest/irrlicht/blob/24594ce2265800aa88e087d4e6f2d4a54a5f2eb8/source/Irrlicht/COpenGLShaderMaterialRenderer.cpp#L45

https://github.com/minetest/irrlicht/blob/24594ce2265800aa88e087d4e6f2d4a54a5f2eb8/source/Irrlicht/COpenGLShaderMaterialRenderer.cpp#L205-L206

This seems like a simple mistake. Pull request incoming soon.

[NathanSalapat]

Why does the slime have those meshes if they are just transparent anyway? Not that the bug should be ignored or not fixed, but it seems silly to add extra geometry if it's not used. Probably not a question to ask here I suppose.

[paradust7]

@NathanSalapat Agreed, the mesh would be better off as one cube. I figure since non-shader rendering and other drivers already have the "correct" behavior of discarding alpha=0 faces, it makes sense for the OpenGL driver to do the same.

[paradust7]

FYI, I found this document which describes this exact issue and possible solutions.