I am trying to construct a model for use in a video game

Basically I have boiled things down to the following situation that needs to

be modelled:

Think of a snooker/pool table (without the pockets) with two balls on it.

The balls bounce around colliding with the sides of the table and each

other. Perfectly elastically for simplicity.

For further simplicity, there is no friction. Maybe they have unit mass.

Basically picture two circles bouncing around inside a rectangle.

My question is:

Given:

1) the dimensions of the rectangle and the circles.

2) the initial velocities of the circles

Is there an equation where I can find the location of the circles at time t?

e.g.

circle_one_centre(x,y) = f(t)

circle_two_centre(x,y) = f(t)

If so, how do i go about finding this equation?

what about the same thing for n circles?

Different shaped tables??

Any ideas?

Thanks for any help

Dean

I wouldn't expect one, especially if you are allowing for collisions. Start

by thinking about 1 ball bouncing around by itself. Decide how long the

ball will be in motion (and at what velocity) and use a loop to track its

position (iterating every 10th of a second, say).

Good luck, Bill

don't think so. What you can do though is to break up the path into a

series of discrete chunks. You don't have to do it like Bill97 says

though, checking the position every short interval of time, because the

only time the equation changes will be when it collides with something.

(Though if there are a lot of balls that might be the easiest way.)

Look at just one ball bouncing around for a minute. Let's set up a

couple variables:

- x will be the current x location of the ball (say that x is the

short distance)

- y is the current y position of the ball

- width is the x dimension of the table

- height is the y dimension of the table

- v is the velocity of the ball

- a is the angle the ball is traveling (0 will be positive x and no y;

90 is positive y and no x; I'm actually going to use v and a at the

very beginning then ignore them)

- t is the current time

The table is set with a corner at (0, 0) and extending into the first

quadrant. I'm using real coordinates, not the reversed y axis you see

in CG a lot. ;-)

Furthermore, we assume one of two things: either the ball has zero

radius or the variables width and height should be increased by the

radius, and the whole table offset by r/2 left and down. In other

words, if the ball is sitting at (0,0) it should be touching the left

and bottom sides, and if it is at (width, height) it is touching the

right and top sides.

If we ignore the edges, the position of the ball can be found as

follows (I'm gonna use a bunch of temporary variables from here on to

make this clearer to both me and you):

The x component of the velocity is vx = v*cos(a)

The y component of the velocity is vy = v*sin(a)

Thus x(t) = x + vx*t and y(t) = y + vy*t.

But this only holds until it hits the side, so we have to find when

this will occur:

If the ball will hit the right rail, it will happen at tr = (width -

x)/vx

If the ball will hit the left rail, it will happen at tl = -x/vx

Similarily tt = (height -y)/vy and tb = -y/vy

So we have these equations holding until t reaches reaches the minimum

of the appropriate x choice and the appropriate y choice:

tm = min( (vx > 0) ? tr : tl),

(vy > 0) ? tt : tb) );

At that point, it hits the rail(s) so we bounce it by flipping the

velocity of the appropriate direction(s):

if( tm == tl || tm == tr) vx = -vx;

if( tm == tt || tm == tb) vy = -vy;

(Note that these both might be true if it hits the exact corner, so you

can't use else if)

Then repeat. (You'll need to make allowances for vx or vy being 0.)

So we have an algorithm for computing the position at time t (I'm

assuming height and width are global constants):

pair<double, double> position(double t, double x, double y, double v,

double a)

{

double vx = v * cos(a);

double vy = v * sin(a);

double t_until; // tm above

do

{

if( t_until == t_left || t_until == t_right) vx = -vx;

if( t_until == t_top || t_until == t_bottom) vy = -vy;

double t_right = (width - x)/vx;

double t_left = -x/vx;

double t_top = (height - y)/vy;

double t_bottom = -y/vy;

t_until = min( (vx > 0) ? t_right : t_left),

(vy > 0) ? t_top : t_bottom) );

} while (t + t_until > t_max);

return make_pair( x + vx * t, y + vy * t);

}

(This won't work if a = 0, 90, 180, 270, ..., or if the

series of discrete chunks. You don't have to do it like Bill97 says

though, checking the position every short interval of time, because the

only time the equation changes will be when it collides with something.

(Though if there are a lot of balls that might be the easiest way.)

Look at just one ball bouncing around for a minute. Let's set up a

couple variables:

- x will be the current x location of the ball (say that x is the

short distance)

- y is the current y position of the ball

- width is the x dimension of the table

- height is the y dimension of the table

- v is the velocity of the ball

- a is the angle the ball is traveling (0 will be positive x and no y;

90 is positive y and no x; I'm actually going to use v and a at the

very beginning then ignore them)

- t is the current time

The table is set with a corner at (0, 0) and extending into the first

quadrant. I'm using real coordinates, not the reversed y axis you see

in CG a lot. ;-)

Furthermore, we assume one of two things: either the ball has zero

radius or the variables width and height should be increased by the

radius, and the whole table offset by r/2 left and down. In other

words, if the ball is sitting at (0,0) it should be touching the left

and bottom sides, and if it is at (width, height) it is touching the

right and top sides.

If we ignore the edges, the position of the ball can be found as

follows (I'm gonna use a bunch of temporary variables from here on to

make this clearer to both me and you):

The x component of the velocity is vx = v*cos(a)

The y component of the velocity is vy = v*sin(a)

Thus x(t) = x + vx*t and y(t) = y + vy*t.

But this only holds until it hits the side, so we have to find when

this will occur:

If the ball will hit the right rail, it will happen at tr = (width -

x)/vx

If the ball will hit the left rail, it will happen at tl = -x/vx

Similarily tt = (height -y)/vy and tb = -y/vy

So we have these equations holding until t reaches reaches the minimum

of the appropriate x choice and the appropriate y choice:

tm = min( (vx > 0) ? tr : tl),

(vy > 0) ? tt : tb) );

At that point, it hits the rail(s) so we bounce it by flipping the

velocity of the appropriate direction(s):

if( tm == tl || tm == tr) vx = -vx;

if( tm == tt || tm == tb) vy = -vy;

(Note that these both might be true if it hits the exact corner, so you

can't use else if)

Then repeat. (You'll need to make allowances for vx or vy being 0.)

So we have an algorithm for computing the position at time t (I'm

assuming height and width are global constants):

pair<double, double> position(double t, double x, double y, double v,

double a)

{

double vx = v * cos(a);

double vy = v * sin(a);

double t_until; // tm above

do

{

if( t_until == t_left || t_until == t_right) vx = -vx;

if( t_until == t_top || t_until == t_bottom) vy = -vy;

double t_right = (width - x)/vx;

double t_left = -x/vx;

double t_top = (height - y)/vy;

double t_bottom = -y/vy;

t_until = min( (vx > 0) ? t_right : t_left),

(vy > 0) ? t_top : t_bottom) );

} while (t + t_until > t_max);

return make_pair( x + vx * t, y + vy * t);

}

(This won't work if a = 0, 90, 180, 270, ..., or if the

D'oh, move the lines that swap the directions AFTER the four 'double

t_<rail name> = <blah>' lines....

t_<rail name> = <blah>' lines....

On 20 Mar 2005 00:01:49 -0800, Evan

It's worse than that (it's dead, Jim!). The resultant trajectories of

balls with non-zero size colliding deoends on where they hit as well as

the velocities involved. A 'clip' or 'graze' has a very different

effect from a collision where the two centers of mass are on the same

line as the relative velocity, even assuming that the balls have no

friction between each other.

If you are doing a complete simulation of friction, there is a residual

value which still acts at zero speed so things will come to a complete

stop in the Real World(tm) as well (ignoring molecular and atomic

motions). Friction is decidedly non-linear.

Friction between balls on glancing shots will also introduce spin (and

spinning balls colliding will be an 'interesting' (in the sense of the

curse) exercise).

Nor do they bounce off other things in expected ways.

I think the phrase is "The rest is left as an exercise for the reader"

<g>.

(There is probably a better newsgroup as well, one on games algorithms

possibly. It's not a C++ problem, anyway, it's a physics one, possibly

some of the sci.* newsgroups will have answers to some of the

questions...)

Chris C

It's worse than that (it's dead, Jim!). The resultant trajectories of

balls with non-zero size colliding deoends on where they hit as well as

the velocities involved. A 'clip' or 'graze' has a very different

effect from a collision where the two centers of mass are on the same

line as the relative velocity, even assuming that the balls have no

friction between each other.

If you are doing a complete simulation of friction, there is a residual

value which still acts at zero speed so things will come to a complete

stop in the Real World(tm) as well (ignoring molecular and atomic

motions). Friction is decidedly non-linear.

Friction between balls on glancing shots will also introduce spin (and

spinning balls colliding will be an 'interesting' (in the sense of the

curse) exercise).

Nor do they bounce off other things in expected ways.

I think the phrase is "The rest is left as an exercise for the reader"

<g>.

(There is probably a better newsgroup as well, one on games algorithms

possibly. It's not a C++ problem, anyway, it's a physics one, possibly

some of the sci.* newsgroups will have answers to some of the

questions...)

Chris C

A better method is to convert the table into a coordinate system.

Give each ball a location.

In your simulation, just query each ball's location.

_I_ would create a ball class that has properties of the ball,

such as magnitude and velocity as well as current position.

Add some methods for calculating the next position as well

as some methods for bouncing off of the rectangle and

intersecting with other balls.

Let your simulation work in chunks of time, dt (the difference in

time or lenght of a chunk). Add methods to the ball to calculate

its next or current position based on dt. The main loop would

call this method for each ball. You could also add some display

methods too, which would erase their old position and draw themself

at the new position.

In summary, I believe the simulation will be easier if you

think in terms of time chunks. Think of what needs to be performed

during one slice or chunk of time. Think not of trying to figure

out how to perform a window or subscript of the big picture.

--

Thomas Matthews

C++ newsgroup welcome message:

http://www.yqcomputer.com/ ~shiva/welcome.txt

C++ Faq: http://www.yqcomputer.com/ ++-faq-lite

C Faq: http://www.yqcomputer.com/ ~scs/c-faq/top.html

alt.comp.lang.learn.c-c++ faq:

http://www.yqcomputer.com/

Other sites:

http://www.yqcomputer.com/ -- C++ STL Library book

http://www.yqcomputer.com/

2. Press Release - Soft Xpansion presents Billiard Kings 2: New 3D billiard simulation for the PC

3. Pool/Billiard Table with Microsoft Surface Technology

4. Converting Adjacency Model Table to Nested Model Tabel.

5. Data Modeling:Lookup table and Main table:establishing relationshi

6. object model for table in table

7. ConTEXt Newbie: Column/table background color - which table model/command?

8. pre teen model, pre teen models, pre teen model websites

9. FS: Model M keyboards, and PS/2 Model 56's, Model 77s and MCA Cards

10. 3d model of golgotha in jerusalem | 3d model of hand | 3d model of hasp

11. using model inputs in model initialise states or model start in C mex s functions

12. 3d model of hand | 3d model of hasp | 3d model of hms surprise

13. The Chess Model (aka Iterative Model, Tactical Model)

14. 767 cabin 3d model | 767 interior 3d model | 91 535 bmw 3d model

6 post • Page:**1** of **1**