Path Tracer
This is the Path Tracer project. It basically reads in some arbitrary file format that I used in my previous interactive raytracer, but the whole raytracing framework is redone in C++ instead of C.
Features
Because this is a Monte-Carlo path tracer, several features come for free: Caustics, Antialiasing, Glossy/rough reflections, Color bleeding, Soft-shadows.
Implementation
Currently, this only supports emitting a certain number of samples per pixel. Each ray, when it hits a surface, has a certain probability of getting sent straight to a light (for direct illumination) or sent through some russian roulette distribution defined by the material properties at the surface.
If the ray sent towards a light-source is occluded, it just repeats the same logic. If it does hit the light source, the surface point that sent the light ray will be directly illuminated with a Phong BRDF.
The russian-roulette section divides up the distribution depending on the material. If a material is all diffuse component, the ray will be bounced in a random cos-distributed direction and its returned color value will be multiplied by the brdf of the surface. If the material is all specular, the ray gets reflected in a phong-globe distribution and its color gets multiplied by the specular brdf of the surface. If the material is transparent, it will refract the ray through the material and the returned color value will get multiplied by a factor proportional to the diffuse component of the material, the material's absorbance, and the distance the ray traveled through the material. If these different material components have non-zero values, one will be randomly selected according to its weight compared to the other components.
The raytracer portion uses an axis-aligned bounding box heirarchy to accelerate ray tests. Additionally, an arbitrary number of threads can be used. It generates worker threads that each render a row of pixels in the final image which keeps all processors busy during most of the render. There is a very large limit on the number of bounces a ray can take, but I haven't seen it get hit yet. Usually the rays terminate much earlier due to the random chance of being direct lit.
As a note, there may be some bias in the renders shown because all samples are clamped in value. I did this because I don't yet support any HDR formats, and if I clamp the average of all samples, I get many unrepresented values.
Images
The following images were rendered on 4 2.5Ghz cores.
This image is a render of a modified cornell box. It demonstrates antialiasing, color bleed, specular (but not necessarily smooth) reflection, refraction, caustics, soft-shadows. It is 1500 samples per pixel and took 1046 seconds.
This image is a render of some random dragon model from some modeling challenge a long time ago. It just shows a high polycount (around 34,730 tris) render and it has a hemispherical light source. This one has 500 samples per pixel and took 362 seconds.
Code Here: needs pthreads, sdl, arial.ttf in /usr/share/fonts/TTF.