 Here in this scene, I have this cube, this sphere, and this capsule, and these objects aren't just visible meshes They also have collider components They have a capsule collider on the capsule, a sphere collider on the sphere, and a box collider on the cube And what these colliders represent is not visible geometry But geometry we can use to test for intersections between one collider and another The geometry for these colliders, when I created these objects by default It starts out the same as the visible mesh, but it doesn't necessarily have to line up with that Right now here on this cube, for example, I've scaled the object itself to 2 on the y-axis But I can apply additional scaling on the collider itself, like I said here I have 4, and now effectively the dimensions of the box collider is 2 times 4 So it's actually 8 units tall right now We can also translate the collider relative to the transform of the object So here, if I change the x to, yeah, it moves the collider So it's not lined up with the box, it's moved over So to be clear, your collision geometry doesn't necessarily have to line up with the visible geometry at all In fact, we can have game objects which have no render whatsoever if I get rid of this Now we have this game object that has this collider over here Transformed away from the origin of the object itself But there's no visible object, it's just this collision geometry So I'm going to bring back that mesh render so we can see the box And I'll reset our box collider, so now it's back the way it was And in this scene on this manager object we have this collision demo script Let's look at the code So what it's doing is we have a logical center and a size where we're going to be every frame moving the center So it goes along the x-axis And then using from the physics class the static checkbox method We specify a center and we specify the so-called half-extence That's the dimensions in all three axes, but cut in half And this method then will return true if there are any colliders in the scene that overlap with this logical box And so having to find the size here to be 222, we divide that by 2, we get 111 But those are the half-extence of the box So we're moving this logical box along the x-axis every frame And colliding will be such a true if that overlaps with any of the colliders in our scene In the ongoing method here we'll display that in a box so we can see whether it's true or false And then down here on draw gizmos, gizmos are visual elements and control elements within our scene That aren't really meant to be part of the actual game They're meant to be seen in the editor for editing and debugging purposes So here in on draw gizmos we want to see this logical box as it moves along the x-axis So every frame we're going to draw it as a wireframe cube Okay, so I'll go back to the game and when I press play you'll see our red gizmo box here The wireframe box moving along the x-axis in this direction And when it overlaps with any of these colliders you'll see a little printout of true here in a GUI box So I'll hit play And yeah it's false but now it's true, false again, true, false again, true Yeah So that's one thing we can do with colliders is we can do explicit queries in our code Like this checkbox method to test if a piece of geometry intersects with a collider In this case we use checkbox, there's also check sphere and check capsule Which as you would expect describe the location of some sphere or some capsule And check if anything overlaps with those shapes instead We also have methods called overlap box, overlap sphere and overlap capsule Which rather than just returning a boolean of whether or not there's any overlap It also gets you information about what colliders we're overlapping with So you get a lot more information from the overlap method Another kind of query we commonly want to do with our colliders is a test called a raycast A raycast tests if a ray in the world intersects with any collider So here I'm going to do a raycast that starts at this position, start And then travels along this vector, dir for direction And just so we can see that ray in the scene I'll draw it as a kind line in the scene To actually do the raycast we call the static method of physics called raycast And there are many overloads of raycast but in this particular overload I'm specifying the ray as again the starting vector and the directional vector from that point And while the method here just returns true or false, true if the ray hits any collider In this overload we have an out parameter of type raycast hit And that gets us information about the actual collision Which collider did we hit, what was the point in space And on the surface of that collider what is the normal vector and other information That's all put in this out parameter here And while we can cast a ray of infinite length I often will want to constrain that to a limited length And here I'm constraining the length to the magnitude of dir So I can actually get rid of this length parameter And now the ray that's cast would start at start, go off in this direction But have an infinite length But sometimes for logical reasons and other times just for performance reasons It's expensive to do an infinite raycast So sometimes we'll just want to constrain the length And that's what I'm doing here And then after the call we're going to print out the value of point If the raycast doesn't hit anything Point will still just be a zero vector Otherwise this should be a non-zero vector Assuming there's not the unlikely coincidence that our ray was cast And just happened to hit a collider at the zero vector So otherwise this should be a non-zero point So let's see this in action, come back here, hit play And there's my ray starting here from the origin and casting off this way And it's going through both the sphere and the cube But the hit info that's returning for the raycast method Is just this first collision here, here on the sphere So the coordinate printed out is 1.12 Which is that point right there on that sphere There is though a method called raycast all Which will give you back information about all the collisions along a ray Though as you can imagine it's generally a more expensive operation So here I've commented out our use of the raycast method And now we're using raycast all It also has several overloads So there's various ways to call it But in this case it's the form where we're just passing in again the start vector The direction vector and the length of the ray But this time we don't pass in an out parameter We just get back an array of hits And so we then print out the number of hits And then print out all the points that we hit So let's see this run here, hit play And I'll just pause And so each frame we get two hits from this ray You might think well why not four Because it's hitting that part of the sphere and coming out the other end Does this not count as a collision? No because the surfaces of our collider here Are considered one way surfaces You only collide from the outward side Not from the inside So same thing here on the cube This counts as a collision But when the ray exits the cube on the other side The ray doesn't detect that collision So you can see our points here is 1.12 It's the same as we got before When we just used the raycast method Rather than raycast all And the other point here is 6.32 That's that point right here on the cube Now there's one more variant of raycast Called raycast non-alloc Which is really actually just like raycast all Except instead of returning an array Of the hit information It expects you to pass in an array Of the raycast hits And it writes the raycast hits into this array So here I've created a raycast hit array Which is just a field of our class Of our script And so we're passing the array into the method And so every frame, every update We're using the same array Rather than creating a new array Every frame Which is very wasteful And creates tons of garbage Which then has to be garbage collected And as we'll discuss in a later video Generally you want to avoid garbage collections entirely So you want to avoid creating garbage So almost always You really should be using raycast non-alloc Rather than ever using raycast all So now just to walk through how this works Pass in the array But then the length of that array doesn't tell us How many hits there are Because maybe here it's an array of a hundred But maybe we only get two hits So we need to know how many hits we're actually detected That is returned as an int And so when we print out the number of hits It's this value And when we do our loop we don't use four weeks We have to iterate up to the number of hits And we're just accessing the points in the array So this code should have the exact same behavior As it did previously when we used raycast all But now we're not wastefully creating a new array Every single frame So let's just see this in action Hit play And yeah, num hits is two And we're getting the same coordinates So exactly the same behavior Just a lot more efficient Much less wasteful Here in this scene we have this floor object Which has a box collider component And we have this cube object Which also has a box collider component But additionally the box has a rigid body component And what a rigid body component represents Is mass and velocity Both directional velocity, movement Translation through space But also angular velocity Rotational velocity And what happens is rigid bodies Is that unity at the fixed interval rate Which we discussed earlier Is this value here in your project Under time and by default it's 0.02 Meaning 0.02 seconds Which is 20 milliseconds And so 50 times a second At this interval Unity performs physics updates And unity does a few things in this physics update But what it does at the end Is given the velocity of a rigid body It automatically moves the object As if it has traveled with that velocity Given the elapsed time Which is going to be the fixed time step interval So in this case as if 20 milliseconds have elapsed So on our rigid body here If its velocity say is 10 units along the x axis going this way Then at the end of every physics update The object will automatically be moved 10 units multiplied by the fixed interval And you'll notice here that they don't expose The velocity as a property We can just directly edit in the scene That doesn't really make sense to do so generally But in the code with your rigid body component There you can modify the velocity As we'll do shortly But notice here it has the used gravity property Which by default is true And when that's on Before moving objects according to the velocity Unity will update the velocities Of the rigid bodies And for each rigid body where used gravity is true It'll modify the velocity of the rigid body In accordance with the force of gravity And the force of gravity is also another global setting here Under physics And by default it's a downward vector Negative wide vector of magnitude 9.81 Which is approximately Earth's gravity right So you can modify this though If you want a different kind of gravity You can have the gravity go in any direction And have any magnitude But let's just stick with this default And the consequence of this then Is automatically this object when we play Is going to just fall to the ground Under the force of gravity Because every physics update The gravity is being applied to its velocity And at the end of the physics update The object is automatically moving under its velocity So let's see this in action Play And there it goes But it stopped when it hit the other collider Why did it stop? Well every collider component Has an attached rigid body property And when this property is null The collider is considered to be static It's considered to be a collider That's really not supposed to move And in fact if you try and move Your static colliders you can do so But understand it triggers an expensive Recapitation of some pre-processing That Unity does for the sake of Making collision detections faster So you generally shouldn't move Your static colliders even though you can Anyway though for collider Where the attached rigid body is non-null It's actually referencing some rigid body What happens in the physics update Is that for those non-static colliders Unity automatically checks If they're overlapping any other collider Whether static or not And if so for every collision It generates a so called collision event Which sends information On to the attached rigid body And so every physics update This rigid body is getting information About any collisions And from that modifying The velocities accordingly It effectively applies forces onto the velocity And thereby affects how this object moves So when I play the scene here The box is moving under gravity But then collisions are detected In physics updates of hey it's hit this thing here And that stops it from penetrating The floor and falling through it Now I didn't actually explicitly Attach this rigid body to this collider But automatically when a collider is created It looks on that same game object For a rigid body And automatically attaches it If there's no rigid body on the same game object It then will look up the chain of game objects Like say our game object is some child And it looks up that hierarchy until it finds a rigid body And then that is the rigid body That will automatically get attached Otherwise if the game object itself has no rigid body And there's no rigid body up the chain Then you'll just have a static collider Which is the case for our floor here Object itself has no rigid body component And there's no ancestor up the chain with a rigid body But if we're then to make this a child of the cube Well now this box collider is going to have The rigid body of the cube attached to it Well first off the floor will move when the cube moves Because it's a child, so that's just how transforms work But then when collisions occur On either the cube or the floor If they hit other objects They'll move as if they're one solid object Even though here these two cubes are not even touching They'll still act as if they're one solid object Right now in the scene there's nothing else For them to collide with so when I hit play Well the rigid body is under the influence of gravity So it starts falling and so the cube falls And the floor falls with it as it's child So here we see that So they're just falling forever together But here very quickly I'll duplicate the floor And detach that so it's off by itself And then move that down in the scene So it's underneath So now let me move and rotate a little bit So we get some funky behavior Let's see So here I hit play And they move together and they collide As if they're one solid object Now I could come here And give the floor its own rigid body And so now collisions of this floor collider Effect this rigid body but not the other one I'm going to see some very strange business here Because the floor when the cube moves The floor moves with it But then it also has its own collisions applied Some very strange stuff is going to happen Let's see what happens Eh Okay well it could have been stranger But still You can do this Unity doesn't stop you But I don't think there's any real legitimate use case Where that makes sense So yeah Understand generally rigid bodies shouldn't be children Of other rigid bodies Now I have attached to this manager object I have a force demo script And the force demo script has a field Of type rigid body a public field And we need to initialize that And we can do so by assigning it the cube Because the cube itself is a game object But it has a rigid body component And so it's a valid value for this field And Unity is smart about this And when the script is initiated It'll be the rigid body component of that game object So then here in the start method of this script We can use the rigid body and get at its properties Including use gravity which will set to false And so regardless of the starting value here Whether this is checked or not And our code at the start we're explicitly making it false So the rigid body will no longer be under the force of gravity And then here we're updating the position Of the rigid body Rigid bodies themselves for a few reasons Have effectively their own transform This cube object of course has a transform Like any other game object But then the rigid body has effectively its own interior transform For both position and rotation Not for scale but for position and rotation And it works out that when you move a rigid body You really always want to do so through the rigid body's Position and rotation Not through the transform of the game object The way the physics updates works Changes to the transform of the rigid bodies Is then translated to changes of the game object transforms And that's done automatically So when you want to explicitly position a rigid body You should do so through its position and rotation properties Not through the transform of its game object So that's what we're doing here We're setting the position of the rigid body to this coordinate And we're setting this velocity So it has a velocity down the z-axis Of two meters per second This is in meters per second So we play the scene And the rigid body instantly at the start Moves to that position that we specified And moves down the z-axis off into the sunset Though notice the floor is coming with it Because it's the child of the cube Let me actually get rid of that The child of the floor Make it its own object Okay so now it's just the cube itself Moving by itself Okay We can also apply angular velocity to our rigid bodies I believe in units of radiance per second I believe This certainly isn't degrees So I assume it's radiance So now this is rotation on the y-axis Of 0.5 radiance per second Let's see that in action Hit play And yeah It's spinning along the y-axis About half a radian per second Now again understand that these movements According to the current velocity Are done at the end of every physics update And we can make this clear If we come into our project settings to time And significantly reduce the interval So instead of every 20 milliseconds We'll say every 200 milliseconds So five times a second And now if I play Object moves But it's doing so five times a second In discrete intervals So it looks really chunky 0.2 is not a very realistic value You'd probably never set it that low But if you do have a fixed time step That you feel is too low Because it produces motion That doesn't look smooth enough Rather than having shorter fixed intervals Rather than having more frequent physics updates Which gets expensive A cheaper fix to get smoother motion Is to come here to your rigid bodies And have the interpolation Of values set from none to interpolate And now I want to hit play What's happening here The motion looks smooth But be clear The physics updates are still only happening Five times a second And so the rigid body transform Is only being updated five times a second But then for these rigid bodies Marked interpolate Unity is taking those interpolated Rigid bodies And calculating the position Based on what the velocity And angular velocity were In the last physics update This interpolation assumes that still holds That hasn't changed So that's why the movement here looks continuous Because our transform is actually being Updated in position And rotated every frame But the rigid body transform is not There's also the extrapolate setting here Which is a little more expensive Interpolation has the problem Of sort of lagging a little bit behind Whereas extrapolate solves that problem But then there are going to be cases Where we get snapback Where it anticipated a movement That actually it shouldn't have And so you'll see some occasional snapback Particularly for objects that move quickly So depending upon the case Sometimes it'll get better results with interpolate Sometimes with extrapolate So now I'm going to set the fixed time interval Back to the default Reset this And looking at our code We're now setting drag to 0.04 And angular drag to 0.1f And what these values do Automatically in every fixed update The velocity is diminished Directionally by drag And angular velocity diminished by angular drag Proportion it to the fixed time step So it's this value Multiplied times the fixed interval And that then is subtracted from the velocity So then now what we should see If I play the scene Is we have our initial velocity Both angular and directional But the drag is slowing them down Until eventually We're just going to come to a halt Eventually That'll eventually stop entirely Now under physics settings here We have the sleep threshold value That's the default sleep threshold For every rigid body And what that controls is It's a measurement of so called energy It's just some sort of total cumulative value Of motion both angular and directional And below that threshold The physics object will be put to sleep Meaning that first off its velocity Both angular and directional will be set to 0 And will remain that way Until something happens Until force is applied to the rigid body Then the object will wake up And the reason we want objects to sleep Is two fold When you have a bunch of colliding objects Bouncing off each other At some point you want them to settle Maybe there's little minute collisions Still going on You want that to eventually just stop Both so you don't waste the computation time To handle those collisions And so you don't get weird behaviors Of objects that seem to be resting But they're actually jittering And doing some weird things potentially So for those reasons The system wants to put objects to sleep And to make this effect more obvious I'm setting the sleep threshold to 10 Something much larger than its default So it'll go to sleep much sooner Even while it's still moving Visibly moving And print out the sleeping state Which we got through the is sleeping method I have this field sleeping of type Boolean Which is being set in the update method And then being printed out in the GUI So I'm going to save that Come back here Play And our object will move And it should come to a halt Yeah So It otherwise would have kept going With a normal sleep threshold But with a very high sleep threshold It still was doing a significant amount Of rotation and movement But it just decided Nope, we're going to get put to sleep So the rigid body has its velocity Both angular and directional Set to zero And it's put into the sleeping state Another property we can set in code Is the rigid body's mass Which is in units of kilograms So now we're saying This rigid body has a mass of five And that will matter When we apply forces like collisions When two objects collide It matters what their relative masses are Because in Newtonian physics You get an equal and opposite reaction But momentum is not just a matter of velocity It's a matter of mass Now as currently set up Nothing in the scene Is being affected by this mass We're just directly setting the velocity And drag isn't affected by mass either So when we play this game Then nothing changes No matter what the mass is Whether it's five or five hundred But mass sometimes does come into play When we use this add force method Of rigid body Where we specify a vector And a so-called force mode And there are these four different force modes One is called velocity change One's impulse One's acceleration And force For the velocity change mode Neither mass nor time Is taking it to account And so if we add force v To the rigid body That's just like taking its current velocity And adding this vector onto it So in fact this expression This operation is exactly equivalent There's never a difference But then for force mode impulse That takes into account mass By making the force Inversely proportional to the mass So the larger the mass The lesser the velocity So it's just like dividing The velocity by the mass The acceleration force mode Doesn't take into account mass But it does take into account The amount of elapsed time And so calling this method Is simply equivalent to Multiplying the velocity by delta time And then adding it to the velocity And then lastly we have force mode force Kind of confusingly named Which takes into account both time and mass So it multiplies by delta time And then divides by the mass And again be clear Add forces is really just a convenience For these operations Sometimes you just want to Make more explicit in your code What the intention of your operation is So it might just seem a little more Readable perhaps to write this Instead of just adding to the velocity Like so But when working with rigid bodies Most commonly you'll want to apply Forces, proper forces You'll want to use force mode force And in fact that is the default value For this parameter So you can actually just leave it out And that is equivalent