Ways to eliminate z-fighting

[KillPixel]

Hello fine folks of QuakeOne!

I've been creeping around this forum for the past few years and learned some cool things along the way (especially in the modding department). I've recently taken on a new challenge: z-fighting. I'm pretty sure I've already been defeated, but before I give up I want to run a few things past you guys.

After some reading and talking to some people I've decided that there is no 100% fix for z-fighting engine-side, so I've decided to go fix the maps themselves. Here are some of the issues I've discovered with that:

1. I'm an idiot.
2. BSP files can't be decompiled without some errors.
3. Once I have the map open (so far I've used BSP, WorldCraft and Quark) how do I even fix z-fighting (in the instance of the quad lift in e1m1)??.

It seems issues 1 and 2 can't be helped. Issue 3 will require me educating myself (FFUUUU). But, issue 3 is irrelevant if I can't even get a decompiled map in there without issue...

So, this is my conclusion (please, PLEASE tell me I'm wrong):

The only way to fix z-fighting issues in quake is map-side. This will require decompiling the map and fixing the errors that have arisen by doing that and then addressing the real issue. Or, just remake the map from scratch (yeah right.)

I really want to eliminate z-fighting but I simply don't have the time to learn how to edit/make maps and fix every instance of z-fighting within quake and the mission packs.

I did, however, find something cool on the software side of addressing z-fighting.

I don't know, I'm not even sure what I'm asking, I just want z-fighting to go away

On a side note, anyone know of a way to run software quake in 1920x1080 at the correct aspect ratio

[MH]

Ah, I recognise you.

zbias doesn't work because the depth buffer is non-linear. A value of 'x' for zbias with near objects will give a completely different result with far objects. OpenGL makes things worse because it allows the effects to be implementation-dependent.

Fortunately the id1 maps were all released under the GPL some years ago. It's just a matter of finding the map sources, grabbing some build tools and doing what's needed.

A copy of the map sources is available here: quake_map_source.zip

Edit: actually that projection matrix trick looks interesting and seems to work well...

[KillPixel]

I figured you'd spot me

I was not aware the map sources were available...that solves the decompiling BSP issue...

Looks like I'm going to teach myself map editing, it's something I've always wanted to learn anyway (It's not like I already have enough projects going on... -_-)

"Edit: actually that projection matrix trick looks interesting and seems to work well..." -that statement made me squeal like a school girl.

[KillPixel]

HO HO! I fixed my first instance of z-fighting...

There are some weird problems I still need to work out though, like the maps having misaligned/tiled textures on doors and switches but WHATEVER.

Looks like I'm going to need to start another thread in the appropriate sub-forum to get some help with this.

The perfect quake is so close I can taste it.

[Baker]

If you are looking specifically for a software renderer solution (WinQuake) well, this wouldn't apply.

But engine side for OpenGL it is possibly to heavily kill Z-fighting:

Inside3d Forums • View topic - Tutorial: Killing z-fighting in a stock Quake engine

It is not 1000000% perfect, but as an example GL ProQuake 4.51 virtually never experiences Z-fighting when using any sort of graphics card on Windows with the OpenGL version. (Oddly enough I get small amount of Z-fighting on my Mac with exact same engine version, so ...).

[KillPixel]

If you are looking specifically for a software renderer solution (WinQuake) well, this wouldn't apply.

But engine side for OpenGL it is possibly to heavily kill Z-fighting:

Inside3d Forums • View topic - Tutorial: Killing z-fighting in a stock Quake engine

It is not 1000000% perfect, but as an example GL ProQuake 4.51 virtually never experiences Z-fighting when using any sort of graphics card on Windows with the OpenGL version. (Oddly enough I get small amount of Z-fighting on my Mac with exact same engine version, so ...).

I was actually reading that post the other night and was going to try it but couldn't locate the files to edit. I have very little experience on the software side of things.

[MH]

Polygon offset is exactly what I'm referring to when I mention a solution that has problems with z-buffer non-linearity and different results on different hardware. It really doesn't work well at all, and there are places in some of the maps (like the zombie alcoves at the end of e2m7) where the value needed to remove z-fighting on the bars over the exit door will cause other objects (the buttons inside the alcoves) to sink into the walls. Again, that's hardware dependent: what works well on some hardware may not work at all (or be too much) on other. glPolygonOffset - "multiplied by an implementation-specific value to create a constant depth offset".

So the first param has flaws which LordHavoc points out, the second param is useless because it's hardware-dependent. Total non-feature.

Contrary to what LordHavoc says in that thread, D3D has a fairly crude Z-bias in version 8 and a fuller implementation in version 9 (although it's not called "polygon offset"). It's actually much better than OpenGL's because it has none of that implementation-specific crap, but it still suffers from a non-linear depth buffer. It's gone in 10+ of course, but it does nothing that you can't do in a vertex shader anyway.

So far tweaking the projection matrix is getting me good results. There's no start map outline and both e1m1 and e2m7 are clean. I'm going to try a run through ID1 beginning maybe tomorrow and we'll see how well it holds up.

[KillPixel]

So far tweaking the projection matrix is getting me good results. There's no start map outline and both e1m1 and e2m7 are clean. I'm going to try a run through ID1 beginning maybe tomorrow and we'll see how well it holds up.

omg...it's a Christmas miracle.

Hopefully you succeed and I can give up my quest. In the interim I've started a new thread here...if anyone has there 2 cents I'm willing to take it.

[Baker]

D3D has a fairly crude Z-bias in version 8 and a fuller implementation in version 9 (although it's not called "polygon offset"). It's actually much better than OpenGL's because it has none of that implementation-specific crap, but it still suffers from a non-linear depth buffer. It's gone in 10+ of course, but it does nothing that you can't do in a vertex shader anyway.

Hmmm. Perhaps this is why with the D3D wrapper you made I couldn't get the polygon offset stuff to work, maybe because I had installed 10+ for DirectQ.

[MH]

Nah, D3D versions don't work like OpenGL versions. They're completely different; nothing in a later version will override or supplement anything in an earlier version. D3D10 doesn't actually contain anything from D3D8 (or 9), it's a totally different set of DLLs.

Most likely explanation is that the hardware or driver no longer supports z-bias (or at least the old D3D8 version of it). It's a relatively common misunderstanding that D3D will software emulate stuff, but the exact opposite is in fact the truth. D3D will software emulate absolutely nothing, all you get is what's on the hardware, and it gives you nothing else. So if something like z-bias is no longer implemented by the hardware then you can't do it. (OpenGL is the one that drops you back to software emulation - often without warning and always without any indication of what you did to be dropped back.) That's why fixed pipeline fog in D3D9 no longer works on SM3+ hardware, for example.

D3D8 z-bias, by the way, is evil, even in cases where it does work.

OK, projection matrix tweak.

I can still find some places in ID1 maps where my default setting for this doesn't eliminate the fighting. Ramping up the setting works, but then you begin to see the outline in the start map.

Roundabout now I'm thinking to detect if polys are co-planar at load time, mark them if so, and send co-planar polys only through the tweaked projection matrix routines, but it's starting to introduce mess and complexity. The whole thing also needs to drop brush model drawing back to a slightly suboptimal path, so performance can suffer in maps like ne_tower that make heavy use of brush models.

[golden_boy]

Content bug in my opinion. Since we have the map sources, no reason to not fix it for real, content side. Engine coders bending over backwards to fix mess created by level designers is funny to watch, but maybe level designers should fix this

[KillPixel]

I agree with golden_boy. The bug should be fixed map side. But, it would be really, really nice to have an engine that could address the issue an effective way with minimal drawback.

I went to sleep last night excited about the (my personal) preferred outcome as far as DirectQ and that projection matrix stuff is concerned. I was actually having restless sleeps due to dreams of MH saying "oh well, it can't be done, moving on...".

Is that funny or really sad? ...who knows.

[MH]

Oh, I definitely agree that it's a content bug. The projection matrix tweak was interesting to try as it seemed like an option that was quick and easy to implement and didn't suffer from the same flaws as polygon offset. It fails because ramping up a setting to tackle all instances will introduce other flaws like the outline in the start map. But it's good to be in a position where at least I can say "tried it, didn't work".

[KillPixel]

Well, I'm glad you tried it out...though it's a bummer it doesn't work fully.

I guess it's full steam ahead for me on fixing the maps then.

[Trickle]

I notice on some Quake engines ( with this particular fix ), the map r1m5 from mission pack 2 still has problems with z-fighting. The spiral like doors and I think the bridge that comes out for you to get to the button after you defeat the lava guy. It was so annoying, I actually made textures metal8_4 and metal8_5 plain black.


Does anyone know why this is? All the other Quake maps I've played seem to be fine, the ones that had z-fighting issues at least.