Issue with wall damage/scorching.

Not quite sure what the technical term is for the black marks weapons make when they strike a wall, but that's what I'm having issues with anyway.

Regardless of what source port I use this is the result, with the black marks being covered in Xs and lines that flicker as I move around, making them quite noticeable at a distance. I believe this is something to do with OpenGL as it doesn't occur with software rendering, and I noticed a similar effect when sprites clipped through walls in Powerslave EX. That being said this bug isn't really Doom specific, but I couldn't find any mention of it through searching, so figured here is probably the best place to ask.

While this is Heretic the same thing occurs in Doom, Doom2, etc.

In case it's relevant:
OS: Debian 64bit
OpenGL Version: 2.1 Mesa 11.2.2

This looks like an OpenGL driver bug. The decals in GZDoom use a feature named 'polygon offsetting', and if that does not work, the results will be precisely what you see here.

Likely culprit in that case is probably my old hardware and (by extension) my old OpenGL version, guess I'll just have to live with it.

The feature we are talking about has been supported by nearly all graphics hardware that has been manufactured in the last 15 or so years. If I remember correctly it has been part of OpenGÖL since version 1.2.

What hardware precisely are you using?

Faeren said:

Not quite sure what the technical term is for the black marks weapons make when they strike a wall, but that's what I'm having issues with anyway.

Decals

It looks like simulated transparency via dithering. Years ago when 15 and 16-bit color video cards were popular, Windows would dither colors to simulate 32-bit color, producing a similar effect. It wasn't pretty, but it was better than nothing.

Graf Zahl said:

The feature we are talking about has been supported by nearly all graphics hardware that has been manufactured in the last 15 or so years. If I remember correctly it has been part of OpenGÖL since version 1.2.

What hardware precisely are you using?

It was just a guess, as I've had the same issue on this computer through multiple OS/Distro changes. So assumed that the issue might be due to my hardware.

CPU: Intel Core 2 Duo P8700
GPU: GMA 4500MHD

kb1 said:

It looks like simulated transparency via dithering. Years ago when 15 and 16-bit color video cards were popular, Windows would dither colors to simulate 32-bit color, producing a similar effect. It wasn't pretty, but it was better than nothing.

I think it's just regular old z-fighting though.

That was the best interpretation of z-fighting I have ever seen... :D

Graf Zahl said:

That was the best interpretation of z-fighting I have ever seen... :D

Quasar said:

I think it's just regular old z-fighting though.

Ah. I guess it *could* be. So in OpenGL and the like, decals are actually placed physically in front of the wall, by a small finite amount? Thus, do you think that increasing that amount would make such a bug disappear?

I would expect something a bit more smooth looking though, like a plane being sliced. Instead, you've got some small repeating patterns there which strongly suggest dithering, or fake/fast translucency.

At first, I'd have put my money on dithering - some of the patterns are shaped very logically for dithering. But, it's too ugly of a result to think it's working properly - I'd expect it to do better than that. That NE/SW slanted line, visible in the pattern, is curious, suggesting an off-by-one issue.

Have you ever seen a z-fighting situation produce the dithering-like checkerboard patterns like this? Very interesting, and a mystery to me.

Another possibility: Video card/driver defect?

kb1 said:

Ah. I guess it *could* be. So in OpenGL and the like, decals are actually placed physically in front of the wall, by a small finite amount? Thus, do you think that increasing that amount would make such a bug disappear?

OpenGL is very unspecific about how glPolygonOffset works, so it may help with some rare badly implemented driver. The current values never have caused problems, though, so I'm hesistant to change them for some really obscure old hardware/driver combination.

kb1 said:

I would expect something a bit more smooth looking though, like a plane being sliced. Instead, you've got some small repeating patterns there which strongly suggest dithering, or fake/fast translucency.

That's how z-fighting works. You essentially get two planes that are virtually identical so the imprecisions in the math put the first plane in front for some and in back for other pixels. Keep in mind that the effect isn't static. It will constantly fluctuate if you move around, this obviously cannot be reproduced by a screenshot.

Have you ever seen a z-fighting situation produce the dithering-like checkerboard patterns like this? Very interesting, and a mystery to me.

Yes. But now that you mention it, this indeed looks like it's partially z-fighting and partially dithered translucency. In any case, that hardware/driver combination can safely be considered unsupported by the engine. As long as it runs the engine, fine, but don't expect me to invest any work here.

Graf Zahl said:

OpenGL is very unspecific about how glPolygonOffset works, so it may help with some rare badly implemented driver. The current values never have caused problems, though, so I'm hesistant to change them for some really obscure old hardware/driver combination.

I just thought it would be interesting to see the entire decal, if it were pulled out of the wall, to see how much of the problem actually is z-fighting, and how much is a botched translucency hardware situation. Seems like it'd be worth a hack up and compile trial for Faeren.

Graf Zahl said:

That's how z-fighting works. You essentially get two planes that are virtually identical so the imprecisions in the math put the first plane in front for some and in back for other pixels. Keep in mind that the effect isn't static. It will constantly fluctuate if you move around, this obviously cannot be reproduced by a screenshot.

Z-fighting occurs at the floating-point epsilon, doesn't it? That decal must really be placed arbitrarily close to the wall to cause z-buffer fighting in only one driver. I have to believe that the decal is transformed and rendered with the same algorithm that translates the walls, suggesting that the math error should at least 'look' uniform. Strange, indeed.

Graf Zahl said:

Yes. But now that you mention it, this indeed looks like it's partially z-fighting and partially dithered translucency. In any case, that hardware/driver combination can safely be considered unsupported by the engine. As long as it runs the engine, fine, but don't expect me to invest any work here.

As for me, I have no expectations - I am simply commenting on what I see. Of course, if you were motivated, you could probably change the decal distance, compile, send an email, change it back, and see an updated screenshot, without committing more than 20 minutes, or so. I'd like to see the results, anyway :) Currently, I'm not prepared to build GZDoom at the moment, or I'd try it. (Not that anything is wrong with GZDoom. I'm convinced that it's the video driver/video hardware. It's just an interesting issue, that's all.)

kb1 said:

I'm convinced that it's the video driver/video hardware.

Me, too. On top of that it's hardware I consider legacy. I have been trimming down support for legacy (i.e. pre-GL 3.x hardware) for some time now to keep the code simple and maintainable. My focus is clearly on hadware that supports modern techniques. I'll keep these old things working as long as possible but it's not the focus of the engine. This legacy stuff already costs more time than it is actually worth and sooner or later support for it will be dropped.

The funny thing with this particular "legacy" video card, is that if Intel wanted they could just as well make an OpenGL3 "compatible" driver that does everything in software, as was their policy with the dreadful integrated GMAs since the DX10 and the Vista days. This way, most features appear to work (or rather, most feature detection tests pass). Whether they actually work or perform satisfactorily, that's another matter altogether ;-)

That GPU/driver probably just doesn't support/implement glPolygonOffset at all.