Megabite #23 - Understanding Local vs World
A basic understanding of how coordinates work can go a very long way in Unity as well as other gaming engines. On a basic level, the world coordinates are the ones that an object defaults to if it's not attached as a child of another object. If it is, it then is subject to coordinates that work in relation to it's parent.
This same thing applies to both the position of an object as well as the rotation of an object.
Why is it set up like this? Well, in truth its for ease of use and more versatility in how your game works. While it might be complicated to wrap your head around at first, its a very worthwhile thing to master.
Lets take a look at an example as see what I'm going on about.
- 3 total gameobjects - none of them are a parent or a child.
In this first picture, we have 2 cubes and a camera. Each is completely independent, and one of them will not affect the other in terms of position or rotation. However, if we make one cube a parent of the other (by dragging the child atop the parent in the Hierarchy), the situation changes.
- Attached Child
- Rotating the Parent
Once the two cubes are paired, the child cube is more reliant on the parent. If the parent moves, the child moves with it. If the parent rotates, so will the child.
What you will see in the inspector will always be the local position and rotation if you have a child object selected. For the purpose of working with the Unity editor, this is typically ideal - it makes a great deal of sense when you can physically see the results of your actions and alterations.
One very common usage for this child-parent relationship would be something along the lines of attaching a camera to a player's character. As the character would move through the world, the camera would move and rotate completely relative to the player's gameObject.
Where things might get somewhat complicated is in the scripting side of things - many unity functions will default to world space and not local space. Some functions and variables will also be specifically used with child objects for the same reason. transform.position for the parent, transform.localPosition for the child, for example.
Calculations made when manipulating child objects will be drastically affected by scale as well, so while transform.position.y+=10; might make an object move exactly where you want it to go, transform.localPosition.y+=10; will not if the scale of your parent is anything other than 1. This becomes further complicated if the child's parent ALSO has a parent - calculations will need to be made to compensate all the way up the chain.
However, just because things might become complex, using this child-parent relationship in gameObjects is crucial. My best suggestion for newer users is to experiment with both the editor as well as code until you are confident you have a basic level of understanding on the subject. Of course, and questions you might have can be fielded here as well.
Happy dev-ing!