Hey all,
I'm using rigid bodies to run a ragdoll simulation for a hockey game.
When the bodies are in "ragdoll" mode, the rigid bodies drive the character bones. Most of the time, the rigid bodies are flagged as kinematic and the position is set from the graphics every frame.
Even when none of the characters are in ragdoll mode, the physics engine is using up most of the processor utilization. I have about 150 rigid bodies which are all flagged as kinematic and I'm trying to run at 600 hz. (1/600 timesteps). I know that this is a really small timestep, but the puck moves very fast with a slap shot and I wanted to represent it accurately. Also, I have deactivation disabled on all of the bodies (because the ragdolls are changed back to kinematic cahracter animation before the bodies would go to sleep anyways)
I'm just confused as to why it's using a lot of the processor when there aren't any non-kinematic rigid bodies. Is there any way to optimize against this? I'm using kinematic bodies because I want the puck to bounce correctly off of the goalie and players when it hits them, but I guess I could just use a cylinder for each non-ragdoll character if I have to.
I was just wondering if there's some optimization I can do here?
Performance problem with many kinematic bodies
-
- Posts: 25
- Joined: Thu Dec 20, 2007 4:03 am
-
- Posts: 133
- Joined: Wed Jul 27, 2005 1:05 pm
- Location: Berkeley, CA
Re: Performance problem with many kinematic bodies
Can you provide a small test program that shows the poor performance? We can optimize Bullet based on that.
-
- Posts: 25
- Joined: Thu Dec 20, 2007 4:03 am
Re: Performance problem with many kinematic bodies
I did some research into it and here's what I found out:John McCutchan wrote:Can you provide a small test program that shows the poor performance? We can optimize Bullet based on that.
It still takes time to process constraints between two kinematic/static bodies. To optimize this, the bullet library could check for constraints that join two non-dynamic bodies and put them in a separate list that does not get processed.
I emulated this idea by removing constraints between kinematic/static bodies by hand as they change to kinematic and adding them back when the bodies change to dynamic. This gave me a pretty big speedup.