3
$\begingroup$

After asking this question, a few new terms that I had never heard of came up. Note, I'm quite familiar with linear algebra, but I've never heard these terms in the context of linear algebra.

Comments like

In my example, you can use the columns to get the basis vectors of the coordinate system it describes. The columns are in the coordinate system of whatever the parent coordinate system is. If there is no parent coordinate system, they are in global space. Else, they are in the coordinate system of the parent.

What's a parent coordinate system? When is this term used? Why is it called a parent coordinate system?

Then the author of the comment tries to explain me the meaning as follows:

Matrices can be parented off of each other, but that is probably too confusing to visualize as you are just trying to learn things. Just imagine that if there was a matrix hierarchy, that all the matrices are multiplied together into one matrix M then you can ignore hierarchies.

This hasn't really cleared things up. What is it mean that matrices can be parented off of each other? What is it meant by matrix hierarchy?


I know that if you have $m$ $A_1, A_2, \cdots, A_m \in \mathbb{R}^{n \times n}$ matrices which represent transformations, any combination of products of these matrices represents clearly a new transformation. For example, say that $A_1 * A_2 = B_{12}$. Suppose now that we have a vector $v \in \mathbb{R}^{n \times 1}$. Then the following two statements should clearly be equivalent

$$A_1 * A_2 * v$$

and

$$B_{12} * v$$

but the transformations used are different, i.e., in one case we use two single transformations (i.e., $A_1$ and $A_2$) and in the other case we use only one transformation, namely $B_{12}$.

Now I don't know if this has something to do with "parent coordinate systems", but I just wanted to show you a few things that I'm suspecting could be related to this terminology and concepts of computer graphics.


Final question would be: does it make sense to talk just about "parent coodinate systems" or does it also make sense to talk about "parent vector spaces"? Why?

$\endgroup$
  • $\begingroup$ "What is it meant by matrix hierarchy?" It is a hierarchy of matrices. $\endgroup$ – Nicol Bolas Jan 13 '17 at 14:01
  • 1
    $\begingroup$ You should read this scene graph page. The scene graph is where the parent and hierarchy concepts come from. $\endgroup$ – Olivier Jan 13 '17 at 14:07
  • $\begingroup$ @NicolBolas I know what's a hierarchy, and I know that it starts to make sense to talk about matrices hierarchies, if there are parent-child relationships between matrices. $\endgroup$ – nbro Jan 13 '17 at 14:09
  • 1
    $\begingroup$ BTW, if you dont get a good answer here nbro, mathematics stack exchange may be able to help more! math.stackexchange.com $\endgroup$ – Alan Wolfe Jan 13 '17 at 16:59
  • 1
    $\begingroup$ @user18490 no nbro understands what matrices are he just didnt undersatand why you would have hierarchies. He is looking at it form very mathematical perspective. There is no such concept in nonapplied mathematics. Having chains of transforms makes only sense for modeling reasons. $\endgroup$ – joojaa Jan 20 '17 at 12:09
4
$\begingroup$

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:

  1. Use the tree to find a relationship between spaces.
  2. 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.

$\endgroup$
1
$\begingroup$

First start to be sure you understand what matrices are (4x4 which are the most common in CG).

1) about your first question. You are taking about a hierarchy of transforms. I don't know if you use Maya at all, but if you do, you know you can for example create a sphere and group this sphere. So you have:

Group1
   |
   --Sphere1

That's the a hierarchy where Group1 is the parent of Sphere1. What does that mean is that if you move Group1 then Sphere1 will move with it. If you move Sphere1 instead, then of course Sphere1 will move but Group1 will stay where it is. That's what parenting is used for.

So I as mentioned you can apply a transform to Group1 as well as a transform to Sphere1 and transforms as you know can be expressed as 4x4 matrices. So Group1 has a 4x4 matrix to represent its transformation (scale, rotation, translation) and sphere1 has one too.

2) so the sphere is affected by the matrix applied to Group1 (since it is parented to Group1) and the matrix applied to the sphere itself do you agree? If you want to transform the sphere then you need to apply both transformation:

Sphere_Final_Rot_Scale_Trans = Sphere_Default_Scale_Rot_Trans * Mgroup1 * Msphere1

Where Mgroup1 is the 4x4 matrix of Group1 and MSphere1 is the 4x4 matrix of the sphere.

However rather than multiplying the sphere by the 2 matrices, you can combine their effect into a single matrix. Just do:

Matrix44f Mcombined = Mgroup1 * Msphere1

This is also called a matrix concatenation. Then you can do:

Sphere_Final_Rot_Scale_Trans = Sphere_Default_Scale_Rot_Trans * Mcombined 

Simple! So all you need to know here is about matrix multiplication. Do you know that if you multiply 2 matrices together you get a third matrix that combines the effect of the first 2?

$\endgroup$
  • $\begingroup$ You probably also need to know about matrix inverses ;) $\endgroup$ – joojaa Jan 20 '17 at 12:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.