I am trying to create a crowd falling animation and found that baking it causes Blender to be in infinite “not responding” state. I’ve tried it with less characters before (15-20) and it was fine. Now with only 10 more (30 total) it never bakes. The thing is, caching and viewing the scene works fine, it just can’t bake it onto rigs for some reason.
Tried baking for 10 frames, 300 frames, 4/8 iterations - no difference at all.
Video is here (GDrive): https://drive.google.com/file/d/1NjdjvZ1wCuSqdlfX-js0mWES3jtwtFaT/view?usp=sharing
Hey @azkapper , welcome to the forum 
The recording is helpful 
That “not responding” is common when the program is busying which makes GUI unable to response. So that should not be a problem, just have to wait for it.
But for baking… How long did you wait for 20 characters?
Compare to Cache, there are way more things going on under the hood while baking so it is expected to take much longer time.
Tried baking for 10 frames, 300 frames, 4/8 iterations - no difference at all.
This might be a clue. The baking process might took a lot longer for preparation. E.g. generating temporary armature and bones before actual baking.
I will have some tests with manikins on my end, see if I can reproduce the problem.
Hi, thanks!
Baking 20 characters took around 5-7 minutes, but it was sort of responsive. The proccesing ended quite fast and animation transfer to rigs took longer. I was even using “Viewport Display”. But when I added another 10, it is just like this forever. Current try is over 1.5h now…
One thing though, my CPU is really not that powerfull. I will change my R5 3600 to R9 7950x next week, maybe this will help.
And another thing, while combining solvers i noticed the slowdown too, it was quite long, but not that long. I’ll probably leave baking proccess running over night to find out if it will bake at all.
Tested a little more, here are the results on my PC.
-
75 frames, 8 Iterations, 8 Substeps - Custom Character (x11)
Ragdoll: _bake in 13544.24ms (5 fps)
bpy.ops.ragdoll.record_simulation(auto_cache=False, update_viewport=True, always_invoke=True)
Finished in 176.27s
-
75 frames, 8 Iterations, 8 Substeps - Custom Character (x16)
Ragdoll: _bake in 22795.52ms (3 fps)
bpy.ops.ragdoll.record_simulation(auto_cache=False, update_viewport=True, always_invoke=True)
Finished in 301.57s
-
75 frames, 8 Iterations, 8 Substeps - Custom Character (x20)
Ragdoll: _bake in 37303.53ms (1 fps)
bpy.ops.ragdoll.record_simulation(auto_cache=False, update_viewport=True, always_invoke=True)
Finished in 596.26s
-
250 frames, 4 Iterations, 4 Substeps - Manikin (x13)
Ragdoll: _sim_to_cache in 14945.17ms (16 fps)
Ragdoll: _bake in 16463.46ms (15 fps)
bpy.ops.ragdoll.record_simulation(auto_cache=False, update_viewport=True, always_invoke=True)
Finished in 37.52s
-
75 frames, 4 Iterations, 4 Substeps - Manikin (x33)
Ragdoll: _bake in 16302.29ms (4 fps)
bpy.ops.ragdoll.record_simulation(auto_cache=False, update_viewport=True, always_invoke=True)
Finished in 209.77s
So I guess the problem is in 2 places. Even Ragdoll Core is strugling using 20+ of my characters, but then the proccess of retargeting animation back on rigs is even slower (because Blender only utilizes 1 core). I guess my character just has a complex ragdoll rig, maybe I should try to simplify it.
Also, I noticed that all the examples have their model split in pieces, but I did it the other way, model itself is one mesh and there is some custom collisions i got while cutting the copy and assigning as collision mesh. Maybe my approach is just wrong?
Hey @azkapper , thanks for the detailed feedback!
Really great that you have time cost messages included. I did some test recordings with 30 manikins and was able to find the root cause.
In short, after some investigation and tweaking, the recording time of 30 manikins has dropped from 100 seconds to just 20 seconds. 
We still need to do a few more tests before making another new release, but I think this improvment can be expected soon. And you don’t have to do any change to your rig.
Finally, about the model splitting, I think your approach is good. The example assets’ meshes were simply generated from exported marker mesh data just for visualisation.
1 Like
Thats great to hear!
Here’s another piece of information, while testing it on my end I stumbled upon another “optimization” of my scene:
I deleted every “Environment” marker and added default markers to my scene meshes (set to “animated” to have them in place). And it worked like a charm, same complex rig, new results:
-
100 frames, 5 Iterations, 5 Substeps - Custom Character (22 characters)
Ragdoll: _sim_to_cache in 18358.78ms (5 fps)
Ragdoll: _bake in 28601.56ms (3 fps)
bpy.ops.ragdoll.record_simulation(auto_cache=False, update_viewport=True, always_invoke=True)
Finished in 58.90s
-
100 frames, 5 Iterations, 5 Substeps - Custom Character (44 characters)
Ragdoll: _sim_to_cache in 36380.47ms (2 fps)
Ragdoll: _bake in 57712.67ms (1 fps)
bpy.ops.ragdoll.record_simulation(auto_cache=False, update_viewport=True, always_invoke=True)
Finished in 168.70s
First of all, Viewport actually showed what was happening and overall waiting time is much shorter. Second of all, caching in Viewport was very fast. Not sure if it is expected behaviour or not, but it might be something.
Hi @azkapper ,
I deleted every “Environment” marker and added default markers to my scene meshes (set to “animated” to have them in place).
Hm, that’s interesting. In your video I did see that each fence mesh was a single rdEnvironment
, but not sure how much. After you deleted all rdEnvironment
, did you merge those fence into one single mesh then assign marker to it? Or not merged, just re-assign each fence with markers? I am curious how the performance was improved without any modification on the rig. Would be great if you can share a bit more details about that “environment-to-marker” process, and how many fence mesh were there. 
Next! Here is a new release. This should work in your original scene too (the one that has lots of Ragdoll environments). Please have a try and see if it makes your recording much faster. 
You won’t have to update Ragdoll Core, just update the Blender addon. Thanks!
1 Like
Hi, sorry for the late reply, after re-testing latest patch multiple times I’ve got to say that it’s simply incredible!
Performance is much better. I am getting bake times cut from 120-140s down to 18-20s with 33+ characters. Thank you so much!!! You are building such a great tool for animation in Blender.
The thing about Environment markers is basically a coincidence, it happens that at the same time i just made my ragdoll rig ligther (less vertices), so yeah, it’s nothing to worry about.
1 Like