btMultiBody instability (character shoots up into the air)
Posted: Tue Nov 18, 2014 2:53 am
I'm trying to make a sports game with physically simulated characters. I created a torso (still missing arms and head) using btMultiBody, ran the simulation, and watched the btMultiBody crumple to the ground as expected. I then wrote a for loop to easily clone this btMultiBody, and position the clone at an offset so I can observe them all crumple to the ground. This works nicely, however some of the btMultiBody instances are unstable as I increase the total number of them in the simulation. I have created 22 of them because that is the number I will need simulated in my game. When some of the multibodies fall to the ground, they shoot upward into the air and fly throughout the void indefinitely (they don't just shoot up into the air and fall back down, they fly throughout, twisting and spinning violently).
I have observed this behavior with a fixed timestep of 8 ms. I have noticed that different timesteps (both larger and smaller) and different numbers of btMultiBody will produce different results, namely, the multibodies that shoot upwards into the air differ with different setups. I am curious as to why different timesteps produce different results, because I thought smaller timesteps was needed mainly to avoid tunneling, but I see none of that here (see my videos at the end of the post).
I am using bullet.git dc731280b865317d0df66da64ab292bfbb341c32 (the most recent revision in GitHub at the time of this post) on OS X 10.9. I tried both single and double precision builds of Bullet, but it makes no difference.
With 22 btMultiBody and a timestep of 700 microseconds, none of the btMultiBody instances shoot up into the air, which is good. I'm hoping that with some improvements to Bullet's Featherstone implementation, I won't need such a small timestep, but I'm also hoping that when Bullet 3.0 is released I'll be able to run this realtime on the GPU, even if it means getting a $500 video card.
So is this simply a bug due to the early work in progress Featherstone implementation? Or is this something that I will have to just figure out a way to deal with? Currently it seems my only solution is to use very small timesteps until the simulation is stable.
Here are some videos to demonstrate. In one video, I run the simulation realtime, and in the other video, I run the same simulation one time step at a time so you can see what happens.
http://youtu.be/YKjdF9K3we0
http://youtu.be/m6Q2pahcvNA
P.S. I should also note that I tried the same simulation using the Simbody library. I had no stability problems at all with 22 characters, however the only thing stopping me from using Simbody is I don't see any work towards a simulation that runs 100% on the GPU, which is my only chance of getting this project to work real time.
P.P.S. The mass of each link in the btMultiBody is 1. The size of the btMultiBody is approximately the same as a human.
I have observed this behavior with a fixed timestep of 8 ms. I have noticed that different timesteps (both larger and smaller) and different numbers of btMultiBody will produce different results, namely, the multibodies that shoot upwards into the air differ with different setups. I am curious as to why different timesteps produce different results, because I thought smaller timesteps was needed mainly to avoid tunneling, but I see none of that here (see my videos at the end of the post).
I am using bullet.git dc731280b865317d0df66da64ab292bfbb341c32 (the most recent revision in GitHub at the time of this post) on OS X 10.9. I tried both single and double precision builds of Bullet, but it makes no difference.
With 22 btMultiBody and a timestep of 700 microseconds, none of the btMultiBody instances shoot up into the air, which is good. I'm hoping that with some improvements to Bullet's Featherstone implementation, I won't need such a small timestep, but I'm also hoping that when Bullet 3.0 is released I'll be able to run this realtime on the GPU, even if it means getting a $500 video card.
So is this simply a bug due to the early work in progress Featherstone implementation? Or is this something that I will have to just figure out a way to deal with? Currently it seems my only solution is to use very small timesteps until the simulation is stable.
Here are some videos to demonstrate. In one video, I run the simulation realtime, and in the other video, I run the same simulation one time step at a time so you can see what happens.
http://youtu.be/YKjdF9K3we0
http://youtu.be/m6Q2pahcvNA
P.S. I should also note that I tried the same simulation using the Simbody library. I had no stability problems at all with 22 characters, however the only thing stopping me from using Simbody is I don't see any work towards a simulation that runs 100% on the GPU, which is my only chance of getting this project to work real time.
P.P.S. The mass of each link in the btMultiBody is 1. The size of the btMultiBody is approximately the same as a human.