Soft body support

[brightening-eyes]

hi, soft bodies are useful for something like soccer and/or basketball nets, cloth, roaps, etc. it would be cool if jolt supports it. thanks for such an awesome physics library (I am still learning it, and its code is well organized, written with good comments, etc) and for your generous time that you devote answering questions and helping others.

[jrouwe]

Hello,

Soft body support is definitively on the todo list, but I first need to read up on the subject and decide how it would fit in, so there's nothing concrete I can say about it yet.

[peter1745]

This would a great addition in my opinion, especially if it can be done efficiently on the CPU, if I'm not mistaken PhysX 5 introduced soft body support but only on CUDA capable GPUs, I would love to see a soft body simulation working on the CPU as opposed to the GPU. Seems like a relatively complex topic though

[brightening-eyes]

also, bulletphysics had it implemented, but it had its own physics world, and the gpu implementation was done with openCL

[betauser6]

Will be great to implement it as a shape. Jolt already has modifiable shapes, also rigid body is special case of soft body. Bullet implementation has a rigid body and soft body separated, it is not the best solution.

[jrouwe]

I will make it work together with the standard rigid bodies, but it will not be a regular Shape/Body but more its own world just like Bullet. Although theoretically you could do rigid bodies with soft bodies, soft bodies are much more expensive to compute, so it doesn't make sense to handle them all in the same system.

[peter1745]

@jrouwe just curious how you're planning on implementing soft bodies? I know that it's common to implement it using compute shaders, just curious if you'll be going down that route as well?

[jrouwe]

The first version will definitively be CPU based (I first need to get the API defined and have a stable simulation, that's much easier to achieve on CPU). Later perhaps there will be a GPU version too.

[betauser6]

I will make it work together with the standard rigid bodies, but it will not be a regular Shape/Body but more its own world just like Bullet. Although theoretically you could do rigid bodies with soft bodies, soft bodies are much more expensive to compute, so it doesn't make sense to handle them all in the same system.

Thanks for the info. It probably matters from an internal implementation point of view.

I am a game engine developer, it will be more understandable and more logical for users to work with one Body class and different types of shapes inside. Separating into two classes in the Bullet complicate their interaction. They can't just replace a type of shape, harder to work with constraints. Ivan)

[jrouwe]

I am a game engine developer, it will be more understandable and more logical for users to work with one Body class and different types of shapes inside.

I don't know exactly what the API will look like, have yet to start on research, but I'll keep your suggestion in mind.

[ODtian]

PBD is very friendly to the simulation of softbody, for example, a simple solver written in js without any parallel optimizations can easily handle softbodies with ten thousands vertices.

If the constraints between vertices are well parallely handled, it could be cheap enough to impl softbody and rigidbody in the same world. Since jolt works really well on multiple threads, it's not a difficult thing.

Moreover, proxy mesh can make softbody simulation even cheaper, which should also take into account.

[a-day-old-bagel]

To chime in on the subject of PBD, there are some excellent publications on the cutting edge of PBD, termed XPBD, authored by a variety of Müller et al, which I'd recommend if I were implementing any of the soft body stuff.

This page provides a number of them: https://matthias-research.github.io/pages/publications/publications.html

Interestingly, as ODtian mentioned, this can be extended to handle rigid bodies too quite nicely, offering a unified physics model. Details can be found in the third paper down on that page I linked (third at time of writing), which is here:

https://matthias-research.github.io/pages/publications/PBDBodies.pdf

I might add to this: There is a youtube channel with three videos so far, in which the creator implements XPBD in C++. It's still pretty early in development, and this might not be appropriate reference material, but it's cool to see at least, and offers a parallel explanation of some of the math involved: https://www.youtube.com/@blackedoutk/videos

[jrouwe]

Thanks for the links! I was aware of this research and I was planning to use it as a basis for soft body in Jolt.

[jrouwe]

Very early implementation:

https://github.com/jrouwe/JoltPhysics/assets/1621693/98038dc3-6dba-441a-be10-4efdf2aab831

[jrouwe]

Now with friction, restitution, pressure (orange sphere) and mesh terrain collisions:

https://github.com/jrouwe/JoltPhysics/assets/1621693/a40794da-8499-4434-839a-7d865693ea3c

[jrouwe]

Starting to work on interactions between rigid bodies and soft bodies:

https://github.com/jrouwe/JoltPhysics/assets/1621693/c87bc455-ec90-44df-8dde-df31ca609e52

https://github.com/jrouwe/JoltPhysics/assets/1621693/a63deaf8-221e-47bf-a9f7-c7f2e6aaea1c

[fire]

Is https://github.com/jrouwe/JoltPhysics/commits/feature/soft_body the branch for this?

[jrouwe]

https://github.com/jrouwe/JoltPhysics/tree/experiment/soft_body_inherits_from_body has the most complete implementation at the moment (but it is very much WIP)

[RT2Code]

That's awesome! Can't wait to be able to use it in my engine. Is there a roadmap for this? I'd love to follow every development step of this feature.

[jrouwe]

I'm hoping that in the next couple of weeks I will merge a first version into the master branch. If you want updates then just follow this issue.

[SirLynix]

Awesome work!

However I noticed some weird behavior, when shooting an object (B) they do affect the soft bodies but don't seem affected by them, is this normal?

[jrouwe]

The ball you shoot with B use a density of 1000 kg/m^3 so weighs 4000+ kg. The soft bodies default to 1 kg per vertex so the soft body sphere is only around 160 kg, so it is not heavy enough to push the ball away.

[SirLynix]

Seems legit 😄 however it would be nice to be able to change the density of thrown objects.

I encountered an assertion failure when playing around (shooting convex shapes through the soft body cloth from the first sample), it seems to happen when a soft body pushes away another body.

here's the callstack:

[jrouwe]

I ran into the same assert. Issue is fixed now.

[jrouwe]

A first implementation has been merged into the master branch:

https://github.com/jrouwe/JoltPhysics/commit/5c9f7a60436f919d7e3409aeeb49861c679500f7

Things to be aware of with this implementation:

• Soft bodies currently can't sleep, are executed on a single CPU core and collision checks are not as efficient as they could be.
• Soft bodies can only collide with rigid bodies, collisions between soft bodies are not implemented yet.
• ContactListener callbacks are not triggered for soft bodies.
• AddForce/AddTorque/SetLinearVelocity/SetLinearVelocityClamped/SetAngularVelocity/SetAngularVelocityClamped/AddImpulse/AddAngularImpulse have no effect on soft bodies as the velocity is stored per particle rather than per body.
• Buoyancy calculations have not been implemented yet.
• Constraints cannot operate on soft bodies, set the inverse mass of a particle to zero and move it by setting a velocity to constrain a soft body to something else.
• When calculating friction / restitution an empty SubShapeID will be passed to the ContactConstraintManager::CombineFunction because this is called once per body pair rather than once per sub shape as is common for rigid bodies.

[fire]

Hi, I want to see if the way this paper accelerates softbody is compatible with your approach.

Video

https://youtu.be/TH5g8TuKIkk

https://dl.acm.org/doi/10.1145/3528223.3530085

Source

https://github.com/fire/preconditioner-for-cloth-and-deformable-body-simulation

[jrouwe]

Thanks for the link! I'm using XPBD, which solves the linear system using a very simple iterative loop. I think your article describes a different solution to the same problem (and maybe a more accurate one), but I don't think the two could be combined.