The title gives it away. I am trying to model a pool table, but can''t seem to get it right. If I have fewer than five balls it looks ok, but after that they seem to start eating into each other. Has anyone tried to do this before? I''m not trying anything fancy. All I''m talking about is 2d, and I''m not worried about the balls jumping or anything involving a 3d dimension. Any ideas to get me in the right direction and/or useful links? ::Daricon::

Are you modelling in a 3D Modeller like 3DS, or are you a programmer?
Can you descibe eating?
Is it Pure 2D?
Is the problem the physics when balls collide?

It can be me, but your question seems a little vague?
Can you descibe your question a bit more?

I''m gonna go out on a limb and guess that your balls "eating" each other means that they aren''t colliding properly and are overlapping or something like that?

In that case I would suggest that you just make sure you check every ball with every other ball when you do your collision detection. The most straightforward method requires 2 nested loops to check all the possible combinations. A simple distance test from the ball''s centers should work fine. (and make sure not to test the balls for collisions with themselves... this is bound to lead to problems.)

If the problem is not collsions and, instead, the physcis (as the title suggests) then I''ll need a little more info to help out. Are you just doing simple collsions? Do you care about roataions? Coefficients of restitution (how much of the collision force is absorbed in the collision... not really needed for a pool game since the collisions are basically all perfectly elastic.)

I''d be happy to go over the physics if you need it or anything else in this post, just let me know what you are having problems with

Check out the GPI project today!

Yeah, I just kind of threw that out there. Now that I reread it, I see how vague it is!

baskuenen:
Yes, we are talking programming. Yeah, eating was just like Chippy guessed, overlapping. Sorry, I thought "eating" was a universally known term . This is pure 2d, the problem isn't really the balls colliding, but the transfer of energy among a collision with more than 2 ball.

chippydip:
As of now, I'm doing exactly like you said Chippy. (Mind if I call you Chippy? ) I've got the two for loops running through all those happy balls. So if two collide, then, sweet, it works. The problem is when more than about four collide. Think of when you start a game of pool and all the balls are in the triangle shape? Following? And you use that pearly white cue ball to break everything up. That is where eating happens. I don't know how to transfer that force(?) properly so every ball bounces off as they should without any eating. So, I would have to guess its much more a physics problem than a collision one. Hope this makes it more clear big guy!

::Daricon::

Edited by - Daricon on May 8, 2000 5:15:51 PM

You might be interested in the September 1999 issue of Game Developer magazine. Page 17 is an article by Jeff Lander on pool table physics. It deals strictly with the mathematics of the system, so it''s not 3d specific.

Game Developer is at http://www.gdmag.com/ and while they have some articles online, I don''t think this particular one is. You might have to order a back issue, or find a friend with that issue.

---- --- -- -
Blue programmer needs food badly. Blue programmer is about to die!

Daricon, didn''t we just discuss physics recently? Anyway, about the ball-eating problem: I imagine that your collisions go something like this: if the distance between ball 1 & ball 2 is less than the sum of their radii, then a collision has occurred, so exchange their velocities or whatever. The problem is, ball 1 and ball 2 are actually overlapping at this instant, and you need to correct for this in addition to just adjusting velocities. You should adjust their positions so that they are just "touching" and not overlapping.

Also, when you rack the balls, I would put a little distance between each ball.

mossmoss:
I unfortunately don't have access to a hard copy of the issue and it doesn't appear to be online . I did look at the source code of the issue, and based on that, I don't think it is exactly what I'm talking about. Thanks though.

Eric:
Yes, you did help me with a collision detection problem early. I worked with the code you posted, and after some tweaking, it worked. I then wrote a little function that pushed the the overlapped balls back so they were not overlapping. So if I have two balls colliding, it works fine. But if I have a lot of balls close together that aren't moving, or not moving much, and then another ball is set to bump into the pack, then problems occur.

::Daricon::

Edited by - Daricon on May 8, 2000 10:04:15 AM

It sounds to me like the problem you are having it in your collision system and not in the physics (since you say it works for small numbers of balls/collsions.)

(Oh, and you can call me chip, chippy, chippydip, brady (last name is bradford)... whatever )

Ok, so back to the problem. What I would guess is happening is this... two balls collide so you reverse thier velocites and move them back so they do not overlap... but if there are other balls around they may get moved back on TOP of other balls which you have already checked for collisions against. I can think of two solutions to this problem at the moment (and these are just off the top of my head, so your results may varry )

1) Decrease your time step between updates... this is not a great solution as it does not address the real problem... it just tries to cover it up... might work well enough for what you need, though.

2) I assume that now you are updating the positions of all the balls and then doing collision test. You might try updating the position of one ball at a time and checking for collisions. If you detect a collision then adjust the velocities of both balls, but only move the ball you are currently updating... finally, make sure that this final position is valid (more collision test.) This method mucks with the physics a bit and takes some more computations, but I don''t think you will notice the effect it has on the physics and the extra calculations should be less than those rewuired to to multiple time steps per frame.

If either of these ideas end up working (esp if you decide to use the send one) I would be interested to know... As I said, I just thought this up off the top of my head and would be curious to see if I''m correct in my assumptions.

Check out the GPI project today!