Difficult to reproduce rendering bugs

[Custodian]

We've had a recurring problem with portions of level textures outright disappearing. The resultant effect looks like this:




While this problem occurs, no HUD or Menu graphics will appear. This problem only occurs in certain areas of the map. I'm at a total loss for what even causes this problem. I initially suspected this was a nodebuilder error. But we haven't been able to reproduce this issue consistently and honestly have no idea how to reproduce it. I was able to save my game while it was happening. Reopening the game with the savefile does not resolve the issue. Because this is for a commercial game project, I cannot share the files here. If you are a dev and want to see the problem firsthand, I can send you a copy of the game with a savefile where this issue occurs via DM. Restarting the game with OpenGL or GLES fixes the issue.

It's been a real nightmare to troubleshoot, so any insight is greatly appreciated.

Thanks!

Details: GZDoom 4.7.1
Graphics hardware on which this has been observed: AMD RX 580, nVidia GeForce RTX 2060 (and many others, this issue seems to exist across multiple different diverse computers)
Any help is wildly appreciated. Thanks!

[Custodian]

To add some more details, this issue does not occur consistently, it seems to happen maybe once every 10 or so playthrus. It never seems to occur if I move the player start into the areas it happens and launch the game repeatedly from there., it only really seems to occur after I've been playing for a bit.

[Graf Zahl]

If you want insight you have to make your map available.

[Custodian]

If you want insight you have to make your map available.

This is a commercial project and won't be available to the public for a while, unfortunately. I'm trying to limit the number of copies drifting around in the wild. I can share files via PM, if that's acceptable. I didn't just want to spam the devs with copies of the file.

[Rachael]

That's always been standard practice anyhow. Many people don't want to share their work but the devs need a copy of the malfunctioning bits of the project in order to fix them. So sending it privately has always been an acceptable compromise. Being commercial makes it no different.

It really comes down to - do you want this fixed, or not?

[Custodian]

Thanks for clarifying! I was hoping to avoid being rude, I am glad to hear this is standard practice. Dropbox link incoming

[Graf Zahl]

That really looks bad. The easiest way to get it was to activate fly mode and move as high as you can.
Since this also renders all 2D overlay invisible it seems like something is not properly resetting its state.

For anyone who wants to test, here's a savegame right at the most troublesome spot I saw. (for me this produces an entirely black screen when being loaded.)

[Custodian]

Thanks for taking the time to look at this! I just wanted to update yall that I found a way to reproduce this bug outside of my game with stock Doom. If you launch the game in windowed mode and Vulkan, then pause the game and resize, this issue will appear.

[Custodian]

I'm not entirely convinced this problem isn't the result me doing something wrong. With the demo publicly announced for release in two weeks, resolving this issue is a top priority for me.
I want to know if you have any idea of what might be causing this problem and what things I should look for in my level to try to resolve it.

Given that this occurs in specific areas of the level, I'm not convinced that the issue is necessarily an engine problem. If it's some kind of design-side issue that are within my ability to fix, that kind of a solution is preferable. I haven't been able to identify any common factors in the level that might be causing this aside from these:

(1) It only happens in areas where I am changing the texture of a linedef via ACS and
(2) areas where there are many sloped floors present.

I thought at first this may be an issue with portals, but I was able to rule those out by remove them all and playing over and over until the issue occurred. Any suggestions for troubleshooting issues with my WAD are greatly appreciated, this is something I very much want to fix before release.

[Rachael]

Alright - this is an educated guess as to what is happening based on empirical observation and hypothesized guessing - I think the problem is too many texture references and either the Vulkan backend isn't able to handle it, or the driver is dropping them when too many are on the screen at once. Which it shouldn't, but Vulkan and GZDoom haven't ever been able to get along too well anyway, there's been a lot of growing pains and a lot of it is due to the fact that the Vulkan API in general is an absolute nightmare to work with for developers.

But please take this with a grain of salt - I can only guess what is happening with my knowledge of engineering, not with actual experience with the code. I am not 100% positive that this is the issue.

I will do what I can to bring this issue to the right people, but I can't make any promises that this issue will get fixed.

Is this issue on your mod's side? Nope. But can it be addressed on the mod side? That depends. Reducing the sprite animations might help. Or other animations, in general. Putting up some occlusion (i.e. 1-sided line structures) might help (but I doubt it).

[Graf Zahl]

To me this looks like an issue with the clipping planes. Something apparently is not resetting them in the backend so they stick around for elements that should not use them.
The problem here is, of course, that this is a bug in the backend, and as Rachael indicated, Vullkan's API is a nightmare to work with, so you just don't have clear and concise code to look at but often some incomprehensible gobbledygook low level hardware access that won't easily reveal such issues.

[Custodian]

Thanks for the insights guys! My level does have a high number of textures and my sprite animations have a much higher temporal resolution than the base game. I have often wondered if using 16-angled sprites with roughly 8 unique frames per animation state might be a bit taxing. I think my first test here will be to split some parts of the level off into a separate map. Breaking up the map, at the very least, will let me further isolate the issue if it continues to occur.

[Custodian]

I wanted to share an update on this, I have done some troubleshooting and here are my results. First, i split that big map into two smaller maps. I felt this could help, but alas, one of my playtesters found the issue on the map after it was split up.

To try to narrow the problem down a bit, I got a copy of the game from the playtester who was having the bug. Like the version I sent everyone in this thread, I loaded the save file with the bad game, and attempted to eliminate things which could cause the problem one by one, except by making changes to the map which would render the save file un-openable. Here's what I have tried so far. I retained the changes made in each previous troubleshooting step, so at the end, these were all the changes I made together:

• Switched to OpenGL (things worked correctly), made a new save, then reopened that save under Vulkan, issue persisted into the new save. Works fine in OpenGL, has the same problem in Vulkan.
• I deleted all the GLDEFS and brightmaps from the PK3. The issue persisted.
• I deleted 8 angles from all the enemy sprites, reducing them from 16 angles to the standard Doom 8 angles. The issue persisted.
• I deleted all TEXTURES lumps and ANIMDEFS, the issue persisted.
• I deleted every texture in the game, the issue persisted.
• I removed "PixelRatio" from the ZMAPINFO lump, issue persisted
• deleted INI file from directory, issue persisted
• disabled dynamic lights, changed texture filtering to none. issue remains
• deleted ZNODES from the affected map - very surprised that the game loaded after this was removed - still the same problem.
• cleared node cache - still the same issue
• I deleted every sprite in the game except for hud sprites, the issue persisted.
• I deleted all /graphics and /fonts the issue persisted.

So even with essentially every graphical asset removed from the game, the problem persisted.

Correct me if I am wrong, but shouldn't eliminating all graphical assets rule out the possibility that there is an issue with running out of texture memory or the like? I admit I'm not really someone who understands hardware rendering all that well, so I apologize if that's not the right way to describe the problem. But, ultimately, the problem persists when the game has close to no graphics assets at all.

[Rachael]

Yeah it would. So it's probably a clipping planes issue - just like Graf said.

Remember though, that I never said that I was sure of my assessment.

I've given the mod to the only people I know who can fix it. I can't do much more than that. You have very few options open to you if you absolutely must have this fixed by a certain date.

[Custodian]

Nobody is beholden to my schedule but me, and I certainly don't want to put any pressure on the devs to resolve this. It's such a rare problem, and I haven't heard anyone else encountering it. It's an edge case, so I don't expect anyone to cater to me when there are other more urgently-needed solutions in the works that affect more users.

Ultimately, this is a consequence of a few different things I should have paid closer attention to. Updating my graphics drivers made OpenGL not viable as a testing solution, as models and voxels display incorrectly with AMD cards + opengl. GLES has just all-around weird issues I can't even begin to articulate, and Vulkan seems to be nearly perfect, save for this one rare weird-ass rendering bug. It unfortunately appears that the openGL issues persist even with the latest drivers, and rolling back to older drivers still resolves the OpenGL problems. I don't think it's reasonable for me to ask people to roll back to old drivers to play my game.

I have no idea how to push AMD to resolve the issue on their end, sadly. Everything worked perfectly, as intended, when I could still use OpenGL.