[Duplicate] GZDoom hardware rendering bug.

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

GZDoom hardware rendering bug.

Postby inkoalawetrust » Wed Sep 15, 2021 10:17 am

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:

Image

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.
User avatar
inkoalawetrust
 
Joined: 26 Aug 2019
Discord: inkoalawetrust #9783
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia (Modern GZDoom)

Re: GZDoom hardware rendering bug.

Postby Graf Zahl » Wed Sep 15, 2021 10:53 am

Yeah, don't do that. It's classic z-fighting and with such extreme overlaps pretty much unavoidable.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom hardware rendering bug.

Postby Enjay » Wed Sep 15, 2021 10:55 am

[edit]Ninja'd by Graf. :ninja: [/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.
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: GZDoom hardware rendering bug.

Postby Rachael » Wed Sep 15, 2021 11:48 am

Am I the only one seeing that the intent of the bug report seems to be the row of pixels being drawn infinitely down?
User avatar
Rachael
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: GZDoom hardware rendering bug.

Postby inkoalawetrust » Wed Sep 15, 2021 12:48 pm

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.

Enjay wrote: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.
User avatar
inkoalawetrust
 
Joined: 26 Aug 2019
Discord: inkoalawetrust #9783
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia (Modern GZDoom)

Re: GZDoom hardware rendering bug.

Postby Graf Zahl » Wed Sep 15, 2021 1:15 pm

In that case:

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

That may be a decal but it's exactly the same thing.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom hardware rendering bug.

Postby Enjay » Wed Sep 15, 2021 1:28 pm

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.
You do not have the required permissions to view the files attached to this post.
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: GZDoom hardware rendering bug.

Postby Graf Zahl » Wed Sep 15, 2021 2:09 pm

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom hardware rendering bug.

Postby inkoalawetrust » Wed Sep 15, 2021 2:10 pm

Graf Zahl wrote: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. :ninja:

Enjay wrote: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.
User avatar
inkoalawetrust
 
Joined: 26 Aug 2019
Discord: inkoalawetrust #9783
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia (Modern GZDoom)

Re: GZDoom hardware rendering bug.

Postby Enjay » Wed Sep 15, 2021 2:41 pm

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.
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: GZDoom hardware rendering bug.

Postby Graf Zahl » Wed Sep 15, 2021 2:53 pm

inkoalawetrust wrote:
Graf Zahl wrote: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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom hardware rendering bug.

Postby drfrag » Fri Sep 17, 2021 6:11 am

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
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: GZDoom hardware rendering bug.

Postby Graf Zahl » Fri Sep 17, 2021 6:25 am

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom hardware rendering bug.

Postby drfrag » Fri Sep 17, 2021 6:53 am

I mean the changes, the code in the shader was already there. Actually it works.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: GZDoom hardware rendering bug.

Postby Graf Zahl » Fri Sep 17, 2021 11:39 am

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Next

Return to Closed Bugs

Who is online

Users browsing this forum: No registered users and 0 guests