I’ve recently had the need for a simple ray-tracer since I started working on a precomputed radiance transfer (PRT) baking tool. There’s multitudes of sample code, implementations and SDKs available, so I wanted to share my findings after a bit of research.

In order to precompute PRT lighting data, all I needed was a simple ray-tracer which allows me to test whether a ray hits any triangle in a scene, with the scene consisting of triangles only. No fancy path-tracing, no photon-mapping, no full-blown ray-tracing engine. Just a simple ray-scene hit-test.

I spent a day or two having a look at different available options, both CPU- and GPU-based:

• Build the ray-tracer from scratch: All you need is an efficient bounding volume hierarchy (BVH), and an efficient ray-triangle intersection hierarchy. I’ve had code for a BVH lying around (built using the surface area heuristic), and a simple Möller-Trumbore intersection test was implemented in a matter of minutes. It worked, but was not nearly as fast as I would have liked it to be.
• Arauna: Arauna is a heavily-optimized ray-tracer/path-tracer, which is able to perform several million ray-casts per seconds on my PC, with source code available. Unfortunately, ripping parts of the implementation out of Arauna seems to be a rather heavy undertaking – basically all code is sprinkled with SSE intrinsics, with little or no abstraction, and pure optimization goodness.
• CUDA: GPU-based ray-tracers can outperform modern CPU ray-tracers if implemented correctly, hence I had a look at available CUDA ray-tracers. However, the amount of setup and extra steps needed in order to get something to run on the GPU is still quite annoying – iteration times are nowhere near as fast as working with C++ code only. I might look into a CUDA-based ray-tracer in the future (this one looks extremely promising, with source code available), but I’ve settled with a CPU-only solution for the time being (more on that later).
• OptiX: NVIDIA’s ray-tracing engine built on top of CUDA is rather simple to use, and offers good interoperability with both OpenGL and Direct3D 11. In my experience, getting something to run with OptiX takes considerably less time than a pure CUDA-based solution, which was to my liking. However, OptiX suffers from the problem of “too much abstraction”, performing about four times as slow as comparable CUDA solutions. If going with a GPU-based solution, I would rather chose CUDA then.
• Intel’s Embree: The last ray-tracer I looked at is the rather new Embree from Intel. I hadn’t heard about Embree yet, which got me curious to take a closer look. The examples were quite fast on my machine, and the source code is clean, concise and documented. You can learn a trick or two about SSE/AVX optimization just by taking a look at the Vec2/Vec3/Vec4 implementations. This is the option I settled with in the end.

Reasons why I chose Embree?

• Embree uses the whole SSE2/3/4 instruction set and data structures built specifically for making good use of the vectorized instruction sets. As an example, Embree uses a bounding volume hierarchy which stores 4*N triangles per leaf, with each set of four triangles stored in a separate data structure which allows intersecting a single ray with four triangles simultaneously.
• Embree does not use ray-packets for tracing coherent rays simultaneously, but rather has excellent data structures like the one mentioned above for tracing single, incoherent rays, which was exactly what I needed for Monte Carlo integration.
• Integrating Embree into Molecule was painless and simple. SSE code, BVHs, and ray-BVH intersection code is nicely abstracted and separated, making it easy to just take those parts of the implementation you actually need.
• Embree can deal with triangle meshes out-of-the-box. Simply create a BVH using one of the available builders, and you’re done.
• Embree is fast. I slightly changed some parts of the implementation which I didn’t need (e.g. base interfaces/virtual functions for different intersectors), and utilized all available hardware threads on my PC (quad-core i7-2600K), resulting in a raw performance of 25 million ray-casts per second in a moderate game scene (~400k triangles).

What actually took me longest with integrating Embree into Molecule was that I would always get the following error message when building Molecule, but not when building Embree standalone:

ray.h(40): error C2208: 'float' : no members defined using this type

WTF? I cannot use a float because of… what?

The innocent-looking code that triggers this error is the following:

namespace embree
{
  /*! Ray structure. Contains all information about a ray including
   *  precomputed reciprocal direction. */
  struct Ray
  {
    ///*! Default construction does nothing. */
    __forceinline Ray() {}

    ///*! Constructs a ray from origin, direction, and ray segment. Near
    // *  has to be smaller than far. */
    __forceinline Ray(const Vec3f& org, const Vec3f& dir, const float& near = zero, const float& far = inf)
      : org(org), dir(dir), rdir(1.0f/set_if_zero(dir,Vec3f(std::numeric_limits::min()))), near(near), far(far) {}

  public:
    Vec3f  org;     //!< Ray origin
    Vec3f  dir;     //!< Ray direction
    Vec3f  rdir;    //!< Reciprocal ray direction
    float near;    //!< Start of ray segment
    float far;     //!< End of ray segment
  };

  /*! Outputs ray to stream. */
  inline std::ostream& operator<

Don’t read any further if you want to solve the puzzle yourself.

There’s a simple reason why the code doesn’t compile – again, it’s one of those stupid global namespace-polluting #defines which gets pulled in via the Windows.h header! If Microsoft only ever changes one thing in one of the future releases of Visual Studio, it should be Windows.h, also known as the header from hell.

Without further ado, a simple

#ifdef far
#    undef far
#endif

#ifdef near
#    undef near
#endif

solves the problem.

If you’ve successfully used other ray-tracers in the past, please let me know! I would very much like to hear about other solutions.