Need to have gl_polyoffset for movable walls

[T4r4sB]

Sometimes I see z-fighting, for example, here (e2m1): https://s8.hostingkartinok.com/uploads/images/2018/04/4861fdc3e227ebef4299cde3f36a6751.jpg In original software-rendering WinQuake there is no problem, because original uses custom polygon culling without z-checking.

But with OpenGL we can't use same technique. I think, using negative polyoffset will fix this problem.

[ericwa]

Have you tried setting gl_zfix 1? That's the best currently available for playing maps (including the base game) with z-fighting. It enables some old / hacky offsetting code, but it's disabled by default, because it can also introduce new artifacts where there were none before (secret doors in e1m1).

What I want to do some time is implement better emulation of winquake by detecting fragments on the same plane without using the depth buffer, i.e. this idea but done in glsl: https://www.khronos.org/registry/OpenGL/extensions/SGIX/SGIX_reference_plane.txt

[T4r4sB]

You right, z_fix is not a good decision, because I will see a 1-pixel dot border around secret doors. I hope, than reference_plane will be a better way to fix z-fighting.

[HonzaCholasta]

Is there something wrong with using polygon offset to fix z-fighting? I tried adding polygon offset to R_DrawBrushModel (see HonzaCholasta/Quakespasm@1bcb1288e4868d8f5c26557552e4918dc91bba22) and it seems to have fixed it just fine. Am I missing something here?

[ericwa]

Hi, I don't know if there was a good reason Quakespasm wasn't using glPolygonOffset.

The current gl_zfix code, which is just sliding the model slightly, fails in cases like these:

map e1m1
setpos -291 2925 -23 5 125 0

How does it look if you delete these bits:

if (gl_zfix.value)
{
        e->origin[0] -= DIST_EPSILON;
        ...
}

and also use glPolygonOffset?

[HonzaCholasta]

I tried the following:

• gl_zfix 1 and no polygon offset
• gl_zfix 0 and polygon offset with the default factor 1
• gl_zfix 0 and polygon offset with factor 0.1

This is how it looks like:

Polygon offset with factor 1 is only slightly better than gl_zfix 1, but with factor 0.1, it's hardly noticeable. Not sure if it would look like this on different hardware or resolutions higher than 1920x1080 though...

[HonzaCholasta]

I did more extensive testing and unfortunately it seems that there is no polygon offset factor value which reliably fixes z-fighting and does not reveal secrets. So I guess that's the reason why it was not used in the first place.

[mhQuake]

For the general case, the following probably works better than anything else: VectorMA (e->origin, DIST_EPSILON * gl_zfix.value, vpn, zfix_origin)

Then use zfix_origin instead of e->origin when positioning the entity. That kills 99% of z-fighting problems stone dead with a gl_zfix of 1, without revealing secrets via cracks in the geometry, and also allows for some user-configurable tuning.

The 1% it doesn't kill includes stubborn cases like the platform in e1m1, but I've never seen a z-fighting fix that kills that without introducing other, more serious problems elsewhere. For Quake I think at this stage it's probably OK to just state that ID1 maps are legacy content so it's OK to hard-code fixes for problem areas like this into the engine - in that case, detect model name "*15" in e1m1 (CRC the entities lump for a more robust match) and drop it's origin[2] by some epsilon.

Polygon offset is problematical in that the spec for it includes an implementation-dependent constant term, so values that work on one GPU/driver won't necessarily work on another. It's not a magic fix for z-fighting.

[NightFright2k19]

Please note that I have released the "Vanilla Quake Fixes" which contain a full set of z-fighting fixes for all ID1, SoA and DoE maps. The Quakespasm authors are welcome to take whatever they want from this pack to address these issues.