Air Puck Physics
by Richard_H · in Torque Game Engine · 10/12/2006 (3:41 am) · 17 replies
Hi,
I've been attempting to create a small air hockey game and after looking over my physics choices I believe a projectile would work best. It can bounce, and have a modified gravity. The current problem I'm facing is the maximum lifetime of this projectile. I'm wondering if I have any better choices or if it would be easy to remove the max lifetime in the source code. So, any sugestions?
I've been attempting to create a small air hockey game and after looking over my physics choices I believe a projectile would work best. It can bounce, and have a modified gravity. The current problem I'm facing is the maximum lifetime of this projectile. I'm wondering if I have any better choices or if it would be easy to remove the max lifetime in the source code. So, any sugestions?
About the author
#2
10/12/2006 (11:26 am)
Rigid body physics would not be stable enough for air hockey without being gimped/modified as to what they try to do. As long as you don't want to be able to hit it off the table, a projectile would be a decent base as far as physics go. Though you would need to do some code changes to get it to behave how you want. Probably need to modify the bouncing code to have a special case for colliding with the "goal" area or some such. Removing the timeout wouldn't be hard though.
#3
Apply a force that's inversely proportional to the distance from the table [it feels like it should be raised to the power four or something, but I couldn't tell you why immediately] away from the table, and apply gravity in the other direction. With some adjustment of the constants, you'll end up with a happy equilibrium where it sits just above the table. That'll allow you to do things like "throw" the puck onto the table to start the match/point, and watch it gently hover into place, with a little visible bouncing as it gets into place.
You probably also would want to damp the body a little bit since you're not playing in a vacuum; add a force that's a small multiplier [between -1 and 0, try -0.1] times the velocity of the object, to the shape.
Adding a dampener would also serve to remove energy from the system, otherwise every time you hit the object with a paddle, you're pretty much just adding energy. The system isn't actually closed [your paddles will be eating some energy for practical purposes], but...
When I'm playing air hocky, I like to let the puck slow down a little on its own sometimes if it's just kinda camping at my end of the table.
Gary (-;
PS All of this is written as someone who'd want to model a realistic physics thing. In all odds, a mindless projectile in the plane of the table would probably work just as well for you :-)]. If an arkanoid/breakout getup is your eventual goal, just ignore everything I just said
10/12/2006 (12:41 pm)
In my mind rigidShape should do the job pretty well.Apply a force that's inversely proportional to the distance from the table [it feels like it should be raised to the power four or something, but I couldn't tell you why immediately] away from the table, and apply gravity in the other direction. With some adjustment of the constants, you'll end up with a happy equilibrium where it sits just above the table. That'll allow you to do things like "throw" the puck onto the table to start the match/point, and watch it gently hover into place, with a little visible bouncing as it gets into place.
You probably also would want to damp the body a little bit since you're not playing in a vacuum; add a force that's a small multiplier [between -1 and 0, try -0.1] times the velocity of the object, to the shape.
Adding a dampener would also serve to remove energy from the system, otherwise every time you hit the object with a paddle, you're pretty much just adding energy. The system isn't actually closed [your paddles will be eating some energy for practical purposes], but...
When I'm playing air hocky, I like to let the puck slow down a little on its own sometimes if it's just kinda camping at my end of the table.
Gary (-;
PS All of this is written as someone who'd want to model a realistic physics thing. In all odds, a mindless projectile in the plane of the table would probably work just as well for you :-)]. If an arkanoid/breakout getup is your eventual goal, just ignore everything I just said
#4
10/12/2006 (1:30 pm)
In practice, I've seen very few good games come from "realistic" physics. Honestly, beyond games that involved some manner of spheroids rolling around, I can't think of any. And for an air hocky puck, all you really need as far as gameplay is concerned, is linear motion and reflection with a low friction constant. I'd be especially wary of using rigidShape for something like air hockey, especially if you intend it to be (networked) multiplayer. High speeds and collision do not bode well for it. I would avoid using any actual poly-based collision detection, and do everything based off raycasts and radius searches. 
#5
you might be way ahead writing your own air-hockey puck physics
than trying to tweak one of these existing classes.
one note on Projectile,
we were recently using projectiles for beach balls,
and one problem is that the physics model in projectile is only modelling a point, not a volume.
that is, it's really just a speck bouncing around with a picture of an object around it.
so your puck will slide halfway into the walls.
We moved to RigidBody for the beach ball and it's worlds better.
10/12/2006 (1:52 pm)
Paul's point is good,you might be way ahead writing your own air-hockey puck physics
than trying to tweak one of these existing classes.
one note on Projectile,
we were recently using projectiles for beach balls,
and one problem is that the physics model in projectile is only modelling a point, not a volume.
that is, it's really just a speck bouncing around with a picture of an object around it.
so your puck will slide halfway into the walls.
We moved to RigidBody for the beach ball and it's worlds better.
#6
verlet integration looks promising. It is fast, and you can account for momentum by moving the old position to account for bouncing off of objects.
Edit:
Oh, but all the stuff that is available like collision and how to construct your object it excellent in the rigid body. Just the current implementation is not fast enough for me.
10/12/2006 (6:26 pm)
I would steer clear of rigid if you need more than a few objects. 6-7 objects took my framerates to < 5 fps. verlet integration looks promising. It is fast, and you can account for momentum by moving the old position to account for bouncing off of objects.
Edit:
Oh, but all the stuff that is available like collision and how to construct your object it excellent in the rigid body. Just the current implementation is not fast enough for me.
#7
10/14/2006 (7:04 am)
Did you find a solution?
#9
This all seems great and rigid body seems like my best bet, but the one resource I found gave me an error and I feel it may be a bit old. Can anyone point me to a working resource for adding rigid body physics?
10/16/2006 (4:47 pm)
Thanks,This all seems great and rigid body seems like my best bet, but the one resource I found gave me an error and I feel it may be a bit old. Can anyone point me to a working resource for adding rigid body physics?
#10
Gary (-;
10/16/2006 (5:23 pm)
RigidShape.cc in your TGE distribution. At least since the most recent version, it's included in the box :-)Gary (-;
#11
I think you will run into problems with rigid shapes.
I was thinking you could do all collision, movement etc with simple 2D physics calculations. For instance, bound the object to only move in the xy plane.
1 Place object some Z position above the table. You could even put a little bit of a slight bounce to the Z as if it is resting on air.
2 Do your own bounds checks with a simple box check to keep your object inside the table area. I think you could even rig it up initially in script.
3 The bouncing equations are just circular checks which would be very easy and more accurate than rigid. Rigid will only ever be an approximation of a circle.
10/16/2006 (9:58 pm)
Search for RigidShape.I think you will run into problems with rigid shapes.
I was thinking you could do all collision, movement etc with simple 2D physics calculations. For instance, bound the object to only move in the xy plane.
1 Place object some Z position above the table. You could even put a little bit of a slight bounce to the Z as if it is resting on air.
2 Do your own bounds checks with a simple box check to keep your object inside the table area. I think you could even rig it up initially in script.
3 The bouncing equations are just circular checks which would be very easy and more accurate than rigid. Rigid will only ever be an approximation of a circle.
#12
I know it is in my distribution, but what I want is a scriptable rigid body. Does anyone know where to find this?
At Frank:
My game will have some twists (such as puck being huge and players shooting at it to move it) and I need it to be 100% 3D.
10/17/2006 (12:49 pm)
At Gary:I know it is in my distribution, but what I want is a scriptable rigid body. Does anyone know where to find this?
At Frank:
My game will have some twists (such as puck being huge and players shooting at it to move it) and I need it to be 100% 3D.
#13
Gary (-;
10/17/2006 (2:06 pm)
What's a "scriptable" rigid body as opposed to any other sort? RigidShape has all the script accessors you'd expect...Gary (-;
#14
I never knew that, is there some resource or document I missed telling me how to add one through script?
10/19/2006 (3:10 am)
It does?I never knew that, is there some resource or document I missed telling me how to add one through script?
#15
Gary (-;
10/19/2006 (10:39 am)
The original RigidShape resource has an example datablock and script.Gary (-;
#17
10/20/2006 (9:01 am)
I've tried using rigidShape for a hockey puck. I found it to be rather unstable, but maybe i didn't tweak the properties correctly. Any suggestions of what values to plug into rigidShape to get a stable object that can sit still and also get slapped around at 90+ MPH? 
Torque Owner Berserk