Jump to content
  • Advertisement

Archived

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

Daricon

pool table physics

This topic is 6926 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

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::

Share this post


Link to post
Share on other sites
Advertisement
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?

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!