Reflection rays

Each object can reflect a ray more or less from a different object. A mirror would reflect the light totally, and a matte object would reflect nothing. Each new reflection is a new ray tracing call, so it can be costly. The number of recursion levels will be fixed, even if an object reflects nothing: this will be implemented through shaders in the future.

Knowing the normal to the intersection point, the reflected ray can be computing: it’s just the symmetric ray of the incident ray.

Some elements will be stored in a material structure that will be used to compute the reflected color:

/// Caracteristics of the primitive at a given point
struct MaterialPoint
{
  /// Normale at the intersection point
  Normal3df normal;
};

In the past, I’ve used this structure to contain diffuse or reflection colors, but usually, an object has not mirror property in red and matte in green, so this was deleted.

Now, I need to update the raytracer:

void Raytracer::computeColor(const Ray& ray, Color& color, unsigned int level) const
{
  float dist;
  long index = scene->getFirstCollision(ray, dist);
  if(index < 0)
    return;
 
  Primitive* primitive = scene->getPrimitive(index);
  MaterialPoint caracteristics;
  primitive->computeColorNormal(ray, dist, caracteristics);
  color = scene->computeColor(ray.origin() + dist * ray.direction(), caracteristics, primitive);
 
  if(level < levels)
  {
    Ray ray_sec(ray.origin() + dist * ray.direction(), ray.direction() - (ray.direction() * caracteristics.normal) * 2 * caracteristics.normal);
    ray_sec.direction() *= 1./(sqrt(norm2(ray_sec.direction())));
    Color color_sec(0.);
    computeColor(ray_sec, color_sec, level+1);
    color += mult(color_sec, caracteristics.reflect);
  }

I need to update the original collision method. Contrary to the last post, it isn’t enough to test if one primitive is hit by a ray, but I still need to test if the retrieved intersection isn’t too close to the original object. Indeed, I could be testing the intersection with the current object because of numerical instabilities. So I’ve added a minimum distance test:

long SimpleScene::getFirstCollision(const Ray& ray, float& dist)
{
  float min_dist = std::numeric_limits<float>::max();
  long min_primitive = -1;
 
  for(std::vector<Primitive*>::const_iterator it = primitives.begin(); it != primitives.end(); ++it)
  {
    float dist;
    bool test = (*it)->intersect(ray, dist);
 
    if(test && (0.0001f < dist) && (dist < min_dist))
    {
      min_primitive = it - primitives.begin();
      min_dist = dist;
    }
  }
 
  if(min_primitive == -1)
    return -1;
  else
  {
    dist = min_dist;
    return min_primitive;
  }
}

Now, when a ray hits a primitive, a material structure is used to get the normal and the other parameters at the intersection point.

The level parameter indicates the recursion level we are at. If the level isn’t high enough, the symmetric ray is cast and the reflected color is used to add the color of the object. I do not test if the contribution is too small, it is possible in some implementations, but not here. Also, adding more recursion is not always costly, as after a while, all rays point outside the scene.

Result

Now, this is the result with 3 recursion levels and 3 lights:

Test on parallelizing a custom library

I’ve decided to test Advisor Lite on my Interactive Raytracer. This is a test to verify if Advisor Lite finds the adequate parallelization and the memory sharing issues. It is a simple raytracer, so it can be parallelized for each pixel in the image. The only memory sharing issue that I know of is in the kd-tree ray traversal.

Profiling the library

First, I will profile the library. For the complete Advisor Lite workflow, I have to use Intel Compiler, and as it is faster than Microsoft’s compiler, I will use the timeit_image.py script instead of the measure_image.py I’ve used when profiling with Valgrind or Visual Studio.

Amplifier can show the results in a bottom-up or in a top-down manner. Unfortunately, you only have the exclusive timing that is displayed. In my case, when displaying bottom-up results, the method getEntryExitDistances() is the most costly one. In the top-down view, unfortunately, I can’t have a simple tree, as it can be seen in the following view:

In Visual Studio, I have the same results – more or less -, but with a correct top-down call-tree:

The method getEntryExitDistances() cannot be parallelized: it is recursively called, several times per pixel, which would lead to a lot of memory contention. The simpler task is thus to parallelized the pixel rendering, a perfect data-parallel problem.

Annotation of the code

OK, now I can annotate my code. I had to dig inside the help for this, as it was not mentionned in the Starting Guide that Intel provides a header, annotate.h, which mimics the issues you may encounter in a multithreaded application.

So you need to read at least once the online help so that you know the available annotation macros, how you can get them and how they will retrieve what you need. Once the code is annotated, it must be recompiled and then the sharing issues can be detected.

Detection of sharing issues

As expected, Inspector detected errors in the kd-tree traversal:

The solution in this case is to have a ray-traversal stack per thread, which will have to be implemented in whichever parallel library will be chosen, or simply to put the stack in the actual traversal algorithm and not in the instance.

Using TBB

I’ve decided to go for Thread Building Blocks, as it was already used for game development. This seemed to me a good idea, as it is a Open Source solution. So now, I will split the screen in 2D pieces, and add a thread-specific storage in the kd-tree class. Of course, I will have to add a flag to disable this paralellization if TBB is not available.

The actual parallelization will be in a future post in the Interactive Raytracer category. It is pretty straightforward once I had the different elements Parallel Studio gave me.

Conclusion

In fact Advisor is mainly the annotate.h header, as you have to know your program to put the macros at correct locations. The parallelization must be done by hand, as well as correcting the memory sharing issues.

The only problem I had is that annotate.h includes window.h. This header is not C++ compliant and declares some macros as max() (in fact I got the same issue with TBB headers!). As I use a max() function declared in std::numerical_limits, I had to explicitely undefine this macro.

Safe from this, Advisor Lite is a good plugin, and I’m looking forward to seeing Advisor in a next Parallel Studio release.

Lights and shadow rays

Without light, objects are bland, seem to have no depth, … Light on a scene can be cast by several light sources. When a ray of the camera hits an object, the intersection point can be illuminated by one or several of those sources. Each of them contributes to the color of the object. If the light source direction is parallel with the normal of the object at the intersection point, the contribution will be maximum. If it is orthogonal, the contribution will be zero. The scalar product is the tool used to compute this quantity.

Each light source will be tested one after another. If there is no object between the light source and the intersection point, the light contribution will be added.
First, in the raytracer, the main method will be modified to get the normal through the MaterialPoint structure.

    void Raytracer::computeColor(const Ray& ray, Color& color, unsigned int level=0) const
    {
      float dist;
      Primitive* primitive = scene->getFirstCollision(ray, dist, tnear, tfar);
      if(primitive == NULL)
        return;
 
      MaterialPoint caracteristics;
      primitive->computeColorNormal(ray, dist, caracteristics);
      color = scene->computeColor(ray.origin() + dist * ray.direction(), caracteristics, primitive);
    }

Now, I add in the primitive class a property named diffuse, which indicates how much light is diffused by the object. Then, the scene can be modified:

  const Color SimpleScene::computeColor(const Point3df& center, const MaterialPoint& caracteristics)
  {
    Color t_color(0.);
    for(std::vector<Light*>::const_iterator it = lights.begin(); it != lights.end(); ++it)
    {
      Vector3df path = (*it)->getCenter() - center;
      float pathSize = sqrt(norm2(path));
      path.normalize();
      Ray ray(center, path);
      if(testCollision(ray, pathSize))
        continue;
 
      float cosphi = path * caracteristics.normal * primitive->getDiffuse();
      if(cosphi < 0.)
        continue;
      t_color += mult((caracteristics.color * cosphi), (*it)->computeColor(ray, pathSize));
    }
 
  bool SimpleScene::testCollision(const Ray& ray, float dist)
  {
    for(std::vector<Primitive*>::const_iterator it = primitives.begin(); it != primitives.end(); ++it)
    {
      float t_dist;
      bool test = (*it)->intersect(ray, t_dist);
 
      if(test && (0.0001f < t_dist) && (t_dist < dist))
      {
        return true;
      }
    }
    return false;
  }

Now, there are several ways of computing the light color. You can just say that a light broadcasts the same color everywhere, or you can use a more physical equation, where the color diminishes when the object is far from the light. As the light emits in every direction, the decrease is proportional to the square of the distance. This is what I used at first (in the newest versions, I’ve used the non-physical equation for some comparisons tests).

  Color Light::computeColor(const Ray& ray, float dist)
  {
  return color * (1. / (dist * dist));
  }

Result

Here is the result of this computation:

One constant is hardcoded: 0.0001f. This is the reason why there are some artefacts in the result image (on the red and the green spheres). If this number is raised to 0.001, the image will be more accurate. But then, if the spheres are nearer, then the shadows may be inaccurate…

Using the profiler

First of all, the code must be compiled with /Zi or /Z7. Then, the link edition must be done with /DEBUG. Without these options, it won’t be possible to measure anything.

Performance Tool must be used in a Visual Studio Solution, which I don’t have in the case of the Interactive Raytracer. I will have to create an empty project, and I will create a bogus project, just to be able to browse the code in the IDE.

Once in Performance Tool, I create a new target which will be my generated library:

Then, I have to add it to the targets to profile:

Then I modify the launch properties to launch python with a sample script that is supposed to be descriptive enough. If you profile a Visual Studio project, you can use the debugging project properties (there are more environment parameters that you may modify).

Sampling

To use the sampling profiler, you have to select it in the session parameters. Once done, you can launch the profiler.

This is the results I got from the IRT:

This view helps finding the function to optimize. It display the current function at the middle of the panel, and then the caller functions at the top and the callee/called functions at the bottom. The displayed costs are inclusive and exclusive costs.

A more general view, the call-tree, can help finding the hotspot as well. The caller can obviously not be displayed.

It is easy to get access to the code by a left click, which is one of the reasons I’ve created a bigus Visual Studio project.

Instrumentation

Instrumentation-based profiling is somewhat different than sampling-based profiling. Here, the executable is modified to count cycles or counters, whereas in sampling-based profile, the program is sampled at regular intervals to get where the program is, the counters, …

Instrumentation results are quite like the sampling ones

Conclusion

According to the different results I got, I know that I have some work to do on the math library. Well, this was some months ago, so now this code optimized as well. Based on Performance Tool profile, a lot has been optimized, as not creating rays inside the loop, …

I cannot really compare Performance Tool to Valgrind, as they are not the same kind of profilers. They each give more or less precise information on some parts of your program.
Compared to KCacheGrind, the callee map is missing, but Microsoft did a great job with the UI. The information may not be visualized as a 2D image, but it is still easy to extract it from the different views.

As a conclusion, I’d simply say that Performance Tool is an excellent tool Mixrosoft provides in its high-end Visual Studio versions. To bad it is not acceissble in the lower versions.

Creation of a wrapper

The module’s name will be IRT. For the vctor, I’ll use Numpy and its C API.

Here is the main file:

%{
#define SWIG_FILE_WITH_INIT
#define PY_ARRAY_UNIQUE_SYMBOL PyArray_API
%}
%include "numpy.i"
%init %{
import_array();
%}
 
%include "constraints.i"
 
%module(package="IRT", docstring="Python interface to the Interactive RayTracer") IRT
 
%nodefaultdtor;
%nodefaultctor;
 
%include "primitives.i"
%include "simple_scene.i"
%include "raytracer.i"

Nothing out of the ordinary, the only trick is not to generate a default constructor or destructor so that nothing bad can happen.

Handling primitives (and lights in the future) is tricky: when creating an object, Python will handle its life, but in IRT’s case, the life time is the scene responsibility. Without special instructions, if the Python object is deleted, so is the undelying C++ object and then we look at memory corruption, double frees, …. I’ll use a SWIG function to split this.

%{
#include "primitives.h"
%}
 
%typemap(in)
    (IRT::Vector3df&)
    (PyArrayObject* array=NULL, int is_new_object=0)
{
  array = obj_to_array_contiguous_allow_conversion($input, NPY_FLOAT, &is_new_object);
  if (!array || !require_dimensions(array, 1) || (array->dimensions[0] != 3)) SWIG_fail;
 
  $1 = new IRT::Vector3df((float*) array->data);
}
%typemap(freearg)
    (IRT::Vector3df&)
{
  if (is_new_object$argnum && array$argnum) Py_DECREF(array$argnum);
}
 
%typemap(in)
    (IRT::Color& color)
    (PyArrayObject* array=NULL, int is_new_object=0)
{
  array = obj_to_array_contiguous_allow_conversion($input, NPY_FLOAT, &is_new_object);
  if (!array || !require_dimensions(array, 1) || (array->dimensions[0] != IRT::nbColors)) SWIG_fail;
 
  $1 = new IRT::Color((float*) array->data);
}
%typemap(freearg)
    (IRT::Color&)
{
  if (is_new_object$argnum && array$argnum) Py_DECREF(array$argnum);
}

I use here the constant IRT::nbColors. This indicates the number of colors (which means that I could use more that RGB, or it can be useful in other contexts, as acoustics). These typemaps are freely inspired by Numpy’s.

The following typemaps handle giving or taking life responsibility from Python to C++ when interacting with the scene.

%typemap(in) IRT::Primitive*
{
  if ((SWIG_ConvertPtr($input,(void **)(&$1),$1_descriptor, SWIG_POINTER_EXCEPTION | SWIG_POINTER_DISOWN)) == -1) SWIG_fail;
}
 
%typemap(out) IRT::Primitive*
{
  $result = SWIG_NewPointerObj($1, $1_descriptor, SWIG_POINTER_OWN);
}
 
namespace IRT
{
  class Primitive
  {
  public:
    ~Primitive();
  };
 
  class Sphere: public Primitive
  {
  public:
    Sphere(IRT::Vector3df& ray, float dist);
    ~Sphere();
    void setColor(IRT::Color& color);
  };
}

I didn’t expose the whole interface to Python. I don’t want everyone to do fancy stuff with the raytracer’s inner code.

Now, for the scene, there is not much to say:

%{
#include "simple_scene.h"
%}
 
%apply Pointer NONNULL{IRT::Primitive*};
 
namespace IRT
{
  class SimpleScene
  {
  public:
    SimpleScene();
    ~SimpleScene();
    IRT::Primitive* removePrimitive(unsigned long index);
    bool addPrimitive(IRT::Primitive* primitive);
  };
}

If a NULL pointer is passed to the function, SWIG throws itself an exception, I don’t have to handle this case myself. This is done in constraints.i.

Finally, this is the raytracer wrapper:

%{
#include "raytracer.h"
%}
 
%typecheck(SWIG_TYPECHECK_DOUBLE_ARRAY)
  (float* INPLACE_ARRAY)
{
  $1 = is_array($input) && PyArray_EquivTypenums(array_type($input),NPY_FLOAT);
}
%typemap(in)
  (float* INPLACE_ARRAY)
  (PyArrayObject* array=NULL, int is_new_object=0)
{
  array = obj_to_array_contiguous_allow_conversion($input, NPY_FLOAT, &is_new_object);
  $1 = ($1_ltype) array->data;
}
 
namespace IRT
{
  class Raytracer
  {
  public:
    Raytracer(unsigned long pixelWidth, unsigned long pixelHeight, float width, float height, float depth);
    ~Raytracer();
 
    void draw(float* INPLACE_ARRAY);
    void setResolution(unsigned long pixelWidth, unsigned long pixelHeight);
    void setScene(IRT::SimpleScene* scene);
  };
}

The raytracer wrapper must be able to set its scene, draw it and change the actual resolution. The main issue here is the image where the scene will be drawn on, implemented here as a Numpy array in Python.

Python scene and display

To generate profiles, I’ve created a small sample scene:

import IRT
import numpy
 
class Sample(object):
  def __init__(self):
    self.raytracer = IRT.Raytracer(800, 600, 8., 6., 40.)
    self.scene = IRT.SimpleScene()
 
    sphere = IRT.Sphere(numpy.array((0, 0, 80.), dtype=numpy.float32), 2.)
    sphere.setColor(numpy.array((0., 0., 1.), dtype=numpy.float32))
    self.scene.addPrimitive(sphere)
    sphere = IRT.Sphere(numpy.array((2., 1., 60.), dtype=numpy.float32), 1.)
    sphere.setColor(numpy.array((1., 0., 0.), dtype=numpy.float32))
    self.scene.addPrimitive(sphere)
    sphere = IRT.Sphere(numpy.array((-2., -1., 60.), dtype=numpy.float32), 1.)
    sphere.setColor(numpy.array((0., 1., 0.), dtype=numpy.float32))
    self.scene.addPrimitive(sphere)
 
    self.raytracer.setScene(self.scene)
 
  def __call__(self, screen):
    self.raytracer.draw(screen)

The screen has a size of (800,600) with a resolution of 0.1. Three spheres will be drawn, one blue, one green and one red. __call__() is where the time can be measured or the profile is relevent.

import timeit
 
setup="""import numpy
import sample
import pylab
 
s = sample.Sample()
 
screen = numpy.zeros((600, 800, 3), dtype=numpy.float32)
"""
 
timer = timeit.Timer('s(screen)', setup=setup)
 
print timer.timeit(10)

Here is the result with Matplotlib:

The next post on IRT will expose lights and shadows.

A matrix library must be used, the same basis class will be used for each element, point or color, but with a different size (if needed). I will use a typedef for defining each of them. This will help explaining what is going on. I will not explain the code of the library, althoug the optimization of the raytracer will surely have to be done in this part of the code as well.

So a vector will be named (for the moment) Vector3df, a point Point3df, a normal Normal3df and a color Color. All elements will live in the IRT namespace.

Basic classes

These basis classes, with the ray class that will be shown later, are what makes the raytracer work. The primitives describe what objects are in the scene, which color they have, if they are transprent, if they reflect light, … The scene itself is a smart container for the primitives and the lights which can allow for fast ray traversal (if implemeted). The raytracer traces rays through the scene and saves the result in an image.

First the Ray class is only an aggregation of two data, a vector and a starting point.

  class Ray
  {
  private:
    Point3df origin_;
    Vector3df direction_;
 
  public:
    _export_tools Ray(const Point3df& origin, const Vector3df& direction);
 
    _export_tools ~Ray();
 
    const Point3df& origin() const
    {
      return origin_;
    }
    Point3df& origin()
    {
      return origin_;
    }
    const Vector3df& direction() const
    {
      return direction_;
    }
    Vector3df& direction()
    {
      return direction_;
    }
  };

The _export_tools macro is used for Windows shared libraries, where you have to explicitely tell which function is to be exported (or imported). This will change in the future when the library will be completely template.

  Ray::Ray(const Point3df& origin, const Vector3df& direction)
    :origin_(origin), direction_(direction)
  {
  }
 
  Ray::~Ray()
  {
  }

Primitives

A primitive is an object in the scene. For the moment, it will be a pure virtual class (an interface) with some methods, like the intersection as well as the color computation.

  class Primitive
  {
  public:
    virtual ~Primitive()
    {}
 
    virtual bool intersect(const Ray& ray, float& dist) = 0;
 
    virtual void computeColorNormal(const Ray& ray, float dist, Color& color, Vector3df& normal) = 0;
  };

My first primitive will be a Sphere with a uniform color. The most complex computation here is the intersection between a ray and the sphere:

  Sphere::Sphere(const Point3df& center, float radius)
    :center(center), radius(radius), color(1.f)
  {}
 
  void Sphere::setColor(const Color& color)
  {
    this->color = color;
  }
 
  bool Sphere::intersect(const Ray& ray, float& dist)
  {
    float A = 1.f;
    float B = (ray.direction() * (ray.origin() - center));
    float C = norm2(ray.origin() - center) - radius * radius;
 
    float delta = (B * B - A * C);
 
    if(delta < 0.f)
      return false;
    float disc = sqrt(delta);
    if(dist = - (B + disc) < 0.)
      dist = - (B - disc);
    return true;
  }

The idea is to consider a straight line parametered with dist. With this equation, we add to the system the equation of the sphere. This way, a second degree polynomial must be solved, and the smallest positive root is the solution (if it exists). To simplify computation, the direction vector is considered unitary.

Now, the color can be computed, as well as the normal (very easy to do with a sphere). In fact the normal is not used here, but will be used in the future.

  void Sphere::computeColorNormal(const Ray& ray, float dist, Color& color, Normal3df& normal)
  {
    Vector3df collide(ray.origin() + dist*ray.direction());
    normal = collide - center;
    normal *= 1./(sqrt(norm2(normal)));
 
    color = this->color;
  }

The scene

The scene stores the primitives. Primitives may be added, deleted or accessed. BEsides, the scene is in charge of finding objects hit by a ray with the method getFirstCollision().
simple_scene.h

  class SimpleScene
  {
  private:
    std::vector<Primitive*> primitives;
 
  public:
    _export_tools SimpleScene();
 
    _export_tools ~SimpleScene();
 
    _export_tools Primitive* getPrimitive(unsigned long index);
 
    _export_tools Primitive* removePrimitive(unsigned long index);
 
    _export_tools long getFirstCollision(const Ray& ray, float& dist);
 
    _export_tools bool addPrimitive(Primitive* primitive);
  };

The scene is also in charge of deleting the primitives it stores. When a new primitive is added to the scene, it is charge of its life time.
Here is the actual code:

  SimpleScene::SimpleScene()
    :primitives()
  {
  }
 
  SimpleScene::~SimpleScene()
  {
    for(std::vector<Primitive*>::const_iterator it = primitives.begin(); it != primitives.end(); ++it)
      delete *it;
  }
 
  Primitive* SimpleScene::getPrimitive(unsigned long index)
  {
    return primitives[index];
  }

Wen a primitive is removed from the scene, it is returned to the user:

  Primitive* SimpleScene::removePrimitive(unsigned long index)
  {
    std::vector<Primitive*>::iterator it = primitives.begin();
    std::advance(it, index);
    Primitive* primitive = *it;
    primitives.erase(it);
    return primitive;
  }

Now, this is the main kernel. In this case, each primitive is tested and if the ray hits the primitive, the distance from the ray to the primitive is updated in dist and the primitive index is returned.

  long SimpleScene::getFirstCollision(const Ray& ray, float& dist)
  {
    float min_dist = std::numeric_limits<float>::max();
    long min_primitive = -1;
 
    for(std::vector<Primitive*>::const_iterator it = primitives.begin(); it != primitives.end(); ++it)
    {
      float dist;
      bool test = (*it)->intersect(ray, dist);
 
      if(test)
      {
        min_primitive = it - primitives.begin();
        min_dist = dist;
      }
    }
 
    if(min_primitive == -1)
      return -1;
    else
    {
      dist = min_dist;
      return min_primitive;
    }
  }
 
  bool SimpleScene::addPrimitive(Primitive* primitive)
  {
    if(std::find(primitives.begin(), primitives.end(), primitive) != primitives.end())
      return false;
 
    primitives.push_back(primitive);
    return true;
  }

A primitive cannot be added twice to the the scene. If the insertion fails, false is returned by addPrimitive().

The raytracer

A raytracer can use any scene from the moment it is possible to get the primitive hit by a ray.

  class Raytracer
  {
  private:
    void generateRay(unsigned long x, unsigned long y, Ray& ray) const;
 
    void computeColor(const Ray& ray, Color& color) const;
 
    void updateParameters();
  public:
    _export_tools Raytracer(unsigned long pixelWidth, unsigned long pixelHeight, float width, float height, float depth);
 
    _export_tools ~Raytracer();
 
    _export_tools void draw(float* screen) const;
 
    _export_tools void setViewer(float width, float height, const Vector3df& origin, const Vector3df& direction);
 
    _export_tools void setResolution(unsigned long pixelWidth, unsigned long pixelHeight);
 
    _export_tools void setScene(SimpleScene* scene);
 
  private:
    Point3df origin;
    Vector3df direction;
    unsigned long pixelWidth;
    unsigned long pixelHeight;
    float width;
    float height;
    float depth;
 
    float precompWidth;
    float precompHeight;
 
    SimpleScene* scene;
  };

Besides the key raytracer methods, this class provides an interface to set the camera (even if the code does not do this at the moment).

First, a screen has a height and a width with a number of pixels for those. The screen is at some distance from the camera (the depth).

  Raytracer::Raytracer(unsigned long pixelWidth, unsigned long pixelHeight, float width, float height, float depth)
    :origin(0.), direction(0.), pixelWidth(pixelWidth), pixelHeight(pixelHeight), width(width), height(height), depth(depth)
  {
    direction(2) = 1;
    updateParameters();
  }
 
  Raytracer::~Raytracer()
  {
  }

With these elements, some additional parameters are precomputed.

  void Raytracer::generateRay(unsigned long x, unsigned long y, Ray& ray) const
  {
    ray.direction()(0) = precompWidth * (x - pixelWidth / 2.f);
    ray.direction()(1) = precompHeight * (y - pixelHeight / 2.f);
    ray.direction()(2) = depth;
 
    ray.direction() *= 1./(sqrt(norm2(ray.direction())));
  }

This method builds an unitary ray in place. Based on the position of the camera, a ray to each pixel is generated.

  void Raytracer::draw(float* screen) const
  {
    Ray ray(origin, direction);
    for(unsigned long j = 0; j < pixelHeight; ++j)
    {
      for(unsigned long i = 0; i < pixelWidth; ++i)
      {
        generateRay(i, j, ray);
        Color color(0.);
 
        computeColor(ray, color);
 
        for(unsigned int k = 0; k < nbColors; ++k)
          screen[nbColors * (j* pixelWidth + i) + k] = color(k);
      }
    }
  }

This was the main method to draw an image from the scene. It works by computing the color for each ray.

To get this color, the following method searches the scene for the nearest hit object. If one is found, the color is generated by computeColorNormal(). This method is also the one that will be in charge of the secondary rays and shadows, but this is for another post.

  void Raytracer::computeColor(const Ray& ray, Color& color) const
  {
    float dist;
    long index = scene->getFirstCollision(ray, dist);
    if(index < 0)
      return;
 
    Normal3df normal;
    Primitive* primitive = scene->getPrimitive(index);
    primitive->computeColorNormal(ray, dist, color, normal);
  }

The next methods help updating the raytracer.

  void Raytracer::setScene(SimpleScene* scene)
  {
    this->scene = scene;
  }
 
  void Raytracer::setResolution(unsigned long pixelWidth, unsigned long pixelHeight)
  {
    this->pixelWidth = pixelWidth;
    this->pixelHeight = pixelHeight;
 
    updateParameters();
  }
 
  void Raytracer::setViewer(float width, float height, const Vector3df& origin, const Vector3df& direction)
  {
    this->width = width;
    this->height = height;
    this->origin = origin;
    this->direction = direction;
 
    updateParameters();
  }
 
  void Raytracer::updateParameters()
  {
    precompWidth = width / pixelWidth;
    precompHeight = height / pixelHeight;
  }

Coming next

It is now possible to use the library for a basic rendering in C++, but I’ve decided to add a small Python wrapper to allow for more easy testing. This will be the main topic of my next post on raytracing.

Link to Launchpad.

A raytracer is in fact really easy to write. The math formulae are simple for a version that will return satisfactory results. On the contrary, an interactive or “real-time” one is more complicated. This is why I started my small project and why I will blog from time to time about it.

Interactive or real-time means that the drawing must be fast, really fast. This also means that realistic drawing is out of the question. I’ve started with a simple raytracer, with some optimizations, and then I’ve added some algorithmic optimizations. I will talk about all this in several posts.

How does a raytracer actually work?

In physical vision, light rays travel around the world from the sources, hitting objects, then reflected or transmitted and finally arriving at the eye (or camera). The principle of raytracing is to do it backwards, from the camera to the light sources. The camera film, or the retina, is symbolized by a screen.

How a raytracer works

In this case, the emitted ray hits object 1 with some angle to the normal (the normal vector is the vector orthogonal to the tangent plane of the object). Object 1 gets some light and so the color ray depends on this light, the object and the angle between the normal and the direction of the light.
The ray is then reflected to object 2 and hits it with another angle. As for object 2, it gets some light and the reflected ray carries a specific color. This color is then blended with the color of the primary ray, and this final color is the color of the pixel on the screen.

Coming next

I’ve written my library in C++, tested it with several compilers on different platforms. So as to test the code, to profile it and to create a scene in an elegant manner, I’ve added a small Python wrapper. This will be the subject of my next post.

Then, I’ll go through secondary and shadow rays, a GUI for the raytracer, acceleration structures, …

The code is released under the LGPL on Launchpad.

Additional links

Interactive Raytracer on Intel website

An Intel article on real-time raytracer architecture

nVidia presentation on raytracing