#### Archived

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

# multiple-body problems

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

## Recommended Posts

in writing a game involving a fair amount of collision, i've hit (eh!) a problem in collisions involving more than one body. i have a decent understanding of general collision detection and the physics of colliding objects, its just when there are a few objects colliding at the same time that my head starts to spin... my first problem came up as follows :
+
|
|
|(1)  <- (2)
|
|
+

ball (2) is heading directly for ball (1), which lies flush against the boundry. in open space (ie no boundry) the collision is easy to solve, based on velocity, mass, transfer of energy, etc. with the boundry, however, ball (2) will hit ball (1), which in turn "hits" the wall causing ball (2) to bounce back out. with my first (simple) algorithm, i wouldnt detect that until it was too late. depending on the sequence of balls evaluated, ball (1) may end up other side of the boundry, or bouncing off back at ball (2) which would only "register" that in the next game tick. no matter which way, it always ended up wrong... i hit similiar problems with situations such as these :

(1)(2)   <- (3)


and

(1)   <- (2)

^
|
(3)

(in which ball (2) and ball (3) are moving at equal velocities - again, depending on the order of balls evaluated, either (2) would hit (1) following which (3) hits (2), or (3) hits (2) and its finished. the results of which are totally different!) as well as

(1)  <- (2)

^
|
(3)


(in which (2) and (3) are set to hit (1) at exactly the same time. (1) should move off with the combined effect of these two balls - instead, it only responded to one of them, and that depending on which was evaluated first!) there were a couple of other similiar problem cases in which my simple system just failed to give consistent results. after much problem-bashing, i cooked up a working system with *loads* of bulky code involving transactions, complex commit queues and way too much coffee. i cant help but think that there must be a more elegant solution - something simple that i missed? something simple i would never have thought of? or perhaps i am just over complicating things here? is there a way to avoid these problems altogether? [edited by - craigf on August 11, 2003 6:22:12 PM]

##### Share on other sites
Well, ASSUMING I understand you correctly then....

All you should have to do is test for collisions, and if one happens, move the objects (both!) to the collision point. Then next frame subsequent collisions happen like the ball with the wall and such. Now, if you're looking for a PERFECT solution and simulation this won't work, but in game code (in my experience anyway) this works perfectly fine. Only side effect is objects appear to slow down when multiple collisions occur, as the objects are jumping.

I.E. (pseudo code of my implementation)
UpdateBallPosition();TestWithRegisteredBalls(); //checks for collisions with other balls in the area, add to collision queueRegisterBall(); //other balls in list now check against this one for collisions//Note:  if you haven't noticed, I add balls as I process them, then when i skip octree nodes (I use an octree) I unregister objects from that node, so only objects in similiar nodes are checked.//Anyway...//Back at the collision response code (processes queue)float t = GetCollisionTime(); //process the collision, find a time (binary search of time is what I do) when the balls were last not colliding.Ball1->SetMove(t * Ball1->Velocity); //set move is a bit of a special function.  Normally when an object updates, it adds its velocity to it's location.  If setmove is called, the vector passed OVERRIDES the location * timeDifference equation.  Soooo//something like this:{  if (MoveSet)      Loc = Loc + ThisSetMove;  else      Loc = Loc + Velocity * TimeStep;}//back to collision responseBall2->SetMove(t * Ball2->Velocity); //move the other ball next frame too//do impulse/other stuff necessary for the collision to take place

I hoep that was clear... If not just say what parts weren't... please not the whole thing lol. See though? That's what I do and it works for me, even in situations where there are 100s (literally) of balls smashing into a common area.

Hope that helps.
Walt

Edit: Code to Source tags looks better.

[edited by - shadowman13131 on August 11, 2003 6:34:49 PM]

1. 1
2. 2
3. 3
4. 4
5. 5
Rutin
11

• 12
• 19
• 10
• 14
• 10
• ### Forum Statistics

• Total Topics
632665
• Total Posts
3007711
• ### Who's Online (See full list)

There are no registered users currently online

×