Great content, much appreciated sensei! I'd suggest colliding the balls and applying impulses only when they are moving against each other, i.e; when the dot product of their velocities is negative. The reason is: due to numerical precision, friction or multiple collisions happening at the same time, the colliding balls can end up still overlapping after the collision. In the next frame, even though they were moving away from each other, we shouldn't apply the same collision logic to this overlapping pair, because it will just turn them against each other. Hence they will flip at each frame. I've experienced this happening on many projects. It is a headache to debug, but the solution is very simple.
It's an interesting observation but I don't think your solution is correct. What if 2 balls are moving in the same direction but the one behind is faster. Eventually it will catch up to the slower ball in front, and the collision will be dismissed by your test. Imo the best way to handle this is to apply a slight overshooting when separating the balls by updating their positions. Multiplying the correction by a small amount like 1.01 is enough to prevent issues related to numerical precision. I'm not sure if double collisions are at fault at all here, since if a second collision causes the ball to immediately re-enter a first collided object, this second collision will also flip the velocity, so we're back to normal when re-handling the first collision a second time.
I think the inverse would be a good solution - dismissing any collisions when the velocities are moving the objects *away* from each other. I believe that would be a positive dot product.
@@alexisdupuis5616 Very well spotted sir! You are right. My actual solution that I use is actually not the dot product of the velocities, but instead: *the dot product between the difference in position and the difference in velocites* Perhaps a pseudocode will be easier: ``` Vec2 deltaVel = objA.vel - objB.vel; Vec2 deltaPos = objA.pos - objB.pos; bool ignoreCollision = dot(deltaVel, deltaPos) > 0; ```
I think there's a small mistake in the way collisions are handled that can cause infinite increase of the Velocity on some basic cases. When applying the correction to the positions to fix the overlaping objects, we are basically doing the same thing we are doing to solve constraints in PBD. But this time we don't update the velocities to reflect this positional correction. It's easy to see the issue by letting a ball bounce on a ground collider. At each frame, the ball has fallen slightly more than physically possible due to the collision overlap. When reflecting the velocity, we are thus letting the velocity grow a bit more than physically possible at each new bounce. This leads to a very noticeable drift/increase in energy. I corrected this by substracting the velocity gained during the deltaTime between the actual collision and the moment it is detected and handled in handleBallsCollisions. I had to store the acceleration of the particle though (which I do in the updateVelocity method). Then assuming a constant acceleration during this deltaTime, we find that: correctedVelocity² = velocity² - 2 * acceleration * correctionDistance
Btw the reason why this is usually not observable in your videos is because either you handle ground collisions by simply preventing objects y coordinate to fall under 0, or in the case of video 11 you use floating balls, so the gravitational acceleration is not causing any issues.
I think there are situations where if there's 3 collisions in the same frame, depending on the order of the balls, 1 of those collisions might not get corrected if the ball is earlier in the array because of the way the for (j = i+1...) loop checks only the latter part of the array. I'm not sure what's the appropriate fix for this Btw these tutorials are amazing. I've been fairly scared of web programming, but doing these so far is giving me more confidence. Thanks a ton!
Great content, much appreciated sensei!
I'd suggest colliding the balls and applying impulses only when they are moving against each other, i.e; when the dot product of their velocities is negative.
The reason is: due to numerical precision, friction or multiple collisions happening at the same time, the colliding balls can end up still overlapping after the collision. In the next frame, even though they were moving away from each other, we shouldn't apply the same collision logic to this overlapping pair, because it will just turn them against each other. Hence they will flip at each frame.
I've experienced this happening on many projects. It is a headache to debug, but the solution is very simple.
Very good observation. You are absolutely right. That check is missing in the code!
It's an interesting observation but I don't think your solution is correct. What if 2 balls are moving in the same direction but the one behind is faster. Eventually it will catch up to the slower ball in front, and the collision will be dismissed by your test.
Imo the best way to handle this is to apply a slight overshooting when separating the balls by updating their positions. Multiplying the correction by a small amount like 1.01 is enough to prevent issues related to numerical precision.
I'm not sure if double collisions are at fault at all here, since if a second collision causes the ball to immediately re-enter a first collided object, this second collision will also flip the velocity, so we're back to normal when re-handling the first collision a second time.
I think the inverse would be a good solution - dismissing any collisions when the velocities are moving the objects *away* from each other. I believe that would be a positive dot product.
@@alexisdupuis5616 Very well spotted sir! You are right.
My actual solution that I use is actually not the dot product of the velocities, but instead: *the dot product between the difference in position and the difference in velocites*
Perhaps a pseudocode will be easier:
```
Vec2 deltaVel = objA.vel - objB.vel;
Vec2 deltaPos = objA.pos - objB.pos;
bool ignoreCollision = dot(deltaVel, deltaPos) > 0;
```
This is awesome. Been following along in Raylib and it works great with a couple of alterations.
I think there's a small mistake in the way collisions are handled that can cause infinite increase of the Velocity on some basic cases.
When applying the correction to the positions to fix the overlaping objects, we are basically doing the same thing we are doing to solve constraints in PBD. But this time we don't update the velocities to reflect this positional correction.
It's easy to see the issue by letting a ball bounce on a ground collider. At each frame, the ball has fallen slightly more than physically possible due to the collision overlap. When reflecting the velocity, we are thus letting the velocity grow a bit more than physically possible at each new bounce. This leads to a very noticeable drift/increase in energy.
I corrected this by substracting the velocity gained during the deltaTime between the actual collision and the moment it is detected and handled in handleBallsCollisions. I had to store the acceleration of the particle though (which I do in the updateVelocity method).
Then assuming a constant acceleration during this deltaTime, we find that: correctedVelocity² = velocity² - 2 * acceleration * correctionDistance
Btw the reason why this is usually not observable in your videos is because either you handle ground collisions by simply preventing objects y coordinate to fall under 0, or in the case of video 11 you use floating balls, so the gravitational acceleration is not causing any issues.
I like the simplicity to the point :)
If only this video existed when I was trying to figure this out when I was in high school
You, removed so much fluff. Awesome serie, and thank you!
This is fantastic, thank you for putting this together!
I think there are situations where if there's 3 collisions in the same frame, depending on the order of the balls, 1 of those collisions might not get corrected if the ball is earlier in the array because of the way the for (j = i+1...) loop checks only the latter part of the array. I'm not sure what's the appropriate fix for this
Btw these tutorials are amazing. I've been fairly scared of web programming, but doing these so far is giving me more confidence. Thanks a ton!
Once again you provided lots of fun! Thanks professor!
These tutorials are wonderful. Thank you so much.
Amazing ❤