Clipping bug

(G0-Gerbil) #1

Take a look at this image:

The bit pointed at by the arrow is pretty simple - it’s an axial aligned brush meeting a non-axial aligned brush. All edges / vertices of both brushes are snapped to a reasonable level of grid (4 units I think).

The problem is the collision detection is wrong - when you walk ‘down’ (when looking at the top-down 2D window), sliding along the non-axial aligned brush, you STOP when you hit the join, even though there’s no earthly reason why you should. The wall extends further ‘up’ and curves more - at every instance of the joins (which match perfectly) you either stop dead in your tracks or get ‘bounced’ out before continuing on your journey.

Any clues?

(Drakir) #2

As long as i can remember this has been an issue with all the Q engines incl. Half-Life!

(G0-Gerbil) #3

Yeah, but what exactly makes it ‘appear’? This is the first time it’s cropped up, and it’s cropping up a lot. Any solutions / workarounds / hacks? :frowning:

(MindLink) #4

Maybe try to insert some angled clip brushes, so that it won’t look like this

------|____ anymore but like this :

------|___ where \ is the clip… I’m currently missing some english words for this, but I hope you get my point. :wink:

(that is : only if your ridge is low enough that you could walk up anyways. If not perhaps you can try to add some more clips around the edge so it is “smoother”, maybe even a bent patch mesh?)

(Moonkey) #5

I can’t see the pic but I know what you mean.

I don’t know whether it’s a q3map change, or one made in the ET code, but it didn’t seem to happen for RTCW maps :confused:

Same deal with the weird patch clipping that you sometimes get.

(G0-Gerbil) #6

Can’t see the image either - hosted site must be down.
More bloody trouble than they are worth some times :frowning:

(hummer) #7

Meh, I rememer this happening now and then in RtCW. I’ve seen this in ET, esp. auto clipping models that have been rotated slightly. No clue what causes it, but those “hooks” are rather annoying :confused:

(WolfWings) #8

For Half-Life, the specifics of the problem were recently figured out, and actually solved.

Turns out it’s caused by a combination of brush normalization and non-axial brush planes. Switch one off, and the problem goes away. Somehow mark ‘touching’ faces, and the problem, also, goes away.

http://www.xp-cagey.com/?article=1000 has all the pretty pictures you could want, and more technical details of the Half-Life version of the bug. I’m guessing a similair (but not quite the same) bug occurs for Q3-based mods as well, though I don’t know the gorey details as well as I do the Half-Life .bsp format details, having been working with XP-Cagey for a while now tracking down bugs.

(G0-Gerbil) #9

Seems reasonable.
I don’t understand why the face normal is used as the scalar to offset the new clip face though - if the game uses BBs then why not extend outwards using the actual distance from center of BB to edge most ‘co-planar’ to the face normal in question, normalised to be IN the direction of the face normal?

That’s what I am doing in my own games, which along with proper beveling (bearing in mind I don’t allow truly freeform geometry I must admit, and I assume AABB for all moving objects), gets rid of these problems. Or, rather, I never had them in the first place :confused: