Real-Time Physics Simulation Forum

I've got the following problem:
In my application, which uses Bullet Physics, the "speed" of the simulation varies over time, which results in objects sometimes moving slower or faster and sometimes even jittering randomly.

Here's a small video of it: https://www.youtube.com/watch?v=5wXpZUOIdYE (switch to 720p to get 60 FPS footage, otherwise the jitter is less noticeable)
At first, it runs like normal. Then it gets slower and from 0:25 on, you can really see the object jumping around.
In this demo, There is a rigid body with an empty collision shape with a mass of 0.0 aligned with the player. When the cup is being clicked, a fixed constraint between the cups rigid body and the empty one is being created.

But I remember having this issue in other situations some time ago as well, e.g. when just throwing a couple of dynamic objects into the scene.

This is how I call stepSimulation: time is usually something between 0.016 and 0.017 as it is running at constand 60Hz limited by VSync.

I can't really imagine what could cause such behavior...

Thanks in advance!

I don't have much experience about moving step simulation time but make sure you check the "time" value to make sure your not getting it crazy values every once in a while.

It is unclear to us why your simulation would start to run slow. You'll just have to profile your program.

Bullet comes with a profiling framework: look for CProfileManager in the Demo code. You when it starts running slow you should dump that profile info and examine where the time is being spent. If the Bullet simulation is running on the main thread then your other code is also suspect and you may have to profile that too.

johnsonalpha wrote:I don't have much experience about moving step simulation time but make sure you check the "time" value to make sure your not getting it crazy values every once in a while.

The time value is ok, I tested it with a fixed value of 0.017 while the program is running at fixed 60 FPS and still have the issue.

drleviathan wrote:It is unclear to us why your simulation would start to run slow. You'll just have to profile your program.

Bullet comes with a profiling framework: look for CProfileManager in the Demo code. You when it starts running slow you should dump that profile info and examine where the time is being spent. If the Bullet simulation is running on the main thread then your other code is also suspect and you may have to profile that too.

The speed of the program itself is totally fine. It just looks like the objects' velocities are varying.

Unfortunately, I still was not able to solve this.

I have just switched my time measurement from SDL_GetTicks to C++11's chrono, which now give me more precise values for the time step, but that did not fix it.

Any ideas where the problem might be?

Could it be that your simulation has strongly varying load and therefore sometimes the speed of your simulation varies basically because the load is too high to be simulated at the same speed? In other words, you might not be able to simulate a single box at the same speed as 100k boxes for performance reasons.

benelot wrote:Could it be that your simulation has strongly varying load and therefore sometimes the speed of your simulation varies basically because the load is too high to be simulated at the same speed? In other words, you might not be able to simulate a single box at the same speed as 100k boxes for performance reasons.

Well, I do have lots of Rigid Bodies with Mesh shapes in the scene, but I don't think it is a performance issue as the time the simulation takes is fine.
Plus, when really adding way too many rigid bodies until it actually takes longer to simulate, the stuttering caused by this is completely independent from the "speed issue".

To make the problem more clear, heres another video that shows it better: https://www.youtube.com/watch?v=DmB5h6_NC4U (60FPS recommended)
At the beginnning, you can see the boxes moving very slowly, then going nuts while the program runs smoothly.

I finally was able to fix it.

The problem was a custom btMotionState subclass I am using to keep the transforms of my rigid bodies in sync with the objects inside my rendering engine.

Basically, setWorldTransform of this Motion State called another method that updated the transform of my own object, but this method then called setWorldTransform on the rigid body itself again, which probably caused more or less an infinite loop that lead to this strange behaviour.