In between end of year celebrations, nights in hotels because of cancelled flights and other snow storms, I still managed to progress on the layered material representation front.
Stanford Dragon, diffuse material coated with glass.
I admit that it is not the most spectacular example as it does not show off the effect of absorption in the glass coat… But at the moment I cannot be asked to wait 20+ hours to re-render.
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.
When I want to test my intersection code, for example when I break the KD-tree (oops), I usually switch to ASCII mode.
The Stanford bunny in all its binary glory:
................
................
...........**...
........*****...
.....*****......
....*****.......
...******.......
....*****.......
....******......
....*******.....
....*******.....
....*******.....
....******......
....******......
................
................
Note that this render is unbiased :-p
Just received my copy of Mac OS X 10.6 Snow Leopard! 
One of the main new features of this version is its 64-bit kernel. However, there are a couple of catches: First, even if you have a shiny Intel Core 2 Duo Mac you must have a 64-bit EFI in order to boot the 64-bit kernel.
ioreg -l -p IODeviceTree | grep firmware-abi
If you get EFI64 you’re in luck, otherwise tough… I got lucky: I do have a 64-bit EFI. Nice.
Second, even then all Macs (except Xserve) boot the 32-bit kernel by default. To use the 64-bit kernel you can either press ‘6′ and ‘4′ everytime you boot your Mac, or you can edit com.apple.Boot.plist as follows:
1. Open /Library/Preferences/SystemConfiguration/com.apple.Boot.plist
2. Find the string:
<key>Kernel Flags</key><string></string>
3. Change it to:
<key>Kernel Flags</key><string>arch=x86_64</string>
That’s it, you’re set. (if you ever need to boot in 32-bit mode, just press ‘3′ and ‘2′ during boot).
_
Update (31st August):
After having made the modification above, I wanted to insure that the kernel used was indeed the 64-bit one. To do that:
uname -a
Which for me unfortunately gives:
Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386
Argh…
So beware: a 64-bit EFI is not a guarantee that you’ll be able to use the 64-bit kernel. Especially, apparently iMac 7,1 (my case) cannot use the 64-bit kernel in any case.
Mac OS 10.6 will be released on Friday (28th August).
It looks like it will be a nice toy for developers of resource-hungry applications:
Needless to say that I’ve pre-ordered it 
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.