thanx..:D
MS
Printable View
thanx..:D
MS
I don't have a finished Billiard game but if you check the collusion of two balls by their distance (hit if distance <2*radius of two balls), use some of the stuff here:
http://board.flashkit.com/board/show...hreadid=279907
And use vectors for the speed of the balls and the speed they give to other balls when they hit them, you could do a pretty good billiard game.
But maybe someone has the source of a finished game, would be easier ;)
Yes Don I spoted this one..the problem is that the bounce off is not that simple. I think there was a formula which calculates bounce agnle depending from the agle at which the balls touch plus there was some momentum preservation, elastic collision in 2D .complicated..:D
mad
I was just playing with some bouncy balls there (very educational, right up there with slinkys). They appear to swap momentum, so the slow one goes fast and the fast one goes slow. The ball collision equation: R = 2W - P seems to work well enough. But, of course I'm sure this isn't true to nature.
Hey Mad-Sci,
You might wanna have a look at:
http://www.playpool.com/apapp/
Dunno if this it's any help, but there seem to be some formula's there...
The real trick is going to be interpolating the positions of the balls to find out when they would have contacted had they not skipped past the moment of collision. Momentum won't be a huge deal since all the balls are of equal mass. So mass cancels. So total x velocity just before coll=total x velocity after coll. Just before and just after because It'll need friction, which can be faked at any desired level of complexity. I like just multiplying the x and y velocities by .9 or .8 or something.
[swf width="100" height="100" background="#ffffff"]http://www.ironmallet.com/flashkit/Pool.swf[/swf]pool.swf
you really have to zoom in to see that these two balls are never 2r apart, they go from >2r to <2r in one frame. I worked on this about 2 months ago, I'll look for my notes because now that there's a Math and Physics forum...
jobe makar give an excellent excellent discussion of this whole topic in flash super samurai.
I was playing pool last night, and decided to watch the balls a little more closely....It does look very difficult.
Simply doing accurate and fast hittesting is enough of a headache.
Still, I'm going to have a go. Probably best to start off with a good hittest, and a basic bounce, then work out rebound angles and momentum afterward.
Then there's spin, which REALLY messes things up.
I imagine that a good pool game in flash would require some convincing pseudophsics, rather than using any of newton's equations etc.
I've just put this together in flash, it looks neat, but it's useless at the moment, as the balls don't collide, I'll post again as soon as I've got some kind of hittest/rebound thing going on.
http://www.proanimate.com/pool1.swf
Use enter to accelerate the balls, if you want to play around with it, here's the source:
http://www.proanimate.com/pool1.fla
I saw an example where when two balls hit they swapped angles and speeds.
Just found this, a working example in flash:
http://absolutist.com/online/pool/
Interestingly, you can adjust the accuracy of the physics if the game runs too slow, and the lag is only noticable when balls collide.
I'm still figuring it out.......
it's definitely not just a matter of swapping speeds or reversing directions. it is all covered in conservation of momentum. you have to know the mass, angle and speed of each ball, then determine the angle of collision (angle between the two balls at point of impact) and figure out how much of each ball's momentum lies along this line. then figure out how much momentum each ball transfers to the other, figure out the resulting momentums along that line, then translate back to world coordinates. again, jobe makar describes it very very well in super samurai. almost to the point where it is understandable for us mortals. :)
OK, I have not posted much on here, but I am an undergraduate engineer, and I just studied collisions in physics, so I may be of some help.
All collisions are is a transfer of "momentum". People misuse words everyday, so momentum can be defined as
p = m * v
where p is momentum, m is the mass, and v is the velocity.
V(velocity) is a vector quantity which means not only does it have a magnitude (number), but it also has a direction. This means the p (I will refer to momentum as p for the rest of this post) also must have a magnitude and direction.
Now onto collisions. There are two types of collisions: inelastic, and elastic. In an inelastic collision, the two objects stick completely together. In an elastic collision, the two objects do not. Elastic collisions are obviously the type between two billiard balls.
It is a fundamental law that in an elastic collision (which is also one with no outside forces), linear momentum is conserved. This means that the momentum before the collision must be equal to the momentum after the collision. Now onto some fundamental equations. These are the equations for a two object elastic collision where
m1=mass of object 1|m2=mass of object 2|v1=velocity of ball 1|we are assume right now that object 2 is stationary.
final velocity of ball 1= ((m1-m2)/(m1+m2))*v1
final velocity of ball 2= ((2*m1)/(m1+m2))*v1
Looking at these equations, one can see that if the two objects are of equal mass, then the final velocity of ball 1 will be "0" where the final velocity of ball 2 will be the initial velocity of the first ball.
You may be thinking to yourself, "But I have played pool before, and the cue ball still have a small velocity on it after hitting another ball." This is because of two reasons. The first is simply that the cue ball is actually a fraction bigger than all of the other balls. This mostly helps commercial ball returns. If you look at the equations, you will see that the final velocity for object 1 if it is just a little bigger than object 2 will be very small. Lastly, the collision is not completely elastic. No collision will ever be completely elastic because the balls bend in a little on contact. You can't see it, but they do, and that absorbs a tad of the momentum.
Now, what if the second ball is also moving? This is where it gets difficult. If the balls are rolling together, do you have to use one equation: m1*v1 + m2*v2 = (m1+m2)V
But if they aren't, you have to use a different equation. What I would do is to think of the balls hitting like this: During the split second that the balls are actually touching, think of one ball as being stationary and being hit by the other ball. Then when you find the final velocity of that, just add it to the actual initial velocity. On top of that, you will need to find the components of the velocities and add them up seperate. For example, a ball that is moving at 10 m/s at an angle of 40 degrees from the horizontal has a x-velocity of 10*cos40, and a y-velocity of 10*sin40. That is about the best I can do with two balls moving at once.
The angles that they hit is important too. The final angle that they rebound at is equal to the angle that they actually hit. You can find this angle by doing the following:
arctan(y/x) which is the inverse tangent function of the change in y divided by the change in x. Example, if you have a ball that's center is at the point (0,0), and it is hitting another ball whose center is at (3,1), first you would find the change in X and Y. the change in Y would be (1-0)=1, and the change in X would be (3-1)=2. So the angle between the two would be the arctan(1/2), which happens to be about 26.6 degrees. Now when these two balls hit, ingoring velocities and concentrating on angles, you can see that the ball being hit will go off at an angle of 26.6 degrees, while the first ball doing the hitting will go off in the exact opposite direction, which is either
-26.6 degrees, or 333.4 degrees.
I won't go over it, it will take too long, and this is already a quite long post, but combining those last two methods, the first of finding the magnitudes, and the second of finding the direction, you should be able to make some pretty realistic collions. Obviously, you will want to apply a friction constant, otherwise the balls will go on forever and never stop.
Also, there is one other collision, and that is with the ball and the rails. Obviously, most people know that it just kinda changes directions. If the ball is traveling upwards, and hits the right rail, the yvelocity will remain exactly the same, and the xvelocity will just inverse, for example initially a ball has xvel=2, and yvel=5, when it hits the rail, it will have a yvel=5, and a xvel=-2. To be more realistic you can add an effect that takes the velocity down just a tad when it does hit. But that must be quite small.
Well, that is about all I have time for right now. I hope this helps someone, I tried to put thought and time into it. Enjoy people
Can somebody please comment my pool example:
http://www.hot.ee/tonypa/flash/flas/pool2b.html
Its not finished, must be restarted, when cue ball goes into hole :)
Minger
Thanks. That's priceless, and I haven't seen it explained so well before.
Tonypa
I do like that, although it's a little slow, and the action could be smoother.
It's a damn site further than I've got, though.... :D
Hey, it's no problem. I am just trying to help out a little with anything that I can. I ask for help with all the scripting and syntax crap, so the least I can do is help out with the things that I am good at: math and physics.
So, like I said, I am an undergraduate engineering student, so I will try to help as much as I can with these types of questions.
here it is in action:
http://www.bit-101.com/content/020402.swf
http://www.bit-101.com/flafiles/020402.fla
this throws in gravity, lift, and different sizes/masses on 10 balls just for fun.
the fla is not commented, so here is the theory.
calculates distance between two balls (pythag. theorem)
if distance<sum of radii, then you have a hit.
calculates angle between two balls.
uses that angle to perform coordinate rotation on the x and y velocities of each ball.
then uses the exact momentum equations given by minger to resolve the collision and new velocities.
in my own twist on things, i manually move the balls so they are just touching each other, not intersecting. this is not mathematically correct, but keeps them from getting "stuck". this is the biggest problem with these types of collisions and various methods have been made to handle it. this is my take on it.
then, re-rotate the velocities and carry on.
funny, i'm now secong guessing myself if i did the rotational vectors correctly. seemed to make sense last night, but now the math seems strange. still, it looks correct.
Looks sweet Bit. Everything looks good, and the code looks good too. Man, you need to know that you are my hero. I check your page everyday to see if something new is up.
Hope my little collision explaination helped.
Keep up the good work.
yeah, i just worked it out again on paper and re-convinced myself that my rotations were correct. this stuff is slippery!
actually, i used super samurai as my main learning material, but it contains all the same equations as you gave there. for someone like me who never had any formal math training, it's good to read as many versions and explanations as possible. sometimes one will give you a slightly different viewpoint that makes the whole subject click.
Yeah, anytime. If anyone needs to know anything math/physics wise, I'm the guy. Recently we learned about fluid pressure, oscillations, and now we are on waves. So, if anyone has any question about those, I might now be able to do the script, but I can give the real life equations and stuff like that.
here's another example
http://www.bit-101.com/content/020403.swf
http://www.bit-101.com/flafiles/020403.fla
this one adds in large body gravity and drag & throw capabilities. looks pretty solid.
Bit-101, that's just sick.
Good work.
I just love this thread :)
Magic :)
Bit, once again you amaze me man. One day.....one day I will be as good as you. Until then...I will just sit here and wonder.
it's just about learning the basics. i concentrate on one thing until i know it so cold i can code it in my sleep. then i just play with the different formulas. how many different ways can you combine elasticity, gravity, momentum, accelleration, rotation, bouncing, angles, etc. etc. ? it's endless.
yeah, it sure it about the basics. I have been learning physics and calculus and stuff like that for years, but I have only been scripting for like a month. I have all of these ideas that I know how to do with real-life formulas and stuff like that, I just don't know the exact script and code and things like that. As soon as I can get the basics, I will hopefully be able to start turning out some good stuff like you.
thats amazing! you can actually get the little ones to orbit the big ones for a short time.
I've played around a bit with the file from BIT-101. It's now a good example to show how something in a perfect order can go in chaos really fast. ;)
http://www.zh-webdesign.ch/icomedia/chaos.swf
Fredi
yup. there's another one, i think on April 7th (www.bit-101.com) that does orbiting directly.Quote:
Originally posted by cadwallader
thats amazing! you can actually get the little ones to orbit the big ones for a short time.
The system cannot find the file specified.Quote:
Originally posted by lesli_felix
I was playing pool last night, and decided to watch the balls a little more closely....It does look very difficult.
Simply doing accurate and fast hittesting is enough of a headache.
Still, I'm going to have a go. Probably best to start off with a good hittest, and a basic bounce, then work out rebound angles and momentum afterward.
Then there's spin, which REALLY messes things up.
I imagine that a good pool game in flash would require some convincing pseudophsics, rather than using any of newton's equations etc.
I've just put this together in flash, it looks neat, but it's useless at the moment, as the balls don't collide, I'll post again as soon as I've got some kind of hittest/rebound thing going on.
http://www.proanimate.com/pool1.swf
Use enter to accelerate the balls, if you want to play around with it, here's the source:
http://www.proanimate.com/pool1.fla
My site's down, and will be for a little while.
I'll upload a file later on my freehost.
I'm getting a little further with the game, I'm playing around with different collision detection routines for the balls. Starting off with 16 balls in pool really slows the game down!!!
Also trying to correctly simulate the friction of the table. Subtracting .1% each frame looks good, but the ball never actually hits zero velocity when you do that, so you have to increase the friction as velocity approaches zero, and arbitrarily stop the ball when the velocity goes below a certain point.
I'm also playing around with things like balls casting dynamic shadows on the table, but this isn't any good on slower machines, unfortunately.
There's quite a few hurdles to programming pool. Here's a few more I haven't even contemplated yet...
Opponent AI
Multiplayer capability
Targetting, showing path of object ball if hit.
Finding some decent sound FX :D
"friction" is quite often taken as a percentage of speed like that. i usually do it that way myself. but it's not physically accurate. it would actually be mathematically represented by an acceleration in the opposite direction of the motion, or a negative acceleration, if you will. so it would be a constant amount, but of course it would never actually reverse the direction of the object, only stop it.
so say you have an object with velocity vx. (we'll limit it to the x-axis) if vx is positive, frictionx will be negative, and vice versa. if vx is less than frictionx, vx should simply be set to 0.
as far as number of balls, yeah, my system seems to max out at 10 or so. after that, too clunky. i could work at optimizing, but the fact is theres a lot of math to do each frame.Code:ball._x+=vx;
if(vx>frictionx){
vx-=frictionx;
} else if(vx<-frictionx){
vx+=frictionx;
} else {
vx=0;
}
Bit-101
To speed things up a bit, try using the basic hit-test before using the pythagoras distance test.
Only use the pythagoras test if you get a positive result on the bounding-box hittest.
Here's that bouncing demo you did to illustrate. I set the balls to 20. There's also a moock fps speedometer in there to give you a frame rate:
http://www.btinternet.com/~proanimat...02modified.swf
Now instead of this:
checkColl(b(i), b(j));
Use this:
if (b(i).hitTest(b(j))){
checkColl(b(i), b(j));
}
It goes from about 8fps to around 14fps on my machine:
http://www.btinternet.com/~proanimat...2modified3.swf
BTW, here's what I've got so far. It's non-interactive at the moment. I'm still looking for ways to speed it up on the break, which is the slowest part of the game.
http://www.btinternet.com/~proanimate/pool6.swf
wow, that pool game looks nice.
and it's kind of spooky seeing my files up there with stuff added to them! :D
keep at it!
mamma mia...this is way cool and way too dif. for me :D I would sugest you guys look in the GamesForum for Xentor's Flash peer-to-peer VB thingie...:D
http://board.flashkit.com/board/show...hreadid=303746
thanx for the tut..
ms
Bit-101
Being able to dissect your bouncing code helped a great deal, along with minger's explanation of the physics.
Another thing I'm working on is a way of giving a ball a rotating spot, so you can see it rolling. I have a very vague idea of how this might be done, I'll post as soon as/if I work it out.
Mad-Sci
That looks very cool.
I was wondering, whether you could apply your mass collision detection routine to pool balls??? I haven't looked at the code myself, so I don't know. But I'm sure the same principle could be used to speed things up.
I guess so..keep in mind that the way it works is one moving against many static,you may want to tweek it a bit
ms
I haven't looked through the code much in the files posted so far, but I haven't seen any that ensure the balls haven't passed through each other completely. Let's say you have two balls, each with a 3 pixel radius. They are moving on a collision path at 30 pixels per step and appear to go through eachother. Do any of the SWF's or FLA's address this issue? I have a feeling that would slow down flash quite a bit in a game like pool where there are many tests going on at once, but it is an essential element to consider if you are trying to write a billiards game.
The only thing I've noticed is that the bounce angles and collision detection become a little less accurate as the balls get faster. This actually happens on a real table, as human accuracy decreases the faster the balls are hit.
So it doesn't matter, as long as the increments each ball makes aren't big enough to pass through a ball at a direct angle.
Another 'problem' I've noticed is that when you break the pack hard enough, two balls appear to overlap as they don't have enough space or anywhere to go. Anybody who's broken up hard enough on a real table will see the same thing, only the ball is forced upwards.
Good point, but it is possible to keep the balls slow enough not to pass through in most cases, but what about two balls that are going should touch edges? That is tough to protect against. I know Yahoo's pool doesn't allow many pass throughs (even on edges).
The problem wasn't addressed very well in the Samurai book, but I know it can be done. I know what you're saying about the slop factor at higher speeds, but game code can be precise since we don't have to worry about external forces. I don't think it will be all that difficult to fix.
(I think) the yahoo pool is timebased, not framebased, so it's coded in a completely different way. If I remember correctly, the ball doesn't slow down in real time, but 'fast-forwards' to its final position.
With frame-based pool, the innacuracy comes from having a ball move too far in one increment, so you need to make sure that the balls aren't ever moving more than a certain number of pixels per frame. If you want a ball moving quickly, and you're movie's running at 15fps, then this is easier said than done!
Another thing to remember is that java is faster than flash, so you can afford more elaborate routines for hit-testing and physics. With actionscript, you have to try and get a good balance between realism and performance.
I actually tried an experiment by putting a ball very slighly in the path of another in flash, and it only hit it when it was travelling below a certain speed. As I said before, this happily reflects the behaviour of a real table in that hitting a ball quickly at an almost 90 degree angle will often result in a miss.
This gave me another idea (which I haven't tried) - What if you increased the size of the ball proportionally to it's speed to exactly compensate for this? As the ball gets faster, it's more likely to miss, so make it bigger! Not physically, but just the hit-radius.
It's an approximate solution, but it could work...