# Collisions: stopped by unseen irregularities

I do apologise if a topic along these lines has been posted before; I started to search, but realised that I wasn’t sure of what keywords to use (“collision” in particular seems likely to be pretty common), and didn’t find much of aid in the first two pages of this sub-forum.

My problem is this: I am trying to put together a fairly simple tilemap-based level at the moment, and have gotten as far as preparing a small map representation and setting it up to produce walls around the edges. For each wall tile I place a copy of a wall model (of which there is just one at the moment), each of which has a skirting collision mesh, of only four joined quads.

Unfortunately, when testing the results, I encountered a problem. While two sides of the walls seem to be fine - I can move my character along them with no apparent problems, it seems - moving along the other two causes the character to either get stuck at intervals (presumably at the edges of tiles) or seem to skip slightly (presumably at the same places).

The player character uses a CollisionSphere, if I recall correctly.

It’s my guess at the moment that the tile collision geometry doesn’t quite fit properly in the two problem directions, leaving me with slight protuberances at the joins, although why this should be for two directions and not the others, I don’t know.

Does anyone have any suggestions, and if so, what are they? (I’m hoping to avoid processing the map just yet, and thus to avoid looking for runs and generating custom geometry for them, instead of simple pre-provided skirts.)

My thanks for any help.

If I were to guess, I’d blame the interior polygons that end up perpendicular to your joined wall. If a sphere happens to detect a collision with one of those, it would cause it to either stick, or skip ahead, exactly as you describe.

As to why it only happens on one side and not the other, it might have to do with random numeric imprecision. At this scale, it’s the toss of a coin whether the sphere actually detects a collision with the embedded polygon or not.

You might test this theory by temporarily creating your wall skirt with only two parallel polygons, instead of the four enclosing polygons.

If this does turn out to the be the problem, I guess you’ll have to do some minimal processing to remove these interior polygons; but that’s not quite as bad as synthesizing an entirely new wall polygon along the joins.

David

Hmm… Much the same occurred to me, I think, and I think that you’re right.

I’ll try your test, I believe and if it does turn out to be this, split up my collision geometry into four separate polygons, with such polygons being removed if the appropriate neighbour tile is also a wall tile…

Thank you very much.

 Excellent! That seems to have done it - thank you again! [/edit]