GZDoom hardware rendering bug.

[inkoalawetrust]

Sorry for the vague title, phpBB didn't allow me to type a more descriptive one. Anyway, I've noticed that a peculiar rendering bug occurs when a slope, 3D floor, and middle texture share the same linedef, and are in contact with each other. (The last one doesn't necessarily cause the bug, more on that below.) The bug causes a row of pixels on the middle texture to be redrawn infinitely below it, here's a screenshot of that:



Lifting the middle texture on both sides one map unit above the 3D floors' side texture, stops the the bug, but it only stops it for the sides of the linedef facing outwards from the bridge like the one above, the bug still occurs on the inwards line sides. The only way to get rid of it entirely for both the inwards and outwards sides of the lines is to lift the inwards facing middle textures really high up.

This is not the first time I've encountered the bug, it had also happened back in 2019, when I was working on another map, and had made more or less the same bridge. But the difference is that back then, lifting all sides of the railing texture by 1 map unit prevented the bug entirely. Instead of only working for the sides facing away from the bridge.

Here is a video demonstrating the bug and me lifting the railing texture to prevent it.

And also here is the exact map shown in the video, along with the texture archive I used, so the bug will occur

Something else I've noticed is that the bug doesn't seem to occur in the software renderer, only in hardware.

[Graf Zahl]

Yeah, don't do that. It's classic z-fighting and with such extreme overlaps pretty much unavoidable.

[Enjay]

[edit]Ninja'd by Graf. [/edit]

Mapname is SHOWCASE, position to see the bug X100 Y-2400

What this looks like is ZFighting. It happens when two surfaces are in exactly the same plane (in this case the bottom of the railing texture and the side of the 3D floor). GZDoom had no way to know what to draw, so the results are glitchy and unpredictable. I've never seen it do that odd fill effect below the floor before but, like I said, it's unpredictable.

You are correct that it only happens in hardware rendering modes. Software does things very differently as far as situations like this are concerned.

In other words, this is not something that the engine can sort out and it is essentially a mapping error if the intended destination for the map is hardware rendering.

[Rachael]

Am I the only one seeing that the intent of the bug report seems to be the row of pixels being drawn infinitely down?

[inkoalawetrust]

I'm seconding Rachael, I know what Z-fighting is, and how, and why it happens. But the issue isn't that two graphics are occupying the exact same space, it's that putting a middle texture on top of a 3D floor, that is itself on top of a slope. Causes the hardware renderer to fill everything below the middle texture with the textures' last row of pixels.

Mapname is SHOWCASE, position to see the bug X100 Y-2400.

My bad, I forgot to also mention that you need to type "map showcase" in the console to enter the city map where the bug happens.

[Graf Zahl]

In that case:

Duplicate of viewtopic.php?f=2&t=71998

That may be a decal but it's exactly the same thing.

[Enjay]

Seeing as how it's been identified, this probably isn't needed. However, I was poking around trying to figure it out and created a very cut down version of the original map that doesn't need a texture pack or anything.

It is interesting that as soon as the texture is moved so that the railing sits on top of the 3D floor instead of intersecting with its side, both the Zfighting and the bleeding effect stop.

[Graf Zahl]

The clamping problem is actually very simple: None of the default hardware clamping modes provides what is needed here, it needs to be custom implemented in the shader.
The alternative would be some costly polygon processing to cut down the wall polygon to the valid area.

[inkoalawetrust]

In that case:

Duplicate of viewtopic.php?f=2&t=71998

That may be a decal but it's exactly the same thing.

Any idea what could be causing this internally ? Besides slopes just being a nightmare to deal with for players, modders, mappers, and developers alike in general.

Edit: Oops, seems like you already answered right after I posted.

Seeing as how it's been identified, this probably isn't needed. However, I was poking around trying to figure it out and created a very cut down version of the original map that doesn't need a texture pack or anything.

It is interesting that as soon as the texture is moved so that the railing sits on top of the 3D floor instead of intersecting with its side, both the Zfighting and the bleeding effect stop.

In that example you've already changed the vertical offset of the bars to intersect with the bridge and cause Z-Fighting though, but if you just set the bars right on top of the 3D floor, where the textures can't intersect, then the bars bleed down anyway like Graf mentioned, which is what ends up also causing bleeding. Also I mentioned this in my first post, but while raising the bars to float just one MU above the bridge stops the bug, it only stops it partially, the sides of the line facing the inside of the bridge will still bleed unless you offset the bars much higher up on those sidedefs*. Which is weird, because when I had this bug happen years ago, raising the middle texture by one MU totally prevented the bug, on both sides of the lines.

*I showed that in the video I linked too.

[Enjay]

Actually, I didn't change the most of the Y offsets at all. I used the offests in your original file. However, because your custom texture is shorter than the texture I swapped them with, they all look different (and therefore their bases sit below floor level).

The one that I did move (one of the ones on the far side of the valley) only showed the issue for me when the bottom of the texture intersected the side of the 3D floor by at least 1 unit. If it was sitting exactly on top of the bridge, then no zfighting and no bleeding occurred. Certainly, 1 pixel gap above the bridge also stopped both of those effects.

So that's why I reported what I did. To be fair though, once I saw that the bug had been identified, I didn't bother digging much further and didn't mess with any more offsets.

[Graf Zahl]

In that case:

Duplicate of viewtopic.php?f=2&t=71998

That may be a decal but it's exactly the same thing.

Any idea what could be causing this internally ? Besides slopes just being a nightmare to deal with for players, modders, mappers, and developers alike in general.

Sure I know. Decals and mid textures get rendered with texture clamping to avoid edge bleeding. But with slopes this can only be done right if the resulting wall polygon is clipped to the texture size afterward. I skipped that part because it is so rare and wasn't worth the added processing time when this code was initially written.
It can be solved much easier in the shader now so that's how it will be fixed.

[drfrag]

Seems it's fixed in LZDoom too, i don't get what was the shader part for tough. The decal part was not applicable.
https://github.com/drfrag666/gzdoom/com ... 54e5b31587

[Graf Zahl]

The shader part was the actual thing performing the clipping. All changes to the C code were just to set the right flag if needed.

[drfrag]

I mean the changes, the code in the shader was already there. Actually it works.

[Graf Zahl]

It was there, but as a dedicated texture mode. I had to turn it into a flag so that it can be used with all texture render modes and not just with default. Decals also need it for alpha textures.