Lab 3: Transforms and Parsing

There are many ways to classify transformations. In the paragraphs above, we are considering their mathematical formulation: translation is not a linear transformation as it does not preserve the origin, and this conclusion is entirely based on the definition of what a linear transformation is.

You will soon see that what is non-linear in one dimension, can actually be linear in a higher dimension 😉.

There is, of course, another way to look at classify transformations. We might do so based on what geometric features they preserve:

Type Of Transformation	What They Preserve	Examples
Displacements	Distances and oriented angles	Translations
Isometries	Distances and angles	Rotations, reflections, and the above
Similarities	Ratios between distances and angles	Uniform scaling, and the above
Affine transformations	Parallelism	Non-uniform scaling, shear, and the above
Projective transformations	Collinearity	Perspective projection, and the above

Adapted from the Wikipedia page on geometric transformations

To illustrate the problem we are now facing, suppose we wanted to translate points by some non-zero vector . Let's use the origin as our example point. What matrix could we use such that ?

Oh dear. No matter what values we put in 2x2 matrix, the output can never be equal to non-zero vector . Clearly, a 2x2 matrix is not sufficient for representing a translation of a 2x1 point in this way (and the same can be shown for 3x3 matrices, with 3x1 points).

Fortunately, adding the extra dimension does not break how points and vectors work. We won't prove this, but here are two examples:

But, we'll have to modify our previous linear transformations to be compatible with our new matrix size. For scaling and rotation, we simply add another dimension (i.e. another row and column) with s for all the values, except for a along the diagonal, like this:

Note how the new, "extended" portion of the matrix resembles the identity matrix. Intuitively, this is because we do want our transformation matrix to still do the same thing, and not change its behaviour just because we added another dimension.

Since for vectors, if we try to translate a vector, we will just end up with the same vector:

Let's say we have a square at the origin that we want to perform the following transformations on:

• Scale x by 1.5 and y by 2
• Rotate by 45°
• Translate by (3, 3)

Here's what happens if we translate, then rotate, then scale (SRT):

Notice how we scale along the standard axes, so rotating first changes the way the object is stretched. Both rotation and scaling are centered at the origin, so translating first changes the final position.

And here's what it looks like if we scale, then rotate, then translate (TRS):

Which looks more like the result you'd expect?

At the top of the graph is the world origin. From it, the rest of the objects and camera branch off, with nodes in between to represent the transformations applied to the objects and camera.

Here's a guide to our notation of transformations:

S X,Y,Z:   scale by factors X, Y, and Z along the corresponding axes
R X,Y,Z,𝜃: rotate by angle 𝜃 about the axis defined by unit vector [X,Y,Z] ([1, 0, 0] would denote the x-axis, for example)
T X,Y,Z:   translate by X, Y, and Z along the corresponding axes

Looking at our graph again, each leaf of the tree is an object in the scene. Traversing the tree from the object to the root will create a path through all of the transformations applied to that object in the scene. So to transform Object 1 to world space, for example, first apply transformation A then C. The cumulative transformation matrix of an object in the scene, resulting from this ordered multiplication of matrices, is referred to as the object's model matrix.

Previously, we emphasized the need to order each of the T, R, and S transformations. Now we may be dealing with multiple matrices composed of multiple T, R, and S transformations, but for the higher level ordering we follow the graph hierarchy.

You can click and drag to move around and scroll to zoom.

The white grid in the background represents the world coordinate system. The white axes at the origin represent your current coordinate system. Though they aren't labeled in the demo, these are labeled here for your reference.

Each of the buttons A, B, C, and D are linked to the functions you completed in the last task to return transformation matrices. Pressing any of these buttons will apply the corresponding function's transformation to the white axes. We have also provided you with inverse buttons for each of these that will return the inverse of the corresponding matrix. (Don't worry about the "View" or "Rotation" buttons for now, you'll be implementing those later.)

As you press the buttons, the text underneath that says "you" will update to reflect the order of transformations you use. Pressing the "reset" button will move your axes back to the origin and reset this label.

Wondering why our view matrix does translation first and then rotation, even though earlier we said rotation should usually come first?

As with the objects' model matrices that we looked at previously, the matrix that transforms the camera to world space is composed of a rotation first then a translation. Since the view matrix is the inverse (it transforms objects from world space to camera space), we must reverse the order of the multiplication.

World Space:

Think of world space as your default overarching coordinate system. Everything else gets placed into the scene relative to the origin and units of the world's coordinate system. World space is arbitrarily defined and acts as a fixed space within which everything else can be defined. In the transformation graph we've been looking at, it is the root that everything else stems from.

Camera Space

Camera space is what you learned about in part 2.9 of this lab. It is the coordinate system defined by the camera's position and rotation. In camera space, everything else in the world is relative to the camera's view, with the camera being placed at the origin, and its axes becoming the . In part 2, we went over how to get the view matrix, which takes world space points and transforms them into camera space.

Object Space

Object space is pretty much what it sounds like - the coordinate system in which an object is defined. In the demo, these are represented by the little sets of axes drawn for each object in the scene.

For example, you might want to make a bunch of variations of a sphere that are all different sizes and in different locations. Rather than define each sphere separately, we can define a single sphere as a set of points around an origin, and then transform those points. You can perform calculations on points in the sphere relative to its own central origin, and then use its model matrix to get those points in world space.

If you have started Project 2: Intersect, you might have reasoned that one of the reasons ray tracing is so computationally expensive is because we need to check for ray-primitive intersections. This is especially true when there are many primitives in the scene to check against.

We use a vector/list to iterate through all the primitives in the scene because it is simple to implement, and has traditionally been sufficient for the requirements of this course.

That said, there isn't any reason that this part of RenderData has to be a vector/list. If you want to get fancy, there are more efficient alternatives which allow for much faster ray-primitive intersection tests (see: "accelerated" data structures like octrees, bounding-volume hierarchies (BVHs), and KD-trees, all covered in lectures).

// Struct which contains the global color coefficients of a scene.
// These are multiplied with the object-specific materials in the lighting equation.
struct SceneGlobalData  {
    float ka; // Ambient term
    float kd; // Diffuse term
    float ks; // Specular term
    float kt; // Transparency; used for extra credit (refraction)
};

SceneGlobalData stores the global ambient, diffuse, and specular coefficients, as well as the transparency index of refraction. These are used to calculate how light interacts with the scene.

// Struct which contains data for the camera of a scene
struct SceneCameraData {
    glm::vec4 pos;
    glm::vec4 look;
    glm::vec4 up;

    float heightAngle;   // The height angle of the camera in RADIANS

    float aperture;      // Only applicable for depth of field
    float focalLength;   // Only applicable for depth of field
};

SceneCameraData stores pos, look, and up in world space, so the view matrix can be built directly from those values. One important thing to note is that pos, look, and up are all defined in world space. They'd be pretty useless if they were defined in camera space.

SceneLightData supports point, directional, and spot lights. A point light has a position. A directional light has a direction. A spot light has both, plus cone parameters.

// Struct which contains data for a single light
struct SceneLightData {
    int id;
    LightType type;

    SceneColor color;
    glm::vec3 function;  // Attenuation function

    glm::vec4 pos;       // Not applicable to directional lights
    glm::vec4 dir;       // Not applicable to point lights

    float penumbra;      // Only applicable to spot lights, in RADIANS
    float angle;         // Only applicable to spot lights, in RADIANS
};

Each light in our scene is represented with a struct that includes its LightType, its color, and other relevant information depending on the LightType.

1. A point light is a single point in space that emits light equally in all directions (e.g. an infinitesimally small lightbulb). It is defined by its color and position.
2. A directional light is a global light which simulates light from a source that is infinitely far away (e.g. the sun, as we experience it on earth). It is defined by its color and direction.
3. A spot light is much more interesting—it is effectively a point light, but it emits light only in a cone shape (e.g. a flashlight). It is defined by its color, position, and direction, as well as a penumbra and angle, which describe its cone.

Documentation about virtual lights commonly used in 3D scenes can be readily found online, such as in the Unity3D manual.

ScenePrimitive stores the primitive type and material. Mesh files are only needed for triangle meshes.

// Enum of the types of primitives that might be in the scene
enum class PrimitiveType {
    PRIMITIVE_CUBE,
    PRIMITIVE_CONE,
    PRIMITIVE_CYLINDER,
    PRIMITIVE_TORUS,
    PRIMITIVE_SPHERE,
    PRIMITIVE_MESH
};

Much like with LightType, we use PrimitiveType to identify different types of primitives. This is used in a struct, ScenePrimitive, to describe a specific primitive in the scene:

// Struct which contains data for a single primitive in a scene
struct ScenePrimitive {
   PrimitiveType type;
   SceneMaterial material;
   std::string   meshfile; // Used for triangle meshes
};

Every primitive has both a type and material. The meshfile field will only be relevant if you'd like to implement triangle mesh rendering, an extra credit option for our Ray and Realtime projects.

material contains important information about what the primitive looks like (e.g. its color, how shiny it is, any textures, etc.). You can look at the definition of SceneMaterial for details, but it's fine not to understand any of the terms which haven't yet been covered in lecture.

Observe that, unlike the light or camera structs, there aren't any fields in ScenePrimitive that describe its transformation. This is because it's more practical to use scene graphs to manage this, especially when we have a lot of primitives!

The parser uses four types of transformations:

// Enum of the types of transformations that can be applied
enum class TransformationType {
    TRANSFORMATION_TRANSLATE,
    TRANSFORMATION_SCALE,
    TRANSFORMATION_ROTATE,
    TRANSFORMATION_MATRIX
};

SceneTransformation stores the specific data for one transform:

// Struct which contains data for a transformation.
struct SceneTransformation {
    TransformationType type;

    glm::vec3 translate; // Only applicable when translating.
    glm::vec3 scale;     // Only applicable when scaling.
    glm::vec3 rotate;    // Only applicable when rotating.
    float angle;         // Only applicable when rotating.
    glm::mat4 matrix;    // Only applicable when transforming by a custom matrix.
};

Our scene graph is composed of nodes, each of which describes zero or more of the following:

1. a series of transformations,
2. a number of primitives, and
3. a number of child nodes.

SceneNode looks like this:

// Struct which represents a node in the scene graph/tree, to be parsed by the student's `SceneParser`.
struct SceneNode {
   std::vector<SceneTransformation*> transformations; // Note the order of transformations described in part 4.3
   std::vector<ScenePrimitive*>      primitives;
   std::vector<SceneNode*>           children;
};

If a SceneNode has transformations, those apply to both its primitives and children.