Primitives

How are GUIs represented using object-oriented design? Simple: by composition.

First, you get access to basic building blocks: buttons, text boxes, check boxes, labels, etc. Next, you get a means of putting these together into larger whole. For example, using WPF terminology, a StackPanel allows you to put GUI controls next to each other, either horizontally or vertically. A Grid allows you to layout controls in a grid-like fashion. You can see these panels as "operations" on GUI controls, a bit like the "addition" of two controls yielding a new, bigger control.

There are many such "operations" available:

The most important aspect of the Composite design pattern is its recursiveness. In other words, if you apply an operation (be it a Panel, a ViewBox, a Border, or whatever) on a control, the result is once again a control, on which you can then proceed to apply the same operations again. For example, you can have a Button, you can apply the Border operation on it, and then again, and then once more, and you’ll have a button with three borders. This three-bordered button can then be put inside a panel, which can be put inside a ViewBox, etc. This recursiveness, i.e. that every operation on controls yields a new control, allows you to build arbitrarily large GUIs.

Classes and objects follow the same principle. Here, the basic building blocks are the primitive types: int, char, bool, … Classes allow you to group these together into new types, and these new types can then be used in the construction of other types, and so on.

Imagine what would happen if this were not the case: say a class can only contain primitive types. This would be quite restrictive, making large programs much more difficult to create.

This brings us to the operations we can apply on these primitives. There are actually many types of operations available, some more abstract than others. The most straightforward operations are transformations:

So, even though spheres themselves only come in size 1, you can use scaling to make them as big or as small as you want. This approach has the advantage that it makes the implementation much simpler. It is certainly possible to create a Sphere class whose constructor takes a center and radius parameter, but the mathematical formula behind it will be more complex.

For example, take the cylinder primitive. For an arbitrary cylinder with radius \(R\) whose axis has direction \(\vec N\) and goes through some point \(P\), the formula is

This is quite an intimidating formula. If, however, we choose to only support vertical cylinders going through the origin, i.e., \(\vec N = (0, 1, 0)\) and \(P = (0,0,0)\) with radius \(R = 1\), this formula can be simplified considerably.

So, although this approach requires us to write more classes, they are much easier to write since they each have very limited responsibilities. Each class can also be tested separately, further simplifying our job.

We have discussed the basic building blocks (sphere, cylinder, cone, …) and transformations (translating, scaling, rotating). This merely allows us to create scenes consisting of a single shape, but hey, look at the bright side, it can be as big as you want.

In order to allow for scenes built out of more than one shape, we need some "grouping" operation, like panels in GUI libraries. For this, we provide Constructive Solid Geometry operations.

These operations together with transformations allow you to craft any shape you want.

Another important operation on primitives is the decorator which assigns a material to a primitive. By default, a basic shape has no material assigned to it, meaning it has no color (not even black), no reflectance properties, etc. It is therefore an error to try to render an undecorated shape.

We can define any kind of materials. Examples are

Consider the scene shown below.

It is described by the following hierarchy:

In the animation above, you can see two separate objects: a plane with a grid drawn on it and a green lens. The union at the top of the hierarchy has as sole purpose of grouping the plane and lens together. Both the plane and the lens need to be decorated; as you can see, there’s indeed a separate decorator for both. We omitted the details of the material. The plane material is responsible for the grid pattern, while the lens’s material specifies that the lens is green and refracts light.

The lens is placed above the plane. We can achieve this in multiple ways: we could lower the plane or raise the lens. We decided to move the plane downwards.

Lastly, we need to create the lens. The lens is not a basic shape, but it can be created by intersecting two spheres: we create two spheres, move one a bit to the left, the other to the right, and we only keep their intersection.

The following C++ code performs all necessary steps to create this scene. Take some time to see how it works.

The ray tracer is also equipped with a scripting language. Using this language is much more practical: if you were to create each scene in C, you'd have both to deal with C's complexity and long compilation times. Using the scripting language avoids all of C++'s pitfalls, plus it requires no compilation. In this scripting language, the same scene would look as follows:

As mentioned above, find_all_hits's job is to determine where a ray hits the primitive. Let’s consider the case of a sphere:

The ray (yellow) hits the sphere in two locations \(H_1\) and \(H_2\). For each hit, the following information has to be computed:

The difference between the local and the global position only becomes apparent when primitives are moved around. Say, for example, that the ray goes through the top of the sphere. The sphere itself is centered at \((0,0,0)\). Both the local and global position are then equal to \((0,1,0)\). If we were to move the sphere to \((5,1,2)\), the local position would still be \((0,1,0)\), but the global position would become \((5,2,2)\). In other words, the local hit position is not affected by transformations, but the global position is.

All these pieces of information correspond to member variables of the RayTracer’s Hit structure. A primitive does not have to update each field, but only those that apply to the primitive in question. A sphere primitive will have to fill out the t-value, the local and global position, and the normal. The material and group id are ignored: these are the responsibility of other primitives (namely the decorator and group primitive, respectively.)

Let’s now consider the decorator primitive. A decorator object has two member variables:

So, how does find_all_hits work in the case of decorators? It’s very simple: since a primitive and a decorated primitive have exactly the same shape, the hits will also be the same. This means that a decorator object can simply ask its child primitives for its hit list. Go take a look at the code to see how this happens.

Once the decorator gets hold of the hit list returned by the child primitive, it has to update the Hit objects somehow, otherwise the decorator wouldn’t be much use. For every hit in the list, it updates the material member variable, thereby assigning a material to the hit.

A transformer primitive has two components: a transformation (which in turn keeps 2 matrices) and a primitive. What does a transformer need to do when asked for its hit list?

To better understand what happens, let’s again venture into a completely different situation. Say you want to make a monster movie about a 100m tall monster, but you only have the budget to buy a small 10cm stuffed animal. How do you make it look big and terrifying? The answer is simple: you place the camera very low to the ground and make it look up towards your stuffed animal.

In our RayTracer, the same problem arises: we only support small spheres, yet we need to make it look big. Instead of growing the sphere, we choose to shrink the camera. Earlier we mentioned the transformer also needed the inverse transformation: this is the reason why. If we want to enlarge a primitive 20 times, we need to be able to miniaturize the camera 20 times.

Say a transformer is initialized with matrices \(M\) and \(M^{-1}\). When asked to give a list of hits, it proceeds as follows:

Let’s apply this on an example:

We have a sphere with radius 3 (solid white circle), which is actually a regular sphere of radius 1 (dashed white circle) scaled by a factor 3. We want to find the intersections of the ray \(O + \vec\Delta t\) with this big sphere (lower yellow line).

Let’s take a look at how the bounding_box function might be implemented for different primitives. For spheres, it’s quite simple: we know the sphere has radius 1, so we build a box around it with corners \((-1,-1,-1)\) and \((1,1,1)\).

A decorator does not change anything about its child’s shape, so it can directly reuse its child bounding box without modifications. Do remember that a bounding box is invisible, so material does not matter.

There is a bit of hidden complexity here. At first glance, you might think implementing bounding_box on transformers is simple: just transform the bounding box. There are, however, two issues.

Bounding boxes need to be very efficient: we want to be able to tell whether a ray hits a box very quickly. This is why we chose to make bounding boxes axis-aligned, meaning each side of the box needs to be parallel to either one of the X, Y or Z axis. If we allow any kind of box orientation, the is-there-a-hit algorithm would be much slower.

Translating an axis-aligned bounding box yields another axis-aligned bounding box, so no problems there. The same is true for scaling. Rotation, however, is another matter:

The tilted box is not axis aligned anymore, so we need to build a new bounding box around it (dashed). While this is not difficult, it does require a fair amount of calculations.

The second issue arises with infinite bounding boxes. Planes, cylinders and cones are infinitely large, so their bounding boxes must be too. Computations involving infinite values, however, tend to go awry. This can be solved as follows: