Page 12: Hierarchy
Spring 2026 Sample Solution
On this page, we’ll extend the single articulated chains from the previous page to make more complex objects. We’ll use hierarchical modeling, the idea that we have parts that fit together into wholes.
The lecture videos cover this topic well:
And you can also learn about it from the Graphics in 5 Minutes Video: Hierarchical Modeling in 5 Minutes, although that discusses it with the math that we haven’t covered yet.
Where this is going…
We want to make complicated objects with multiple parts that stay attached, but move relative to each other. We want cars where the wheels spin around the axles, even as the whole car moves. We want characters whose arms and legs bend, but stay attached to the body. Here’s an example that I made (it will come back on a later page):
Notice that this character is made up of rigid pieces that rotate relative to one another.
The place where pieces are attached (the centers of rotation) are called joints. The crab has a lot of them. We’ll start with something easier.
Two Arms
Here is a variant of the arm example from the last page. This time, I made two arms.
Again, since the code gets a little long, let me make a simpler version so we can focus on the interesting pieces…
|
|
I have indented the code to make it clearer. I started by drawing the green square in the center, the “body”. I put it at the center of the canvas. The center of the coordinate system is the center of the body.
I then drew the right arm (lines 4-9). The main thing that is new is that I use save when I start drawing the arm. That way when I am done drawing the arm I can return to the “body” coordinate system with restore. Because I didn’t want to think about negating all of the design of the right arm to make it go to the left, I just used scale to cause a mirror reflection on line 73.
If you notice, the two arms are the same. I can write the code once and just reuse it.
This isn’t much shorter. But it does have the advantage that if I improve the arm, I improve all of the arms. Of course, I can use the arms multiple times…
I didn’t make more sliders - so all arms on a side do the same thing. But hopefully you can read the code and get the points.
What are the points?
- Notice how I defined each object as a rigid piece, with a “joint center”. I used rotations around those joint centers.
- I translated each object to its place relative to its parent (the thing it is connected to).
- I used
saveandrestoreto go back to a previous coordinate system that I wanted to work in.
The save and restore are important. And I should point out… there needs to be a save and restore with every redraw. Each redraw needs to return the coordinate system to a place where the next redraw expects it. The workbook does this automatically for each “inline code box”.
Box 1: Arms and Legs
Here’s a little more complete version of the arm example:
view - look at the box and experiment with it
examine - look at the code for the box
edit - change the box's content
rubric - several steps are suggested in the rubric page - form elements on page in rubric
02-12-01.html 02-12-01.js
This has so many parameters (one for the “root” position x,y and one for each angle) that the sliders are made with a loop! Try it out and see how each joint is connected to a slider. The code can be found in 02-12-01.js .
The place to focus on is the drawBody function (in
02-12-01.js
). It takes the parameters for the rotations and root positions, and draws the hierarchical figure.
In this example, notice how some parts (the body) have multiple parts inside of them. Our hierarchical model is a tree. For the stick figure, the “root” is the body, which has 4 sub-parts (the four limbs).
If you look carefully, you will notice that the arms are actually the same code repeated (with a changed coordinate system by scaling the X axis to make it go the other direction). We could have made the two arms the same (they are instances).
Because we can have instances (the same part used by multiple “parent” parts), hierarchical models are usually thought of as directed acyclic graphs (or DAGs). A DAG is the generalization of a display list. We discussed display lists in the previous workbook. A common term for a DAG that represents a hierarchical model is a scene graph.
Most retained mode APIs (including SVG and THREE.js, which we will use later in the class) support representing models as scene graphs. In Canvas, because it is immediate mode, we either need to represent the graph in our own data structures, or represent the graph implicitly in code. The latter is what the drawBody function does: you can see the hierarchy of parts, but we never create any data structures to represent them.
More on Save and Restore
Hopefully, you noticed that we can do many saves and restores. When we restore, we get back to the most recent save. When we restore again, we go back to the save before that.
We usually think about saving and restoring as a stack. Save pushes a copy of the current context onto the stack. Restore pops a context off the top of the stack and makes it the current context.
An alternative way to think about this is that the “current context” (the one that we are using) is the context at the top of the stack. Save makes a copy of the current context and pushes it onto the top of the stack (so we start using that copy), while restore pops the top element off the stack and discards it (so the “current context” is now the element that is newly exposed on top of the stack). This is how many systems actually implement the “context stacks”.
In Canvas, we call these operations save and restore and they act on a context. Many other immediate mode graphics systems have similar operations with a stack of contexts. Often the save operation is called push and the restore operation is called pop (which makes sense given what they do). Because the most important piece of context we save is the current coordinate system (or transformation), the stack of contexts is sometimes called a matrix stack because transformations are represented as matrices.
All that is relevant because (1) you need to understand the concept of the stack; and (2) when you read code (or books) written for something other than Canvas, you will see stack terminology.
At this point, you will want to see another example of hierarchical modeling (or more than one). I recommend looking at the lecture video and/or the graphics in 5 minutes video:
Hierarchical Modeling in 5 Minutes (which is part of Graphics in 5 Minutes). This video assumes you’ve learned the math from Affine Transformations in 5 Minutes.
Summary: Hierarchical Models
Hopefully, you have gotten the idea of how we use hierarchical modeling to put complicated objects together. Next week, we’ll learn about how transformations are implemented using linear algebra. But for now, we’ll give you a chance to make some models on your own on the next page.
Next: Page 13 - Quadcopter Exercise