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.

Both features are combined below in a Cornell Box test (using original spectral and dimension data).

Cornell Box

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?

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.

The Stanford bunny in all its binary glory:

................
................
...........**...
........*****...
.....*****......
....*****.......
...******.......
....*****.......
....******......
....*******.....
....*******.....
....*******.....
....******......
....******......
................
................

Note that this render is unbiased :-p

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.

It looks like it will be a nice toy for developers of resource-hungry applications:

1. full 64 bit support,
2. OpenCL,
3. Grand Central Dispath (see Apple’s technology brief on GCD) for efficient multithreaded design.

Needless to say that I’ve pre-ordered it

Hopefully soon I’ll get a nice speed bump and a leaner code base to move forward to more render features.