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