You have to step outside the world of mathematics for a while and look at what we are trying to achieve. Mathematics in its purest form only tells us what kinds of properties certain constructs have, it does not tell us why and how that would be useful.
The modeler's perspective on things
So we have to look at the problem from modeling perspective. In this perspective it is mostly irrelevant how the mathematics work. As long as it provides the modeler with a system that yields with a understandable toolset to do his work everything is as it should be.
It is frequently beneficial to describe things such as physical objects (creatures, mechanisms etc.), forces or any number of other things independent of each other. Either because it's easier to think in one orientation or just simply because you want to move/rotate/scale objects out of convenience.
In practice you want at minimum that the camera is separated from the rest of the objects. While in more complex cases you want to have a more rich system. For example a bug is walking straight ahead on a straw. For practical reasons it would be neat if the bug only move forward in relation to the straw while the straw sways in the wind in relation to the world and the camera is independent of the straw. Similar modeling cases happen a lot, in human hands, robotics, car simulations, Finite object modeling etc.
Computational perspective
The rendering and other functions need to be able to transform elements from these modeling hierarchies to each other. For example you need to know the point location in camera space to render. Preferably all this space transform happens automatically. For this purpose the modeler tells your application how the modeling elements are structured in relation to each other, a hierarchy, for modeler's benefit.
Although this could be done in any number of ways it is commonly done with a tree structure, much like a filesystem with much the same effect. Each level stores in addition to tree information a affine matrix that describes the transform to its predecessor in the hierarchy. Mainly because this takes care of two core issues. The tree structure is easy to traverse and find the path to any other part. The matrices solve the problem of needing to do a lot of work transforming form a transform from one hierarchy space to another.
So the user provides a tree where each object describes the transform required to transform the object to the coordinates of the object it is described in relation to, the parent. This parent in turn in turn describes the transform to its parent all the way to the world. Since all objects share one common ancestor, world, we can easily traverse the tree to find a transform path from any one coordinate system to another coordinate system.
Since linear transforms are invertible, we do not need to store a description separately for moving in the opposite direction, away from world towards the children/leaves of the tree structure. All we need to do is to invert the matrix. This is almost always needed as it's practical to describe camera as a separate object under the world, there is no reason to describe the cameras transform from world to camera just treat it like any other object.
To compute a point from one space to another you do as follows:
- Use the tree to find a relationship between spaces.
- For each step on the way pre multiply your matrix/ or its inverse if you're traversing away from world. **
Example: You have the following hierarchy because it makes sense (this way you do not need to model each petal separately)
World
|
+---- Flower
| |
| +--- Petal 1
| |
| +--- Petal 2
| |
| +--- Petal 3
|
+---- Track
|
+--- Boom
|
+--- Camera
To render Petal 1 you need to transform the vertices of petal one into the camera object space and from there to perspective space etc. Your calculation would be:
$$
T_{\text{Perspective}} \cdot T_{\text{Camera}}^{-1} \cdot T_{\text{Boom}}^{-1} \cdot T_{\text{Track}}^{-1} \cdot T_{\text{Flower}} \cdot T_{\text{Petal 1}} \cdot \vec{v}_{\text{PetalPoint}}
$$
This way you can model a flower in a flowerpot totally independently from from the robot shaking the camera about. At the same time freeing the modeler of the need to do complex trigonometric calculations, and in fact a big load of mathematics. Pretty neat.
Now that you understand why, you should understand also that we do not have any limit to complexity of the hierarchy to
facilitate a broad range of things you could do.
This kind of hierarchy is called a scene graph and such things can be found in web pages, vector and CAD applications, many scientific modeling applications, most games.
This should answer why as well as the less exciting how.
Do we absolutely need these?
No, we do not. We can dispense all the matrices and describe all of our data directly in the camera's final coordinates. It's just that this is horribly complicated in 98% of the cases.
In practice we need this hierarchy if we try to do even something more complex than a stationary box. Most of this deign is to make scene modelers' life easier. So that simple operations make more sense.
* why do we call it a parent child relationship? Because it's a tree, and earliest tree graphs are genealogical studies, aka family trees. Where the previous level is simply the parents and the next one is their children.
** or the other way around if you want to transpose your calculations.
