That’s quite a long title there…
When I first learned that you can find the answer to certain problems by throwing random numbers at them, I was understandably rather shocked. If I could just throw a random number generator at everything, had all the maths I’d been learning up to this point been pointless?
Fortunately, no. No it wasn’t.
Monte Carlo methods are exactly this: a way of statistically calculating the answer to questions by using random numbers.
The easiest (and most common, sorry) example is calculating pi using a square and a circle:
By selecting random points inside the square, then finding the ratio between the number of points inside vs outside of the circle, you can find an estimation for the value of pi! The accuracy of this value is proportional to the number of points used, although the law of diminishing returns does come into play.
Thankfully, we can improve our estimate by using a probability density function (pdf).
A pdf may be thought of as a continuous function that, for any point f(x), defines the relative probabilty that a randomly generated number would equal that point. The more the pdf follows f(x), the better it describes the distribution and the faster our Monte-Carlo estimation will converge on the correct answer.
Unfortunately a pdf, and importance sampling in general, can only be used when the answer to the problem is known, preventing its use in fields such as particle physics, but this technique can be applied to computer graphics. Each type of material and object has a pdf that defines the distribution of the ray bounce directions according to the properties of the material, resulting in less noise in the final images:
The first (correct) Monte-Carlo render.
To further improve the quality of the renders, Gaia takes into account both primary and secondary light sources (eg reflections) through the use of Shadow Rays. Shadow rays are additional rays that, for any randomly chosen ray bounce, are sent directly towards a randomly selected light source in the scene rather than bounce around the scene. This ‘sampling’ of the light source results in the image converging far faster. The light sources must be explicitly defined however, otherwise the image will be incorrectly exposed.
To make the most of this advancement, I need to make some improvements to how the scene is described: currently scenes must be described around any meshes that are being imported, which isn’t ideal and results in a lot of trial-and-error when setting them up.
Release 0.2.1
Rendering methods:
- Monte Carlo path tracing
- Edge Line pass
- Z-Depth pass
Objects:
- Spheres
- Quads (buggy)
- Triangles
- Triangle meshes from .obj files (with subdivision)
Material BRDFs:
- Ideal Lambertian, dielectric, metallic
- Oren-Nayar reflectance model (buggy)
- Blinn-Phong shading model (in-progress)
- Diffuse area lights
- Gooch shading
Acceleration structures:
- In-core multithreading support
- Bounding volume hierarchies
- Axis-aligned bounding boxes
Output file types:
- .hdr
- .ppm