@Vitor m the dt is not needed because here « velocity » is in fact the distance traveled since the last update so it’s already equivalent to velocity * dt
Me after spending 4 hours of pure suffering to figure out the problem then figuring it out and being so proud of my self. Then moving both of my fingers up to see the comment section and realizing that the first comment is addressing the problem 😭😭😭😭😭😭😭😭😭. It's even worse when I realize that I have tests and that I should have spend that time studying 😭😭😭😭😭😭. Please edit the video to save people from suffering like that. Or maybe it's just me whose that stupid |(>_
Thank you! And thank you for your videos as well, I found your channel very recently and I really like what you are doing! it seems that we have common interests :)
My understanding of the code is currently too limited, but I will definitely learn and come back to this amazing video, I have always wanted to do things like that. Amazing work again Pezzza, wish you all the best.
How ?! It looks so easy to implement and the result is awesome ! Thank you so much, each of your videos is a bigger mindblowing for me than the previous one
I suspect this is just the art of having studied some mathematics (multivariable calculus and linear algebra is probably enough). With math knowledge you can just take the equation and implement it.
The picture at the end? That's a cool effect and relatively easy to achieve. The foundation is the simulation must always produces the same results given specific input conditions. Knowing this, you run your simulation and keep track of each ball separately-it's sufficient to assign each one a unique ID. Once you have that, you run your simulation to the end so that all the balls reach their final positions. You then use the picture (like the one of the chicken) and map pixels from the picture to the balls in the final stage of the simulation. For example, if ball 1245 is at a certain position (x,y), you can take that as pixel coordinates and see what color is on the picture at that exact pixel location (say, for (x,y) it's "red"). Now you know that whenever you spawn ball 1245, it must be red. You then repeat mapping process for all the other balls and then re-run the simulation with the same starting conditions (e.g., how you spawn the balls) but with the newly assigned colors. That's it. Since simulation get the same input condition it will produce the same output, so our ball 1245 will end up in the same location (so will all the other balls), but this time is not randomly colored, but "red". And once the simulation is completed, (or reach the same state/frame as the one we used for mapping) all your balls will be in the exact the same positions we seen while mapping. And that would produce the final "balled" image.
You inspired me to learn C++ after fearing its complexity for months. I finally was able to learn C++ because of you. Please make more videos like this in the future. I enjoyed the teaching style and learned a lot. Keep up the great work man.
Thank you so much for your message, it is so cool to read ! I hope you will enjoy the possibilities that c++ offers! It’s a complex but very powerful language
Wow! Incredible. I can't believe how elegantly and simply you set up the code for a complex-looking and incredible result. I also can't believe how you fit this into a 9min video. You're incredible.
Bravo my friend, Bravo! An excellent look at the basic Velocity per frame physics engine and just how powerful circle collisions can be. I spent a moment trying to figure out why the velocity was updating before realising you were actually calculating it each step rather than keeping it persistent throughout. I'm going to play a little with the idea of calculating Velocity before applying motion to it, in 3D though since I work a lot on 3D character control systems and write the motion custom. This has been visually the nicest way to show the beauty of a physics engine.
@@PezzzasWork I do plenty of platformer gameplay systems, but usually keep velocity persistent rather than calculate immediately before applying the new step. Definitely something I want to try out, might end up making some cool stuff out of it too.
I find you right that moment and i am a software engineer in trainee... i can understand the code a bit and on the other hand i sit here and think, i know nothing about physics and simulations. Pretty mind blowing your work. This Bonus at the end.... HOW?? Thanks man, i cant stop to smile. :)
This is really cool, I always learn something new watching your videos! Implementing collisions and constraints by simply updating positions and having an integration function that can figure out velocity/acceleration is powerfully clever. Great explanation at the beginning, and the surprise picture at the end was a nice touch. Looking forward to your next adventure :)
The colored circles at the end turning into your logo was pretty bad ass. How was it done though? Running the simulation to see where each object ends up then running the simulation again and coloring each object based on its final resting point?
@@themikek99 Possibly, but Verlet integration is lossy when you add collision handling, so it would have to be a different process in order to be reversible. I think Stylex may have the right idea there. The process is entirely deterministic, so with the same conditions you'll always get the same outcome. You could run the simulation once, take note of where each object ends up, then color them accordingly, and re-run the sim to get the logo.
He probably read the image data and the. assigned the objects for some of the pixels and then gave them the velocity to make them move in the right way.
Your work is very impressive. Thanks for the video. It motivated me to implement this on the language I know the most, so I implemented it in Java. Finally after a couple of hours it worked fine. I implemented all the functions you demonstrated. Functions can be initiated from the menu. Additionally based on the chain example I implemented a rigid body. The last function will be the magic. You can open a picture and cut a part of it and that will appear as your logo did. I will share it as soon as it is done. So thanks again, nice job!
5:40 I was thinking the "perfect" solution to this would be, aside from sub-stepping, to add a bit of friction every time there is a collision, this would settle the objects quicker so they don't vibrate while stationary. Just multiply the vectors by 0.99 or something like that.
bro, this video is a masterpiece, my dream is to be a developer like you. i saw all your past and recent videos and every one of them are amazing! please, PLEASE keep the good work
Amazing! I've been trying to understand the programming behind physics and make my own 2D and 3D game engines. Visually appealing and informative video. Thanks. :)
I loved the video and really respect this channel! if you do a version with continuous collision detection then there is nothing more to expect from you!
I don't even know much about code, so this is already very helpful! And by helpful I mean I will probably keep rewatching this every time I want to do physics simulation.
It's amazing! You just taught me in less than 10 minutes what I wasn't able to learn on my own in weeks! Do you plan on uploading more videos like this in the future? It would be amazing to see how you deal with problems like tunnelling and static collision shapes
Smaller sub steps never hurts, but the part of the issue that really matters with verlet integration is that you typically need multiple iterations of the constraint resolvers. It enforces the constraints by moving the objects, but when it moves A and B to be correct relative to each other, it can make B and C worse relative to each other. Only the last pair of objects moved is guaranteed to honor their constraints. But if you run the constraint enforcement multiple times in a loop, it converges toward a solution where everyone is happy. Instead of putting a sub step loop around everything, if you take out the sub steps and just put a loop around applyConstraint() and solveCollisions() and have them repeat a few times, I believe you'll get even better results, and with less processing needed. Ideally what you want is to have applyConstraint() and solveCollisions() keep track of the largest distance they had to move something (within each loop iteration), and keep looping until that largest distance is below some threshold (when the constraints are "close enough").
I also thought at first that more constraint iterations would be better than sub steps but it has been shown that it is much more efficient to use small dt instead: th-cam.com/video/at6S8RkXQhw/w-d-xo.html
@@PezzzasWork Wow, I had no idea! Every reference I've seen has always done constraint correction iterations until an error threshold is satisfied. Thanks for the info! That's good to know.
The calculatoions are completely deterministic, meaning that it has no randomness involved. You can run the program once w/out color, and then apply the colors to each object; then just run it again but with the new colors applied and voilà
lol... was gonna write so many questions in another video, asking how to get there... now I found this clip before I would have sent that long comment! This is a clip to start with, I guess. Thank you for enabling me to at least try. Subscribed! Maybe you link this video clip in the notifications of other stuff you uploaded!
The concept of Verlet integration is actually super cool IMO, because it means momentum changes from collisions/etc are handled more or less automatically.
Max did that in 2002 while I was doing the AI. Great times. Max, if your read this: I'm really looking for you those last 20 years. Once I thought I found you while running around the Alster at night. In the dark and from afar a man with a dog looked just like you and I shouted "Max!", "Max!" while the man was just looking at me in disbelief. When I came closer very late I realized it wasn't you and the man asks me "Where do you know my dog from?". Turned out the mans dog was named Max. It was as funny as it was sad. Hope you're well.
THANKS A LOT!!! PLEASE, PART 2 some ideas: (I really excited about) rotation/angle, applyForce, applyImpulse, box shape, custom shape(polygon, array of Vec2 stroke and fill
I was literally trying to implement physics, then I though "wait a sec, Pezzza's Work as a video on that!" I'm surprised how well it works without even considering the forces between the objects or even their masses - it just moves the objects around based on an extremely simple set of rules.
This was fantastic. I loved the way you simply coded this complex looking problem. I was wondering what would it take if I wanted to add friction forces among particles.
I can't understand how thing is being applied, but i loved it especially the bonus clip 🔥 I have to learn alot to achieve this, nevermind i will do that
I remember Kaze Emanuar talk about using ray casting to calculate collision in between frames, an alternative to sub steps but may not provide realistic physics... I don't really know.
Why does just moving the objects if they don't satisfy a constraint work? I would expect this to continually add energy to the system. Would adding ghost forces work? Why does substepping work? Is it just because the timestep is smaller? Or is the "flickering" periodic allowing you to always render the same frame of the flicker?
It removes energy as well. Think about what happens when a ball falls straight down, accelerating due to gravity and then strikes the ground with a ton of velocity. All that velocity gets deleted because the object gets reset to a very similar position for more than one frame in a row. The substepping allows objects to "settle" more when dealing with collision corrections, but ultimately it is indeed the smaller dt that improves the behavior. The underlying problem is that the collision response is not necessarily recursive to other objects that are touching the objects being corrected. If you have three objects, A, B, C, that are in a row like that, overlapping then: 1) A and B will push apart when A gets updated 2) B and C will push apart, which pushes B back into overlapping with A 3) C will no longer be colliding So at the end of the pass there's a collision that was actually created by the collision solver. One way to deal with this would be to just run the collision solver several times per frame, but that can easily lead to unexpected volatile reactions. Multiple full simulation updates with shorter dt, on the other hand, masks some minor jitters and reduces the amount of intersection that objects will end up with, since they just don't have as much time to penetrate each other before they get a collision response. The downside, of course, is that you're literally multiplying your computation cost by the number of passes per frame, but Verlet integration is REALLY cheap, so there's plenty of room to trade off into.
Having written an impulse based physics engine using euler's integration, I have to say Verlet is so much simpler. Its cool to see how for collision resolution, simply changing their positions gives a realistic effect on the velocities. Definitely trying this out myself! I'm also very impressed at how fast this runs, with 3000 objects using brute force O(n^2) checking. If you had 10 substeps running at realtime, doesn't that means there's 3000^2 * 10 * 60 = 5.4 million checks per second! I didn't know c++ was this fast (im a python guy). With spatial hashing I can see this simple code running thousands of objects. One question, for the collision resolution for big to small objects, do you move them based on the ratio of their sizes? Or are they still moved 0.5 * delta * n.
A lot of high level languages are written in a lower level language, which in turn is written in a lower level language, etc. Python is a fabulous language for a lot of things - but not so good for making so many checks per second. However, it's a lot easier to use and manage than C++. I don't know what Pezzza did here, but there are defined math equations for how much collision impulse to apply to an object. A simple implementation of this would be adding a weight variable to each object which assumes they are all the same material, and calculates it based off their area. I don't know what the math is exactly off the top of my head, but it's out there. www.toptal.com/game/video-game-physics-part-i-an-introduction-to-rigid-body-dynamics This is one of many helpful resources I found online, and there are plenty more. :)
just wrote this in Python and the prgram dipped below 60 when #objects=100ish and quickly dropped below 30 when the #objects increased to ~130. Thought about doing thread pooling to alleviate the O(n^2) but then quickly realized the collision detection was implemented in a sequential way. Spatial partitioning might help a bit, but I am not sure to what extent - 3000 objects with 10 substeps at 60 FPS might still be too much for Python to handle. Assuming objects share the same density, we can factor in the size differences and compute the scaling factor (0.5) accordingly, i.e. larger objects would move less, smaller objects would move more. I still used 0.5 for collision resolution on objects with varying sizes, not the best way to simulate collision but meh it looked okay.
It is amazing how simple this is! This is also a really good tutorial!. I do have a question though, that is vaguely related: How could you resolve a collision with an immovable aabb, assuming the particle is also an aabb? Perhaps if I could work out the collision axis, I could then selectively choose x, y, or z to be set to the old version, but I can't find anything online. Some guidance would be appreciated.
![[TH] 2024 PMGC League | Survival Stage วันที่ 1 | PUBG MOBILE Global Championship](http://i.ytimg.com/vi/FVFT-PFwU80/mqdefault.jpg)
There is an error at 3:04 at line 41: it should be (radius - 50.0f).
Thanks to those who pointed it out to me!
@Vitor m the dt is not needed because here « velocity » is in fact the distance traveled since the last update so it’s already equivalent to velocity * dt
Me after spending 4 hours of pure suffering to figure out the problem then figuring it out and being so proud of my self. Then moving both of my fingers up to see the comment section and realizing that the first comment is addressing the problem 😭😭😭😭😭😭😭😭😭. It's even worse when I realize that I have tests and that I should have spend that time studying 😭😭😭😭😭😭. Please edit the video to save people from suffering like that. Or maybe it's just me whose that stupid |(>_
@@ziyadcodes sorry not sorry ¯\_(ツ)_/¯
Thank you soooo much I finally have it working
;)
I like how it really doesn't take much to create an amazing looking result (as long as you know what to actually implement of course). Nice video!
Thank you! And thank you for your videos as well, I found your channel very recently and I really like what you are doing! it seems that we have common interests :)
Waiting for your next video as well! (And btw the video on bloom was amazing)
engine guy :D
My understanding of the code is currently too limited, but I will definitely learn and come back to this amazing video, I have always wanted to do things like that. Amazing work again Pezzza, wish you all the best.
I dont even know what language it is lol, i was thinking C++ but not 100%
Maybe rust
It’s indeed C++ :)
@@PezzzasWork thought so, I'm more a java/c# man myself, want to learn c++ but struggle to wrap my head around some of the functions
C++ is a big and complex language, it's not easy to get into it
Wow I love this kind of content so much, thanks pezzza!
You're welcome :)
How ?! It looks so easy to implement and the result is awesome ! Thank you so much, each of your videos is a bigger mindblowing for me than the previous one
I guess thats the Sebastian Lague Effect😉
I suspect this is just the art of having studied some mathematics (multivariable calculus and linear algebra is probably enough).
With math knowledge you can just take the equation and implement it.
The picture at the end? That's a cool effect and relatively easy to achieve. The foundation is the simulation must always produces the same results given specific input conditions. Knowing this, you run your simulation and keep track of each ball separately-it's sufficient to assign each one a unique ID. Once you have that, you run your simulation to the end so that all the balls reach their final positions. You then use the picture (like the one of the chicken) and map pixels from the picture to the balls in the final stage of the simulation. For example, if ball 1245 is at a certain position (x,y), you can take that as pixel coordinates and see what color is on the picture at that exact pixel location (say, for (x,y) it's "red"). Now you know that whenever you spawn ball 1245, it must be red. You then repeat mapping process for all the other balls and then re-run the simulation with the same starting conditions (e.g., how you spawn the balls) but with the newly assigned colors. That's it. Since simulation get the same input condition it will produce the same output, so our ball 1245 will end up in the same location (so will all the other balls), but this time is not randomly colored, but "red". And once the simulation is completed, (or reach the same state/frame as the one we used for mapping) all your balls will be in the exact the same positions we seen while mapping. And that would produce the final "balled" image.
why struggle finding happiness when you can just watch this video? seriously its so relaxing and makes you feel like you have reached nirvana
You inspired me to learn C++ after fearing its complexity for months. I finally was able to learn C++ because of you. Please make more videos like this in the future. I enjoyed the teaching style and learned a lot. Keep up the great work man.
Thank you so much for your message, it is so cool to read ! I hope you will enjoy the possibilities that c++ offers! It’s a complex but very powerful language
Yeah, the hardest part of programming is overcoming the fear of complexity. It's what kept me away for years.
Beautiful work and thank you for showing how you did it. That was very interesting.
Also very cool ending
This video is a masterpiece in technical execution and artistry
I'm really glad to have found your channel after Sebastian Lague made the ant simulation video. The stuff you make is amazing!
I love the inclusion of the code itself seeing what it does is cool but being able to see how it was made is very cool imo
Please a part 2!
this was by far the most interesting and ACTUALLY HELPFUL video i have seen in a while
Wow!
Incredible. I can't believe how elegantly and simply you set up the code for a complex-looking and incredible result. I also can't believe how you fit this into a 9min video. You're incredible.
I always finish your videos in awe. This is what I aspire to be able to do with my knowledge of math and coding.
Bravo my friend, Bravo!
An excellent look at the basic Velocity per frame physics engine and just how powerful circle collisions can be.
I spent a moment trying to figure out why the velocity was updating before realising you were actually calculating it each step rather than keeping it persistent throughout.
I'm going to play a little with the idea of calculating Velocity before applying motion to it, in 3D though since I work a lot on 3D character control systems and write the motion custom.
This has been visually the nicest way to show the beauty of a physics engine.
Thank you very much! This should be directly transposable to 3D. I think it’s a good fit for what you are trying to do!
@@PezzzasWork I do plenty of platformer gameplay systems, but usually keep velocity persistent rather than calculate immediately before applying the new step.
Definitely something I want to try out, might end up making some cool stuff out of it too.
I find you right that moment and i am a software engineer in trainee... i can understand the code a bit and on the other hand i sit here and think, i know nothing about physics and simulations. Pretty mind blowing your work. This Bonus at the end.... HOW?? Thanks man, i cant stop to smile. :)
This is really cool, I always learn something new watching your videos! Implementing collisions and constraints by simply updating positions and having an integration function that can figure out velocity/acceleration is powerfully clever. Great explanation at the beginning, and the surprise picture at the end was a nice touch.
Looking forward to your next adventure :)
No idea how you made a physics programming video both beatiful and relaxing. Amazing work.
OMG I have been trying to figure out how to make a physics "engine" like this from scratch.
Can you make the .cpp files available in the description or tell me where I can find them. THANKYOU!!!
These simulations would have made great screensavers back when we needed those
The colored circles at the end turning into your logo was pretty bad ass. How was it done though? Running the simulation to see where each object ends up then running the simulation again and coloring each object based on its final resting point?
Maybe it's reversed? B)
@@themikek99 Possibly, but Verlet integration is lossy when you add collision handling, so it would have to be a different process in order to be reversible.
I think Stylex may have the right idea there. The process is entirely deterministic, so with the same conditions you'll always get the same outcome. You could run the simulation once, take note of where each object ends up, then color them accordingly, and re-run the sim to get the logo.
@@khatharrmalkavian3306 You could also bake the whole simulation, color the outcome and replay
He probably read the image data and the. assigned the objects for some of the pixels and then gave them the velocity to make them move in the right way.
If he did not do it in reserve i am interested on how he pulled it off....
Your work is very impressive. Thanks for the video. It motivated me to implement this on the language I know the most, so I implemented it in Java. Finally after a couple of hours it worked fine. I implemented all the functions you demonstrated. Functions can be initiated from the menu. Additionally based on the chain example I implemented a rigid body. The last function will be the magic. You can open a picture and cut a part of it and that will appear as your logo did. I will share it as soon as it is done. So thanks again, nice job!
will never regret subscribing to this amazing and talented channel
5:40 I was thinking the "perfect" solution to this would be, aside from sub-stepping, to add a bit of friction every time there is a collision, this would settle the objects quicker so they don't vibrate while stationary. Just multiply the vectors by 0.99 or something like that.
i tried that out and it pretty much worked, but it still wound up "vibrating". still went from ~30 fps to ~200, so a massive improvement
bro, this video is a masterpiece, my dream is to be a developer like you.
i saw all your past and recent videos and every one of them are amazing!
please, PLEASE keep the good work
You must have worked really hard to get where you are. You are really good at what you do
I used a translator so I don't know if what I said was strange 😁
@@aupaca nah not at all
@@aupaca the only problem with that sentence was the punctuation lol
@@TetyLike3 i dont see anything wrong with the punctuation
i love this channel :D
Thank you :)
Always love watching your videos for the cool content you tackle :)
Thank you :)
That chicken has glasses for a reason! So cool!
This video is gold and I will definitely have to come back to it in the future if I build something like this
Amazing! I've been trying to understand the programming behind physics and make my own 2D and 3D game engines. Visually appealing and informative video. Thanks. :)
I loved the video and really respect this channel! if you do a version with continuous collision detection then there is nothing more to expect from you!
This is amazing! Thank you so much for your help! I've always wanted to make a physics engine, and I'll definitely implement this in Rust! :D
I don't even know much about code, so this is already very helpful! And by helpful I mean I will probably keep rewatching this every time I want to do physics simulation.
That ending was..... unexpected
Nice cock
I'm glad I subscribed to you, this vid made me really interested in making my own physic engine
Phenomenal work ur doing here man
This makes me want to go back to school and learn programming. Simply Amazing!
The end was really cool!
That is just incredible!
My cat was very interested in the chain!
It's amazing! You just taught me in less than 10 minutes what I wasn't able to learn on my own in weeks!
Do you plan on uploading more videos like this in the future? It would be amazing to see how you deal with problems like tunnelling and static collision shapes
Can’t wait for part 2: Writing a Physics Engine in Scratch
This video greatly benefits my coding skills! Thank you for the explenation!
Wow it literally felt like magic how it just simply worked with such little effort and code
Smaller sub steps never hurts, but the part of the issue that really matters with verlet integration is that you typically need multiple iterations of the constraint resolvers. It enforces the constraints by moving the objects, but when it moves A and B to be correct relative to each other, it can make B and C worse relative to each other. Only the last pair of objects moved is guaranteed to honor their constraints. But if you run the constraint enforcement multiple times in a loop, it converges toward a solution where everyone is happy.
Instead of putting a sub step loop around everything, if you take out the sub steps and just put a loop around applyConstraint() and solveCollisions() and have them repeat a few times, I believe you'll get even better results, and with less processing needed.
Ideally what you want is to have applyConstraint() and solveCollisions() keep track of the largest distance they had to move something (within each loop iteration), and keep looping until that largest distance is below some threshold (when the constraints are "close enough").
I also thought at first that more constraint iterations would be better than sub steps but it has been shown that it is much more efficient to use small dt instead: th-cam.com/video/at6S8RkXQhw/w-d-xo.html
@@PezzzasWork Wow, I had no idea! Every reference I've seen has always done constraint correction iterations until an error threshold is satisfied. Thanks for the info! That's good to know.
Excellent work and a beautiful result
this is so sick, can’t wait to get as advanced as u lol
Unreal! Very Enjoyable! Thank You!
I don't understand how you achieved the last one and that bug me a lot ! . Anyway, this is truly amazing ! I learned so much from it. Thank you !
It deterministic, and done in two passes.
The calculatoions are completely deterministic, meaning that it has no randomness involved. You can run the program once w/out color, and then apply the colors to each object; then just run it again but with the new colors applied and voilà
This is the most underrated coding channel ever. Your videos are so high quality
Wow, looks so simple and elegant! Great job, looking forward to more videos like this one!
Amazing tutorial, and the ending was such a twist!
Thank you for this, I used it to make a 4D gravity simulation in Godot 4!
Good choice of music. Nicely demoed. Solid video.
Awesome! Great tutorials and Great help!
Oh my god, that is so beautiful.
Absolutely AMAZING! I will try and replicate in C# now.
I'll try to do it in scratch
I was having the same idea since I'm rooted in C# myself. Did you get it done? Share?
Love ur content, great to see a "behind the simulation" video ! Amazing :D
Very cool demonstration. Great work.
:O Especially the end blew me away!
Amazing tutorial! Worked really well even when using a different language!
lol...
was gonna write so many questions in another video, asking how to get there...
now I found this clip before I would have sent that long comment!
This is a clip to start with, I guess.
Thank you for enabling me to at least try.
Subscribed!
Maybe you link this video clip in the notifications of other stuff you uploaded!
The concept of Verlet integration is actually super cool IMO, because it means momentum changes from collisions/etc are handled more or less automatically.
Love these endings, keep it up
The ending got me. Nice work!
You scared away half of the people away with the equation as the first thing in the video.
But I’m all here for it
Nice video man! A wiki article and your video helped me very much.
what a master piece!
Max did that in 2002 while I was doing the AI. Great times. Max, if your read this: I'm really looking for you those last 20 years. Once I thought I found you while running around the Alster at night. In the dark and from afar a man with a dog looked just like you and I shouted "Max!", "Max!" while the man was just looking at me in disbelief. When I came closer very late I realized it wasn't you and the man asks me "Where do you know my dog from?". Turned out the mans dog was named Max. It was as funny as it was sad. Hope you're well.
Just using the colors makes this so much better lol.
THANKS A LOT!!! PLEASE, PART 2
some ideas: (I really excited about)
rotation/angle, applyForce, applyImpulse, box shape, custom shape(polygon, array of Vec2 stroke and fill
I was literally trying to implement physics, then I though "wait a sec, Pezzza's Work as a video on that!"
I'm surprised how well it works without even considering the forces between the objects or even their masses - it just moves the objects around based on an extremely simple set of rules.
I'm so glad youtube recommended this video to me. How did I not know about this??
This was fantastic. I loved the way you simply coded this complex looking problem. I was wondering what would it take if I wanted to add friction forces among particles.
The ending logo showing up was like magic.
that ending felt like an assembly theory flex before its time, wow.
Awesome dudeee, I never get bored watching your videos. A subscriber btw, keep it up!🏃
Thank you!
This video made my day!
yes!!!!!!! love the video please make more of them!!!
I can't understand how thing is being applied, but i loved it especially the bonus clip 🔥
I have to learn alot to achieve this, nevermind i will do that
Thanks for this great video!
the jaw dropping last scene!!!
felt like magic show
That ending was lit.
I remember Kaze Emanuar talk about using ray casting to calculate collision in between frames, an alternative to sub steps but may not provide realistic physics... I don't really know.
amazing effect
Nice ending! It's the reason I subscribed :-)
At 3:04, at line 41 in your code, we should scale vector `n` by (radius - 50) instead of (dist - 50).
Three words: epic!
Omg the ending ... was ... amazing... just how ???
Why does just moving the objects if they don't satisfy a constraint work? I would expect this to continually add energy to the system. Would adding ghost forces work?
Why does substepping work? Is it just because the timestep is smaller? Or is the "flickering" periodic allowing you to always render the same frame of the flicker?
It removes energy as well. Think about what happens when a ball falls straight down, accelerating due to gravity and then strikes the ground with a ton of velocity. All that velocity gets deleted because the object gets reset to a very similar position for more than one frame in a row.
The substepping allows objects to "settle" more when dealing with collision corrections, but ultimately it is indeed the smaller dt that improves the behavior. The underlying problem is that the collision response is not necessarily recursive to other objects that are touching the objects being corrected. If you have three objects, A, B, C, that are in a row like that, overlapping then:
1) A and B will push apart when A gets updated
2) B and C will push apart, which pushes B back into overlapping with A
3) C will no longer be colliding
So at the end of the pass there's a collision that was actually created by the collision solver. One way to deal with this would be to just run the collision solver several times per frame, but that can easily lead to unexpected volatile reactions. Multiple full simulation updates with shorter dt, on the other hand, masks some minor jitters and reduces the amount of intersection that objects will end up with, since they just don't have as much time to penetrate each other before they get a collision response. The downside, of course, is that you're literally multiplying your computation cost by the number of passes per frame, but Verlet integration is REALLY cheap, so there's plenty of room to trade off into.
Having written an impulse based physics engine using euler's integration, I have to say Verlet is so much simpler. Its cool to see how for collision resolution, simply changing their positions gives a realistic effect on the velocities. Definitely trying this out myself!
I'm also very impressed at how fast this runs, with 3000 objects using brute force O(n^2) checking. If you had 10 substeps running at realtime, doesn't that means there's 3000^2 * 10 * 60 = 5.4 million checks per second! I didn't know c++ was this fast (im a python guy). With spatial hashing I can see this simple code running thousands of objects.
One question, for the collision resolution for big to small objects, do you move them based on the ratio of their sizes? Or are they still moved 0.5 * delta * n.
yeah youd be surprised how unoptimized python is. its strength is quick prototyping and library integration but thats about it
A lot of high level languages are written in a lower level language, which in turn is written in a lower level language, etc. Python is a fabulous language for a lot of things - but not so good for making so many checks per second. However, it's a lot easier to use and manage than C++.
I don't know what Pezzza did here, but there are defined math equations for how much collision impulse to apply to an object. A simple implementation of this would be adding a weight variable to each object which assumes they are all the same material, and calculates it based off their area. I don't know what the math is exactly off the top of my head, but it's out there.
www.toptal.com/game/video-game-physics-part-i-an-introduction-to-rigid-body-dynamics
This is one of many helpful resources I found online, and there are plenty more. :)
just wrote this in Python and the prgram dipped below 60 when #objects=100ish and quickly dropped below 30 when the #objects increased to ~130. Thought about doing thread pooling to alleviate the O(n^2) but then quickly realized the collision detection was implemented in a sequential way. Spatial partitioning might help a bit, but I am not sure to what extent - 3000 objects with 10 substeps at 60 FPS might still be too much for Python to handle. Assuming objects share the same density, we can factor in the size differences and compute the scaling factor (0.5) accordingly, i.e. larger objects would move less, smaller objects would move more. I still used 0.5 for collision resolution on objects with varying sizes, not the best way to simulate collision but meh it looked okay.
thank you for this!
Wow this code is mind blowing🤯
I'm really not sure about your explanation of the method at the beginning, but really nice video!
Awesome video!!!
beautiful
Impressive !
It is amazing how simple this is! This is also a really good tutorial!. I do have a question though, that is vaguely related: How could you resolve a collision with an immovable aabb, assuming the particle is also an aabb? Perhaps if I could work out the collision axis, I could then selectively choose x, y, or z to be set to the old version, but I can't find anything online. Some guidance would be appreciated.