# Ignoring contacts involving seams between tiles

This topic is 2639 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I'm working on a game where the world is composed of tiles. I'm using a simple SAT implementation to generate contacts. This works fine for the most part except for the following situation:

The blue box is my player and is separated from the yellow box by 0 units along the Y-axis and so I generate a contact between the blue box and the yellow box with the normal <0, 1, 0> and distance 0. Which is fine. Now the player is trying to move left and it finds that it's also 0 units from the red box but on both the X-axis and the Y-axis. If I'm allowed to move over the seam comes down to the order I test the axes. If I test the Y-axis first I generate a contact with normal <0, 1, 0> and distance 0. Then I test the X-axis and I get <-1, 0, 0> and distance 0 but that's ignored because the distance isn't any closer to the first one. That's fine too. But if I test the X-axis and then the Y-axis I'm prevented from going over the seam. Obviously I can just always test the Y-axis first but then my problem just becomes sliding along walls instead of sliding along the floor.

Is there some common approach to dealing with this problem? I've looked a little into welding but in my game you can add and remove tiles during gameplay so it would need to be something that could be done really quickly. I could also probably do something like tagging the faces of the blocks as obscured/ignored but that's starting to seem hacky and would start to add coupling between my physics systems and game code. Hoping for a more general solution and I'm sure I'm not the first to run into this anyways

##### Share on other sites
I've looked into different way of trying to achieve an extension to SAT to deal with inner edges without incurring extra peformance hits, and thus far i've been unsucessful for general cases.

you cannot simply tag edges to be ignored; take your example for instance, if you ignored the inner edge in the ground, you'd just get contact point/normal relating the the vertical edge of the player quad instead simply ignoring edges can also lead to cases where you can get generated contact points.normals which are just totally wrong and mess things up.

##### Share on other sites
This is a really tough problem to solve robustly. It took me a long time while working on Little Big Planet PSP to get something which worked right in most cases...

The first step is to identify internal edges and vertices. Once you know where they are, you at least stand a chance of being able to pick a different normal for your contact. And there in lies the key; you don't want to discard contacts wholesale, because you'll miss collisions - instead you want to be able to pick a more appropriate normal for the collision, by using the tagged information and then choosing a normal to the left or to the right of the vertex in question, depending on the scenario.

The difficulty becomes how to pick the correct normal - and from which object? If you know which objects are static, and represent the 'ground', this is good because you can generally say that these are the normals you want to pick. However, if you have two dynamic objects sliding over each other all bets are off, because you now have no idea what represents the 'sliding' surface.

Hope that helps a little!

Cheers, Paul.

1. 1
2. 2
Rutin
29
3. 3
4. 4
5. 5
khawk
14

• 11
• 11
• 23
• 10
• 9
• ### Forum Statistics

• Total Topics
633647
• Total Posts
3013108
×