Sprite rendering order transparent midtexture error

[Bauul]

There seems to be an issue around the order the sprites are rendered on-screen when a transparent midtexture is also present in the same part of the screen. Sprites that are in the same section of the screen as the transparent midtexture are rendered infront of sprites that are in a different part of the screen, even if they are physically behind them.

Attached is an example wad. If you run side to side behind the transparent-textured sector, you can see how the order of the drawn Cacodemons shifts around. Removing the transparency on the midtextures removes the issue. It also seems to require more than one transparent midtexture, and manifests when viewing sprites that are behind midtexture which itself is not closest to the camera. My hunch is its something to do with how the engine handles multiple overlapping transparent textures, and sprites that are included in that calculation get their rendering bumped artificially forwards meaning the overlap things they shouldn't.

This is tested with 4.6.1, and is easily replicable. Note: it seems to be present in 4.6, but not in in 4.5, so seems to be a relatively new issue. Apologies if this has already been reported - I searched but couldn't find anything.

Example screenshot. All the (dormant) Cacodemons are physically further away than the transparent SHAWN2 texture, but are being rendererd in front of it and the other (closer) Cacodemons.

[Graf Zahl]

I cannot reproduce this with any version, neither official 4.6.1 nor self-compiled 4.6.1 and master.
What's your hardware specs?

[Bauul]

I cannot reproduce this with any version, neither official 4.6.1 nor self-compiled 4.6.1 and master.
What's your hardware specs?

Edit for quick reading: Found the issue, it's the "Sprite Billboarding" X/Y Axis setting and "Sprites face camera" setting in the Hardware Renderer. If either of these are set, the issue occurs.

Example video:






Original post:

Processor: Intel Core i5-7300HQ CPU @ 2.50GHz
GPU: NVidia GTX 1060 MaxQ (i.e. the laptop version)
16Gb RAM, SSD, Win 10 64bit, latest drivers and all that.

Tested in all three hardware renderer modes (OpenGL, Vulkan and Softpoly), same issue in all of them. Doesn't happen in Software mode.

I recorded a video to make it more obvious what's going on:


Actually, a development: I just tried it on a fresh config with 4.6.1 and it doesn't happen. It must be something in my config causing it. I'll do some experimenting and see if I can work out the exact cause.

[wildweasel]

Before you do too much experimenting, you might want to post a copy of your INI file where you're seeing the glitches.

[Bauul]

Before you do too much experimenting, you might want to post a copy of your INI file where you're seeing the glitches.

Good shout, attached here in case it's useful.

[Graf Zahl]

What happens here is rather simple. The renderer is unable to properly sort x/y billboarded sprites due to how they get oriented in the world.
So unlike normal sprites which are split across translucent linedefs they just get sorted by their origin point. And depending on where you stand, the side line of the translucent box is picked first for sorting, not the back line, so these sprites may get sorted in outside the box area and rendered too late. The exact same problem can happen with wall and flat sprites due to their ability to get rotated into non-orthogonal positions.

[Gez]

Probably a [wontfix] issue honestly; the jank with non-default sprite orientations is a known and accepted limitation of the engine.

[Bauul]

Yep, I went back and checked through old versions of GZDoom to find when the glitch first started occurring, and you're right, you have to go back about five years: it first appeared in GZDoom 2.2.0. In GZDoom 2.1.1 and earlier they render correctly.

If it's been five years and barely anyone has noticed (myself included) then it probably isn't a big enough deal to fix. But it's interesting to know that it did render correctly upon a time at any rate.

[Gez]

I'm pretty sure the option to have "sprites face camera" didn't even exist in 2.1.1, so that's not exactly an apple-to-apple comparison.

[Graf Zahl]

The glitch was surely there before as well, but the line picking logic may have changed due to feature addtions.

[Bauul]

I'm pretty sure the option to have "sprites face camera" didn't even exist in 2.1.1, so that's not exactly an apple-to-apple comparison.

No you're right, but "X/Y Billboarding" was there, which is what I was checking against.

The glitch was surely there before as well, but the line picking logic may have changed due to feature addtions.

That would make sense. Plus 2.1.1 is such a long time ago there could be all sorts of things changed since then which would compound the issue.

Ok, happy for this to be flagged as [wontfix]. Thanks for confirming what the issue was!