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?
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.
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
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.
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…
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.
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.
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.
That one does not have self collision. The boxing character appears to be one from mixamo, which is simply set as an obstacle (collision object). The monkey mesh is the soft body. Any collision objects added to the scene will be picked up by the soft body solver and treated as immovable obstacles.
Well… I’m here to show a test with multiple softbodies interacting and it looks right for me… a little jittering but this effect is the same with cloth modifier but I can get rid of it by increasing the quality steps of cloth simulations and cloth collision quality as well, maybe increasing the steps of the solver here will also work but there’s another issue… This simulation took almost 4 hours!!!
I will share the original simulation test I did but using blender cloth with pressure(after almost 4 hours o baking I noticed that the upper cube needs to go down a little further)
In this example all spheres are merged in the same object and they collide by self-collision:
Thanks for taking the time to set it up . This is an interesting set up. So each ball is an independent soft body, but also set as a collision object. A way to view what’s happening is that when one ball is simulating, it “freezes” all of the other balls in time and pretends they are immovable obstacles. I would expect a lot more jittering than what we are seeing. The balls aren’t responding to each other within the same time step, and these are especially large time steps (1/24s !!!), unless something else was used in the bake?
Looking at the resolution, we’ve got 12 balls at 1880 tets and 611 verts each, so a simulated domain of 22560 tets and 7332 vertices. That’s not very high, so it should be reasonable fast.
The reason why it’s slow: treating the deformable models as immovable obstacles. Collision obstacles are treated differently than deformables in how they preprocessed. A high-ish resolution signed distance field is computed for every obstacle whenever it changes shape/location. Including the moving box and casing, each time step, 12*13=156 high res signed distance fields are computed! Yikes.
I think from a user standpoint that important detail is not clear - I really need to put together a manual when I get some free time!
But anyway, the SDF computation is not fast. It’s the bottleneck of that annoying frame=1 computation. So, this is certainly why the bake took 4 hours, and not the solver.