Problem When Increasing Gravity

[Spuddy]

I'm writing a game and am looking for a physics engine. Bullet looks impressive but the object range of 0.2 to 5 units is a problem because my objects are outside that range if I work in meters. "Easy enough", I hear you cry, "just use different units". Well that sounds easy enough in theory. If I just multiply all my object units by 50 to get them into to 0.2 to 5 unit range then no problem there. However, to make my objects move realistically, I would have to multiply gravity by 50 too and that's where the problem lies. When I use a larger gravity in Bullet, the objects never seem to come to rest properly. They jiggle around on the surface they're landing on. I have an easy way for you to see this in action .....

Just build the BasicDemo from the standard Bullet demos and change line 99 in BasicDemo.cpp from:

m_dynamicsWorld->setGravity(btVector(0,-10,0)); to:
m_dynamicsWorld->setGravity(btVector(0,-500,0));

You'll see that the blocks fall more realistically instead of falling in slow motion due to their huge size, but then they jiggle on the collision surface and never really come to rest properly.

Can anyone advise me on what I need to change to fix this if I use large values for gravity ? It seems like all the demos run in slow motion because of this 0.2 to 5 unit range limit.

Thanks !!

[steven.hutheir]

If I just multiply all my object units by 50 to get them into to 0.2 to 5 unit range then no problem there. However, to make my objects move realistically, I would have to multiply gravity by 50 too and that's where the problem lies.

Why do you think that you would need to increase gravity?


When Appolo 15 astronaut Dave Scott let go of the feather and hammer they fell down with about the same speed and touched the Moon surface about the same time.

Feather & Hammer Drop on Moon:
http://www.youtube.com/watch?v=5C5_dOEyAfk


Size does not matter, mass matters but you can leave the mass out too if your objects are smaller than mountain i suppose. With all that said, gravity is actually pretty much unexplained really.

[sparkprime]

spuddy: you will have to increase the simulation frequency I think. Bullet works best if the bodies only penetrate a small percentage of their overall size each internal simulation step. In my experience of simulating bodies on a personal scale (i.e. <1m in earth gravity) 60hz has been far too small.

You could also try some of things I tried here: http://www.bulletphysics.com/Bullet/php ... f=9&t=2535

Depending on the size of the jitters, you may just need to increase the sleep thresholds by the same factor (50)

Using a restitution of 0 may give you more stable results.

Ignore steven.hutheir; he seems to have not understood the question.

This might be interesting if you haven't already seen it: http://www.bulletphysics.com/mediawiki- ... _The_World

[steven.hutheir]

Ignore steven.hutheir; he seems to have not understood the question.

Exscuse me? Can you explain your statement?

you will have to increase the simulation frequency I think

I'm afraid that it is you who does not understand. On the contrary, he needs to *decrease* simulation frequency, i.e. to increase fixedTimeStep. Practically, change your stepSimulation() call to one of these:

1.) stepSimulation(dt, 100, 1.0f/30);
2.) stepSimulation(dt, 100, 1.0f/10);
3.) stepSimulation(dt, 0);


Please report the results so that everyone can learn from their mistakes.


Thank you,
Steven

[RobW]

Ok, I'll give a concrete example of why you *do* need to increase gravity, real simple.

Imagine a game of football, now lets say the players are roughly 2 metres tall, the ball is roughly 30cm in diameter, and when the goalie kicks the ball in the air it goes about 5 times the height of the players, i.e. to 10m in the air. We have an intuitive sense of roughly how long the ball will take to fall to the ground from this height, about a second or two.

Ignoring all but the most basic forces, and using Netwon's laws, the physics of the ball are as follows: Lets say gravity is 10m/s/s

acceleration = force/mass
force = mass * gravity
so,
acceleration = gravity
velocity = gravity * time
displacement = 1/2*gravity*time*time

in this case, the displacement is 10m (assuming the bottom of the ball is at this height, not the centre), and we want to know how long it will take for the ball to hit the ground. So we rearrange the formula above:

time = sqrt( 2 * displacement / gravity )

so time = sqrt( 2 * 10 / 10 ) = sqrt(2) ~ 1.4 seconds.

Now, lets say the problem is that a ball of 15cm radius is considered too small for the simulation, and we scale everything up 10 times. The ball is 3m in diameter, the players are now 20m tall, and to keep everything relatively correct, the keeper kicks the ball 100m in the air.

If gravity is still 10m/s/s, then

time = sqrt( 2 * 100 / 10 ) = sqrt(20) ~ 4.5 seconds.

So the ball takes 4.5 seconds to hit the ground, which given out intuitive idea about how long it takes, now seems really slow, hence the slow motion effect. If you increase gravity to 100m/s/s then we get back to ~1.4 seconds, as we would expect.

It certainly is the case that there are a few constants in Bullet which are tuned for a certain object size, the contact breaking threshold being the main one. That is easy to fix. Beyond that, I don't think all the discussion about scaling objects up to fix problems is very helpful and is simply masking the issue which is that making objects bigger reduces the amount of penetration relative to the size of objects, due to gravity, in a single timestep. Shallow penetrations are easy to resolve nicely.

Of course, if you have tiny, or absolutely massive objects then floating point accuracy is going to start being an issue, but I doubt it in the range of sizes being discussed.

The real issue is one of continuous collision detection/physics, but it is more complex for objects in constant contact with each other (like a rolling snooker ball), because I think most people would agree that you would need to be careful about constantly generating small toi events especially if you only solve time of impact globally. The simplest solution is to decrease the step size. A better solution is to perhaps solve local toi's (which is equivalent really to ticking some objects at a higher frequency than others, in the rolling case), or have some sort of 'hack' to reduce gravity on a single object once it is resting on a surface perpendicular(ish) to the direction of gravity.

[steven.hutheir]

Ok, I'll give a concrete example of why you *do* need to increase gravity, real simple.

I simply can't believe what is going on?
How do you two find appropriate to be giving any advice if you do not know basics of Physics?


RobW,
You simply must be wrong,
because if you measure gravity anywhere on the Earth surface you will read around ~9.8. Maybe if you simulate 'Black Hole', then you would have increase in gravity, according to popular theories. I don't even dare to read how you managed to "explain" your statement, its just wrong to begin with.

Hopefully, someone will come along and clear it up. I will happily admit if im wrong.


Steven

[RobW]

How is anyone going to clear it up when you won't read a concrete example?

Go on, give it a try

And of course, I'll happily admit if I'm wrong.

[steven.hutheir]

Huh?

- because if you measure gravity anywhere on the Earth surface you will read around ~9.8

This is going to be very silly discussion if you are unable to understand that, in computer simulation, we are trying to "imitate" the above fact - meaning, we actually want gravity to be constant, just as it is in a real life, ok?

[RobW]

How is anyone going to clear it up when you won't read a concrete example?

You haven't answered my question.

Nor have you refuted my example.

Surely you can take a little time out from being a general physics genius to point out my mistake?

[steven.hutheir]

Surely you can take a little time out from being a general physics genius to point out my mistake?

I do have time because i find it amusing. Basically, you only have to read my 1st message, at least once. Anyway, here we go again - look at the last sentence starting with "because", its a 3rd time now.. told you its gonna be silly.

- because if you measure gravity anywhere on the Earth surface you will read around ~9.8

[RobW]

Yeah, gravity measured near the earth's surface is ~9.81 ms/s/s, well done, but that was never in question.

This is the situation that we are actually talking about.

Spuddy is making a game where the objects are small in metre units. Let’s pretend it's a pool game.
A pool ball is about 0.05m in radius. Gravity is ~9.81m/s/s, as you're so keen to point out.
0.05 is less than 0.2, the recommended minimum size for objects, and he observes various problems like jiggling.
So Spuddy tries scaling his world up to get the pool ball within the recommended range of sizes.
This fixes the jiggling, but unfortunately, the result he sees is that the balls seem to fall in slow motion.
He thinks that he would need to scale up gravity in the same way to make the falling seem correct.

You don't think that is necessary.

I give a concrete example to show why it is necessary, and comment that scaling isn't really solving anything, and
we should tackle this problem (jiggling etc) in a completely different way.

You can't show that my example is wrong, so instead you iterate the same irrelevant fact over and over again.

[steven.hutheir]

Nonsense, are you actually the same person as "sparkprime"?


There should be age limit or something. Are you not aware how much time you can waste by giving a bad advice? I hope you're not doing this on purpose or as some kind of a bad joke.

Is this a joke?

.

[Spuddy]

Steven - You said that if you measure gravity anywhere on the Earth's surface then it will read around 9.8 .... but 9.8 what ? 9.8 donkeys ? You forgot your units which in the case of gravity are meters per second per second ..... 9.8 m/s2. Now I'm quite happy to work in meters but the objects I'm using are 3cm in diameter, so 0.03m. If I create objects in Bullet that are 0.03m in diameter then they jiggle about when they try to come to rest on a surface, I assume this is because the docs say that dynamic objects need to be in the range 0.2 to 5 units for the best accuracy. I say "units" this time around because Bullet leaves the units up to the user, but by using a gravity value of 9.8 then you are actually defining the unit of length as meters. In order to get my objects into Bullet's 0.2 to 5 size unit range then I have to use units of centimeters (or similar), which as I said is 3cm, sitting nicely in the middle of that 0.2 to 5 range. However, if I change my units of length to cm then I can't use a value of 9.8 m/s2 for gravity. I have to convert gravity to cm/s2 which is 980 not 9.8 and using a higher value for gravity also causes the jiggling problem in Bullet that I would like to find a fix for. If you scale up the size of small objects and leave gravity in the wrong units of 9.8 then the objects end up looking like they're on the moon, floating to earth instead of falling quickly which is what all the demos seem to suffer from. My objects are 3cm in diameter not 300cm.

I'm trying to model a real life situation in real time. This means I want to plug in the actual dimensions and masses of my objects, apply realistic forces to them and have them behave the way they would in real life and look realistic. Right now, Bullet is preventing me from doing this and I'd like to find a fix for it. All the demos look like they're running in slow motion on the moon. They don't look realistic. If you can't see this and acknowledge it then I'd prefer that you didn't reply to this thread as I'd like to find a solution, not argue with you over my requirements. The replies from RobW are much more helpful to me than yours and you're actually starting to sound like a bit of an idiot. Thanks !

[steven.hutheir]

..you're actually starting to sound like a bit of an idiot.

That's not very nice thing to say.
You did not mention what were the results with:

Code: Select all

1.) stepSimulation(dt, 100, 1.0f/30);
2.) stepSimulation(dt, 100, 1.0f/10);
3.) stepSimulation(dt, 0);

So all 3 of you are actually one and the same person?
You pose question, then answer it yourself with another nick-name and got angry because someone interfered?

I don't see other explanation, it is impossible that three different persons would have this same understanding, especially if the one actually posed the original question, and then get angry for no apparent reason. Anyway, I have nothing more to say, except that I still hope someone more reasonable and more polite will come to clear this up.

[steven.hutheir]

If you can't see this and acknowledge it then I'd prefer that you didn't reply to this thread as I'd like to find a solution, not argue with you over my requirements.

You see, you say "not argue with you", but "Spuddy" we never had an argument - I only had an argument with your other two nick-names.

What is it you think you're doing?