AddForce Gravity

[Overhertz]

I'm having some issues with gravity in the addforcetorque callback.

I set gravity via -9.8 * mass and then call NewtonBodyAddForce, however no matter what i set the mass as, all objects fall at the same speed, if i remove mass from the equation then the lighter objects fall faster, what's up with this? any ideas?

Thanks

[Julio Jerez]

if two objects has the same gravity, they fall at the same rate, regarless of the mass.

[Overhertz]

Yes sorry i did not explain very good

so box 1 mass = 1
box 2 mass = 10

in the callback i set gravity to -9.8 * mass, but both boxes fall at the same speed.

[Julio Jerez]

yes this is correct, that was Gallileo experiment.

Galileo's "falling bodies" experiment re-created at Pisa

[Sweenie]

Yep.
Newton doesn't simulate wind resistance(drag) by default so all bodies falls like in perfect vacuum.
Also keep everything in correct scale.
Some people create a cube several meters in size and expect it to tumble around like a dice and wonders why it
moves in slowmotion.

[Overhertz]

but you don't quite understand..... lol

mass of box 1 is 0.1
mass of box 2 is 1.0

gravity on box 1 is 0.98 on each callback
gravity on box 2 is 9.80 on each callback....


both boxes fall at the same speed. (both boxes are the same dimension - they should definitely fall at a different speed, the heavier box should hit down first)

Edit: I was trying this problem in a delphi app, and had issues, For anyone else having a similar problem, I solved by the following:

changing

Code: Select all

Force[1] := -9.8*mass;

to

Code: Select all

Force[1] := -(9.8+mass*mass);

now the objects fall at a different speed, and look correct

[Sweenie]

But they shouldn't fall a different speed.
It doesn't matter if they have different mass, the acceleration towards earth remain the same, -9.8 m/s
Actually heavier objects should fall slightly faster towards earth as it would pull the earth to itself aswell. But that is almost unmeasurable unless the body is of planetary size.

Check this for example...
http://www.youtube.com/watch?v=_XJcZ-KoL9o

The second experiment in that clip would be how a physics simulaton in Newton would be like.
In the first experiment it's the atmosphere and air resistance that causes the feather to fall slower.

[Overhertz]

So no other factors are taken into account? Then how would i go about taking some kind of resistance into account?

Since a box full of books against an empty box will not fall at the same speed, simply because of resistance, so to leave them both to fall at the same speed looks very unrealistic.

I guess i can do this very easy in the callback, if there is a way to get the total length a body is along the current directional opposing direction ( can i do this with NewtonCollisionCalculateAABB do you think? ), i could do some calculations to add a small up-force to simulate resistance, based on xy dimensions and mass.

[Sweenie]

Well it depends on how real you want it to be.
The best would be to calculate drag based on the objects surface area but that can be quite complex depending on how realistic you want it.
If you are doing "simple" game physics I think it's ok to cheat a bit and simply apply more gravity to heavier objects as long the results looks ok. The player would never know.
One approach could be to have some kind of drag constant that could be low for round objects and higher for more flat objects. That would make the drag calculation a bit more lightweight and an easy way to manipulate the objects fall speed.

[Overhertz]

That would be fine, i just want to have semi good looking game physics, however if i apply higher gravity for falling objects this would probably not work good since the resistance is only due to movement, the velocity of the object, so it would depend also on the direction, for example a ball being kicked up into the sky would have resistance opposing its direction, so i would need to be able to get the dimensions of the object in the opposing direction of velocity.

[JoeJ]

I've never tried out, but what i've planned to approximate this is:
Precompute air-resistance values along each axis for the object (for example by ray tracing against the object to find approx. aera on each plane).
At runtime, dot the velocity with the object axis to find the current air resistance:
curRes =
fabs(dot(v,xaxis)) * precResistX +
fabs(dot(v,yaxis)) * precResistY +
fabs(dot(v,zaxis)) * precResistZ;

[Overhertz]

looks interesting, what is your xaxim, yaxim and so on?

[JoeJ]

xaxis is the objects x axis vector in world space.
Maybe it's easier to understand if done in object space:

vec velWS = NewtonBodyGetVelocity (body);
matrix = NewtonBodyGetMatrix (body);

// velWS -= noise4D (matrix.pos.x, matrix.pos.y, matrix.pos.z, time); // optional small random pseudo wind

vec velLS = matrix.unrotate(velWS); // rotate velocity to object space (which does the dot products from previous post for us)
float curAirRes =
fabs(velLS.x) * precResistX +
fabs(velLS.y) * precResistY +
fabs(velLS.z) * precResistZ; // now everything as seen from bodies orientation, it get's simpler

So, if a object is moving exactly along it's local y axis, only it's precResistY-value will give its current air resistance.
Otherwise a useful approximisation will be interpolated.
As with the inertia matrix, it's important that the object is well orienatetd in the coordinate system.
For example, if you model a pencil rotated 45 degrees somehow, you'll get bad inertia and bad air resitance, leading to unnatural looking simulation behaviour.
But if you model it nicely aligned to one principial axis, both will be good.
Usually any modeller will choose good alignment automatically, so no need to worry about that.

the typical modellers 3d software views (top, left, front, perspective) give also a good example for the precomputation step:
if object is at the same scale in all views, you can do (if y is up):
precResistX = number of pixels occupied by object in left viewport (yz plane)
precResistY = number of pixels occupied by object in top viewport (zx plane)
precResistZ = number of pixels occupied by object in front viewport (xy plane)