Another excellent tutorial. Thank you very much!! In your recent paper, you use two constraints on the tetrahedra; deviatoric (skew) and hydrostatic (volume). In this video you seem to have replaced the deviatoric constraint for edge length constraints. I assume this was for simplicity of demonstration; but can you describe how the behavior differs when using edge length constraints instead of the deviatoric one from the paper? Kind regards.
Right, I used edges because the method is easier to understand and implement. The visual difference is not significant. I might do a tutorial on the neo-hookean model as well.
i'd like to mangle your attention again with my gratitude having had an opportunity to implement this. i did years of hacky modeling at audio rate, never occurred to me to use the actual step difference as velocity i'm dumb haha. now my ragdoll limb length is constrained, i can smoke that the same method can be used to model controlled movement by soft constraining towards an intended rotation, a 3d mass-spring if you drive the correction some. blah blah ok back to it.
Thanks for all these great demos. I want to see a soft body interacting with a fluid simulation! That would be incredible. I’m actually working on combining the concepts in this video with some of your other videos to see if I can achieve this.
Hi Matthias, thanks for the great videos and source code. It is a complete mystery to me why you don't have more likes. I would love to see your take on 2D soft bodies, and challenges such as incompressibility and shape matching.
Hi Matthias. Thank you so much for these videos, they are amazing. I had one quick question. In this video and the last (vid 9), you show the form of a general constraint, and in the denominator of lambda you multiply the inverse masses with the length of the gradient squared. However in the code I see you are using a sqrt which is actual length (not length squared). I also saw in the paper that the terms are length squared as well. Would you please elaborate on why they are different? It might be something simple that I'm just not seeing.
In the case of a distance constraint the lengths of the gradients are 1. I use the sqrt to compute the gradients. In the denominator of lambda, the lengths of the gradients don't appear for the distance constraint because they are one. For the volume constraint you see that I use vecLengthSquared
I think the "unbreakable" thing can't be understated since Matthias is using a broken non conformal tetrahedral mesh and yet the simulation is still behaving quite nicely
Excited to see a new tutorial! I'm trying to do some PBD with GPU, I wonder how effecient is the multi-color gauss seidel, compared to the serial gauss-seidel? Since multi-color GS is kinda of a multi-pass Jacobi solover, and Jacobi has worse convergence than serial GS... Also, is it feasible to use distance field as a constraint or external force? If that's possible, then PBD can be used for deformable surface tracking/registration!
I'm also trying to implement this on the GPU, but have problems with stability and especially energy conservation (eg. if th bunny is dropped it bounces higher and higher). Could you explain why you think that multi-color GS is like a multi-pass Jacobi solver? I don't see why it would be any different from serial GS since all the constraints solved in one pass are unrelated.
This content is amazing, but the code is a little hard to read sometimes. For example, the code for this particular video has a variable `grads` that is used in `solveEdges`. It took me a few minutes to figure out that it was just the direction vector.
With the current constraints and the current mesh, it is possible to bring the object to a state where all constraints are working against each other, stopping the object from recovering to its rest form. You can grab the slider and move it quickly between the allowed min and allowed max and eventually you will see what I mean. Same if you are alternating between squash/run rapidly. Do you have suggestions to prevent this from happening?
I'm a new subscriber. This channel looks great! With the volume constraints are you implicitly assuming an incompressible medium? How to deal with compressible media? Where do the constitutive equations have been gone?
Great serie... but I think there is a little problem. When computing the mass of each particle, your divide the volume of the tets by 4 for the 4 points of the tets, and then invert it and add the invert to the invMass of the particle. But you should add the 1/4 of the volume as the mass, and when all adds are done, invert it, no?
Sorry for reviving your old comment but it got me curious.. It doesn't matter because the initial inverse masses for each particles are 0 here (initPhysics is called in the constructor right after creating the empty array for inverse masses). He used the "+=" operator but it's only a basic assignation so using "=" would have the same effect in this case.
@@alexisdupuis5616, not really. It is true for the first tet, but then, as vertices are shared by other tets, it is no more the case. Take a pyramid with a square base for example. It is made of 2 tets, and 3 of the 5 vertices are shared by the 2 tets. So, when you compute the first tet volume, it is working... but for the second, it is no more working for the 3 shared vertices... that is why there an initialization to 0 and then a +=.
@@crouette Oh yeah I missed that. I think you're right then because the logic would be to have the inverse mass get smaller when the vertex is present in multiple tets, I guess (?)
I'm trying to implement this technique for a softbody simulation in Unity (using Compute shaders according to lessons learned from tutorial 16 "Simulation on the GPU"). In most cases, it works well with a fixed substep time of 0.0004s (50 substeps with 0.02s fixed timestep). But if I try to set the compliance (both edge and volume compliance are the same) to less than 1, it explodes. If I lower the substeps, it explodes. If the mesh hits the ground (even from a moderate height), it explodes. Any clue why this "unbreakable" simulation would be exploding?
I sort of solved it. According to tutorial 16 "Simulating on the GPU", a good "magic value" for averaging the corrections is 1/4. But this was not enough to maintain stability. Instead, I'm using 1/#adjacent constraints (to get the average correction over all of the adjacent constraints). Now the simulation doesn't explode (even with a 0 compliance) but (as is stated in the notes), momentum conservation is violated which causes the bunny to slide and start spinning like a figure skater eventually spinning out of control. Maybe this can be improved by damping the velocity?
@@oostenjadenhtv Hi, I'm also trying to implement this on the GPU in Unity for a uni project. I'm wondering if you managed to get a good simulation without momentum/energy conservation problems. I'm implementing it with the GS colouring method so I'm not applying corrections, but I get the bunny bouncing higher and higher. Do you know what could be the cause of this. Since you're applying corrections, I assume you're using Jacobi.
I'm also surprised that your simulation explodes for low compliance, as I have the opposite problem. For high compliances the bunny gains a lot of velocity very quickly.
At 12:50 : I often project Y coordinate of the 'predicted' position, in such out-of-boundary condition, not reusing the 'previous' position as in this tutorial. Is there a mathematical reason for discarding the predicted position or is there any issue when using the predicted position for such boundary projection? Anyway, it's really valuable to see the implementation code from the developer of PBD. I really appreciate it.
I'm very curious. Why did this never caught on? It seems to be the superior system for most use cases. I see videos from Miles Macklin about PBD from 8 years ago already. Are there some fundamental drawbacks holding it back? Is it too good to be true? or just a case of the industry not wanting to change something so fundamental as traditional physics simulations?
Hi Matthijs - it is being used in the gaming and film industry. Vellum, a physics engine for houdini is based on it for instance. Check it out, it is pretty cool :-) But yes, I think it could be interesting for researchers outside those industries. That is why I created this channel.
The fundamental drawback is that this modeling approach is not based on physical laws. In contrast, the continuum models are based on laws like conservation of mass and conservation of momentum. Therefore if the continuum model equations are discretized and solved accurately, the simulation result will satisfy the underlying physical laws. This is an important property for accurate prediction in real-world engineering applications. In games and films, satisfying physical laws is less important and therefore I can see why this simpler approach is valuable.
So the scale on the constraint error is arbitrary, right? As long as the gradients are correct and the error drops to zero when the constraint is satisfied, that '6' in the volume constraint just kinda cancels out? Does that also mean the signs are arbitrary? Negative and positive error are the same?
@@TenMinutePhysics Hello Matthias. Firstly, huge fan of your simplicity. Can you point us out, how exactly were you able to get "tetIds": [],"tetEdgeIds": [],"tetSurfaceTriIds":[] from the obj file. The obj file from Blender simply gives face ids as "f 39//1 33//1 31//1 278//1" or some other numbers which is vertex ID// normal ID, but how to identify which vertices make the tetrahedral?? What was your regex like, when you tried to parse obj to JSON??
@@abhisheksinha3074 I am glad you like it. I hacked a script to converge the meshes generated by the tetmaker. I might put it online ifI find it again :-)
This is pure gold! I have been a fan for many years, and spend countless hours implementing your articles for fun and surgical simulation.
hi chuck, do you have anywhere youd recommend to get started with surgical sims (bone, flesh etc)?
Any help will be appreciated with getting start with surgical sims.
This channel is excellent.
your PBD videos are amazing! These algorithms are so easy to understand and can be used over a wide range of applications!
Another excellent tutorial. Thank you very much!!
In your recent paper, you use two constraints on the tetrahedra; deviatoric (skew) and hydrostatic (volume). In this video you seem to have replaced the deviatoric constraint for edge length constraints.
I assume this was for simplicity of demonstration; but can you describe how the behavior differs when using edge length constraints instead of the deviatoric one from the paper?
Kind regards.
I will probably do that when I will talk about the new paper.
Right, I used edges because the method is easier to understand and implement. The visual difference is not significant. I might do a tutorial on the neo-hookean model as well.
Dude, these videos are so awesome!
Wish me luck for my exam :D
Excited on the next video!
i'd like to mangle your attention again with my gratitude having had an opportunity to implement this. i did years of hacky modeling at audio rate, never occurred to me to use the actual step difference as velocity i'm dumb haha. now my ragdoll limb length is constrained, i can smoke that the same method can be used to model controlled movement by soft constraining towards an intended rotation, a 3d mass-spring if you drive the correction some. blah blah ok back to it.
Awesome! I Like your personality
Thanks for all these great demos. I want to see a soft body interacting with a fluid simulation! That would be incredible.
I’m actually working on combining the concepts in this video with some of your other videos to see if I can achieve this.
This is amazing! I've implemented the shape matching technique in 2D and loved it! :)
Thank you very much for these incredible videos that make your work very accessable!
Hi Matthias, thanks for the great videos and source code. It is a complete mystery to me why you don't have more likes. I would love to see your take on 2D soft bodies, and challenges such as incompressibility and shape matching.
Hi Matthias. Thank you so much for these videos, they are amazing.
I had one quick question. In this video and the last (vid 9), you show the form of a general constraint, and in the denominator of lambda you multiply the inverse masses with the length of the gradient squared. However in the code I see you are using a sqrt which is actual length (not length squared). I also saw in the paper that the terms are length squared as well. Would you please elaborate on why they are different? It might be something simple that I'm just not seeing.
Ah I think I get it after seeing another tutorial on this. In the distance constraint, the gradient n is a unit vector so the length squared is 1.
In the case of a distance constraint the lengths of the gradients are 1. I use the sqrt to compute the gradients. In the denominator of lambda, the lengths of the gradients don't appear for the distance constraint because they are one. For the volume constraint you see that I use vecLengthSquared
@@TenMinutePhysics Thanks :) Are the derivations for the gradients of the C functions anywhere?
I think the "unbreakable" thing can't be understated since Matthias is using a broken non conformal tetrahedral mesh and yet the simulation is still behaving quite nicely
Excited to see a new tutorial!
I'm trying to do some PBD with GPU,
I wonder how effecient is the multi-color gauss seidel, compared to the serial gauss-seidel?
Since multi-color GS is kinda of a multi-pass Jacobi solover, and Jacobi has worse convergence than serial GS...
Also, is it feasible to use distance field as a constraint or external force?
If that's possible, then PBD can be used for deformable surface tracking/registration!
I'm also trying to implement this on the GPU, but have problems with stability and especially energy conservation (eg. if th bunny is dropped it bounces higher and higher). Could you explain why you think that multi-color GS is like a multi-pass Jacobi solver? I don't see why it would be any different from serial GS since all the constraints solved in one pass are unrelated.
Thank you for your video! How do you convert the tetrahedron from Blender into the JS code you show in your softbody video?
help me
This content is amazing, but the code is a little hard to read sometimes. For example, the code for this particular video has a variable `grads` that is used in `solveEdges`. It took me a few minutes to figure out that it was just the direction vector.
With the current constraints and the current mesh, it is possible to bring the object to a state where all constraints are working against each other, stopping the object from recovering to its rest form. You can grab the slider and move it quickly between the allowed min and allowed max and eventually you will see what I mean. Same if you are alternating between squash/run rapidly.
Do you have suggestions to prevent this from happening?
I'm a new subscriber. This channel looks great! With the volume constraints are you implicitly assuming an incompressible medium? How to deal with compressible media? Where do the constitutive equations have been gone?
Great serie... but I think there is a little problem. When computing the mass of each particle, your divide the volume of the tets by 4 for the 4 points of the tets, and then invert it and add the invert to the invMass of the particle. But you should add the 1/4 of the volume as the mass, and when all adds are done, invert it, no?
Sorry for reviving your old comment but it got me curious..
It doesn't matter because the initial inverse masses for each particles are 0 here (initPhysics is called in the constructor right after creating the empty array for inverse masses).
He used the "+=" operator but it's only a basic assignation so using "=" would have the same effect in this case.
@@alexisdupuis5616, not really. It is true for the first tet, but then, as vertices are shared by other tets, it is no more the case. Take a pyramid with a square base for example. It is made of 2 tets, and 3 of the 5 vertices are shared by the 2 tets. So, when you compute the first tet volume, it is working... but for the second, it is no more working for the 3 shared vertices... that is why there an initialization to 0 and then a +=.
@@crouette Oh yeah I missed that. I think you're right then because the logic would be to have the inverse mass get smaller when the vertex is present in multiple tets, I guess (?)
I squashed 1 million tests and released them all at once... It did NOT break the internet :'( I'm disapointed
Awesome stuff besides that :D
I'm trying to implement this technique for a softbody simulation in Unity (using Compute shaders according to lessons learned from tutorial 16 "Simulation on the GPU"). In most cases, it works well with a fixed substep time of 0.0004s (50 substeps with 0.02s fixed timestep). But if I try to set the compliance (both edge and volume compliance are the same) to less than 1, it explodes. If I lower the substeps, it explodes. If the mesh hits the ground (even from a moderate height), it explodes. Any clue why this "unbreakable" simulation would be exploding?
I sort of solved it. According to tutorial 16 "Simulating on the GPU", a good "magic value" for averaging the corrections is 1/4. But this was not enough to maintain stability. Instead, I'm using 1/#adjacent constraints (to get the average correction over all of the adjacent constraints). Now the simulation doesn't explode (even with a 0 compliance) but (as is stated in the notes), momentum conservation is violated which causes the bunny to slide and start spinning like a figure skater eventually spinning out of control. Maybe this can be improved by damping the velocity?
@@oostenjadenhtv Hi, I'm also trying to implement this on the GPU in Unity for a uni project. I'm wondering if you managed to get a good simulation without momentum/energy conservation problems. I'm implementing it with the GS colouring method so I'm not applying corrections, but I get the bunny bouncing higher and higher. Do you know what could be the cause of this. Since you're applying corrections, I assume you're using Jacobi.
I'm also surprised that your simulation explodes for low compliance, as I have the opposite problem. For high compliances the bunny gains a lot of velocity very quickly.
At 12:50 : I often project Y coordinate of the 'predicted' position, in such out-of-boundary condition, not reusing the 'previous' position as in this tutorial. Is there a mathematical reason for discarding the predicted position or is there any issue when using the predicted position for such boundary projection?
Anyway, it's really valuable to see the implementation code from the developer of PBD. I really appreciate it.
is it good and fast enough for the real-time performance for scripting xpbd in python?
Give it a try and let me know!
I'm very curious. Why did this never caught on?
It seems to be the superior system for most use cases. I see videos from Miles Macklin about PBD from 8 years ago already. Are there some fundamental drawbacks holding it back? Is it too good to be true? or just a case of the industry not wanting to change something so fundamental as traditional physics simulations?
Hi Matthijs - it is being used in the gaming and film industry. Vellum, a physics engine for houdini is based on it for instance. Check it out, it is pretty cool :-) But yes, I think it could be interesting for researchers outside those industries. That is why I created this channel.
The fundamental drawback is that this modeling approach is not based on physical laws. In contrast, the continuum models are based on laws like conservation of mass and conservation of momentum. Therefore if the continuum model equations are discretized and solved accurately, the simulation result will satisfy the underlying physical laws. This is an important property for accurate prediction in real-world engineering applications. In games and films, satisfying physical laws is less important and therefore I can see why this simpler approach is valuable.
@@MichaelDodd1 I wasn't talking about real world engineering applications
how do I implement self collisions with this?
So the scale on the constraint error is arbitrary, right? As long as the gradients are correct and the error drops to zero when the constraint is satisfied, that '6' in the volume constraint just kinda cancels out? Does that also mean the signs are arbitrary? Negative and positive error are the same?
That's a great video
How is the data generated？"verts":[], "tetIds": [],"tetEdgeIds": [],"tetSurfaceTriIds":[],thank you very much
I will show that in upcoming tutorials
@@TenMinutePhysics Is that tutorial online now?
@@jelenalukic268 help me
@@TenMinutePhysics Hello Matthias. Firstly, huge fan of your simplicity. Can you point us out, how exactly were you able to get "tetIds": [],"tetEdgeIds": [],"tetSurfaceTriIds":[] from the obj file. The obj file from Blender simply gives face ids as "f 39//1 33//1 31//1 278//1" or some other numbers which is vertex ID// normal ID, but how to identify which vertices make the tetrahedral?? What was your regex like, when you tried to parse obj to JSON??
@@abhisheksinha3074 I am glad you like it. I hacked a script to converge the meshes generated by the tetmaker. I might put it online ifI find it again :-)
Can't this suffer from inversions of the tetrahedra under certain conditions?
No, they will always flip back due to the volume constraint. You can check the demo
@@matthimf Ah, because the gradient direction!
How to convert .obj to json?
👍👍👍
' I thought this was actually going to be satisfying and show Soft body animations because of the title... I am very disappointed ' - Chrome