Collision Response doesn't work properly

[Cadisol87]

Hey guys!

I have a question about collision response.
In my program I check if some circles collide, and if they do, the collision is being resolved and the new velocities are being set.
That works fine if the circles have the same radii, but when the radii are different, the circles stick together sometimes.
a video showing the problem. ( I recommend you to watch it in fullscreen mode. The password is 'sfml')

Here's my resolve circle to circle collusion function:

void resCtcCollision(elasticCircle &circleA, elasticCircle &circleB) //Resolve Circle to Circle Collision
{
    sf::Vector2<long double> v1(circleA.getVel());
    sf::Vector2<long double> v2(circleB.getVel());
    sf::Vector2<long double> ap(circleA.getPosition());
    sf::Vector2<long double> bp(circleB.getPosition());
    sf::Vector2<long double> n = ap - bp;
    n = Normalize(n);

    long double a1 = dotProduct(v1, n);
    long double a2 = dotProduct(v2, n);
    long double optimizedP = (2.0 * (a1 - a2)) / (circleA.getMass() + circleB.getMass());

    v1 = v1 - optimizedP * circleB.getMass() * n;
    v2 = v2 + optimizedP * circleA.getMass() * n;

    circleA.setVel(v1);
    circleB.setVel(v2);

}
 

My timestep is correct.

Has anyone an Idea what I've could done wrong?

[Cadisol87]

If u need more code, please tell me

[eXpl0it3r]

To me it seems like a precision issue and since I don't have the time to break down the math, I can just guess.

Btw why do you need long double? I don't think you'll gain anything from that.

[Cadisol87]

Btw why do you need long double? I don't think you'll gain anything from that.

You're right, I'll change it back to double...

To me it seems like a precision issue

Yeah, but how can I get more precision? Do I need to download an Arithmetric library for that?

[eXpl0it3r]

You're right, I'll change it back to double...

float should be fine as well.

Yeah, but how can I get more precision? Do I need to download an Arithmetric library for that?

Well, how's your collision function? In the response function you only change the velocity, that might be enough if the circles each have a large enough radius, but what happens if the center of a circle fully enters the other circle before the collision gets detected? Besides changing the velocity you might want to ensure that the circles' center are outside of the other circle.

[Cadisol87]

Well, how's your collision function? In the response function you only change the velocity, that might be enough if the circles each have a large enough radius, but what happens if the center of a circle fully enters the other circle before the collision gets detected? Besides changing the velocity you might want to ensure that the circles' center are outside of the other circle.

Yes, I think that's ensured already.
Here's my collision function:

bool altCtcCollision(sf::Vector2f a, sf::Vector2f b, float radA, float radB) // Alternative Circle to Circle Collision (I have two different Collision-detection methods)
{
    float dx = b.x - a.x;
    float dy = b.y - a.y;
    float radii = radA + radB;
    return ( dx * dx )  + ( dy * dy ) < radii * radii;
}
 

The collusion will be resolved if this boolean is true. I also added a if-statement in the resolve-collision function to ensure that the center of circle A is outside of the circle B:

void resCtcCollision(elasticCircle &circleA, elasticCircle &circleB) //Resolve Circle to Circle Collision
{
    if(Distance(circleA.getPosition(), circleB.getPosition()) >  circleB.getRadius())
    {
          // Calculate and set new Velocities
    }

}
 

But it still doesn't work.

[Njifra]

To detect collision between two circles, do following:

if (sqrt(pow(circle1.getPosition().x - circle2.getPosition().x, 2) + pow(circle1.getPosition().y - circle2.getPosition().y, 2)) <= circle1.getRadius() + circle2.getRadius()) { }
 

P.S. I'm writing this from my mobile so code might be wrong.

[Nexus]

The case of concentric circles is already handled by that formula: the difference vector will be zero, so it's length is always smaller than the radii of both circles.

Have you debugged a bit? You should observe how the velocities look after collision and make sure they point away from the circle, so that no collision is triggered more than once. For example, you could use thor::Arrow to represent the velocity vectors. If the time step is too big, that might also be a problem.

Njifra, he already uses a more efficient version of your algorithm. There's no point in taking the square root when comparing two distances.

[Cadisol87]

Hmm, Okay I'll try to debug it with Thor

And what do you mean with 'big' time step?

[Nexus]

When your time step is too long, the collision detection and response won't be accurate. This can be noticeable if objects seem to collide although there are gaps between them (or already overlaps).

[Cadisol87]

Okay, I debugged with thor and it showed me some weird results: Sometimes when the circles stick together the arrows don't point away, like the velocities haven't changed, and sometimes the arrows point in the right directions, but the circles yet still stick together.

And I don't think that there's something wrong with my timestep, since I'm using the same one as in the sfml game-development book, but If you want I can post it

[Nexus]

Sometimes when the circles stick together the arrows don't point away, like the velocities haven't changed, and sometimes the arrows point in the right directions, but the circles yet still stick together.

I imagined something like that
Now you can find out why this happens (using a debugger or logging: check the intermediate values of your algorithm and compare with your expectations).

And I don't think that there's something wrong with my timestep, since I'm using the same one as in the sfml game-development book

But you're aware that the timestep we used in the book is not the ultimate solution for every problem? How you choose the logic timestep depends strongly on your game logic. (I don't think that's the problem here, but keep this in mind.)

[zsbzsb]

I have already been working with Cadisol87 on this in a PM, I can verify the issue is not at all with the collision detection, but with his collision resolution code. It also has nothing to do with the time step. The issue is when two circles have a large difference in radius/mass the code in the first post will not properly move the circles away from each other causing them to "stick" together.

[Cadisol87]

First of all: Welcome back zsbzsb!

Unfortunately I'm very busy at the moment, so I don't have much time for my project. I'm gonna have a look at the part of my code where the new Circles are created, I think that the problem maybe has something to do with that, since the debugger showed me some weird values created by that part of the code.

[Raincode]

Would you mind explaining how you generate the movement? I need something like that for a game and the best I can do is make all circles bounce like they would off a wall (reverse x or y part of velocity)