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.
Week 12
Many things. I was also wrong about this being the last week.
. It would be easier if I was better at c programming!Next week, the actual final week
Week 13
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.
Suzanne is by far the nicest toy for this GSOC project…
Some realtime manipulation test here
SoftSuzanneRealTime2
I want to rig characters with this now. Supposedly possible ? Parent hook objects to bones, animate, profit ?
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
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.
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]
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.
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.
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.
Thank you mattoverby, for the answer.
This is the file updated so you can investigate better.
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!!!
SoftBalls
ClothPressureFIXED_LOW
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.
