 The game objects in our scene can be arranged in a hierarchy that is a game object can have a parent And so that means that also game objects can have multiple children So here for example, I'm going to take my cube and make it a child of my sphere just by dragging it on top of it Now this indentation is implying that the cube is a child of the sphere We can give the sphere other children like I can take my manager here and make it a child of the sphere Or I can make manager a child of cube and now we have a hierarchy going three levels deep where cube is managers parent Sphere is its grandparent, or we also say that Cuban spheres are its ancestors and manager is their descendant But I'm going to put that back make it its own independent object and the significance of this hierarchy is that well One you may just want to arrange your game objects in a hierarchy for the sake of organizational purposes Like say you might just create some empty game object Which you want to use as a effectively a container a parent for a bunch of other objects Which need to logically be grouped together and something you might do for organizational purposes But the other significance of this hierarchy is that when an object is positioned in space First its own Transform is applied, but then its parents transform is applied to it as well So here the cube when it's positioned in space It's not only its own transform being applied to position it But then also after that the spheres transform and if say here I'll make the directional light a child of cube Now when directional light is positioned in space It's not just its own transform But then the cube transform and then the sphere transform in that order so we go up the chain when the transforms are applied So let me just put that directional light back And the significance of this then well in the simple case here now because sphere is a parent of the cube If we move the sphere around the cube is moving around with it because when the cube is positioned We're not actually modifying cubes transform here. Let's actually see that in action Let's open up another inspector tab Bring that down here Drag it up, and then we're going to lock this so it stays on being the sphere And I'm going to select the cube and lock this inspector so we always see the cube Okay, and as we can see here when I move the sphere Notice only the X position of the sphere is changing the transform of the cube is remaining untouched But the cube does move along with the sphere effectively because when this cube is positioned in world space It's own transform was applied and then the spheres transform was applied in some cases though This produces some strange effects the the classic example is if I were to apply a so-called non uniform scaling to a parent Like you're gonna make this y3 So X and Z are still one for scale, but then we're applying line three and if the child object has some rotation on it Here I'll just rotate in a few directions to make it even more obvious Yeah, so you may be able to tell right now that our cube is no longer a cube It has been skewed and that's happening because well that just always happens whenever you Rotate an object and then scale it after rotation You're gonna get weird distortion to the vertices and so that's why we no longer have a cube here And probably this is not what we had in mind. It's not what we expected so Generally the guideline then is to avoid non uniformly scaling your parent objects and if you want to get What maybe the expected behavior like you may assume the well, okay So the sphere itself is just along its own local y-axis It's growing three times and you want the same thing to happen to the cube that can be arranged They're they're very solutions to that problem But by default this is how the transformations work I believe to get the behavior you're probably expecting where this cube doesn't get skewed It just grows along its own what local y-axis. I think to get that behavior Unity would have to apply the scale of cubes ancestors before it applies its own local rotation And that would work that would fix the skew problem But for efficiency reasons, that's that would be more expensive because of the nature of data is laid out of memory So the engine doesn't want to do that So anyway, it's default behavior does create some aberrant cases like that Which perhaps are not expected and what you're gonna have to try and avoid Also understand that some weird things can happen that after positioning objects and Removing them as children or adding them as children Unity will try and update the transforms when you do this So that it preserves what you see but because of the skew effect, you're not always gonna get perfect results So you're gonna take the cube and make it its own independent object and yeah So now it's removed the skew But it's preserved the position and you may have noticed you'll just undo that Notice that our transform of the cube is being modified Its values have to change to so can stay in place because Because right now as a child of sphere to achieve this position in space It requires applying the transform of the sphere, but then when we make it independent These values need to be modified. We need to effectively take these values of the sphere transform and use them to Update the values of the cube transform and unity is doing that automatically here, let me put the cube back as a child of sphere and Notice up here. There's this toggle between pivot and center that affects if we select an object that has children When the pivot mode is active when you do transformations on the sphere It's as if we're doing that transformation relative to the center of the sphere and when I do rotations We're rotating around the the pivot point of the the sphere itself But let me put that back and go into center mode and now we're rotating the center here is the center point between The the pivot of the sphere and its children so now it's sort of in between the sphere and the cube and now when I apply a rotation It's doing so around that point. It's it's repositioning the objects accordingly. Look at the transform It's not necessarily just updating a single value in the transform That's normally what was happening when we were moving objects around But now unity is doing the extra math to figure out well to get this effective Position and rotation in space. What does the transform then have to look like so it's doing some extra work And also up here. We have the local versus global toggle local meaning that we're transforming Around the axes local to the object or group of objects You know, let me make that pivot again to make it a bit more clear Whereas global would be the global XYZ axis and now we'd be rotating around the global XYZ this would be around the local XYZ and Again when I do these transformations Notice that it's not just one rotation value. That's being updated. It's all three unity is doing the extra math to figure out What the transform needs to look like to get this apparent position So anyway getting used to these controls can be a bit tricky You'll need to play around with them. The core concept to keep in mind though Is that what's really ultimately going on is that your objects are really positioned by the transforms Starting with its own transform and then by applying the transforms of its parents That is the ultimate source of most confusing behavior. You'll see when you try and position objects in unity Rotations in particular tend to be the part that makes things confusing We'll play around with rotations quite a bit later when we talk about quaternions and manipulating rotations in our code So we still have the same setup here We have cube as a child a sphere and our manager has a myscript component where the cube objects map to the cube field and the sphere object is mapped to the sphere field and Looking at the code what we want to do is in our wake method where we're doing our scaffolding work of like Hooking up objects together. Perhaps we want to from an object get at its parent or its children So first here we're logging out from the cube. We're getting its parent and logging its name and from the sphere We're getting its parent and logging the name of that But notice that Cuban sphere which are game objects. They don't directly have a parent property instead We have to get it through the transform. That's a bit strange But remember again Internally transforms and their game objects are really one of the same thing and for whatever reason maybe there's an efficiency reason They decided that you can only access parents and children through the transforms rather than directly through the game objects now Let's see this in action come here play and We get printed out cube parent is sphere. That's what we expected But we also get a null reference exception and that we get because here We're accessing the name of the parent of the sphere, but the sphere has no parent So this is giving us back null and we try and access the name of that and you can't do that I guess it's a no reference exception And now down here we have this loop that's going through all the children of the sphere And it does so by accessing the count of the number of children again through the transform of the sphere Not directly through the sphere itself And then we use get child on the transform and an index value to get back the actual child Except again be clear. We're getting back a transform and not the game object itself Yet if we want to access the name of the game object We can do so directly through the transform because it has a name property But that's really just the same as if you were to write t. Game object Dot name this would be the same effect, but just for convenience We can directly get out the name and so this is printing out the name of the sphere's child And now to see this in action Well, I need to comment this out so we don't get that null reference exception come back here I'm going to duplicate the cube so the sphere has multiple children now. I'm going to play the game And we see cube parent is sphere still yes, but then sphere child cube So your child cube one spirit child cube two and cube three Another thing we may want to do in code is change these child parent relationships like say here on sphere on its transform We're calling detached children that takes all of its children and makes them independent of the parent so that they themselves are now root objects But then here we're taking the transform of our cube and sending its parent to be the sphere And again the way the API exposes this is it's not really the game objects that have the parent child relationships It's their transforms. So we're passing in a transform of the sphere not the sphere itself So now with this code if we print out all the children of the sphere It should actually only have one child now even though in our scene we have four. So let's see that in action So yeah, the cube parent is sphere, but then the sphere only has the one child the first cube and Notice that here in the hierarchy window. We see the live state of the hierarchy We detach all the cubes from the sphere and then reattach the cube to the sphere and we're seeing that state reflected here But be clear these changes are just transitory while the game plays when I stop the game Our scene is again as we defined it in the editor So all the cubes are children of the sphere at least when the scene loads and then in our code We're detaching them all and then reattaching just the first cube as a child of sphere Now if we just want to detach one child from his parent We shouldn't use detached children because that detaches all of them instead the child We want to remove we set his parent to null and that will detach it. So now Cube will have no parent. I'm gonna get rid of this line So we don't give a null reference exception there and go back and play and As you can see so just the one cube got detached and the remaining cubes remain as children And in fact, there's also a parent property which we can set And we can also set that to null and this would do the same thing. So this code is equivalent Another little convenience that strangers not mentioned the documentation if you look at the definition of the transform class You'll see it's an eye enumerable It's something that can be iterated and it's actually then something we can iterate over in a for each and when we do so What we're getting back is the children transforms So this here is basically the equivalent of what we did when we loop through the the children of the sphere And we're just printing out all the names of the children of the sphere So this is just a more compact way to loop through all the children of our sphere rather than writing this code here Annoyingly they don't mention this in the documentation Okay, so we can lock up and down our hierarchy of objects and access their transforms But often in code will want to get up the other components that make up our game objects And we can do that with a few methods including get component which is a generic method where you specify the type There's also a non-generic version of this But the generic is most convenient to use Because having specified the type here that determines what kind of component we're accessing and it also tells the compiler That what this call returns is of that type So we want to store our mesh render component for example in a mesh render a reference And so it's just most convenient to use this generic form So now from the sphere we're getting its mesh render components joined in M And again a transform and its game object are really kind of the same thing internally So the get component and similar methods are also accessible through the transform and they do the same thing So this line of code is doing exactly the same thing the previous one did It's getting the mesh render component of the sphere and assigning it to M So now we have a component. What can we do with it? Well, that depends on the kind of component and we'll get into the details of the various component types later For now though, there is one thing which all behavior components share in common Remember that many of the component types inherit from behavior which in turn inherits from the component type And what behaviors add on top of the base component type is they have an enabled property And as you would expect when the enabled property is true That component is active and does its normal business every frame But when we set the enabled property to false then we're effectively Disabling that component it does not have its usual effects its business does not get performed every frame until we re-enable it So in this case if we're disabling the mesh render component of our sphere That should have the effect of making the sphere no longer render Logically, it's still there. The object still exists. It's just its rendering is not getting done So the significance of this flag depends upon what kind of component we're talking about in this case It's just a matter of whether something gets rendered and then down here in addition to get component There's get components plural in children and we specify a component type And this will return an array of mesh renders Including the mesh render of the object itself the sphere itself But then also all the mesh renders of its children as well And I believe this only goes one level deep So if our children had their own children it wouldn't look for the mesh renders in those children Just the immediate children of the sphere itself Anyway, so having gotten back this array, we're not going to do anything with it except just print out its length Similarly, we have a get components in parent method this time. We're getting the transform component But it's going to include the transform of the cube itself and its parent which is going to be the sphere So we should expect this length here to be two so let's see this code in action come over here hit play and Number renders is five because we're getting back a mesh render for the sphere and all of its four children That's five and then num transforms is two because the transform array will include the cube transform the first cubes transform And the spheres transform Actually, there's sort of a strange asymmetry in the API here where if I make here sphere a child of manager Now the cube has two ancestors and has this direct parent sphere, but then also its grandparent manager And if we run the code again Num transforms is three Because get components in parent isn't just looking at the immediate parent. It's going up through all the ancestors So we're going to get back three transforms here But again get components and children doesn't behave like that get components and children just goes one level deep It just finds the components in the immediate children. It doesn't traverse through all the descendants I'm not sure why there's that a symmetry It's probably some sort of efficiency thing or maybe they decided that that's the behavior most commonly needed But of course, we don't really need these methods Anyway, if we ever really need to get out the components we want We could just traverse the tree of objects and collect the components we need into our own array