Blender newbie here. I'm building some kind of "obstacle course" with soft bodies and rigid bodies in which a jelly ball falls down a ramp with a few obstacles. Problem is, just a frame of simulating the ball merely touching the ground takes about two minutes, in which the program freezes. I've been told it's due to lack of RAM memory, but, for example, when I simulate a soft body ball falling into a cube in a new project it calculates it almost instantly (I've got 8 GB of RAM, an Intel i5-4430 processor and no, the platform has not a lot of edges). How can this be? I'm sure people who do these kind of simulations with soft bodies don't have to leave their computer open for a week just to bake a simulation. Ground that the sphere collides with

Soft body specs

Any advice will be welcome. Thanks!

(File download HERE. Sorry for bad modelling and all that stuff, I'm still learning :c ).

Edit- some details as suggested by Rich Sedman.

  • $\begingroup$ Please elaborate on your set up - provide screenshots of your mesh, scene, soft body settings, etc. Most likely you have a large number of vertices on your soft body and/or self collision and/or edge and face collision. As it stands this question is likely to be closed as too generic or unclear what you’re asking. $\endgroup$ Jun 21, 2018 at 18:14
  • $\begingroup$ docs.blender.org/manual/en/dev/physics/soft_body/… $\endgroup$
    – user1853
    Jun 21, 2018 at 18:56

2 Answers 2


Separate your rendered world from your physical world.

With soft body physics, your vertex count is the biggest thing that's going to impact the time it takes to calculate. Physics complexity is combinatorial in nature. Each bit capable of interacting has to check with every other bit capable of interacting. So doubling your vert count slows down your scene by much more than half.

How do you get around this? By using simplified proxy physics objects. You may need a thousand verts to render your beautiful sphere with nice glossy reflections, but do you need a thousand verts to simulate its physics? No.

Look at your first image. In that image, you have wireframes of four objects, each of which has more than a hundred vertices. Yet the actual profile of these objects is pretty flat. Do you need all those vertices for physics, or do you only need those vertices for rendering? If you don't need them for physics, make an octagon mesh collider instead. Simply disable rendering on your new octagon collider, and possibly parent your rendered object to the octagon, rather than involving these thousand vertices in your simulation.

What if you have something soft and squishy, and the render needs to represent that? One way to handle this is to use a physics object as the target of a mesh deform for your rendered object. Another is to use an armature with constraints that track vertex groups on your physics object. These kinds of deformations can be computed much more quickly than physical deformations can. Use your physics as a guide for your render. Don't try to render physics directly.

  • $\begingroup$ I'll look into the armature and simplified proxy objects, as I never thought about them and went all the way into rendering the animation directly, as you said. But you pointed out those four objects with more than a thousand verts. The simulation still freezes even when the sphere has not yet arrived to those objects, so I assume it's a problem from the sphere, right? $\endgroup$ Jun 21, 2018 at 23:01
  • $\begingroup$ First: those are an example. I expect the rest of your scene to have way too many verts as well, but I can only see the verts on the wireframed objects. Second, it doesn't matter whether some object has reached those objects or not, they are still being tested at least 168 times a frame (your min soft body step size), because that test is how it knows whether your object has in fact reached them. (And because they're probably soft bodies, and have to interact with themselves anyways.) BTW, is there a reason you increased that 17-fold over your defaults? That will make it slow too. $\endgroup$
    – Nathan
    Jun 22, 2018 at 0:15
  • $\begingroup$ Sorry - wht's this 17-fold thing? If you mean the min step, I don't know why was it set to 168, but I already changed it. $\endgroup$ Jun 22, 2018 at 8:03
  • $\begingroup$ Yes, I mean min step. $\endgroup$
    – Nathan
    Jun 22, 2018 at 8:04

@Nathan’s answer is certainly very good advice. However, in this case I notice that you have the Soft Body ‘Edge’ and ‘Face’ collision properties set. These control wether the soft body edges and faces should collide in addition to the vertices - with them disabled only the vertices of the soft body will collide (but this does not affect what those vertices collide with - they’s still collide with other mesh faces and edges). Since your ‘blob’ is quite “vertex rich” and the things it’s going to collide with are quite rounded those settings will not make a great deal of difference but will greatly increase the simulation time.

So, quick fix is to try unchecking Soft Body Edges Collision ‘Edge’ and ‘Face’ and see how much that helps.

Also, I note that you have increased the Soft Body Solver 'Min Step' to 168 from its default of 10. This will mean it will apply at least 168 steps per frame to the solver - reducing this back to 10 should result in a much faster computation. Only increase it if the simulation is behaving erratically due to fast moving objects or large forces - although enabling Auto-Step will allow Blender to determine the best Step Size to use between the Max and Min settings.

  • $\begingroup$ I don't recall changing this value. However, lowering it to 10 and enabling Auto-Step made a substantial change in relation to calculations. What would be the best mode to render simulations like these? First baking them in the "Soft Body Cache" tab and then rendering the full scene, right? $\endgroup$ Jun 21, 2018 at 22:58
  • $\begingroup$ @Crazychemsist Yes - bake first, then render. That way the simulation is complete before you render, which also lets you render frames in any order or skip frames. Even better is to enable ‘Disk cache’ in which case the cache is held on disk rather than only in memory so saving and reloading the .blend doesn’t lose your cache. $\endgroup$ Jun 22, 2018 at 5:48
  • $\begingroup$ but Nathan told me to use armature, rather than baking and rendering. Does it make a big difference? $\endgroup$ Jun 28, 2018 at 6:19
  • $\begingroup$ @Crazychemsist I don’t know what Nathan meant by that, sorry. $\endgroup$ Jun 28, 2018 at 6:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .