Dielectrics with Beer's Law.
Dielectrics and Beer’s Law are now integrated into the materials and environment frameworks. In the picture above the indices of refraction increase from left to right.
Reflection functions
I have been experimenting with BRDFs lately.
In the picture above, from left to right: Oren Nayar, Torrance-Sparrow with different roughness, and smooth dielectrics.
In addition to having a first (very limited) framework for material representation and rendering, I have just added support for convex quadrilaterals.
Both features are combined below in a Cornell Box test (using original spectral and dimension data).
Cornell Box
I’ve just added a caching mechanism for the kd-tree.
It makes a huge difference in start-up time for complex meshes: Kd-tree construction for a 10 million triangle mesh takes quite some time (Ok, my construction routine may not be the fastest…) but once cached, rendering can start nearly instantaneously.
I’ve also noticed that kd-trees my renderer generate lend themselves to compression fairly well. E.g., the tree generated for the Stanford repository’s Asian Dragon weights around 124 MB, but a standard zip slims it down to 53 MB.
Hence, I’ll certainly add compression support to the cache.
That brings up the question: What does a high compression ratio say about a tree’s quality?
I’ve finally finished implementing multithreaded ray tracing in order to take full advantage of my iMac’s Core 2 Duo.
The implementation currently uses pthreads, which are simple enough to use and integrate. Of course, now with Snow Leopard a good move would be to go the Grand Central Dispatch route.
One issue of multithreaded ray tracing is synchronised access to the frame buffer in order to insure consistent reconstruction filtering.
A solution is to restrict access to the frame buffer to a single thread. This implies buffering the samples produced by the worker threads and have this dedicated thread splatter them on the frame buffer.
Another solution, which I have implemented, is to have the worker threads work on non-contiguous parts of the frame buffer at any given time: That way worker threads may have access to the frame buffer and no buffering is required.
I would be curious to have performance figures in order to compare these two approaches.
It’s been quiet lately… However development has not stalled: I’m busy working on re-architecturing the code, which was quite experimental. I’m also working on multithreading support.
Hopefully soon I’ll get a nice speed bump and a leaner code base to move forward to more render features.