**Contents**

## A Minimal Ray-Tracer: Rendering Spheres

In this chapter, we will detail the source code of the program that is provided with this lesson. The program is a basic but functional program that accurately renders a scene containing spheres only. Here is a list of the program's main features:

- Camera transformations are supported. In other words we can render the scene from any viewpoint. To do so we will be using what we learned in the previous lesson on generating camera rays.
- Geometry visibility is correct. If a ray intersects more than one sphere, we display the sphere with the closest intersection distance.
- When an intersection is found, the normal and the textures coordinates of the intersected point on the sphere are computed. We will use them both to shade the spheres.

The problem we first need to solve is to find a way of supporting different types of geometry in the program. In this version of the program we want to render spheres and spheres only but what if we want to render polygon mesh in the next version? They are different ways of tackling this problem, but the way it is usually done in C++ is by taking advantage of class inheritance mechanism. We generally define a **base class**, which provide a generic definition of the concept of geometry in the program. We can add to this class as many virtual functions we like (virtual functions in C++ can be overloaded by derived classes) and customize these methods for each class derived from the base class. For example:

In the pseudo-code above, the class Object is purely virtual. A class that is derived from the class Object needs to implement the intersect() method. This method is where the ray-geometry intersection code specific to the geometry type represented by the class is added. In the example above, this would be the ray-sphere intersection code which we learn about in the second chapter of this lesson.

Next time we will have to add another geometry type, all we need to do is create a new class derived from Object and add whatever code is needed to compute the intersection of a ray with this geometry to the intersect() method. For example:

Note that for simplicity, we haven't bothered creating a Ray class in this program. This is only to show you that this is not strictly necessary. Plus creating a class to group two variables is not particularly justified at this point. We use the ray origin and direction directly in the intersect() method.

Now that we know how to define a sphere, we can create a scene containing a bunch of spheres whose position in 3D space and radius are randomly computed. The spheres are added to a list of objects. The list can contain object of the type Object but due to the way inheritance works in C++, any instance of a class that is derived from Object can in fact be added to this list as well (plus no instance of the class Object can actually be created because the class is purely virtual). In our case, there would be instances of the class Sphere.

We also set the options, such as the image width and height in the main() function of the program, and then finally pass the object list and the options to the render() function. As usual, the render() function loops over all pixels in the image and construct primary rays. The origin and the direction of the rays are transformed by the **camera-to-world** matrix.

About the MAYA_STYLE if-else statement: recall that when the image is not a square, we need to stretch the screen window by the image aspect ratio. Mathematically this can be done in two ways. You can either multiply the screen window in x by the image aspect ratio. Let's say for instance that the image resolution is 640x480, providing us with an image aspect ratio of 1.33. The screen window would thus be 1.33 in x and 1 in y (we will assume that the field of view has no influence on the screen window size here). Though note that we could as well keep the screen window equals to 1 along the x-axis, and scale it down along the y-axis by dividing it by the inverse of the image aspect ratio (as shown in the image below).

Obviously this changes the framing on the object seen through the camera, but mathematically both options are perfectly valid. It happens that Maya uses the second option. Thus if you want the output of your ray-tracer to match a Maya render, you will need to scale the direction of the ray along the y direction by the inverse of the image aspect ratio. Otherwise, you can leave the y-coordinates of the ray unchanged and scale the x-coordinate instead by the image aspect ratio:

When you will compile the program you can activate the first case by adding the option -DMAYA_STYLE to your command.

The ray origin and direction as well as the object list are passed to the castRay() function. This function is not the function where we loop over all the objects of the scene. To find if the ray intersects an object we will use the trace() function instead. The function takes as argument, the object list and the ray origin and direction once again. The function loops over all the objects in the scene and call the intersect() method of each object. If the object is a sphere, it will call the intersect() method of the Sphere class. If the object is a TriangulatedMesh (though we haven't implemented this class yet), the intersect() method of the TriangulateMesh class will be called. This function returns true if the ray intersects the object and false otherwise. If an intersection is found, \(t\) which is passed to the intersect() method is set with the distance from the ray origin to the intersected point. The trace() function is important of course, because this is where we keep track of the object with the closest intersection distance (as the ray may intersect more than one object). The variable tNear is first set to a very large number (line 3) and is only updated when we find that the intersection to the tested object is closer to its actual value (line 7 and 9). If the object is intersected and passes the test of the nearest object found so far, we also keep a pointer to that object (line 8).

If the function trace() returns true in the rayCast() function, then the ray intersects the object defined by the variable hitObject. We also know the intersection distance t to that object. From there we can compute the intersection point (line 9 below), and call the getSurfaceData() method of the intersected object to get the normal and texture coordinates of the surface at the intersected point (line 12 below). The normal and the texture coordinates are used to shade the point. We can use the normal with the ray direction (we need to invert the direction though) in a dot product to compute what call a facing ratio. When the normal and the ray direction point in the same direction, the result of the dot product is close to 1. When the normal and the ray direction are perpendicular (or facing away from each other), the dot product is close or lower than 0. Finally we can use the texture coordinate as usual to compute a checkerboard pattern. The color of the object at the intersection point is a combination of the object's color (set randomly when the object is created), the result of the facing ratio and the pattern:

This concludes the description of the program's source code. The result of the program can be see in the image below. On the left, an image of the scene rendered in Maya. On the right, the image produced by our program. The only difference is the color of the objects which we haven't bothered replicating in the Maya scene. Though as you can see the spheres are in the same position in the image and the pattern is also the same.

As usual, you can find the complete source code in the final chapter of this lesson.