In THREE, objects (instances of Object3D) can contain other objects. Rather than adding an object directly to the scene, we can add an object to another object. This parent object can be added to the scene (or to another object). In order to be in the scene, an object either needs to be added to the scene, or added to some object who has a parent that is part of the scene (recursively).
In the previous workbook (and in class), we learned that in THREE, every object (technically, every instance of Object3D, which is the base class for just about everything), has its own transformation associated with it.
This transformation is relative to the object's parent. If the object is simply placed in the scene, the transformation is relative to the scene (the scene is not actually an Object3D). However, if the object is a child of some other object, then its transformation is relative to that object. If you transform the parent, the children are transformed as well.
When an object has a parent, its transformation is composed with the parent transformation. In class we talked about how this trickles along the tree of object containment.
In THREE, there are special Group objects (documentation). These objects have no geometry themselves - they exist only to serve as the parents for other objects.
The three documentation for Object3D (here) says:
Note that this can be used for grouping objects via the .add( object ) method which adds the object as a child, however it is better to use Group for this.
It is unclear why it is better, or when you have to use a group rather than simply adding a child object to some regular object.
When we did hierarchical modeling in 2D Canvas, we had to worry about saving and restoring transformations. We talked about how we use the "transformation stack" to implement hierarchy.
When we use a scene graph API like THREE, the steps of applying and saving transformations are taken care of as part of the scene graph traversal process. Basically, in order to do drawing, the tree must be traversed to visit all objects. As part of this process, the transformations are applied appropriately. The algorithm for doing this involves saving the state before descending down the tree to a child node, and restoring the state when returning to a higher level node in the tree. This is usually (but not always) implemented using a matrix stack. The books (FCG 12.2 (FCG4_Ch12.pdf) and Hart Chapter 7 (Hart07-jan19.pdf)) discuss this if you're curious. But for now, THREE will take care of it for us.
Now we've seen how hierarchical modeling works in THREE. On the next pages, you'll get to try it. First, to make a Quadcopter again (like you did in 2D), and then to use the CS559 code framework. Be sure to do all three exercises.
Start with the Quadcopter on the Next Page, and then read about the CS559 Code Framework before the last two exercises.