# Circle-Circle impulse resolution not working properly

## Recommended Posts

I am doing a little physics project with circle circle collisions for now, and have tried to do impulse resolution for collisions with 2 circles, using the following code.

relativeVelocity = (other.doVerletVelocity()).subtract(self.doVerletVelocity())
normDirecVel = relativeVelocity.dotProduct(collisionNormal)

restitution = -1 - min(self.restitution, other.restitution)

numerator = normDirecVel * restitution

impulseScalar = numerator / float(1 / self.mass) + float(1 / other.mass)

selfVel = self.doVerletVelocity()
otherVel = other.doVerletVelocity()

impulse = collisionNormal.scalarMult(impulseScalar)

selfDV = impulse.scalarMult(1 / self.mass)
otherDV = impulse.scalarMult(1 / other.mass)

newSelfVel = selfVel.subtract(selfDV)

self.oldPos = (self.center).subtract(newSelfVel.scalarMult(dt))
other.oldPos = (other.center).subtract(newOtherVel.scalarMult(dt))

The problem seems to be that whatever value I give to self.mass and other.mass, the output stays exactly the same, the values that I used are:

center = Vector(0, 0)
oldPos = Vector(0, 0)
accel = Vector(0, 0)
mass = 100
restitution = 0.001

center2 = Vector(0, 3.20)
oldPos2 = Vector(0, 3.201)
accel2 = Vector(0, -1)
mass2 = 1
restitution2 = 1

the output was:

0.0      0.0      0.0      2.165000000000114
0.0      0.0      0.0      2.1360000000001174
0.0      0.0      0.0      2.1066000000001206
0.0      0.0      0.0      2.076800000000124
0.0      0.0      0.0      2.046600000000127
0.0      0.0      0.0      2.0160000000001306
0.0      0.0      0.0      1.985000000000134
CIRCLE INTERSECTION
0.0      -1.985000000000134      0.0      3.938600000000271
0.0      -3.970000000000268      0.0      5.891800000000408
0.0      -5.9550000000004015      0.0      7.844600000000544
0.0      -7.940000000000535      0.0      9.797000000000681

I changed the values for the masses to make them higher, bu the output still remained the same, if you could get to the bottom of this, it would be much appreciated.

##### Share on other sites

I noticed this:

impulseScalar = numerator / float(1 / self.mass) + float(1 / other.mass)

You are missing parentheses:

impulseScalar = numerator / ( float(1 / self.mass) + float(1 / other.mass) )

##### Share on other sites

Dirk Gregorius, That does not have an effect on the values outputted by the method.

##### Share on other sites
23 hours ago, Dirk Gregorius said:

I noticed this:

impulseScalar = numerator / float(1 / self.mass) + float(1 / other.mass)

You are missing parentheses:

impulseScalar = numerator / ( float(1 / self.mass) + float(1 / other.mass) )

I tried that, yet it has no effect on the values. When displaying the circles on the screen, using pygame module, it showed that after colliding, the circles moved in opposite directions, but with velocities faster than what they collided with.

Edited by Bob Dylan

##### Share on other sites

Doesn't that appear strange to you? Obviously it should have an effect since :

n/a + b != n / (a + b) for any b != 0

##### Share on other sites
1 minute ago, Dirk Gregorius said:

Doesn't that appear strange to you? Obviously it should have an effect since :

n/a + b != n / (a + b) for any b != 0

It definitely is strange, yet what I described is the case. I think the error might be in the way that 1/mass is calculated because changing the mass when defining the particle object has not bearing on the resultant impulse.

##### Share on other sites

What language are you programming in? It might be that it is the type promotion. Try

float(1.0f / self.mass)

Either way, this should be easy to find. Simply debug and step through the code.

##### Share on other sites
17 minutes ago, Dirk Gregorius said:

What language are you programming in? It might be that it is the type promotion. Try

float(1.0f / self.mass)

Either way, this should be easy to find. Simply debug and step through the code.

Are you supposed to deal with penetration in the collision detection phase, or the impulse resolution phase? I ask this because that might be what is throwing this off, because as soon as they collide, the circles make a large jump, which might be affecting their velocities as i am just approximating velocity as current position - old position divided by the timestep, since my velocity verlet implementation does not deal with veloicty explicitly.

Edited by Bob Dylan

##### Share on other sites

You detect penetration in the collision phase. You can deal with it in the impulse phase or in a separate penetration recovery phase.

##### Share on other sites
Just now, Dirk Gregorius said:

You detect penetration in the collision phase. You can deal with it in the impulse phase or in a separate penetration recovery phase.

Thanks, I think that is what is causing the value of the velocities to be large after impulse resolution.

##### Share on other sites

I would try with zero penetration recovery and restitution first. Then add penetration recovery and finally restitution.

Edited by Dirk Gregorius

##### Share on other sites
Just now, Dirk Gregorius said:

I would try with zero penetration recovery and restitution first.

What does that mean?

##### Share on other sites

That means, I would first not worry about penetration recovery and don't support restitution. In particular getting penetration recovery and restitution work correct together can be tricky.

Edited by Dirk Gregorius

##### Share on other sites
3 minutes ago, Dirk Gregorius said:

That means, I would first not worry about penetration recovery and don't support restitution.

But there was a rather helpful and in-depth tutorial that showed how to deal with it. Through I will follow your suggestion if my approach to change the penetration handling from the collision detection to impulse resolution section of the code and by the way - thanks for all the help and time that you have taken to help me. I'll let you know how it goes (if you care).

Edited by Bob Dylan

##### Share on other sites

One thing I learned over the past years is that with software development in general and physics development in particular is that you want to come to a working solution as fast and easy as possible. From there you want to add one feature at a time always iterating on a working solution.

You are currently seeing yourself what a pain it can be to search for a bug without having an idea where to look. If you use a smart incremental approach this helps to keep problems manageable. That is why I suggest getting the simplest problem working first and then add one feature at a time (e.g. penetration recovery and restitution).

I don't know which tutorial you are referring to so I cannot comment on this. With game physics you have the problem that there are a couple of good references by industry experts and then a bunch of students essentially rewrite these tutorial for studying purposes and quite often introduce errors reflecting their lack of understanding. So when looking at in-depth tutorial make sure they are from people who know what they are talking about.

##### Share on other sites
1 hour ago, Dirk Gregorius said:

I will take your advice on board when continuing with this simulation. However, if you want to inspect the tutorial I used, it is the following link.

##### Share on other sites

That is Randy's stuff. He is on the forum here and should be able to help. I will ping him...

##### Share on other sites

Hi there, Dirk's advice is trying to describe a method to debug your code. The idea is if you get a working solution, then whenever you make small changes it is easy to know what broke. From here finding problems becomes much easier.

The tutorial you posted is best used by referencing the source code in the final article. The source code is here: https://gamedevelopment.tutsplus.com/tutorials/how-to-create-a-custom-2d-physics-engine-oriented-rigid-bodies--gamedev-8032

Unfortunately I don't have time to manually step through your code to look for problems. The best thing you can try doing is to take Dirk's advice and start with a small working solution. From there you can modify the working code to look more like your own code, and replace piece by piece until something breaks. This can give you clues on where problems lay.

##### Share on other sites
7 hours ago, Randy Gaul said:

Hi there, Dirk's advice is trying to describe a method to debug your code. The idea is if you get a working solution, then whenever you make small changes it is easy to know what broke. From here finding problems becomes much easier.

The tutorial you posted is best used by referencing the source code in the final article. The source code is here: https://gamedevelopment.tutsplus.com/tutorials/how-to-create-a-custom-2d-physics-engine-oriented-rigid-bodies--gamedev-8032

Unfortunately I don't have time to manually step through your code to look for problems. The best thing you can try doing is to take Dirk's advice and start with a small working solution. From there you can modify the working code to look more like your own code, and replace piece by piece until something breaks. This can give you clues on where problems lay.

Thanks for your advice, I realise that you do not have much time, but could I trouble you to explain to me when and were you deal with penetration, as I have since got the collision response working with restitution. If you would't mind, could you also explain to me how you would calculate the penetration vector for a circle-circle collision?

As at the moment, I am using this code:

PD = -(self.rad + other.rad) + math.sqrt(centDist)
angle = diff.xAxisAngle()
PDx = PD * math.cos(math.degrees(angle))
PDy = PD * math.sin(math.degrees(angle))
penetrationVec = Vector(PDx, PDy)
dP = penetrationVec.scalarMult(0.5)

other.center = (other.center).subtract(dP)

While it does provide accurate enough collisions, it does however make the circles jump when I represent them on the screen. Thanks again.

Edited by Bob Dylan

##### Share on other sites

I'd like to help but the question you're asking is very open ended. There isn't really a specific piece I can help you with here. I'd love to help, but it sounds like you're not sure where the problem is yet.

##### Share on other sites

I would recommend adding a visual "step" by "step" debug system, so you clearly see when something goes wrong.

You can just use a bool to force to simulate one step or even step a single body pair. Its really hard to solve physics problems when you just look at the final output.

Render your bounding boxes + orientation and render your contact points inluding the surface normal and penetration distance. Start simple like dirk already recommended and build up from there.

Also making a realtime dragging tool to move/rotate two bodies around at realtime helps a lot!

I made such stuff in the past for javascript if you are interested: http://root.xenorate.com/final/jsstuff/

Edited by Finalspace

##### Share on other sites
5 hours ago, Randy Gaul said:

I'd like to help but the question you're asking is very open ended. There isn't really a specific piece I can help you with here. I'd love to help, but it sounds like you're not sure where the problem is yet.

Here is the problem, as explicitly as I can describe it: sometimes, when my circles are moving with velocities not perpendicular to the X or Y axes, when they are supposed to collide, they just get stuck in each other.

This is not what it would be like in real life, and I know that I am supposed to somehow find the penetration vector of the circles and them move them apart.

Now what I want you to do is to tell me how to get the penetration vector and then when to move the circles apart from each other.

##### Share on other sites
29 minutes ago, Bob Dylan said:

Now what I want you to do is to tell me how to get the penetration vector and then when to move the circles apart from each other.

That's not something answerable on a forum. You're basically asking how to create an entire physics sim. That said, the answers are in the link you posted earlier. If you can't find them in the link, I'm not really sure anyone can help you here.

29 minutes ago, Bob Dylan said:

Here is the problem, as explicitly as I can describe it: sometimes, when my circles are moving with velocities not perpendicular to the X or Y axes, when they are supposed to collide, they just get stuck in each other.

I appreciate the explicit description. I can't help you because what you are describing is not explicit, even though the description of it is clear. Your problem is vague, even though you described it nicely.

There are many reasons why circles may get stuck inside each other, and the problems could be anywhere. There is no simple answer of "how to make them not stick together".

Edited by Randy Gaul

##### Share on other sites

One thing you can do is to setup similar situations both in Randy's and your simulators and step through them side by side. Or write down an analytical solution and confirm your results in debugger. The problem is that you need to debug your code and nobody else is going to do this for you.

Edited by Dirk Gregorius

## Create an account

Register a new account

• 9
• 11
• 18
• 14
• 10
• ### Similar Content

• Hi all, I am starting to develop a tactics game and ran into a problem I had not thought of. I began by drawing a screen with a hex grid, and this is no big deal. I got that working fine. But, I realized it didn't look quite right. This is because in most strategy games, you're not looking straight down. There is a bit of a tilt. Attached is an example of what I mean. The hexagons on bottom are larger than the hexagons on top, and I'm unsure of how to go about adding this effect. Especially when you consider that some maps may be of different sizes.
I'm not sure if this is the right place to post something like this, but it seems as though some sort of linear transformation would be applied? No? I don't even know where to begin in a problem like this.
Thanks.

• By nick1
Hello,

I have limited programming experience in C++, but have always had a passion for games.  Where do I start?  I have a rough idea of the type of game I want to develop and am ready to commit the time necessary to learn new languages.  Are mobile games too difficult to begin with? Should I begin learning the basics of keyboard controls before attempting touch screens?  I would appreciate any input or advice!
Thanks!
Nick1
• By khawk
Dene Carter, Managing Directory @ Fluttermind LLC (@fluttermind)
From Indie to Fable and Back. 30 Years of Wisdom.
Started writing games in 1984 when he was 14 years old. What has he done in 33 years?
Druid - Commodore 64 Original Dungeon Keeper core team Fable franchise and more Indie through AAA.
"I am an idiot" - first learned in 1984, and every year after.
Rockman - made $7500 for 2 weeks of work. Figured he could make 26 games a year, or$438k in today's money.
Takeaway: Really stupid at 14.
Even in 1980's, developer only got 12-14% royalties.
(Side note: Dene is fun to listen to. Recommend this on the Vault when it goes online.)

Made a black and white game on a Spectrum, which was color. Did it because he was poor. Problem is his audience were not poor, and had color TV's. Reviews were not nice. Players see things completely different to you. Do not forget that your players have not seen the game as much as you. Avoid difficulty/complexity-creep. The real world has distractions and beer - they don't care about your game as much as you do. Test your mobile game on the toilet - that's what your real players do. Fundamentally, players live inside their own brains, not yours. Those you ignore will ignore you in return. Design for your players' minds, not for you. Generalizing is Really useful
"An expert who is too narrow has difficulty colaborationg" - Valve Employee Manual Did a lot of things over the course of his career. Everyone did everything in the 1980's and 1990's. Most developers generalized. Developing a broad skill-set aids communication. Large teams require collaboration and clear communication. Knowledge breeds respect (never say 'JUST'). 'Just' suggests a task is easy. It might not be. Ignorance is an energy. Don't forget you are human. You are designed to adapt and can do anything if you put your mind to it. Be a human. Learn a skill outside your area. Programmer learn how to 3D model. Artist learn how to code. Learn music, theater. Think of yourself as an artist. Rapid Team Growth is Dangerous
"If your team can eat more than two pizzas, it's too large." Werner Vogels, Amazon VP/CTO Early Fable - 3 developers. Communication very easy. Later Fable, team grew bigger. At 12 people rumor mill started to develop. Can't have everyone in every meeting at same time. Pockets and cliques develop. Fred Brooks. Communication paths don't grow linearly. Team communication grows exponentially. [n * (n-1)] / 2 8 people on team, 28 connections. Ringelmann Effect - "Larger groups lead to less motivation & coordination & productivity." Decreased motivation - larger group, start to feel like a cog in the machine. Decreased coordination - communication pathways explode. Suggestion: Increase identifiability. Make sure everyone knows everyone's contribution. Most of all: think before growing your team. Blandness Has Its Uses
Pursuit of excellence can be wasteful. Sounds counterintuitive. Blandness helps disguise repetition. Think reusing assets. Players notice the patterns. When asking for something to be made, communicate the context of assets - how will they be seen or heard? Often find they need to be bland. Prototypes Can Be Misleading
Experiential games are difficult to prototype. More useful for mechanical games. Fable only came together at the very end - threw away at least one entire combat system. Looking back, it wasn't polished not necessarily bad. Bland prototypes are better than ugly ones for experiential. Keep prototype completely separate. Define prototypes success criteria. Art Style is More Important Than You Think
Curate rather than create Style can hide the fact you can't draw. Restrict complexity. Style is marketing. Unique style tells players there may be something unique about your game. Streamline Your Process
What is your iteration cost? Recognize your cost to try something and learn from it. Making your life easier is real work. Resist self-sabotage. (context of making tools) Closing Thoughts
Don't let technology dictate your game's core promise. Static screenshots have to look good, too. No 1 pixel lines. Don't worry about the things people don't ever get to see. Don't panic if your game sucks - fix it. Editor thought: Really enjoyed this talk. Dene is a fun speaker, and his advice was raw, real world advice for anyone aspiring to make it in game development.

• I am animator by hard, and i am doing game animation for at least 8 years so far. During the last 2 years, i came with a idea for game and maybe some day, i want to start indie game company. As i am thinking to start game company, i am also thinking what kind of value i can give to the company. For example, am experience in animation,sales(I was selling web development services, before i jumped to gaming), bit of rigging- just not for production, i am learning on the side as well. The rest of the gaming production, like modeling, concept art, texturing, i am total noob or to say better, i am no near interest to do modeling for example, don't have such a patience to do it. But before characters and things are made for animating, what the hell i am would do?
Also, what is the ideal size of the founding team of a game company? Positions to be filled mostly are, Concept artist, Modeler/Texture artist, programmer, animator-rigger. And later would need more people to join, like more animators, programmers, sound, fx,etc.

And lastly, do i need to have something,like a prototype, to show people and get them interest, or should i ask someone i know, for skill that i lack, for example, Modeling would be great, texturing and rigging, and to start all together from scratch?
• By Arthev
Hey folks, new here