Massive rendering errors with nodeboxes in inventory (closed erroneously, this bug still exists)

[erlehmann]

Minetest version

5.7.0-279-gb1dec37ad

Active renderer

OpenGL 1.4

Irrlicht device

X11

Operating system and version

Debian GNU/Linux 11.7

CPU model

Intel(R) Core(TM) Duo CPU T2400 @ 1.83GHz

GPU model

Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)

OpenGL version

1.4

Summary

With my studs mod enabled, some pages in the minetest_game creative inventory result in strange rendering errors, that manifest as:

• fhe nodebox not being rendered
• flickering triangles that come from the upper left corner of the Minetest window
• parts of the interface being textured with the wrong texture

These errors only happen in the minetest_game creative inventory and only with some (not all) pages of the inventories that contain studs nodes. I therefore think that the way a specific nodebox is rendered in the inventory may trigger this error.

Unfortunately, the flickering behaviour of the rendering errors seem to affect VokoscreenNG's capability to record in real-time, so the recording is botched, but you can still see at least 2 frames at the end that show how it looks.

minetest-game-studs-inventory-rendering-issues.webm

Steps to reproduce

1. Acquire the exact hardware I have. 😜
2. Install the studs mod from ContentDB.
3. Join a minetest_game game with the studs mod activated and the checkbox for ”Creative Mode” checked.
4. Flip through the pages of the creative inventory until you encounter the error.

[erlehmann]

The bug does not happen with Mesa OpenGL 3.1 software rendering (which does not help, as it slows rendering too much).

It does, however, happen on my hardware with older Minetest (e.g. 5.4.1), so I assume that either this is a driver issue or it has been there for a long time and my stubs mod has indeed triggers something that is usually not triggered.

Edit: It also does not occur in the devtest inventory, if I add the stubs mod.

[NathanSalapat]

Works as expected on my machine with both stable and a dev build.
Linux Mint 20.2 Intel i7, Geforce RTX 3060

[erlehmann]

Current state: renderdoc does not do OpenGL below 3.2. Now trying apitrace.

What do people usually use to debug OpenGL render failures?

Edit: It seems that qapitrace is exactly the right tool.

[erlehmann]

Using qapitrace, I found the this occurence of glRectf after which a rendering bug shows up. So … how to continue from here?

[AFCMS]

Please. Minetest is a game engine.

Nobody should expect support for OpenGL 1.4 (< 2003) on a CPU from 2006 in an actual 2023 3D video game.

I am not speaking of requiring the latest GPUs, Minetest currently support low end PCs from 8 years ago at playable framerates and viewing ranges (from your video capture you get max 20 FPS at 40 viewing range which is completly unplayable), and that's a really nice thing so that 99.9% of people can play it.

But PLEASE. Having work done to support 20 yo tech is a nonsense.

For fun

- CPU Comparaison (I have access to all recent models, my daily is the 2023 one)
- OpenGL 1.5
- Vulkan vendor support

[erlehmann]

Please. Minetest is a game engine.

Nobody should expect support for OpenGL 1.4 (< 2003) on a CPU from 2006 in an actual 2023 3D video game.

It works on my hardware – which is old, but works just fine for my day to day tasks.

I can browse the web, watch videos, chat, do email. MInetest is less complex than Firefox, so IMO it should work.

Besides, Minetests OGLES2-Renderer is very slow on some older hardware that is OGLES2-compliant, so this is the only remaining option for quite a few devices (e.g. all my old Thinkpads) that run software from $CURRENT_YEAR just fine.

I am not speaking of requiring the latest GPUs, Minetest currently support low end PCs from 8 years ago at playable framerates and viewing ranges (from your video capture you get max 20 FPS at 40 viewing range which is completly unplayable), and that's a really nice thing so that 99.9% of people can play it.

The unplayably low framerate happens probably because the framerate has always been lower in inventories: #6905

The reason my viewing range is 40 is because I can not input a ”+” character anymore to increase it due to this bug: #13899

For testing, i do not rebind the “increase viewing range” functionality, but sometimes press the “-” key by accident.

I can assure you that Minetest is quite playable on my hardware (and probably some hardware that is worse), apart from this bug.

In fact, I am pretty sure that Minetest runs okay-ish on hardware that is quite a bit worse.

But PLEASE. Having work done to support 20 yo tech is a nonsense.

So far, I have been doing the work. All I am doing in this issue is:

a) asking for help
b) noting my findings

@AFCMS I think your comment could have been reduced to “I have superior hardware and you should stop trying to fix bugs”, which to me suggests contempt for a) not buying a modern gaming PC b) trying to fix bugs that occur on my hardware so I can play Minetest. I have not, so far, created work for anyone else than myself by trying to figure out the cause of this rendering bug.

[AFCMS]

I am sorry but 20 yo hardware has nothing about buying "modern gaming PC". What are you using Firefox to? Browsing in text mode? I wouldn't call using a text based IRC with no JS "using a web browser". How can you even load GitHub website? I have a MUCH more recent low end laptop at home and it can't even handle one of the most basic and ugly DE, and Firefox is completely unusable with any modern website.

20 yo computer can't run any serious apps in 2023.

PCs this old can only realistically be used with old OSs to run old apps and retro games. I have several PCs this old at home, but I use them to run Windows XP for retro games.

In fact I have used modern low end PCs before eventually getting a gaming PC. These low end PCs were no more than 4 yo, but were unsurprisingly not fun to use with Blender, multiple IDEs, not speaking of modern games. Minetest was running fine (without the dynamic shadows and bloom ofc, just shaders) on these PCs and on a ton of reasonably older ones I have at home. Minetest is nice for low end PCs, but your PC is more than low end, it's just unusable for ANY modern day-to-day usage (not even speaking of gaming).

I am pretty curious how many FPS you get with a 200 viewing range....? (which is the bare minimum for playing CTF and to know where you are going in survival) In world and inventory...?

[erlehmann]

@AFCMS please stop responding with stuff not relevant to the rendering bug. GitHub loads in Firefox like it does on any other computer. I watch videos from YouTubers. The one web site that does not work is probably Discord, which I do not use. The OS that i use is Debian 11.7 – released on April 29th, 2023. Among the games I play are Minetest, Hyperrogue and Xpiratez, all of which have relatively recent releases. Maybe you should install an adblocker instead of bitching about someone doing debugging work on hardware you think is crap. Or maybe you could help me instead of insulting me.

Edit: “I am pretty curious how many FPS you get with a 200 viewing range....?” – probably not many. My usual range is often somewhere between 50 and 100, depending on the game. I do not play CTF competitively. I have played Alter, Inside The Box, Nodecore, Minetest Game, Mineclonia and many more games that use Minetest as an engine that work just fine that way.

Regarding the issue: I have so far found out that frames with rendering bugs have a lot of drawcalls. I am now going to research if my graphics card is unreliable because of that. Should that indeed be the case, then I will try to fix it – because fixing it would also help with the generally low performance in inventory from this issue: #6905

Edit 2: Regardless of how good your GPU is, it seems completely unreasonable for me that Minetest uses that many drawcalls to render the inventory – qapitrace reports about 3 to 4 times the amount in an inventory compared to a screen without an inventory. However, I do not understand OpenGL that well. Am I wrong?

Edit 3: I found the explanation for the number of drawcalls: #11305 (comment) … seems rendering inventory is really inefficient.

[AFCMS]

I have an adblocker on all my PCs 🤦‍♂️

• Minetest is good for low end PCs, as I said. But I highly doubt it can run at a decent framerate with the shaders. The bare minimum my eyes support for this kind of game is around 40 FPS which ALL of my low end PCs support at 500 viewing range.
• Hyperrogue is a really bad exemple of recent game. It has extremely simple graphics and size, so it can run on computers with low GPU power.
• Same for OpenXcom/Xpiratez, it seems pixelated isometric graphics

I doubt you could even run CS:GO on lowest settings (not speaking of CS2), even if it was released in 2012.

About Edit 1:

Which resolution? Undersampling enabled? My reference for my FPS estimations is for 1080p.

About Edit 2 and 3:

If Minetest uses too much drawcalls for inventory that should obviously be fixed, and you surely have technical skills I don't have in this domain. FPS impact is much less important on recent hardware (probably because Minetest is CPU limited so the GPU is never to its maximum performance, idk)

What I am saying is that making fixes specifically for supporting OpenGL 1.4 doesn't make sense. If it happens to be caused by this drawcalls problem affecting everybody, then that's cool.

[erlehmann]

@Zughy on what basis did you decide this does not have to be fixed? Not only did I see nothing on IRC in #minetest-dev – I am debugging this right now, I have a 3D rendering expert on hand and fixing it might also fix several other issues. Please reopen it.

[Zughy]

Sfan tag and rubenwardy likes. Also, premises look wrong considering AFCM comments, and it looks like the umpteenth issue that's only gonna drain core devs from their energies for close to nothing. Unsubscribing

[erlehmann]

@Zughy I am doing work on this issue. No one else has even offered help so far.

[Zughy]

Then please reopen another issue if your assumption turns out to be correct, without all this noise. Unsubscribing

[erlehmann]

@Zughy look, if the harassment from @AFCMS is noise, just mark their comments as offtopic and reopen this issue? I do not see the point in creating yet another issue just because you have a vague feeling that sfan5 and rubenwardy would like it if they did not say it outright. The both do probably not experience this bug and if I work on it I not take any development time away from anyone.

Edit: Also sfan5 has tagged rendering bugs that were hardware-specific with “possible close”. Those issues were closed if no one was willing to work on them or because they might end up being driver bugs or because it was decided that Minetest should not support something explicitly. But here we have someone working on it (me) – and the only thing I got for that is harassment.

[rubenwardy]

I'm unable to reproduce this issue, appears fine to me

You're welcome to make improvements/fixes to draw calls and batching, as that will improve performance for all users (see #6905). At this stage, it appears to be an obscure issue on outdated hardware and OpenGL. We're not intending to support OpenGL 1.x, so this has zero priority which would justify a close. For this issue to be confirmed/remain open it needs to be reproduced on OpenGL >3.0 and another person's machine

[erlehmann]

Maybe relevant intermediate result: It seems that simply not setting any materials during item stack rendering makes the artifacts go away, even if the framerate is still low due to the number of drawcalls. See screenshot for the (obviously unusable) result:

diff --git a/src/client/hud.cpp b/src/client/hud.cpp
index 5d3de7bfb..f5571ed13 100644
--- a/src/client/hud.cpp
+++ b/src/client/hud.cpp
@@ -1118,7 +1118,7 @@ void drawItemStack(
                        video::SMaterial &material = buf->getMaterial();
                        material.MaterialType = video::EMT_TRANSPARENT_ALPHA_CHANNEL_REF;
                        material.Lighting = false;
-                       driver->setMaterial(material);
+                       /*driver->setMaterial(material);*/
                        driver->drawMeshBuffer(buf);
                }

[erlehmann]

The following patch should skip some setMaterial invocations I think, but it does not make this bug disappear for me:

diff --git a/src/client/hud.cpp b/src/client/hud.cpp
index 5d3de7bfb..a48970003 100644
--- a/src/client/hud.cpp
+++ b/src/client/hud.cpp
@@ -1096,6 +1096,7 @@ void drawItemStack(
                video::SColor basecolor =
                        client->idef()->getItemstackColor(item, client);
 
+               video::SMaterial &prev_material = driver->getMaterial2D();
                u32 mc = mesh->getMeshBufferCount();
                for (u32 j = 0; j < mc; ++j) {
                        scene::IMeshBuffer *buf = mesh->getMeshBuffer(j);
@@ -1118,8 +1119,10 @@ void drawItemStack(
                        video::SMaterial &material = buf->getMaterial();
                        material.MaterialType = video::EMT_TRANSPARENT_ALPHA_CHANNEL_REF;
                        material.Lighting = false;
-                       driver->setMaterial(material);
+                       if (prev_material != material)
+                               driver->setMaterial(material);
                        driver->drawMeshBuffer(buf);
+                       prev_material = material;
                }
 
                driver->setTransform(video::ETS_VIEW, oldViewMat);

[erlehmann]

The following patch, when applied with git am, might slightly improve performance for rendering item stacks (to be determined):

From e90a90d2eafee28c653d970832fedc181b4e9926 Mon Sep 17 00:00:00 2001
From: Nils Dagsson Moskopp <nils@dieweltistgarnichtso.net>
Date: Tue, 24 Oct 2023 21:41:56 +0200
Subject: [PATCH] Do not set material for item stack needlessly

---
 src/client/hud.cpp | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/src/client/hud.cpp b/src/client/hud.cpp
index 5d3de7bfb..16a769c9b 100644
--- a/src/client/hud.cpp
+++ b/src/client/hud.cpp
@@ -1096,6 +1096,7 @@ void drawItemStack(
 		video::SColor basecolor =
 			client->idef()->getItemstackColor(item, client);
 
+		video::SMaterial &prev_material = driver->getMaterial2D();;
 		u32 mc = mesh->getMeshBufferCount();
 		for (u32 j = 0; j < mc; ++j) {
 			scene::IMeshBuffer *buf = mesh->getMeshBuffer(j);
@@ -1116,9 +1117,13 @@ void drawItemStack(
 				setMeshBufferColor(buf, c);
 
 			video::SMaterial &material = buf->getMaterial();
-			material.MaterialType = video::EMT_TRANSPARENT_ALPHA_CHANNEL_REF;
-			material.Lighting = false;
-			driver->setMaterial(material);
+			// only set material if it is not already set
+			if ( (0 == j) || (prev_material != material) ) {
+				material.MaterialType = video::EMT_TRANSPARENT_ALPHA_CHANNEL_REF;
+				material.Lighting = false;
+				driver->setMaterial(material);
+			}
+			prev_material = material;
 			driver->drawMeshBuffer(buf);
 		}
 
-- 
2.30.2

[erlehmann]

I have investigated 3 frames using qapitrace and the corruption seems to begin consistently with 6884th or 6886th gl command, regardless of if that command is drawing anything to the screen (so far glColor4ub and glRectf were these commands).

Edit: My friend (who knows 3D stuff better than me) says a) a limited amount of gl commands per frame is a thing b) such a high number is “ridiculous” though.

[erlehmann]

I have come to the conclusion that item stacks should probably be rendered once and then cached to fix this issue and all kinds of performance issues that result from the massive amount of drawcalls that looking at an inventory produces. Unless I am mistaken, this should not be too hard for non-animated item stacks.

[erlehmann]

For future reference (if anyone has similar corruption):

1. My studs mod is basically making the already bad rendering of inventories worse. Nodeboxes in general are affected.

2. That patch I posted above is wrong. It results in one more OpenGL function call per frame, not less resource use.

3. Ville Syrjala (vsyrjala on #intel-gfx on OFTC) told me “the driver will flush stuff out as the batch fills up”, but apparently there is no error condition for the engine here to even react to. It pretty much explains why this does not happen in software rendering to me – obviously the software renderer has no limits set by hardware, so it just becomes painfully slow when the number of OpenGL function calls increase. I guess one could try to make more complex nodeboxes or display more items in inventory until other hardware craps out … in the end the solution stays the same: Improve the performance of inventory rendering.

4. It seems that changing the material often is an issue. Just doing many drawcalls is not an issue. I wonder if having some texture atlas for node textures could solve this. I also wonder if having some kind of automatic batching support can help. I am planning to look into this.

5. You can get interesting limits of your graphics cards with glxinfo -l.

[erlehmann]

@Calinou I saw bug https://gitlab.freedesktop.org/mesa/mesa/-/issues/722 over at Mesa about Minetest artifacts that you (?) observed. Do the artifacts you experienced look like the ones in this issue? Also could you try to reproduce this issue on your hardware?

[Calinou]

@Calinou I saw bug gitlab.freedesktop.org/mesa/mesa/-/issues/722 over at Mesa about Minetest artifacts that you (?) observed. Do the artifacts you experienced look like the ones in this issue? Also could you try to reproduce this issue on your hardware?

I no longer have access to the hardware in question (I originally reported that issue in late 2012, and I've decommissioned that netbook years ago). That said, I remember the vertex explosions looking similar to what you're mentioning here.

I also remember opening the inventory being a common cause of this, especially if you have a lot of mods installed or a lot of inventory images need to be cached (back when node icons were prerendered when first needed, as opposed to being rendered in 3D).