The bare necessities

I just reached the second big milestone - the first one being rendering anything coherent - for my (still unnamed) ray tracer: A reasonable Cornell box. I modelled (although the metaphor of the analog counterpart kind of breaks when you’re hard coding vertex coordinates and topology) a scene based on the “official” Cornell standard - http://www.graphics.cornell.edu/online/box/data.html, to see if my engine could produce anything close to the real deal. After fixing up some fireflies (it’s easy to forget lights are geometry too) and a bug where I wasn’t accounting for the solid angle of the area light geometry when evaluating a brdf, I’m actually getting results that are pretty reasonable.

  
There are still one or two fireflies my render - those would be rays that are hitting the tiny gap between the area light and the ceiling, and getting radiosity values of about 99% of the light source energy, (so absurdly high) but without a light source pdf for MIS to kick in and balance it out. Other differences are: My ray tracer being color based, while the reference was rendered with a spectral renderer, so the temperature of my light source behaves somewhat differently. My surface albedo values are also slightly off compared to theirs due to eyeballing the wavelength to color conversion, so my side walls are a bit brighter and more saturated, and my white material is probably off by some factor as well. Also, mine is noisy, of course, and doesn’t have as many light bounces, because my engine is still extremely slow.

Here’s another render, with a white environment light instead of the area light inside the box.



Now that I’ve reached this point it’s time to take a small step back and look at the bigger picture. There are a couple of design choices that I don’t really like, and I ended up taking a few shortcuts towards the end to get the cornell box render out faster (as in less time to write the code, not faster rendering unfortunately), so next week I’ll be refactoring most of the source. I want an interface for setting up a scene by parsing an external scene description in some human-friendly format/language rather than needing to hard code the scene into the engine itself. I also want a better separation between the front end (parsing, primitive management, dicing and building the acceleration structure) and the back end (light transport, ray intersections) so I can have a nice and abstract structure for the first, and an optimized, faster structure for the latter without the two concepts conflicting. The code base is still relatively small, so it shouldn’t be too much work.

-Espen