Allelouia!!! This video is amazing!!!! Bravo for all the preparation work to make the subject understandable!!! I discover your channel today. I will look at the rest very closely. 1000 times thank you!
Man I recently discovered your channel, the quality of the way you teach is crazy! gonna start binging on your courses starting with the NES course. Thanks for all your content, keep going!!
Hallelujah! Finlay got some time to resume the physics course and watch this video! Great video, loved the explanation and comparison between different integration technicians.
Absolutely stellar job with the lecture! Your dedication and effort are clearly visible in the content you've created, making it both insightful and engaging. I sincerely appreciate your hard work in enlightening us on such an interesting topic. Keep up the fantastic work!
I really enjoyed the talk about euler integration and all the others, both as context to verlet, and also due to having user Euler's method a lot and didn't know of the negative sides of it. Really interesting :)
That's some amazing and much better explanation than my professor in university. Thanks for sharing your knowledge you earned my respect and a subscriber i can't wait to see more videos on game dev.
I’m writing a simple 3D game right now for fun but it was time to implement physics and was struggling until I found an old PDF explaining Verlet integration. The PDF was great, but as I searched on Google for a couple questions I had, TH-cam started recommending stuff and that’s how I found this video. This was amazing. Such a great explanation. I’m going to go back and watch the rest in order (watched all of this and also just watched your video on Calculus at the beginning of this playlist) I was pretty happy with the results of my initial (very simple) implementation converting the code to work in 3D, but I still need to implement more to support collisions with polygons, angular momentum, etc. You are a fantastic teacher. I’ve been up all night wondering how I’m gonna implement angular momentum but I have ideas now. I’m also very curious about stability (especially in 3D which seems very prone to instability?) I noticed you have a physics engine course! With a baby I only get an hour here and there to work on this stuff so not sure if I’ll be able to watch the 35 hours- but planning to buy just to support this work and maybe I’ll be judicious about which ones I watch. I can try fill in gaps in my knowledge enough to help me with my project.
Really good video. I like how you take time to show how you think through the problem. The text is a little small and the background a little light to read the text, but outside of that, great explanation. You explained something I saw in my own code years ago.
man, thanks, really, yesterday I was all day trying to make a simple pendulum movement using topics I've learned in my Physics 1 class, ending up almost surrendering... now, I've followed your tutorial and I'm amazed at how automatic and simple this is, I tried making an immobile point and another connected to it, and there it was, perfect pendulum motion... I'm trying different shapes and I burst laughing to myself out of amazement.
Thank you so much for this video! I needed to make rope physics for a project and at first i didnt understand anything from wikipedia but this video made it really simple.
Awesome video Gustavo! As per your note at 55:00, I actually didn't like any of the 2 options you showed - what I did for a Breakout clone I wrote once, was to to the proper reflection vector calculation and collision resolution - which would work for both the verlet and Euler methode: Say you have position A just before a collision with a wall and point B inside the wall, and lets assume a 0 diameter collider (point) - to resolve it you can consider the progression from point A to B as a lerp (linear interpolation) with a normalized 't' value of 1 at B. At some point C with some 't' value, the point is right at the wall. That 't' value is easy enough to compute using the 'x' coordinate of the wall and that of A and B : t = (Wall.x - A.x) / (B.x - A.x). That 't' value can then be used to compute the 'y' component of C so you get: C = {Wall.x, (A.y + t*(B.x - A.y))}. Then, to add the remaining movement that would be bounced in the opposite x direction, you take the remainding portion of the vector (B - A) that is left after subtracting the first part of the movement from A to C: (B - A) - C and mirror it across the Y axis by negating it's x component. Then you add that resulting vector to C to get where a bouncing point would end up at - precisely. That's streight forward for the Euler methode, then for Verlet you could just mirror the first portion from (from A to C) across Y as well, and subtract it from C to get what an "old position" 'would have been' if the point was going in a streight line from somewhere inside the wall towards the final resulting point - maintaining the proper "velocity" that would have been, so no loss of energy from the wall-bounce, etc. Then, for a non-0 point collision (say a circle) it gets a bit more complicated, as it would hit the wall at a non-trivial point to compute (when it's radius along X would have it's horizontal bound at the wall, which for some diagonal direction would be before the point-based collision would be)
Hey Arnon, good to see you here! That's the good stuff right there. Thanks for the breakdown. 🙂 Would you still use this same method if you were coding this solution for a *super* slow machine?
@@pikuma Hey Gustavo :) I think so? Donno what super slow would be exactly, but I cant see why that approach would be an issue for just the walls as resolving it for purely vertical / horizontal walls like that is pretty cheap overall, and it is also cheap to check for whether that even needs to happen on a per frame basis (I mean at least for the Breakout clone case where there are just 2 horizontal and 2 vertical walls). Collision detection and resolution can get way more complex and expensive than that, for example this does't even test for "tunnelling" (going through 2 consecutive walls next to each other at high velocity) and also does point-based detection and resolution (as opposed to circles or anything else with non-zero surface area). For those there's the Minkousky Sum and something fancy called GJK (Gilbert Johnson Keerthi) that is typical one to use as is very general yet robust (Haven't looked into that one myself but I know it should be more expensive). It typically gets to ray-casting at some point in some form. And then there's the whole spatial acceleration structures that become necessary at some point, like a quad-tree or an oct-tree for 3d to localize the search space for possible colliders - in short, yeah - it all can get way more expensive then what I suggested, which is still very minimalistic by comparison.
This was my solution to the bounds issue. Should be a perfect reflection, accuracy determined by how small dt is. Just draw it out, you'll see by swapping the X or Y components of previous and current, we get a basically perfect reflection, with the same magnitude, and a reflection hit point right near the axis (again accuracy determined by dt, smaller dt, closer to axis). You may want to do extra checks to make sure that particles don't get stuck zig-zagging by spending 2 consecutive frames out of bounds, but in my testing I didn't need it. Integrating prior to constrains seems to make it unnecessary. I did however have to add and extra check since I have a floor that is independent from my bounds type. Pseudocode: VerletIntergrate(); if( position.x < x_min || position > x_max) swap y components of previous and current; if( position.y < y_min || position > y_max) swap x components of previous and current ; Actual code: //| Verlet Integration // Determine velocity for readbility, reset previous position float2 clampedVelocity = Vector2.ClampMagnitude( point.position_current - point.position_previous, physicsProperties.maxVelocityMagnitude ); point.position_previous = point.position_current; // integrate point.position_current += clampedVelocity + point.acceleration * (deltaTime * deltaTime); point.acceleration = float2.zero; //| Contrain to bounds // NOTE: We do this part after the integration so that it doesn't get pushed back down below the bound limit. // NOTE: If we did it before, and the new position ended up below the limit twice in a row it could cause zig-zagging, and a stuck point. // Do the floor bool floorWasUsed = false; if (physicsProperties.useFloor) { if (point.position_current.y < physicsProperties.floorHeight) { // Cache and swap the y components float cached_position_current_y = point.position_current.y; point.position_current.y = point.position_previous.y; point.position_previous.y = cached_position_current_y; floorWasUsed = true; } } // Do the other bounds switch (physicsProperties.boundsType) { case PointMassPhysicsProperties.BoundsType.BOX: float max = physicsProperties.boundsLength; float min = -physicsProperties.boundsLength; // Bounds X if (point.position_current.x < min || point.position_current.x > max) { // Cache and swap the x components float cached_position_current_x = point.position_current.x; point.position_current.x = point.position_previous.x; point.position_previous.x = cached_position_current_x; } // Bounds Y if (point.position_current.y < min || point.position_current.y > max) { // If we already hit the regular floor, don't also hit the box floor // ...or we might get a point stuck zig-zagging // Note that this never seems to trigger. // Note this is despite testing with a 0.001 gap between floor and box floor, and with gravity being toggled from 9999 to -9999 and back (instead of the usual -9.8) if (point.position_current.y < min && floorWasUsed) { Debug.Log("Can't hit box floor, already hit normal floor!"); break; } // Cache and swap the y components float cached_position_current_y = point.position_current.y; point.position_current.y = point.position_previous.y; point.position_previous.y = cached_position_current_y; } break; } //| Push the point pointsWrite.TryAdd(pointID, point); }
Shouldn't the bounced ball follow the trajectory it was going in but mirrored? If we displace only the X we are misplacing the bounced object right? I would just mirror the old X relative to the line it crossed and mirror the current X the same way.
I think using semi-implicit Euler method you can increase accuracy even more by updating current velocity using gravity, then using the average of the previous and current velocity and then update the position, this applies newton's kinematics equation d=1/2*(vi+vf)*t which states position is the average of the initial and final velocities multiplied by time
what verlet allows you to do which i dont think is as good in euler integration, is have restitution in the objects, so a value of 0 makes the constraint absorb all the energy (along the normal of the constraint surface), and a value of 1 makes energy in = energy out. As for bouncing off a wall, i would instead of first iterating forward and then detect a collision, i would rather use a line-line intersection test or a ray tracing method to find the intersection between the object and the surface of the constraint, then use the same approach as you to move the previous position in the wall. this is a pseudo-code f this: for each line in constraint_lines { if line intersects with the objects "velocity_line" { // I define the velocity_line as being a line from object_pos to 2 * object_pos - object_prev_pos let object_vel = object_pos - object_prev_pos; object_pos = intersection; let line_vector = line_b - line_a; let normal = normalize(line_vector.y, -line_vector.x); let vel_inverted = object_vel - 2 * dot(normal, object_vel) * normal; // Use Ray Reflection formula to get a reflected vector from the surface normal let object_prev_pos = object_pos - vel_inverted * line_restitution * object_restitution; // I don't know if this is the proper way of combining objects with different restitutions } } i think this should give a accurate result if i'm not mistaken or got a math error anywhere. The best part about this is that it can be expanded into 3D pretty easily, just change the line intersection tests with surface intersection tests or triangle-ray intersection tests and the rest would be the same
Great video thank you, finally got to practice verlet integration with constraints for real! I tried to reproduce the example in a slightly different context to create hanging cables, it looks great but one issue that I encountered is that you don't use the delta-time in your stick update function, I did not either, and it messes up totally the results each time I have a slow-motion effect (the sticks are not using delta time thus they move the points waaaaaay more than they should). To fix this I tried to multiply the offset_x and offset_y by the delta time (and also multiply by an arbitrary value to compensate the decrease) but to my surprise this didn't worked, the problem persists the same. What could be done to implements this example in a way that if we multiplied the deltatime by some value before it goes to the points and sticks the results will be the same but slower/faster, and not something totally different?
I think in the case of semi-implicit Euler integration, when the initial velocity of the particle is a zero vector, then the system will actually conserve energy, keeping the particles bouncing forever. If we initialize the start velocity to some small random values then we'll actually observe loss of energy.
When we move from points to sticks. The system is no longer conserving energy. It is loosing energy. What's the reason for that? Also what numerical methods are used for calculating mission trajectories and planetary orbits for space missions?
Storing the current position and the old position requires a constant delta T. In a system where delta T can vary, it would be better to store the current acceleration and prior acceleration (and if you include jerk, the prior prior acceleration).
When you talk about different integration methods having different levels of accuracy, does that also mean that more accurate methods help prevent a simulation from exploding or becoming unstable (something I care about) or is it only about accuracy in terms of following trajectories for example (something I don't care about)?
Sorry, but I have another question: Is it possible to use verlet integration but instead of storing the current and previous position, you just store current position + velocity or previous position + velocity? After all, we should be able to convert between the two-position representation and position+velocity very easily. For example, sometimes you may need the velocity readily available, instead of having to recompute it every time by subtracting the two vectors. Would this make sense or does it break the verlet properties?
Also to solve your boundary reflection problem, there's actually a correct and dead-simple method (which is also more accurate than your Euler method). Idk if you are unaware of it or you are aware and just asked us as an exercise. You just subtract the wall's coordinate from your new coordinate and then flip the vector. Keep the other component unchanged. *Example when hitting the wall on the right:* old_pos.x = wall.x + (wall.x - old_pos.x); old_pos.y = old_pos.y; // Unchanged pos.x = wall.x + (wall.x - pos.x); pos.y = pos.y;
if x>boundary: then (x=boundary-(x-boundary)) and (old_x=boundary+(boundary-old_x)) else do notting??? Its like mirroring the position over the boundary line/value if it has crossed the boundary.
In the case of updating a stick where one point is pinned and the other is not, shouldn't the adjustment in the position of the point that is not fixed be twice what it is as implemented in the current code? Otherwise it seems that you are adjusting the stick position only by half of the actual difference on length change.
I have a question, verlet only need acceleration to update position. but in most case, we must provide velocity not acceleration, so in this case how can we update position by velocity
Question though, can you explain why the semi explicit euler loses energy over time? I see that reason in explicit euler, the velocity continually increases, but I'm not seeing where that would be different by just flipping the order of the equations in the semi-explicit version? Thanks.
Looks awesome. Also implemented some stuff of it. But one thing i don't understand is why acceleration is multiplied twice with dt. When i calculate the velocity then it is the velocity between two frames. This is why velocity is divided by dt to get the velocity for one second. But as we are frame dependent we multiply again by dt. So in the end the division and multiplication of dt cancels and we just can add the velocity as it already is the velocity for one frame step. Same goes for acceleration. I would just add (acceleration * dt) to get the acceleration for one frame. But in Verlet it has to be (acceleration * dt * dt). Why?
I figured it out. In Euler we do add "acceleration * dt" to velocity. But then again just "velocity * dt" is again added to the position. So for acceleration it turns out to be "velocity * dt * dt" that is added to position. Btw. thanks for the video, its really great and your content is awesome.
1:10: I personally would have preferred a geometric explanation using the proportion of similar triangles: The smallest triangles are similar to the largest one so they have the same proportions, and they are smaller than the largest one by the amount that their hypotanous (diff/2) is smaller than the largest triangle's hypotenous (dist). Tha is, the scaling factor between the smallest triangles to the largest one, is the proportion: (diff/2) : dist So that applies to the other edges so: " 'offset_x' is to 'dx' as 'offset_y' is to 'dy' which is as '(diff/2)' is to 'dist' " Algebraically: offset_x : dx = offset_y : dy = (diff/2) : dist So: offset_x = dx * ((diff/2) : dist) offset_y = dy * ((diff/2) : dist) I personally find that more intuitive and clearer algebraically than to envision a conceptual "precentage"
@pikuma I tried a constraint that is more 'fluid', it continues the velocity of each particle off the wall by reflecting the path, not just hard resetting onto the wall. I tested it in your code and the box hit the wall, bounced a bit and then stayed there flat against the wall, so it seems more stable than the hard reset. What do you think? On line 46 onward you can test } else if (this.x > SCREEN_WIDTH) { this.x = SCREEN_WIDTH - (this.x - SCREEN_WIDTH) this.old_x = SCREEN_WIDTH + (SCREEN_WIDTH - this.old_x) } ...
I like to learn by applying topics in real projects. That way I never forget how somethjng works. But a great book on beginner math for gamedevs is gamemath.com.
Sorry. I have printed a parabolic trajectory comparing the real solution, Euler and Verlet. I see Verlet and Euler very very similar. Where is the improvement versus Euler? I see more less the same error.
Thank you for the Video. Well explained as always! I like the way you express things that need special attention! Thank you! 👏👍 However I have two points to discuss. One critism abaou the bad audio quality . I even recognised this clicking and some sort of short interrupts in the audio . They are quite short but noticeable. This phenomenon even exists at your Videos at Pikuma. I tried several different devices to watch your videos but on every this quite annoying problem is audible. Is there anybody out her who may confirm this? The Issue number 2 is in regard of this video: Honestly I don't get why a computer just necessarily needs to work (its algorithm) in Timeframes - the time from one picture to another. So i men in TimeFrames from one from to the other. Why can't i treat an animation in absoluter times? The Player starts jumping at t=0 and from this point upon every Frame the time proceeds running by deltaT and keeps the absolute time running. The absolute time t passes by as in reality... This is the same model as we all have here! We start our time count at the birth of Jesus Christ which is 1. January of the year 0... ;-) So if one want to do the calculation she just takes the so far *absolute* time and inserts it into the formula as usual we do in physics and learned in school. The calculation in relative Times (delta T) in addition bears the problem. that an inexact calculation will add its effect from step to stop. Treat the absolute time will not have this flaw. For example consider the position y of a falling item: The absolute formula is y(t) = 0.5 * g * t * t. So why shouldn't I just use this and instead do the calculation by considering the "delta T" which then would be the speed by do derive y(t) by t which then is v(t) = dy(t)/ dt = g * t and then calculate the "delta s" (change of the position) by applying die deltaT (The time between one from and the other) delta s = v(t) * deltaT which then is g * t * delta T... I don't get why we need to consider calculation in terms of delta T's (The time between on frame to the other) and not by absolute times as the original formula of physics tells? May anybody pls shed some light on this? TIA - Peter -
1: I don't have that bad audio. Might be a browser / system problem on your side. 2: A computer game is usually a dynamic system. Imagine a Super Mario-like game. How would you predict / absolutely calculate the position e.g. if the player jumps? You have to see from frame to frame if they have jumped, what speed they had before, if the get hit by a bullet mid-air, bounced off a wall etc.
@Bim Overbohm Thanks for your Reply! For 1: I tried it with several systems - iPhone, iPad, Mac Pro (which should have plenty of CPU Power), my Wives Laptop running Windows armed with an Intel I7 CPU... On all of them I recognise this subtile audio drops... And none of them are known to issue these audio drops. I never recognised this except on his videos. Even The videos I purchased on Pikuma showed the subtile audio drops... I Own a lot of them at Udemy but none of them showed this issue. So I really doubt that this is an hardware / Browser issue... For 2: That is what I don't get: Why should one need to "predict" the next position on the next frame? Why can't I calculate this when this happens - NOW? All Objects have their physics. All o f the rely on the *same* absolute time. All of them are rendered at the position as they should be NOW. So why is it so important to consider a calculation from Frame to Frame? If I write a physics simulation with a moving object, then I may even calculate the current position based on the *total* elapsed time. And If something happens such a collision, the I'll need to start my time at this point for this particular animation too. Why Isn't this possible? I don't get why an computer algorithm to animate things should not calculate positions / physics based on an absolute time.
@@hanspeterbestandig2054 Well, theoretically you could do that, but then you'd need to keep track of different "absolute time"rs for each object, each one accumulating "absolute time" since it's own last collision, and update those per object on each collision. But, then what if instead of a binary collision that can discretely determine an "absolute time reset" event, you introduce the notion of a dynamically changing counter-fource being applied to your object at varying degrees at varying times - and maybe the source of that force itself is moving dynamically - that would seriousely interfere with your perfect platonic parabola - where's yout nicely discrete "absolute timer accumulator rest" event in that story? Also, consider that the difference between frames is not consistent, and if you fail to account for how it changes you get incosistent and gittery simulation/movement.
Hi there! Good points. The first thing you mentioned about us using the absolute formula to compute the correct numerical integration only works if the rate of change is always constant. If we have other forces and acceleration & velocity changes as time steps progress, then accuracy errors will happen. A great suggestion of an old article that covered this with numerical examples is: gafferongames.com/post/integration_basics/ Observe how the constant rate of change integration example in his article gives us the correct result, but as we apply forces it will show accuracy errors based on delta time size. Also, about the sound quality, I know one of my courses called "2D C++ Game Engines" is really bad in audio quality. I noticed it after I was done recording it. I changed my microphone and audio software since then, and I thought the TH-cam audio for this video was not that bad. But I'll check it again and try to improve. I'm definitely not an expert in this video/audio thing. Any tips on mics and recording tools are welcomed!!! :)
I've tried this twice and every time i switch from euler to verlet the speed of the particles increases by a factor fo around 10. I don't see this in your video or any other ones i've seen so far. I'm not sure what the hell i am doing wrong.
A few weeks ago I didn't know I was going to make a voxel engine. Today I learned I'll be doing Verlet Integrations this weekend.
Allelouia!!! This video is amazing!!!! Bravo for all the preparation work to make the subject understandable!!! I discover your channel today. I will look at the rest very closely. 1000 times thank you!
I've always heard about Verlet integration and never fully understood it.
This video made it not only understandable, but intuitive!
Man I recently discovered your channel, the quality of the way you teach is crazy! gonna start binging on your courses starting with the NES course. Thanks for all your content, keep going!!
It's very great that you take your time and explain in depth topics and not hastily trying to complete a video
Very nice video Gustavo sir
Hallelujah! Finlay got some time to resume the physics course and watch this video! Great video, loved the explanation and comparison between different integration technicians.
Absolutely stellar job with the lecture! Your dedication and effort are clearly visible in the content you've created, making it both insightful and engaging. I sincerely appreciate your hard work in enlightening us on such an interesting topic. Keep up the fantastic work!
I really enjoyed the talk about euler integration and all the others, both as context to verlet, and also due to having user Euler's method a lot and didn't know of the negative sides of it.
Really interesting :)
That's some amazing and much better explanation than my professor in university. Thanks for sharing your knowledge you earned my respect and a subscriber i can't wait to see more videos on game dev.
Hallelujah! it finally clicked, thank you so much for putting this together.
Wonderfull explanation of verlet integration. Clear, simple and explicit.
Thanks a lot for this.
I’m writing a simple 3D game right now for fun but it was time to implement physics and was struggling until I found an old PDF explaining Verlet integration.
The PDF was great, but as I searched on Google for a couple questions I had, TH-cam started recommending stuff and that’s how I found this video.
This was amazing. Such a great explanation. I’m going to go back and watch the rest in order (watched all of this and also just watched your video on Calculus at the beginning of this playlist)
I was pretty happy with the results of my initial (very simple) implementation converting the code to work in 3D, but I still need to implement more to support collisions with polygons, angular momentum, etc.
You are a fantastic teacher. I’ve been up all night wondering how I’m gonna implement angular momentum but I have ideas now. I’m also very curious about stability (especially in 3D which seems very prone to instability?)
I noticed you have a physics engine course! With a baby I only get an hour here and there to work on this stuff so not sure if I’ll be able to watch the 35 hours- but planning to buy just to support this work and maybe I’ll be judicious about which ones I watch. I can try fill in gaps in my knowledge enough to help me with my project.
This lecture has so accurately cleared multiple concepts for me. Very clear explanations.
Just discovered your channel and it's a gold mine...❤
Really good video. I like how you take time to show how you think through the problem. The text is a little small and the background a little light to read the text, but outside of that, great explanation. You explained something I saw in my own code years ago.
hallelujah! i made this into my own physics drawer game with spacial hashing and other things. great channel!
man, thanks, really, yesterday I was all day trying to make a simple pendulum movement using topics I've learned in my Physics 1 class, ending up almost surrendering... now, I've followed your tutorial and I'm amazed at how automatic and simple this is, I tried making an immobile point and another connected to it, and there it was, perfect pendulum motion...
I'm trying different shapes and I burst laughing to myself out of amazement.
It's fun, isn't it?.😅
love the way you go through things. true understanding and logical connection of related topics. fantastic content
Thank you so much for this video! I needed to make rope physics for a project and at first i didnt understand anything from wikipedia but this video made it really simple.
Awesome video Gustavo!
As per your note at 55:00, I actually didn't like any of the 2 options you showed - what I did for a Breakout clone I wrote once, was to to the proper reflection vector calculation and collision resolution - which would work for both the verlet and Euler methode: Say you have position A just before a collision with a wall and point B inside the wall, and lets assume a 0 diameter collider (point) - to resolve it you can consider the progression from point A to B as a lerp (linear interpolation) with a normalized 't' value of 1 at B. At some point C with some 't' value, the point is right at the wall. That 't' value is easy enough to compute using the 'x' coordinate of the wall and that of A and B : t = (Wall.x - A.x) / (B.x - A.x). That 't' value can then be used to compute the 'y' component of C so you get:
C = {Wall.x, (A.y + t*(B.x - A.y))}. Then, to add the remaining movement that would be bounced in the opposite x direction, you take the remainding portion of the vector (B - A) that is left after subtracting the first part of the movement from A to C: (B - A) - C
and mirror it across the Y axis by negating it's x component. Then you add that resulting vector to C to get where a bouncing point would end up at - precisely. That's streight forward for the Euler methode, then for Verlet you could just mirror the first portion from (from A to C) across Y as well, and subtract it from C to get what an "old position" 'would have been' if the point was going in a streight line from somewhere inside the wall towards the final resulting point - maintaining the proper "velocity" that would have been, so no loss of energy from the wall-bounce, etc. Then, for a non-0 point collision (say a circle) it gets a bit more complicated, as it would hit the wall at a non-trivial point to compute (when it's radius along X would have it's horizontal bound at the wall, which for some diagonal direction would be before the point-based collision would be)
Hey Arnon, good to see you here!
That's the good stuff right there. Thanks for the breakdown. 🙂
Would you still use this same method if you were coding this solution for a *super* slow machine?
@@pikuma Hey Gustavo :)
I think so? Donno what super slow would be exactly, but I cant see why that approach would be an issue for just the walls as resolving it for purely vertical / horizontal walls like that is pretty cheap overall, and it is also cheap to check for whether that even needs to happen on a per frame basis (I mean at least for the Breakout clone case where there are just 2 horizontal and 2 vertical walls). Collision detection and resolution can get way more complex and expensive than that, for example this does't even test for "tunnelling" (going through 2 consecutive walls next to each other at high velocity) and also does point-based detection and resolution (as opposed to circles or anything else with non-zero surface area). For those there's the Minkousky Sum and something fancy called GJK (Gilbert Johnson Keerthi) that is typical one to use as is very general yet robust (Haven't looked into that one myself but I know it should be more expensive). It typically gets to ray-casting at some point in some form. And then there's the whole spatial acceleration structures that become necessary at some point, like a quad-tree or an oct-tree for 3d to localize the search space for possible colliders - in short, yeah - it all can get way more expensive then what I suggested, which is still very minimalistic by comparison.
that was my exact thought when I saw how collisions were handled here!
Time index 1:13:02 -- "OH!!! That's how 2D shapes physics engines work!!!" What a wonderful video, thank you!!!
Oh my god, thank you so much for your explanation. I'm making a video game about a sewing mechanic and I needed to simulate the rope. This help a lot
Wonderful video. Thank you for your time and effort.
Amazing in depth explanation, i need more
this channel is crazy good. appreciate you
Very nice! You mentioned to write in the comments so I guess you already know that gravity should not be scaled by mass. 😊
There you go! ❤🙂👍
This was my solution to the bounds issue. Should be a perfect reflection, accuracy determined by how small dt is. Just draw it out, you'll see by swapping the X or Y components of previous and current, we get a basically perfect reflection, with the same magnitude, and a reflection hit point right near the axis (again accuracy determined by dt, smaller dt, closer to axis).
You may want to do extra checks to make sure that particles don't get stuck zig-zagging by spending 2 consecutive frames out of bounds, but in my testing I didn't need it. Integrating prior to constrains seems to make it unnecessary. I did however have to add and extra check since I have a floor that is independent from my bounds type.
Pseudocode:
VerletIntergrate();
if( position.x < x_min || position > x_max) swap y components of previous and current;
if( position.y < y_min || position > y_max) swap x components of previous and current ;
Actual code:
//| Verlet Integration
// Determine velocity for readbility, reset previous position
float2 clampedVelocity = Vector2.ClampMagnitude(
point.position_current - point.position_previous,
physicsProperties.maxVelocityMagnitude
);
point.position_previous = point.position_current;
// integrate
point.position_current += clampedVelocity + point.acceleration * (deltaTime * deltaTime);
point.acceleration = float2.zero;
//| Contrain to bounds
// NOTE: We do this part after the integration so that it doesn't get pushed back down below the bound limit.
// NOTE: If we did it before, and the new position ended up below the limit twice in a row it could cause zig-zagging, and a stuck point.
// Do the floor
bool floorWasUsed = false;
if (physicsProperties.useFloor)
{
if (point.position_current.y < physicsProperties.floorHeight)
{
// Cache and swap the y components
float cached_position_current_y = point.position_current.y;
point.position_current.y = point.position_previous.y;
point.position_previous.y = cached_position_current_y;
floorWasUsed = true;
}
}
// Do the other bounds
switch (physicsProperties.boundsType)
{
case PointMassPhysicsProperties.BoundsType.BOX:
float max = physicsProperties.boundsLength;
float min = -physicsProperties.boundsLength;
// Bounds X
if (point.position_current.x < min || point.position_current.x > max)
{
// Cache and swap the x components
float cached_position_current_x = point.position_current.x;
point.position_current.x = point.position_previous.x;
point.position_previous.x = cached_position_current_x;
}
// Bounds Y
if (point.position_current.y < min || point.position_current.y > max)
{
// If we already hit the regular floor, don't also hit the box floor
// ...or we might get a point stuck zig-zagging
// Note that this never seems to trigger.
// Note this is despite testing with a 0.001 gap between floor and box floor, and with gravity being toggled from 9999 to -9999 and back (instead of the usual -9.8)
if (point.position_current.y < min && floorWasUsed)
{
Debug.Log("Can't hit box floor, already hit normal floor!");
break;
}
// Cache and swap the y components
float cached_position_current_y = point.position_current.y;
point.position_current.y = point.position_previous.y;
point.position_previous.y = cached_position_current_y;
}
break;
}
//| Push the point
pointsWrite.TryAdd(pointID, point);
}
Aleluia, I'm from Brazil. That video is super cool. Thanks.
Dude you are awesome! Thanks for sharing your knowledge.
Glad it was helpful! :)
Great video. How does one introduce mass into this equation though?
Hallelujah ;) Great video. Thank you.
Great! Love when people actually complete the tasks. 😉
Shouldn't the bounced ball follow the trajectory it was going in but mirrored? If we displace only the X we are misplacing the bounced object right? I would just mirror the old X relative to the line it crossed and mirror the current X the same way.
Thank you very much! Just awesome! 💫
I think using semi-implicit Euler method you can increase accuracy even more by updating current velocity using gravity, then using the average of the previous and current velocity and then update the position, this applies newton's kinematics equation d=1/2*(vi+vf)*t which states position is the average of the initial and final velocities multiplied by time
Hellelulja! Very good talk :)
This is so great video and explanation. Thank
what verlet allows you to do which i dont think is as good in euler integration, is have restitution in the objects, so a value of 0 makes the constraint absorb all the energy (along the normal of the constraint surface), and a value of 1 makes energy in = energy out. As for bouncing off a wall, i would instead of first iterating forward and then detect a collision, i would rather use a line-line intersection test or a ray tracing method to find the intersection between the object and the surface of the constraint, then use the same approach as you to move the previous position in the wall.
this is a pseudo-code f this:
for each line in constraint_lines {
if line intersects with the objects "velocity_line" { // I define the velocity_line as being a line from object_pos to 2 * object_pos - object_prev_pos
let object_vel = object_pos - object_prev_pos;
object_pos = intersection;
let line_vector = line_b - line_a;
let normal = normalize(line_vector.y, -line_vector.x);
let vel_inverted = object_vel - 2 * dot(normal, object_vel) * normal; // Use Ray Reflection formula to get a reflected vector from the surface normal
let object_prev_pos = object_pos - vel_inverted * line_restitution * object_restitution; // I don't know if this is the proper way of combining objects with different restitutions
}
}
i think this should give a accurate result if i'm not mistaken or got a math error anywhere. The best part about this is that it can be expanded into 3D pretty easily, just change the line intersection tests with surface intersection tests or triangle-ray intersection tests and the rest would be the same
Great post. Thanks for this!
I was wondering, how easy is it to add rotation to these verlet objects, making one in scratch and I feel like that will make it stand out
Very good!
Any thoughts, is semi-implicit Euler and Verlet the same thing?
Great video thank you, finally got to practice verlet integration with constraints for real!
I tried to reproduce the example in a slightly different context to create hanging cables, it looks great but one issue that I encountered is that you don't use the delta-time in your stick update function, I did not either, and it messes up totally the results each time I have a slow-motion effect (the sticks are not using delta time thus they move the points waaaaaay more than they should).
To fix this I tried to multiply the offset_x and offset_y by the delta time (and also multiply by an arbitrary value to compensate the decrease) but to my surprise this didn't worked, the problem persists the same. What could be done to implements this example in a way that if we multiplied the deltatime by some value before it goes to the points and sticks the results will be the same but slower/faster, and not something totally different?
Hey I enjoyed this lecture. Do you recommend any books because I want to learn more about this with respect to game programming.
I think in the case of semi-implicit Euler integration, when the initial velocity of the particle is a zero vector, then the system will actually conserve energy, keeping the particles bouncing forever. If we initialize the start velocity to some small random values then we'll actually observe loss of energy.
When we move from points to sticks. The system is no longer conserving energy. It is loosing energy. What's the reason for that?
Also what numerical methods are used for calculating mission trajectories and planetary orbits for space missions?
Storing the current position and the old position requires a constant delta T. In a system where delta T can vary, it would be better to store the current acceleration and prior acceleration (and if you include jerk, the prior prior acceleration).
When you talk about different integration methods having different levels of accuracy, does that also mean that more accurate methods help prevent a simulation from exploding or becoming unstable (something I care about) or is it only about accuracy in terms of following trajectories for example (something I don't care about)?
Sorry, but I have another question:
Is it possible to use verlet integration but instead of storing the current and previous position, you just store current position + velocity or previous position + velocity? After all, we should be able to convert between the two-position representation and position+velocity very easily.
For example, sometimes you may need the velocity readily available, instead of having to recompute it every time by subtracting the two vectors.
Would this make sense or does it break the verlet properties?
Also to solve your boundary reflection problem, there's actually a correct and dead-simple method (which is also more accurate than your Euler method). Idk if you are unaware of it or you are aware and just asked us as an exercise.
You just subtract the wall's coordinate from your new coordinate and then flip the vector. Keep the other component unchanged.
*Example when hitting the wall on the right:*
old_pos.x = wall.x + (wall.x - old_pos.x);
old_pos.y = old_pos.y; // Unchanged
pos.x = wall.x + (wall.x - pos.x);
pos.y = pos.y;
if x>boundary: then (x=boundary-(x-boundary)) and (old_x=boundary+(boundary-old_x)) else do notting??? Its like mirroring the position over the boundary line/value if it has crossed the boundary.
@@TheX5yacht-ui6gc Nice!!!
this is a wonderful channel
In the case of updating a stick where one point is pinned and the other is not, shouldn't the adjustment in the position of the point that is not fixed be twice what it is as implemented in the current code? Otherwise it seems that you are adjusting the stick position only by half of the actual difference on length change.
I have a question, verlet only need acceleration to update position. but in most case, we must provide
velocity not acceleration, so in this case how can we update position by velocity
Question though, can you explain why the semi explicit euler loses energy over time? I see that reason in explicit euler, the velocity continually increases, but I'm not seeing where that would be different by just flipping the order of the equations in the semi-explicit version? Thanks.
muito bom.. molto buono. I don't know if you're brazilian or italian, or where are you from? :)
🇧🇷🙂
Looks awesome. Also implemented some stuff of it. But one thing i don't understand is why acceleration is multiplied twice with dt. When i calculate the velocity then it is the velocity between two frames. This is why velocity is divided by dt to get the velocity for one second. But as we are frame dependent we multiply again by dt. So in the end the division and multiplication of dt cancels and we just can add the velocity as it already is the velocity for one frame step. Same goes for acceleration. I would just add (acceleration * dt) to get the acceleration for one frame. But in Verlet it has to be (acceleration * dt * dt). Why?
I figured it out. In Euler we do add "acceleration * dt" to velocity. But then again just "velocity * dt" is again added to the position. So for acceleration it turns out to be "velocity * dt * dt" that is added to position.
Btw. thanks for the video, its really great and your content is awesome.
1:10: I personally would have preferred a geometric explanation using the proportion of similar triangles:
The smallest triangles are similar to the largest one so they have the same proportions, and they are smaller than the largest one by the amount that their hypotanous (diff/2) is smaller than the largest triangle's hypotenous (dist).
Tha is, the scaling factor between the smallest triangles to the largest one, is the proportion: (diff/2) : dist
So that applies to the other edges so: " 'offset_x' is to 'dx' as 'offset_y' is to 'dy' which is as '(diff/2)' is to 'dist' "
Algebraically:
offset_x : dx = offset_y : dy = (diff/2) : dist
So:
offset_x = dx * ((diff/2) : dist)
offset_y = dy * ((diff/2) : dist)
I personally find that more intuitive and clearer algebraically than to envision a conceptual "precentage"
Please do Verlet Integration Part 2 where you go through a bunch of different types of constraints
And.... how do you set an initial V0 using Verlet method?
Muito obrigado, gustavo. Halleluja.
@pikuma I tried a constraint that is more 'fluid', it continues the velocity of each particle off the wall by reflecting the path, not just hard resetting onto the wall. I tested it in your code and the box hit the wall, bounced a bit and then stayed there flat against the wall, so it seems more stable than the hard reset. What do you think?
On line 46 onward you can test
} else if (this.x > SCREEN_WIDTH) {
this.x = SCREEN_WIDTH - (this.x - SCREEN_WIDTH)
this.old_x = SCREEN_WIDTH + (SCREEN_WIDTH - this.old_x)
} ...
Great video btw, I really appreciate you digging into the equations to understand the roles of the different components here in detail. Many thanks.
Thanks for you tutorial! @55:08 - Why not simply calculate the reflection off the wall? It is not much harder to do than your hack...
Exactly. There you go! 🙂
Great video. Thank you
Hallelujah 🙌
yay!
so cool!!!! Hallelujah!
34:19 but there is no step between steps
thank you for u r work
What a gem!
Great work - thanks so much! I really need to catch up on math and I need to do it quickly. Anyone know of any good resources?
I like to learn by applying topics in real projects. That way I never forget how somethjng works. But a great book on beginner math for gamedevs is gamemath.com.
@@pikuma Thanks! Looks great!
Sorry. I have printed a parabolic trajectory comparing the real solution, Euler and Verlet. I see Verlet and Euler very very similar. Where is the improvement versus Euler? I see more less the same error.
Thank you !
Can you please add your physics engine course in udemy ? You website doesn't support other payment methods .
Hi Abhay. We don't publish on Udemy anymore.
Hallelujah!
Halleluja! Good video
Hallelujah
very very cool
Hallelujia!!!
Alléluia !! ;) Thanks
Great! 🙂
Hallelulja!
Hallelujah Glory glory
Oh yes! 🙂
haleluiah. so cool
Damn...(out of words)
Halleluja))
Yes! 😅
Thank you for the Video. Well explained as always! I like the way you express things that need special attention! Thank you! 👏👍
However I have two points to discuss. One critism abaou the bad audio quality . I even recognised this clicking and some sort of short interrupts in the audio . They are quite short but noticeable. This phenomenon even exists at your Videos at Pikuma. I tried several different devices to watch your videos but on every this quite annoying problem is audible. Is there anybody out her who may confirm this?
The Issue number 2 is in regard of this video: Honestly I don't get why a computer just necessarily needs to work (its algorithm) in Timeframes - the time from one picture to another. So i men in TimeFrames from one from to the other.
Why can't i treat an animation in absoluter times? The Player starts jumping at t=0 and from this point upon every Frame the time proceeds running by deltaT and keeps the absolute time running. The absolute time t passes by as in reality... This is the same model as we all have here! We start our time count at the birth of Jesus Christ which is 1. January of the year 0... ;-) So if one want to do the calculation she just takes the so far *absolute* time and inserts it into the formula as usual we do in physics and learned in school. The calculation in relative Times (delta T) in addition bears the problem. that an inexact calculation will add its effect from step to stop. Treat the absolute time will not have this flaw. For example consider the position y of a falling item: The absolute formula is y(t) = 0.5 * g * t * t. So why shouldn't I just use this and instead do the calculation by considering the "delta T" which then would be the speed by do derive y(t) by t which then is v(t) = dy(t)/ dt = g * t and then calculate the "delta s" (change of the position) by applying die deltaT (The time between one from and the other) delta s = v(t) * deltaT which then is g * t * delta T...
I don't get why we need to consider calculation in terms of delta T's (The time between on frame to the other) and not by absolute times as the original formula of physics tells? May anybody pls shed some light on this?
TIA - Peter -
1: I don't have that bad audio. Might be a browser / system problem on your side.
2: A computer game is usually a dynamic system. Imagine a Super Mario-like game. How would you predict / absolutely calculate the position e.g. if the player jumps? You have to see from frame to frame if they have jumped, what speed they had before, if the get hit by a bullet mid-air, bounced off a wall etc.
@Bim Overbohm Thanks for your Reply! For 1: I tried it with several systems - iPhone, iPad, Mac Pro (which should have plenty of CPU Power), my Wives Laptop running Windows armed with an Intel I7 CPU... On all of them I recognise this subtile audio drops... And none of them are known to issue these audio drops. I never recognised this except on his videos. Even The videos I purchased on Pikuma showed the subtile audio drops... I Own a lot of them at Udemy but none of them showed this issue. So I really doubt that this is an hardware / Browser issue...
For 2: That is what I don't get: Why should one need to "predict" the next position on the next frame? Why can't I calculate this when this happens - NOW? All Objects have their physics. All o f the rely on the *same* absolute time. All of them are rendered at the position as they should be NOW. So why is it so important to consider a calculation from Frame to Frame? If I write a physics simulation with a moving object, then I may even calculate the current position based on the *total* elapsed time. And If something happens such a collision, the I'll need to start my time at this point for this particular animation too. Why Isn't this possible? I don't get why an computer algorithm to animate things should not calculate positions / physics based on an absolute time.
@@hanspeterbestandig2054 Well, theoretically you could do that, but then you'd need to keep track of different "absolute time"rs for each object, each one accumulating "absolute time" since it's own last collision, and update those per object on each collision.
But, then what if instead of a binary collision that can discretely determine an "absolute time reset" event, you introduce the notion of a dynamically changing counter-fource being applied to your object at varying degrees at varying times - and maybe the source of that force itself is moving dynamically - that would seriousely interfere with your perfect platonic parabola - where's yout nicely discrete "absolute timer accumulator rest" event in that story?
Also, consider that the difference between frames is not consistent, and if you fail to account for how it changes you get incosistent and gittery simulation/movement.
Hi there! Good points.
The first thing you mentioned about us using the absolute formula to compute the correct numerical integration only works if the rate of change is always constant. If we have other forces and acceleration & velocity changes as time steps progress, then accuracy errors will happen. A great suggestion of an old article that covered this with numerical examples is: gafferongames.com/post/integration_basics/
Observe how the constant rate of change integration example in his article gives us the correct result, but as we apply forces it will show accuracy errors based on delta time size.
Also, about the sound quality, I know one of my courses called "2D C++ Game Engines" is really bad in audio quality. I noticed it after I was done recording it. I changed my microphone and audio software since then, and I thought the TH-cam audio for this video was not that bad. But I'll check it again and try to improve. I'm definitely not an expert in this video/audio thing.
Any tips on mics and recording tools are welcomed!!! :)
@@pikuma I have no audio issues here,
halleluya
this guy has to be brazilian, no where else we find that accent
I've tried this twice and every time i switch from euler to verlet the speed of the particles increases by a factor fo around 10.
I don't see this in your video or any other ones i've seen so far.
I'm not sure what the hell i am doing wrong.
Hallelujah!
Oh yes! 😉
Hallelujah