Game Development Community

Physics question

by Mirko Topalski · in Torque Game Builder · 06/25/2009 (3:13 am) · 10 replies

I am moving my player with key arrows using setConstantForce() function. And it seams like:
setMass( 1 ); // this effects player movement
setInertialMoment( 10000 ); // have no effect at all
setDamping( 10 ); // this effects player movement
setDensity( 0.01 ); // this effects player movement (when using setAutoMassInertia(true) )
setFriction( 10000 ); // have no effect at all
setRestitution( 1 ); // have no effect at all (when using CLAMP )

My question is, does it really matter whether i will use setAutoMassInertia or not? Or it is just a choice whether i will set mass or density of an object? What if i use setAutoMassInertia(false) and set both mass and density - which one of these properties will be relevant?

And why some physics properties doesn't affect player movement at all?

#1
06/25/2009 (3:21 pm)
TGB can be confusing in terms of collision/physics because it doesn't just offer one. If you use the basic rigid-body collision response then every physics setting above is used. However, if you use basic movement (linear/angular velocity) but you use (say) the bounce-response then there are a number of those settings which are not used.

If you split-up the physics and the collision-detection, things become much clearer.

For physics, an object has position and size. It has both linear and angular velocity.

When you apply a force to change the linear velocity the thing that resists that change is the objects mass so increasing the mass reduces the effects of forces on the linear velocity.

When you apply a force to change the angular velocity the thing that resists that change is the inertial moment (moment of inertia) so increasing the inertial moment reduces the effects of forces on the angular velocity.

So Mass and inertial-moment are important to the physical movement of objects and you are free to set them directly for all of your objects however if you're interested in having objects move in ways approximately related to their size then you can get TGB to calculate both the Mass and inertial-moment for you. This is what the "setAutoMassInertia(true)" does.

To achieve this calculation however it needs to look at the area of the shape (this is a 2D world calculation so volume is out) but it also needs to take into account the objects density. It's only during this calculation that density is used, it's not used anywhere else. If you leave the density at default then all objects will have both their Mass and Inertial-moments set according to their areas alone. I chose a useful default for this as there's rarely a reason to change it.

The final setting that is used in physics is the damping. Damping is a kind of non-contact "air" friction you can apply to an object. It reduces both the linear and angular velocity by scaling both values by the damping value so 0.5 will result in half the linear and angular velocity in 1 second. Damping will never really reach zero, that's where the minimum linear and angular velocity can be used to clamp them at zero when a reasonbly close zero value has been reached.

Finally then we're on to collision-detection or what is known as the contact-physics settings. These settings relate to the body itself and its "surfaces". Friction (technically kinetic or dynamic friction) is one of them and is similar to damping but whereas damping only applies to the linear/angular velocity when non contact is made (like air friction), friction is used when the object is in contact with another surface. The value here is a coefficient and is used exactly like the real coefficient of (dynamic) friction. If the friction is 1.0 then the surface resists all the force of contact so it seems "rough" whereas a value of "0.1" would only resist a small proportion of the force and would seem "slippy". A value of zero effectively turns off friction.

Restitution is another coefficient which describes the ratio of velocities after a collision. A restitution of 1 is a fully elastic collision (a perfect bounce) whereas a restitution of 0 is a fully inelastic collision (stops dead). It sort of describes how much energy is lost but in practical terms a value of 1 means the object doesn't loose any velocity. If you use a value greater than one then the object will actually speed up and gain magical energy from somewhere!

Both friction and restitution were designed for the rigid-body collision response only (remember, they are only used during collision-contact).

With that said, it was request a few years back that the bounce collision-response include restitution so I changed it to use that. Friction however is only used for the rigid-body response.

If the engine was a rigid-body engine only (like Box2D) then everything would be used all the time however it isn't. It's not so hard to remember though. Everything is used if you're using rigid-body. If you're using anything other than rigid-body then restitution/friction are not used with the single exception of the bounce-collision which does used restitution.

I hope that helps to clairfy things a little.



External Links:

Velocity
Mass
Density
Moment of Inertia
Coefficient of Restitution
Dynamic (Kinetic ) Friction
#2
06/26/2009 (2:08 am)
Whoooaaaa! Thanx man for this extensive explanation!

So, in plain words:
mass - resist the forces applied to an object
InertialMoment - used for rotation
density - used if u want to take into account actual size of the object
Damping - (invisibly) scaling world physics forces

I forgot to mention, i've set:
setCollisionPhysicsSend( TRUE );
setCollisionPhysicsReceive( FALSE );

So even if set PhysicsReceive to TRUE, friction and restitution will not be applied to an object until i use rigid-body.

Thnx again. I'll bookmark this explanation ;)

Edit: i have to corrrect you, but the TGB doesn't allow me to set Restitution to the value greater than 1. (since it may cause infinite bouncing on the screen) :)
#3
06/26/2009 (4:29 am)
Yes, the restitution greater-than one was just to clarify its meaning.

In terms of those methods, they just decide whether the physics is applied under those conditions, the physics/collision rules apply as described above. There's no special logic other than what I've already said. :)

If this is a useful thread then I might consider asking for it to be a sticky for this forum.
#4
06/26/2009 (6:35 am)
Well, you explained just about everything about physic-properties of objects. I dont know what else we can add here...

Exept maybe people's experience about physics, during their game developing.
#5
08/23/2010 (3:09 am)
Woo Hoo! Thanks guys. By the way is there an easy way to trigger spinning as my object bounces around such that more it's moving left or right, the faster the spin?

Also could you guys point me to any easy to follow tutorials for having the camera follow an object?
#6
01/30/2011 (6:56 pm)
Melv or anyone:

Ok, trying to follow this for physics, but in english, how would you make a ball drop such as a free falling pinball for a PB game? You can apply Send and recv physics, with Y as a force, but how do I get it to where I can hit it with a shooter like in pinball (see other pinball based threads for what I've found) and allow the ball to free fall with the built in physics TGB has currently? Very interesting read I might add. Thanks for any help guys.

I've got basic free falling from others here on the site, but it's not allowing me to do what i really need the ball to do, freely drop and when hit allow it to fly anywhere based on how its hit with the flipper or if its just shot and drops down hitting pegs on the way down like in Japan Pinball games. Thanks again for the help!!

Will
dlstorminc@yahoo.com

PS: My ball is flying around more like a space object floating rather then dropping like gravity has it. That is why I'm writing here. I keep playing with the Y and adding force to it but it doesn't feel like a normal ball dropping as in pinball..
#7
01/31/2011 (10:35 pm)
Give your ball an onUpdate() or onTick() or update() or whatever script function - something called every tick. In this function, simply perform a calculation for your 'gravity' and add this to the Y speed. You can use a simple +1 to Y speed per tick with a cap, or you can actually use 9.86m/sec^2 acceleration, or some variation of that. In fact, for pinball you'd want to use some factor to mitigate the actual gravity effect based on the incline of the pinball table. To make this even more realistic, you can apply a damper to your X speed while you're at it. Nothing too strong, you just want a natural-seeming arc so we want to simulate a little air friction.

As far as bouncing around, Melv already covered collision physics.
#8
03/30/2011 (7:05 am)
Hey Melv,

This is a great explanation, many thanks for the text!

Still, there is an issue I'd like to be sorted out. In platformers, we generally don't want to use rigid response on collisions and stick with clamp. It poses a small problem though -- when your object is situated on a slope, it starts sliding and continues to do so after going to a level terrain until it hits something. The desired behavior would be for the object to just stand still. Setting friction does not help, obviously.

If anyone has any thoughts on how this can be solved, please share!
#9
04/01/2011 (3:47 pm)
@Melv - Yes, Please sticky this! Your explanation answered a lot of questions I've had regarding Collision/Physics. Thank you!

#10
04/17/2011 (10:40 am)
As another poster mentioned pinball, I'm also attempting to hit a ball with a paddle as an exercise. When the paddle is still, the physics looks pretty good. However, when the paddle is rotating, it seems to either go through the ball, or the ball kind of "sticks" or jiggles on the paddle before heading off poorly.

I wonder if the paddle is moving too fast for the simulation? An angular "speed" of around 300-500 seems minimal to look like a pinball paddle. (I'm not sure what the units of angular velocity are.)

I'll write back if I figure out what is wrong. At this point, I've turned on all collision/physics send/receive etc to see what matters, but having no luck.