• Advertisement

Archived

This topic is now archived and is closed to further replies.

Collision Detection Physics

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

Guest Anonymous Poster
hmm...
The cars get stuck together? This sounds like an inelastic Collision to me, and you seem to want an elastic collision. Here's what my schoolbook says :
Let there be two balls : one with mass m1 and velocity v1 hitting the other with mass=m2 and v2=0 . Then we get, assuming an ideal elastic collision, the nev velocities :
v'1 = (m1-m2)/(m1+m2) * v1
v'2 = 2*m1 / (m1+m2) * v1

To get this working when both objects are moving, you could chose a coordinate system in witch m2 rests in the origin

Share this post


Link to post
Share on other sites
Advertisement
Hi !!

Is your game 3D ?? If so, something very big is coming towards you !!! I tried to program something like that, and after weeks of learing physics, writing hundreds of different routines I gave up !! Ever heard of Rigid Body Dynamics ??? Well, then time is close to learn what that is.
Basically it means, that you have a physical system that is solved every frame based on the time of the prev frame. That's very hard stuff. Because you have to deal with everything. For example two cars are colliding, they are moving with new directions and speed, but then one car collides with another car, and then this car collides with a building. What, if a few objects are colliding at once.
I never got that running properly !!!

But, perhaps you will succeed. Search the internet for "Rigid Body Dynamics" if your game is 3D, there you will be right.

Phillip

Share this post


Link to post
Share on other sites
well, about the gecko suggestion it was right (at least for my 11th grade physics book) but i have found recently it isn't so right as i thought, that equation only works for front to front or front side or something like that, if fro ex a car is going north and the other northeast (is this right i mean northe and east) the car behaves differently and that equation is worth nothing, i recently bought a book which i think it explains this a little better but i lend it to a friend that has got a physics exam next week, when i get it back i shall look at it and then say something.

Stay well

------------------
Bruno Sousa aka Akura
Founder and programmer - Magick.pt
magick_pt@geocities.com
http://magickpt.cjb.net

Share this post


Link to post
Share on other sites
Hello

For the past little while I've been trying to include a realistic physical reaction when two entities in my game engine collide with each other. In other words, I want my cars to crash properly.
Currently, upon a collision, each entity updates its physical state like so:

AccelX = (AccelX + cos(col_angle));
AccelY = (AccelY - sin(col_angle));
Vx = col_vx;
Vy = col_vy;

Where Vx,y = velocity of the entity
col_angle = angle of colided entity
col_vx,y = velocity of colided entity

I arrived at this method after a week of testing and tweaking, and it seems to be the one that works the best. However, the two entities have a bad habit of becoming "stuck" in each other and this obviously is not a feature I want in the finished game!

Keep in mind that this is a result of someone with a grade 11 education in physics, so my background isn't that great. Oh, and also keep in mind that this is a 2D over head style action game, as I know it makes a difference in the physics.

If there's any information that I left out that would be crucial to the solution, please say so

Thanks in advance,
chris

Share this post


Link to post
Share on other sites
There's a small trick you can apply when things get "stuck" during collision:

What usually happens is that while your physics code manage to change velocity and acceleration correctly, the position stays the same. This makes your collision detection code detect the collision AGAIN, and re-apply the physics, giving odd results.

Another problem that can cause this kind of behaviour is round-off errors on floating point numbers. There is one crucial rule to remember: NEVER compare floating point numbers for equality (I.e. if(float1==float2)), instead do like this: if( abs(float1-float2)<LIM ), and define LIM to be a "sufficiently small" number. The exact value of LIM depends on what is "small" in your particular context.

Essentially, you need to make sure that once a collision is detected it is also resolved - that is, the entities colliding must be re-positioned in a way so that the same collision is not detected the following frame.

Hope it helps !

/NJ

[This message has been edited by Niels (edited September 21, 1999).]

Share this post


Link to post
Share on other sites

  • Advertisement