This is cool, thanks for sharing!
2 Likes
Week 10
A big push to finish all the interface bits, some still in progress. Also, a surprise cloth sim mode!
- Greatly improved the cost of obstacle collisions with signed distance fields using https://doi.org/10.1109/TVCG.2017.2730202. Works pretty nice for obstacles, not very useful for self collisions (which have also been sped up but only marginally).
- A few more misc gui parameters: linear solver, verbosity (debugging and timings)
- Big change to how goal positions work. Basically, if you only change the pin location and not its stiffness or which vertex is pinned, the solve is extremely fast otherwise itâs as fast as it was before. This was easier said than done.
- Cloth simulation: Itâs just a rudimentary initialization without any bells or whistles to get the stuff in place to be improved later. There are no self collisions or collisions with obstacles.
- Iâve made the entire ADMM-PD internal data copyable. This is to support copy-on-write which apparently Blender invokes every time you change a simulation parameter. I still havenât quite worked it out as there is some funny business going on and my data is getting freed before itâs getting copied. At the moment, the simulation will simply reset if you change a parameter, and I want to fix that.
Next Week
- Finish copy-on-write to get ADMM-PD internal data into new object so that simulation does not reset on a parameter change to allow animatable parameters.
- First draft of the documentation and write up.
cloth
29 Likes
Week 11
As we approach the finish line, Iâve been working heavily on critical usability features. This amounts to playing whack-a-mole on Blender interface bugs.
Daily builds are now available: https://blender.community/c/graphicall/spbbbc/
- Animatable parameters. Many parameters can now be changed between time steps, but I havenât tested it thoroughly. Some parameters cannot (e.g. mesh topology, or terms baked into factored matrices like elastic stiffness). To support animatable parameters I had to make it so internal ADMM-PD data persists over copy-on-writes. It took a long time to get that working, as it introduced many bugs elsewhere (e.g. saving and loading to a file, multiple soft body objects, etcâŚ)
- Vertex groups for self-collision. It occurred to me that self collision (with high resolution meshes) is by far the bottleneck. It makes sense for many applications that only certain areas of the mesh need to be queried (e.g. near the joints of limbs). You can now optionally specify which vertices should query self collision using vertex groups, which can greatly speed up the simulation.
- LERP obstacles if substepping. If the number of substeps is increased, the simulated time step is decreased. This is now applied to obstacles in motion as well, which should give more accurate collision results.
- Reworked signed distance field calculation to use different threading. There was some non-trivial thread sync so it was a little tricky. It originally used OpenMP which is not included by blender.
- Added strain limiting option for cloth. This allows you to specify how much the cloth is allowed to stretch as a hard constraint.
Next Week (the last week! 
)
- Final report and user manual.
- Fix any bugs that cause system crashes.
As an example of strain limiting, Iâve attached two videos. The first video has no limiting and low stiffness, so you can see it stretch unrealistically. In the second video, I have it limited to 2x stretch, then switch it to 1x stretch halfway through, while keeping the stiffness the same. Strain limiting is a pretty useful cloth sim feature.
27 Likes
Hi @mattoverby. Thanks for your amazing work for adding new soft body physics to Blender!
I do AI research and build generative models for objects (e.g. this work) . I am thinking to build a generative model for objects with physical properties. For that, I need to be able to probably generate lots of objects and run physical simulation which what you are doing here helps me achieve. However, I also need to have access to some âground-truthâ values for the physical parameters. I wonder if you can make it possible to access the values of the physics, force and geometry parameters of objects through the Blender Python API over time (i.e. for each solver and/or iteration step) and for the objects? Making this possible would be of great interest to lots of people who do research in AI and want to use Blender as a tool for their AI research. Do you think it would be possible for you to do this?
2 Likes
Hmm, I donât know much about how information is passed to the Python API. But it is easy to make the various terms youâre asking about available through the solver API. However, Iâd want to finish the TetGen mode (right now all that is available is embedded and cloth). For now the embedded results will look okay but arenât exactly faithful to real world physics. So yes it would be possible but not in the final week of GSoC.
If would be great if you can at least make it possible to access that data through C++ and provide a short description on how one can do that. Of course, still, a Python interface would be much more preferable.
@brecht, do you think it would be easy to make it possible to use the Python API to access the C++ variables/buffers that hold the data for the physics engine?
Blender physics systems should be designed for VFX, and we should not complicate them with other use cases that make maintaining or improving them harder.
By putting such internal data structures in the API it becomes harder to change them, so I donât think this should be supported.
3 Likes
Week 12
Many things. I was also wrong about this being the last week.
- Added Blender UI warnings and errors. You should see the orange or red message appear in the bottom right corner of the UI if there is a problem.
- Fixed bug with floor collisions.
- Fixed threading error that only appeared on some machines, in which collisions were not being processed for certain vertices.
- Fixed bug with multiple collision obstacles.
- Updated code to Blender style standards (c style comments, make formate, etcâŚ)
- TetGen mode now available which attempts to tetrahedralize the mesh instead of only embedded.
- Added visualizer for embedded mode (similar to TetGen) as a remesher operation. You should not run this before running the simulation, itâs purely for debugging mesh generation. Image attached.
- Completely restructured the way the ADMM-PD data is stored internally to avoid crashes. This is to facilitate the many ways Blender makes copies of data and duplicates pointers. Though I do have my doubts that it is 100% crash free, since there always seems to another function unknown to me, hidden in the depths of the source code that somehow touches the SoftBody data and not through interface functions
. It would be easier if I was better at c programming! - Support for blend file IO and versioning. No more crashes on loading older blend files.
- Changed the way collision obstacles are passed to the solver. Previously, the obstacle meshes are copied to ADMM-PD and a signed distance field is computed on every time step (an expensive operation depending on the number of faces). Now, the SDF is only computed as-needed, when the deforming mesh intersects the bounds of the obstacle. So if a soft body is bouncing away from a moving obstacle, there will be no unnecessary SDF computations.
- Nearly done with final report.
Next week, the actual final week
- Finish and submit report
- Bug fixes and usability improvements
17 Likes
Week 13
- Final report finished: User:Mattoverby/GSoC2020/mattoverby final report - Blender Developer Wiki
- Bug fix: you can ctrl+z to delete soft body objects now
- Added diff: Login
In the diff, you can see two blend files. The first (dillo) is from a while ago, with an armadillo bouncing off cylinders. The other (pile) is an example of how to set up multiple colliding deformable objects.
Here are some interesting tests by @EvertonSchneider that shows the effects of volume preserving materials (neo-Hookean) vs ARAP. They also show how embedded elastics can exhibit faceting artifacts (those little dimples when stretched/twisted). You can learn more about that in a recent siggraph paper. In any case, I was happy with the results, they appear as they should.
As for the future, Iâll still be around for critical bug fixes. I still want to do a user manual at some point, and youâll see that sooner than later.
And I guess thatâs all folks. Itâs been a fun summer. Thanks for the support 
41 Likes
Thanks, @mattoverby You did it! And you did it well. Nice to know that you will be around for support critical bugs, thatâs super nice! I hope to see this project going on because it have huge benefits, especially in motion graphics, vfx, character animations⌠pretty much everything turns into something special with a decent softbody simulation⌠itâs something needed.
Thanks again for bringing this nice alternative to blender. Even unfinished as you mention but yet very nice to play with.
5 Likes
Suzanne is by far the nicest toy for this GSOC projectâŚ
Some realtime manipulation test here
SoftSuzanneRealTime2
27 Likes
I want to rig characters with this now. Supposedly possible ? Parent hook objects to bones, animate, profit ?
2 Likes
Yes you can rig characters. The rig should update the goal positions like they would in the old soft body solver. Youâll want to play around with goal stiffness and elastic stiffness to get the results you want though.
One of the advantages I noticed is a âself contactâ effect with all vertices as a goal group. It still âwigglyâ because of the self collision being calculated there but I think itâs useful. The examples already have a correction smooth modifier to minimize the âwiggleâ effect caused by self collisionsâŚ
RigContact
19 Likes
Ah thatâs some unpleasant jitter in self collision though. This is caused by fighting between constraints - the pin constraints are pulling it inward, the collision constraints pushing it outward. If you turn down the stiffness of both of them, you should get the same result but without jitters.
5 Likes
well done! So much progress in this GSoC! Looks great!
So how do you setup the detection between two objects for interaction?
Are they both soft bodies?
Used the latest build 2020-08-31 - [44819c69a4e7]
1 Like
There is no âexternalâ interaction between multiple softbodies(at least in my tests).
Another thing is that this system is based on objects volume, so it would not work with simple planes, you need to use solidify or extrude to add some volume to the plane. (note that solidify doesnât work before softbody modifier so the sofbody system wonât recognize the volume, you need to apply solidify)
You need to join the meshes and use self collision for interaction. In your example file you need to join the sphere to the plane(extruded to have volume) and turn the self collision on.
2 Likes
Thanks for the reply Everton. Yes youâre correct there is no external interactive between multiple soft bodies (or other bodies, e.g. right or cloth). This is because collisions are not treated as a post process like they are with most solvers. Collision detection is online, so the body can make large deformations (big time steps) and still detect/resolve new internal collisions as the body deforms. For this to happen, the meshes need to be represented within the same solver, i.e. soft body object.
Thatâs where it becomes tricky. In order to set up scenes that have mesh-to-mesh interaction, there will need to be some Blender volumetric meshing support. I explain this in the final report. For now, the solver simply âguessesâ upon initialization based on the distance between multiple bodies. If they are still behaving as one body, move the objects a little further apart and possible increase the lattice resolution. That should allow them to be meshed as separate entities.
2 Likes
How was the posted 29th of July boxing scene achieved with the new soft body simulator?
Some people may be more interested in how it was set up, rather than the theory behind it.
1 Like