BIG BIG caulking problem.....

(BadIdea) #21

Hello.
And what is with bobtoolz ?
http://home.arcor.de/q3michel/tutor/tutor36.html

-Auto Caulk.
-Auto Caulk +

?

(ziege) #22

I was using ‘space’ as it’s real-world term, to make it easier to understand. Also I wasn’t completely sure of the correct techy/geeky terminology to use :slight_smile: Just for clarification, this is what I was attempting to describe:

This is ‘zebraing’ apparantly (surely that’s not the technical term!), so could someone post a pic that shows ‘z-fighting’ please, because I’m confused?

(cicero) #23

Anyone heard anything about this?

http://groups.yahoo.com/group/quark-python/message/4185?source=1

> > > — In quark-python@y…, “Donald, Alan” <adonald@a…> wrote:
> > > > Just wondering if this feature had slipped through the cracks
> > > (bugs) :slight_smile:
> > > >
> > > > In case it’s been forgotten - the q3 engine benefits from
> having
> > > unseen
> > > > faces applied with the common/caulk texture. There is a plugin
> in
> > > radiant
> > > > which loads a .map and .prt to generate a list of caulkable
> faces
> > > and then
> > > > applies said texture.
> > > >
> > > > Alan.
> > >
> > >
> > >
> > >
> > >
> > > Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
> > >

(ziege) #24

:bump:

(chavo_one) #25

I can’t help you because z-fighting to me, always meant exactly what your pic describes.

(Shallow) #26

Zebraing and z-fighting are essentially the same thing, one name describes the visual appearance of the effect, and the other name describes the technical cause for that effect.

(ziege) #27

Oh well, I’ll carry on calling it z-fighting then and just ignore Redfella next time he says I’m wrong :slight_smile:

(denizsi) #28

just open Radiant. Open a fresh new map, import your own map. When whole map is imported, all brushes will be selected, now just click on caulk texture in texture interface. And then retexture every surface visible in world one by one. A lot easier than trying to caulk surfaces one by one.

(Shallow) #29

Actually reading back to what he said (I foolishly neglected to read whole thread before posting) he may have a point in the distinction he’s making between z-fighting from overlapping faces and z-fighting between faces that are very close together in the z-buffer. I’d have said z-fighting is z-fighting whether or not the faces are actually coplanar, but using zebraing to refer exclusing to coplanar faces z-fighting seems perfectly legitimate.

Personally I’d tend to say “it’s an overlapping brush face” which is immediately comprehensible.

(chavo_one) #30

Yes, but by redfella’s definition set, “zebraing” is a subset of “z-fighting”, so therefore all cases are technically “z-fighting”.

(SCDS_reyalP) #31

ummm no… What you just described is technically called “zebraing”. And occurs only when two textures are on the same plane.

Z-fighting is when two textures fight to be displayed (in-game)… It occurs when u got a texture half inside and half outside of a portal (I believe) and the textures are NOT on the same plane. Someone correct me if I’m wrong.[/quote]
No, nothing to do with portals. Textures don’t have to be exactly in the same plane to z-fight. They just have to be closer together than the precision of the z-buffer. The precision of the z-buffer is not evenly distributed, it is much more precise near the camera than far away, which is why you tend to see z-fighting in zoomed views.

z-fighting is the z test giving an indeterminate result.

(damocles) #32

To expand on what Reyalp is saying…

Z-Fighting is when the game attempts to calculate the distance between two planes and decide which is in front of the other, so it doesn’t draw the one behind. The further you get from the player, the less precise these calculations become, meaning that thin brushes when viewed at a distance may not draw properly because the calculations will assume the two faces are at the same depth because it cannot differentiate. Typically the problem is worsened if there are two thin brushes, one in front of the other. A thin brush that has a large distance of space behind it should (in theory at least) suffer less with z-fighting because the faces being tested are farther apart.

This typically only happens in 16-bit depth modes, as the 32-bit mode is usally sufficient to precisely tell which is farthest away.

Zebraing on the other hand is when two faces attempt to occupy the same space. They will flicker and draw all striped (like a zebra :clap:) no matter how far away they are. This is very very bad and should never make it into a final map, which is why overlapping brushes is a BAD thing to do.

Z-buffering is aviodable, but you still see a lot of maps released with it in them. The problem is lessening as more people use 32-bit settings to avoid it, but some people still use older hardware that prefers the 16-bit modes. The trick is, if you must have thin brushes, try and ensure that they cannot be seen from a long way away, or you will get z-fighting.

And just to make this post relevant to the original post…

You MUST caulk all unseen faces. The only ones that do not require caulking are those that press perfectly against others. EG, if you have two identically sized walls in a line, the ends where they meet would be removed by the compiler. However, if one wall was lower than the other, the faces would get drawn because part of them is visible (thanks to Reyalp for pointing this problem out to me in another thread).

As for the engine not drawing any faces that are facing away from the player - this is true, but you should caulk them anyway. The engine still has to decide if the faces are facing away or not, which is calculations it doesn’t need to be doing - especially if there are thousands of faces that don’t need to be drawn!

(redfella) #33

Thanks for the detailed reply damocles. At least I got one part right. :slight_smile: