InsideQC Forums

You hate it, I hate it, even the dogs in the street organized a protest march about it last week.

So let's get rid of it.

Step 1
Find the #define for DIST_EPSILON in world.c and move it to quakedef.h

Step 2
Open gl_rsurf.c, find R_DrawBrushModel, and add these lines before the call to R_RotateForEntity: Step 3
Same file, same function, add these lines after the call to R_RotateForEntity: Result
No more brush model Z-fighting.

OK, it's the cheapest, nastiest hack in the universe, but it works. You do get a tiny glitch in that there's a very very small see-through crack around some edges of some doors, but if that bothers you, you can make your own define for this purpose (or even cvar-ize it) (I don't recommend messing with the value of DIST_EPSILON).

Corrects if I'm wrong, but this code will arbitrarily (but consistently) show either the bmodel face or the world face, depending on facing angle, right? And there's a certain weird angle that will still have z-fighting?

(Not knocking it, seems like a worthwhile hack)

metlslime wrote:Corrects if I'm wrong, but this code will arbitrarily (but consistently) show either the bmodel face or the world face, depending on facing angle, right? And there's a certain weird angle that will still have z-fighting?

(Not knocking it, seems like a worthwhile hack)

No, you're perfectly right. I consider it an acceptable trade-off, as the Z-fighting normally occurs on horizontal planes viewed at oblique angles, and is more likely to be observed looking forward or down than looking up, so subtracting a tiny fraction from the z origin (going up in Quake) will resolve it in 99% of practical cases, with 99% of the remaining being at least consistent (no fighting).

what the F oh so thats what that codebit was for very cool some where wondering how you fixed z fighting in realm me to btw

back from christmas now and going to release some tutorials about how to add compressed pk3 support to quake and a few other goodies comming

I have implemented this fix and have done extensive testing.

I still noticed a small amount of Z-Fighting.

It does reduce it drastically but it is just enough to still be a small annoyance.

It's never going to be perfect owing to the non-linear nature of the Z buffer (the same applies to a polygon offset solution).

sorry to sound like a newb but i am one. so what exactly is Brush model Z-Fighting?

http://en.wikipedia.org/wiki/Z-fighting



in basic its if two surfaces hold the same data in the Z-buffer the image will look like its broken up so to alleviate it you offset part of the data.

or you use a higher resolution Z-buffer.

hmm sounds like something worth trying to implement. on my list.

ceriux wrote:hmm sounds like something worth trying to implement. on my list.

For what it is worth, the Z-fighting thing is largely an original id1 maps problem that affects e1m1 near quad, several exit areas with doors and a couple of other places.

Any engine with the idea of running all custom made maps, doesn't really need this. Because no one would make maps like that today.

For instance, I can't recall seeing Z-fighting in any quality custom map I have ever played. Or even a bad quality one, actually.

I'm just saying that any engine with the idea of it really being made more for a specific total conversion, the priority level of this kind of thing would be near rock bottom.

oh well then scratch one off then lol thanks for the tips. im just now getting into engine stuff so i have a lot to learn.

Baker wrote:

ceriux wrote:hmm sounds like something worth trying to implement. on my list.

For what it is worth, the Z-fighting thing is largely an original id1 maps problem that affects e1m1 near quad, several exit areas with doors and a couple of other places.

Any engine with the idea of running all custom made maps, doesn't really need this. Because no one would make maps like that today.

For instance, I can't recall seeing Z-fighting in any quality custom map I have ever played. Or even a bad quality one, actually.

I'm just saying that any engine with the idea of it really being made more for a specific total conversion, the priority level of this kind of thing would be near rock bottom.

Well with every quake total conversion that you can map for someone is bound to make a badly made map.

I think this is good but mainly because I like keeping backwards compatibility with standared Quake maps via engine side.

The real fix of course is to just rebuild and rerelease the maps. Opportunity could be taken to fix a few other minor bugs in them, such as misaligned textures/etc.

Just thought I would throw in that this provided a small speed up as well.

Mexicouger wrote:Just thought I would throw in that this provided a small speed up as well.

I'm 100% sure you're wrong.