Problem When Increasing Gravity

[RobW]

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

Well, I'm a reasonable person, so I tried your suggestions. Now I'm reporting back the results. Let’s just say, it wasn't good. Massive instability, the stack falls down immediately, everything jitters about, and most of the objects fall through the ground. It would take me 10 minutes to post up a video for everyone's enjoyment, if you would like that, Steven?

Do you really think that sparkprime and I registered months ago (me in February, sparkprime in May) and operated under separate names, for all this time, just in preparation for the day that you find your way to this forum?

I'd like to contribute some serious suggestions, but I'll PM Spuddy since this isn't the place for a constructive conversation, it's just a shame that others will miss out.

edit: To be clear, I tested the suggestions with AND without the gravity change. The latter just made no difference to the original problem, as I would expect.

[Erwin Coumans]

Please stop heating this flamewar, steven.hutheir, Spuddy.

When using stronger gravity and you face jitter/instability, you can try subdividing the timestep further, by using a smaller internal substep. This is the 3rd argument to stepSimulation, for example 240 hertz instead of the default 60 hertz:

Code: Select all

stepSimulation(dt,100,1./240.)

Indeed, when using a different scale for the objects/collision shapes (centimeter instead of meter), you have to use a matching scale for gravity too.
Hope this helps,
Erwin

[Spuddy]

Hi RobW- thanks for taking time to reply and to try out a few things. I'm going to follow your links now and try out some of your suggestions. We've already wasted enough time trying to explain to steven.huthier why I want to increase gravity and he just wants to argue why it doesn't need to be done so I think it's best to just ignore him. If he thinks anyone would spend time posting messages to a forum and then replying to themselves is obiously a little detached from reality, so for the benefit of myself and everyone else reading, please keep posting anything you find and we'll just ignore his posts unless he has a useful suggestion. Thanks !

[Erwin Coumans]

You can also consider discussing this on IRC, any freenode server channel #bulletphysics

Spuddy, can you try this, and report if the stability improves?

Code: Select all

stepSimulation(dt,100,1./240.)

Thanks,
Erwin

[steven.hutheir]

Indeed, when using a different scale for the objects/collision shapes (centimeter instead of meter), you have to use a matching scale for gravity too.

Can you please explain in what relation is size and gravity?


Thank you.

[Spuddy]

Erwin - I'm using the BasicDemo.cpp as my test bed and the only line I've changed from the zipped up files on this site in order to force the jiggling behaviour is:

Code: Select all

m_dynamicsWorld->setGravity(btVector3(0,-10,0));  to ....
m_dynamicsWorld->setGravity(btVector3(0,-980,0));

The BasicDemo.cpp uses stepSimulation in the following manner:

Code: Select all

float ms = getDeltaTimeMicroseconds();
m_dynamicsWorld->stepSimulation(ms / 1000000.f);

so, using your suggestion to try stepSimulation(dt,100,1./240.), I changed the above code to:

Code: Select all

m_dynamicsWorld->stepSimulation(ms / 1000000.f, 10 , btScalar(1.)/btScalar(240.));

and that helps - there's still a very tiny bit of jiggling on some cubes but definitely improved. However, the frame rate is so slow using a MaxSubSteps with 10 that it's probably not practical. With MaxSubSteps of 100 as you suggested then the frame rate is completely killed - like the cubes just end up in their final positions with nothing in between. It looks like it's updating at around 1 frame every second. I was hoping there would be a better solution to this than running the physics a ton of times in smaller time slices. Any other suggestions ? Thanks !

[steven.hutheir]

There are two problems,

1.)

Code: Select all

stepSimulation(dt, 0) 

will solve moon-like slow downs, if not your computer is simply too slow.


2.)
Everyone should understand that 3m ball will fall with the same speed/acceleration as 15cm ball (no air friction), and so the normal sized, real life pool table will play just as same as 10x enlarged. Of course, mass should stay the same as in real life pool table.

You should not increase gravity if you need to change the size of the balls.

What physics equation has both gravity and size?

[John McCutchan]

Hi,

Just to summarize:

By default, Bullet assumes that 1.0 float == 1.0 meters thus gravity of 9.8 m/s/s is represented as 9.8 float. If you are scaling your objects / world, please follow the suggestions found here: Scaling The World.

The jiggling you are experiencing is related to penetration and can be solved by shortening the time delta between physics simulation steps or, optimally, by using continuous collision detection (not currently complete in Bullet.) This is something that is very high on TODO list and can be expected in a future release.

Hope this helps,
John

[chunky]

1.)

Code: Select all

stepSimulation(dt, 0)

will solve moon-like slow downs, if not your computer is simply too slow.

I would urge you not to use this, and instead stick with erwin's suggestion of stepSimulation(dt, 100, btScalar(1.0)/btScalar(240.0))

Code: Select all

m_dynamicsWorld->stepSimulation(ms / 1000000.f, 10 , btScalar(1.)/btScalar(240.));

Well. Assuming that you have "ms" as milliseconds, then dividing it by one million will in fact mean you're passing kiloseconds as the first parameter, which will break horribly. Try changing that 1e6f to 1e3f and see what happens?

Gary (-;

[Spuddy]

the ms is in microseconds not milliseconds. I took it straight from the Bullet demo code:

Code: Select all

float ms = getDeltaTimeMicroseconds();

so dividing by 1000000 should be correct. The conclusion I've come to from this thread is that increasing the step frequency is the only real way round the jiggling problem so I'll try it out in my game code and hope the frame rate is okay when running the physics code four times more frequently at 240 hz. I'll keep my fingers crossed for the continuous collision detection soon. Anyone got an ETA on that ? Cheers !

[jolgeirr]

Indeed, when using a different scale for the objects/collision shapes (centimeter instead of meter), you have to use a matching scale for gravity too.

Can you please explain in what relation is size and gravity?

Thank you.

it's not about size, it's about scale and units.

if he chooses centimeters as his unit instead of meters, he will need to scale everything to be centimeters.
his 0.03 meters-radius ball will become a 3 centimeter ball.
his 9.81 m.s-2 gravity vector will become 981.0 cm.s-2.

the size stays the same, the gravity stays the same. he only remaps the values to a different unit.