Wonder why so few followers.... Every graphics researcher & developer should follow this channel. Everytime I see the name "Müller" in any real-time physics simulation paper, I know it's gonna be good.

This channel is a gold mine

Your videos are amazing, thank you so much! I started watching because I wanted to try to implement XPBDs in Blender and I can't wait for the tutorial about rigidbodies!

Thank you so much!. I can't believe that I have the opportunity to directly learn from Matthias Muller!!!

Thank you so much! So many other resources are filled with fluff, but this is clean and straight to the point. Perfect introduction for someone with physics/math background who might be interested in simulations

This channel actually has the best most helpfull easy to under stand information i could find for the past few weeks. Thank you ❤

Thank you for these videos. They are a fantastic supplement to your papers.

This video is incredible! Everything is making sense now, thank you for sharing!

Thanks matthis, great stuff. Really cleared things up for me.

Hey dude. Your videos are great. This series is fantastic

single most brilliant cg physics channel!

Thank you so much! Unvaluable learning material...

Fantastic work! Very helpful!

I am always so excited to see a new video from you! Your work makes writing physics simulations fun. Thank you! P.S. The tires in the rc car demo dont use the volume conservation constraint, do they? That would be a nice improvement.

Very excellent tutorial!

I wish I could follow even a little of this. It looks very cool.

I'm a great fan, hope to be on your team some day.

Thank you for another amazing tutorial, I was so excited by your demos in the rigidbody PBD paper I have decided to write my College Master's Thesis on the topic :D You truly are making a great job at making physics simulation more accessible than ever. I'm planning on comparing the results while using Gauss-Seidel methods, Jacobi(on GPU) and SSOR or any other variations I can find. Any tips? I would also love to know more about how you did that inverse kinematics demo!

The comparison of force, impulse, and position based simulation gives me a clue (although not mathematically understandable yet) why they make such different characteristics. For more than a couple of years of studying how to make physics code , I've looked through those three ways, but failed to figure out why modifying the particles' status via force/velocity/position makes so different ends - apart from using different integration schemes -. You are the first teacher for me to give such a 'big picture' of simulation methods using easy words. Thank you!

Thank you for this wonderful video Matthias. Is there a mathematical difference between increasing the number of substeps by a factor N, and reducing the timestep by a factor N? Or are we just playing with the refresh rate of the plotting function in this case, with the underlying math being identical?

Thank you for this fantastic channel, very helpful. How you would setup a friction constraint, static and dynamic? Do you have a video or paper on that?

Thank you very much! I hope I could implement a physics engine from scratch based on your video in Rust! So if we want to add constraints to prevent an object hitting a wall, does that mean the constraint has to be applied to all inner particles of the object? or we need to precalculate the convex points somehow and only apply constraints on those? Can we skip some calculation based on the distances between the wall and particles. what about a softbody hitting a wall? I also hope you could compare the technical choices of some of the most famous physics engines (if they are not position based), like mujoco, physx and bullet etc. Basically I'm curious if XPBD should be the way to go to implement the ultimate physics engine for a game engine? For example, why does NVIDIA have both physx and flex, is physx not PBD? I also hope, in the later stage of this series, you could cover some approaches on implementing XPBD on GPU. Thanks!

these videos are great. I'm struggling to understand how you would do the constraints simultaneously. How would you vectorise applying the delta distances from the edge length constraints?

Hi, First of all, thanks for your tutorials, they are really fantastic Also, I was trying to understand and reproduce your softbody demo, I was able to use tetgen in order to create some tetmeshes, and export tetras, tris, edges, vertex data However I'm having hard time to understand how you generated thoses variables: dragonAttachedTrisIds, dragonAttachedVerts By looking at your demo the tetramesh seems to approximate the base mesh (Likely for performances reasons) and the real mesh is just "pinned" by some vertices to the tetramesh softbody simulation Am I understanding it correctly ? Also how did you achieved to generate the dragon simplified tetramesh and keep the vertices "match information" with the base mesh ? Thank you !

fascinating how this is so similar to how deep learning algorithms work by seeking the minimum error

Can everything still be achieved with only local constraints (a list of constraints attached to a single particle that the particle itself accounts for in its own update)? Or do you need to introduce global constraints that themselves contain a list of participating particles?

Hi Matthias, Thank you for you work in popularizing of physics simulations. Just got impression that slide "Example: Distance Constraint" has wrong signs in expressions for grad(C_1), grad(C_2) and delta(x_1) Did I miss sign somewhere? Thanks, Andrii.

Thanks for the video! For collision detection in substeps, is it recommended to do the collision detection every substep or do we do it once only at the start of the simulation? Is there any cost or benefit from both methods?

at 15:00 shouldn't the gradient vectors have length 1, and thus be equal to the normalized cross products of the opposite vectors, instead of just the cross product?

Hi, first thank you again. I posted in your other channel but then saw that you had moved over to this channel so I want to post my question here as well: Thank you for this video, I have been attempting to implement PBD with some degree of success for ropes. But once I tried to give the rope some stiffness it becomes very unstable, especially if I enforce length-preserving constraints at the same time such as LRA. But even without LRA it is quite wobbly and not stable enough. I'm trying to avoid using additional "ghost" particles to enforce stiffness because of performance issues. Do you have any tip on how to give thin ropes some stiffness like rods while keeping stability?

Why did you not use the stiffness/compliance parameter in the calculation of the correction step/the Lagrange multiplier in the "Example Distance Constraint" section? I am a little confused, how would the stiffness actually come into play in this constraint for XPBD? Thanks for this great video and your contribution to computational physics!

Could you please upload an example of this in python or c++ as a guide?

Hi ! I don't really understand why at 1:45 you say a large stiffness implies stability problems ? I don't know if the link is obvious, but for me it isn't so if anyone has an explanation I'm open to it ! Thanks for all the work and resources you put out :D

What I found is that when using only one iteration the velocity error is too big that results in instability. I need at least 2 iterations to get stable results. Also too many substeps leads to vibrations, not exactly sure why but I guess it’s because the velocity gets bigger when the delta time is really small. When solving collision or distance constraint, the position change is irrelevant to delta t, so if you have a small delta the velocity is much bigger.

I am a soft brained Person yet some how i can understand 10/10

Hi Matthias, I've tried adding the alpha/(dt *dt) change into the lambda calculation for my position based fluids solver, but it doesn't have the effect of creating timestep independent stiffness, instead it really reduces the constraint forces drastically based on timestep. the XPBD paper is pretty dense, and I haven't been able to find any implementations of XPBD for fluids.

does XPBD not have a factor of lambda*alpha to the numerator of the calculation of lambda?

2:20 Why does't impulse-based simulation have overshooting problem? How exactly does it control velocity update?

Confused about gradient calculations C1 and C2. C1 is shown visually as facing the opposite direction of C2, and yet its calculation is the same. Shouldn't it be X1 - X2 to go from X2 to X1?

i thought i'd never find meaningful documentation for projective dynamics :O you're probably aware; for those who aren't, the spring constant k = -w * w (w = angular frequency, 2 * pi * hertz/samplerate) i feel so privileged to find this secret video, but i'm still not going to their lodge, ever.

couldnt you use this to simulate fluids by enforcing a constraint that guarantees an equilibrium of density? So fluid particles must satisfy a constraint where no density is much higher than the neighboring densities? _

Beware. As written in 5:55 or 7:06, you get inconsistent results with permutations. Consider a chain of N identical particles ABC...Z, linked with N-1 distance=1 constraints, one between A and B, one between B and C, etc. Assume the order of constraints is AB, BC, .... Now, let's say something shoves particle A by 1/2 a unit towards B. What happens? The AB constraint updates, moving A back 1/4 unit and B forward 1/4 unit. Then the BC constraint updates, moving B back 1/8 unit and C forward 1/8 unit. Net result is an exponential decay, but, notably, particle Z is affected in a single timestamp. Now, let's say something shoves particle Z by 1/2 a unit towards Y. What happens? The YZ constraint updates, moving Y back 1/4 unit and Z forward 1/4 unit. And then... that's it. That's the timestep. X isn't affected at all in the first (sub) step, and in general, the effective speed of sound is one unit per (sub)step. In other words, the speed of sound is dependent on update order of constraints. A relatively straightforward approach to avoid this is to accumulate updates instead of updating positions 'in-place' in the constraint loop. Unfortunately, this does require additional memory, and also results in a speed of sound of 1 constraint / (sub)step, which can be good or bad depending. There are other more complex approaches, of course. For instance, color the constraints graph such that no two constraints with the same color share a particle, and iterate over constraints in order of color. This also allows for parallel solving without locking, as all constraints with a given color operate on independent sets of particles. Maintaining a dynamic graph coloring, even approximate, is itself a task, however. And this approach falls over if you have a single particle with many constraints. The other main issue with this approach is that it often ends up dissipating excessive amounts of energy. Consider your bead on a wire example again. Your projection to the nearest point on the wire results in a slightly shorter distance than the original timestep. And as that is used to calculate the next velocity vector, this means that every timestep the velocity of the particle decreases. Luckily, in this example the velocity loss per timestep scales with timestep^3, and so the velocity loss per unit time scales with timestep^2, but this still can be a problem in some cases.

You are like Jesus to me Matthias ┌[ ◔ ͜ ʖ ◔ ]┐