GSoC 2020: Soft Body Sim - Weekly Reports

[mattoverby]

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.

[NoSoulX]

Thank you mattoverby, for the answer.

[EvertonSchneider]

@NoSoulX

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.

This is the file updated so you can investigate better.

SuzanneBoxer.zip

[EvertonSchneider]

@mattoverby

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.

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:

SoftBodyBalls.zip

[mattoverby]

@EvertonSchneider

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!!!

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.