Week 7
New tag: softbody-stable-v3 - will have bug fixes, collisions vs obstacles, goal positions, no self collision, no friction.
Minor things:
- Fixed a bug that was causing crashes in softbody-stable-v2 (thanks @EvertonSchneider for pointing it out). I was using a deprecated threading function to obtain the thread index, which I needed for a unique reduce operation, and apparently there is no replacement. I found a workaround that isn’t as efficient but will suffice for now.
- Rewrote the lattice generation to be a bit faster using octrees. I ran out of time before I could improve the mass distribution from mesh->lattice.
Collision detection:
- Spent a day trying different collision detection strategies. In the end I found something that works fine, but is a bit slow. There is certainly room for improvement, but speeding up CD can be a lot of work. My primary focus is on robustness over speed. We’ll leave that for a to-do.
- Added self collisions. It’s not fully tested so I didn’t include it in the softbody-stable-v3 tag.
Next week
- Non-linear elastic energies
- Start using the gui to provide solver input, primarily frame rate, stiffness(es), collision booleans.
Here’s a comparison of with and without self collisions.
28 Likes
This is insane! Thank you so much! “Non-linear elastic energies” seems an interesting topic.
2 Likes
Playing with SOC-2020-SOFT-BODY branch after this non linear commit
It does not fit well for a hammer but it’s fun. 
It’s working really well, it’s faster than before, I assume you turned off self collisions, right?
23 Likes
Haha wow that’s really great! Yes, self collisions turned off at the moment.
1 Like
Week 8
Short version: Hyperelastics and starting some runtime improvements.
- Hyperelastics (nonlinear energies): Updated the ADMM local step to support nonlinear energies. It’s nothing more than a standard Newton solver that requires the value/gradient/hessian of a given model for a single tet. This means that many different models may be available in the future (e.g. Mooney-Rivlin, Stable NH, StVK). Before the end of summer I will probably add others. Adding new ones is trivial: you only need to implement the corresponding value/gradient/hessian to admmpd_energy.cpp.
- Templating: I’ve started to template sections of the code, piece by piece. The hope is that the user will be able to choose between float or double precision. In practice, floats will be much faster and use less memory (obviously), but depending on parameters may be unstable. To be honest I have not explored this with ADMM-PD so I do not know how robust it is w.r.t. precision.
- Replaced Eigen::JacobiSVD with ImplicitQRSVD (Gast et al 2016). It’s quite a bit faster.
Next week
Now that most of the features are in place, I’ll be working on extending the usability. This includes GUI functionality for setting parameters, finding default/auto-tuned parameters, and run time improvements. Next week I’ll specifically focus on:
- input for simulation parameters, e.g. time step, stiffnesses, gravity, collisions, etc.
- Simplify balancing the various stiffnesses: collision, goal position, and elastic. So far has not been trivial…
I don’t have any new eye-candy for you this week, instead check out @EvertonSchneider’s animation. It’s way cooler than anything I could put together .
23 Likes
Nice work @mattoverby thanks!
I keep playing, not as I want but I’m playing… I see some penetrations issues but I’m pretty sure that when simulations settings get exposed it can be solved by “simulations steps” or some similar setting…
16 Likes
Ah yup. A few things going on that may be the culprit:
- I am using discrete collision detection, this means that at the current state it does a simple in/out test. If at the current state a vertex has passed all the way through an element (tunneled), collision won’t be detected. Continuous collision detection is considerably more expensive and I don’t plan on implementing that before the end of summer. CCD is certainly a possibility for the future.
- The default time steps are fairly large (1/24 to match the frame rate). Decreasing the time step and taking several substeps up to the full step would not only help the dynamics (nicer jiggles), but also improve the tunneling issues you’re seeing here. This will be a setting I plan to expose.
- There actually is a bug with collision detection. I’ve seen it in a few cases but on some occasions I see penetration when it shouldn’t exist, like dropping a default cube on a bigger default cube.
- The solver itself is resolving collisions with penalty springs. Even if we’ve detected the collisions and generated appropriate constraints, the springs may not be stiff enough or the solver is not converged enough to resolve them fully. This is another thing that increasing substeps/decreasing time step will resolve.
7 Likes
Test of today. Moving collision obstacles, again another thing that maybe will benefit from more simulations steps…
But the fact that I can grab any kind of model and have a great softbody simulation out of the box is insane!
I like the new UI also with options to choose from the “Legacy” solver, nice to keep the old one, it’s still useful.
Question:
Is it possible to map the mass density with vertex groups? For example, in this scene, I would like to set the head with more mass than the legs and arms… Is it something possible in the future?
6 Likes
That is possible within the solver, but I haven’t implemented it yet.
Also, what’s going on with the character in your animation at the end when it launches to the right? Is that a bug or are you animating that with goal positions?
This is something related to the collision object in motion… maybe some interpolation step from the simulation is not synchronized with the animation steps… I’m not sure about what is happening technically but It explodes away from the collision object.
Maybe you can try to give some thickness to your colliding “paper”.
That used to help me fix some inexplicable behaviors with rigid body bullet solver, not sure if it would make any difference with this new solver.
2 Likes
Yes, @Voidium you’re right.
Talked with @mattoverby and he confirmed, the collision objects must be “volumetric”.
Now the branch is getting seriously fun, the UI settings are now tweakable! I make them even “softer”… slimes ragdolls? Can’t wait to see them interacting with each other.
With 1 step:
With 2 steps:
16 Likes
I can’t wait until this can do Soft-Body Tetris 
These look like great improvements.
May I ask a question?
Do you know why the soft bodies solver is a separated one from the rigid bodies?
Both are bullet right?
1 Like
Could be really interesting to see the monkey boxing demo with some more rigid soft body and plasticity, to see how does it behave
I can imagine a coupled solver some day, but for now they are entirely different solvers. The soft body solver (and collision detection) is not Bullet. I have been implementing it from the ground up starting June.
I tested the new settings and this is the result. I still have problems with “penetrations” but with a lower stiffness (“poisson’s ratio” and “young’s mod”) it works better because the lower resistance…
19 Likes
Another great option in settings! Lattice Resolution.
The both models settings are the same, only Lattice Resolution is different for comparison.
9 Likes
This is one of those things that has real artistic value – even a low-resolution lattice produces great results, and makes the floppiness behave differently. For materials like leather, I can imagine artists using a lo-res lattice in preference to hi-res lattices.
1 Like
Week 9
- Updated the gui so that many of the parameters are adjustable. Implemented some knobs so that map more intuatively to internal parameters while reducing the likelihood of breaking the sim.
- I’ve been keeping roadmap (now future work) updated with more specific tasks. It’s unlikely I’ll get to most of these before the summer is up.
- Been standardizing some of the code, e.g. hooking in ADMM-PD’s error codes into Blender’s internal logging.
You can see @EvertonSchneider’s post above for many of the parameters and what it looks like. All the parameters will be discussed in detail in the final write up. There are a few important ones that I would like to briefly mention here, in case you’re testing out the branch:
- Substeps: This is the number of solver substeps to take up to time step. Increasing the substeps is equivalent to decreasing the time step, which will improve convergence and collision detection at the cost of run time. If you’re running a simulation and things look damped or there are nasty penetrations, the first thing to try is to increase the substeps.
- Lattice resolution: Directly increases/decreases the max number of subdivisions taken when generating the embedding lattice. This is a fickle parameter, as it’s not obvious is how much resolution is needed and where. If you see odd behavior like shearing or stiff collision response, try increasing the resolution.
Next Week
- Improve the robustness of TetGen: In many cases an actual tet mesh is preferable to the lattice. I have that option disabled since TetGen parameters are a little finicky. I’ll have to see if I can automate some of them based on the dimensions of the input mesh.
- Improve speed of self collision detection.
15 Likes
