Due to implementation issues back then, I was however limited to a curve of (27)3 elements. For 1024 depth maps with a resolution of 128×128 pixels this came down to 8 cubes of (27)3 elements (1024x128x128 = 224 = (27)3 x 23). With my new implementation this restriction is gone and I can generate Hilbert curves up to (210)3 (going any higher would require the use of 64 bits integers, which would only slow down my computations, something that is to be avoided as much as possible).

These are the currently best results:

3D Hilbert Compression vs Per-Pixel Compression

As can be seen from this graph, the 3D Hilbert compression outperforms the per-pixel compression for anything below 9216 (962) depth maps. Beyond that per-pixel compression is still the way to go. Two weeks ago I thought that this could possibly be solved by increasing the resolution of my Hilbert curve (and thus reducing the amount of cubes necessary to browse through all my data). Last week I got more insight in the recursive nature of the Hilbert curve and had a suspicision that the size of my cubes (and the resolution of the Hilbert curve) wouldn’t matter that much. The thing is, a Hilbert curve of a higher resolution is basically a concatenation of rotated versions of a lower resolution Hilbert curve. So the difference between one cube of a high resolution and two cubes of lower resolution is merely a rotation. And due to it’s nature, the effect of these rotations are minimal.

(Left) 2D Hilbert curve of order 1. (Middle) Hilbert curve of order 2. This consists of four rotated order 1 curves (corners) that are connected with each other. (Right) Order 3 curve, consists of four rotated order 2 curves.

This theory is also confirmed in practice. The results for higher resolution Hilbert curves are nearly identical to those given above (up to some KB).

3D Hilbert Curve

In his work, Hamilton also wrote about Compact Hilbert Indices. This allows for Hilbert curves to be applied to non-hypercubic data (a rectangle instead of a square for example). Though a Hilbert curve is still generated for the smallest hypercube fitting around all data, the compact indices don’t require as much memory (bits) as their conventional indices. This is the next thing I will implement and once the job is done, I can begin working on the GPU version of the algorithm. I wonder if anyone ever tried that before .

[1] C. H. Hamilton. Compact Hilbert Indices. Dalhousie University Technical Report CS-2006-07, July 2006.
[2] C. H. Hamilton, A. Rau-Chaplin. Compact Hilbert Indices: Space-filling curves for domains with unequal side lengths. Information Processing Letters, 105(5), 155–163, Feburary 2008.

1. Bounding Sphere Algorithm
I’ve implemented some more advanced algorithms for finding the (minimum) bounding sphere of an object. I first tried the Ritter algorithm (Graphics Gems, 1990). Ritter stated that his algorithm should give an approximation within 5% of the true minimum sphere. A simple test on a cube proved otherwise though.
Then I tried the Gärtner algorithm. Writing my own implementation would be to much work, so I used an existing implementation from here. After doing some tests with the algorithm, it seems the implementation must be broken because I never even ended up with a sphere containing all the necessary vertices …

In short: attempts to use another bounding sphere algorithm failed.

2. Uniform Sampling
Taking uniform samples on my bounding sphere gave some interesting results. Depending on the orientation of my bounding sphere and the space-filling curve used to traverse through my samples on this sphere, it’s possible to decrease the size of the compressed depth maps with one third (compared to my original results). There’s also a huge variation in the size of the CSM’s for various settings of orientation and space-filling curve.

To give you an example, an Armadillo with 1024 depth maps:
Uniform, Vertical Zig-Zag curve and a ZYX (left) rotation of the bounding sphere: 6.6 Mb.
Not uniform, Horizontal Zig-Zag curve, YXZ: 17.3 Mb!

In order to find the best match of orientation, sampling and path-curve I wrote a script that builds CSM’s for all of the possible combinations for a specific number of depth maps. This was repeated for the Stanford Dragon, Bunny, Teapot, Armadillo and Venus. (I currently have around 9Gb of CSM’s, without going any higher than 4096 depth maps). As an overal result of all the data I gathered, the (ZXY, Uniform, Vertical Zig-Zag) combination gave the smallest (and best) CSM’s. I have yet to test if this is also the case for the overall quality of my shadows.

3. Hilbert Curve
Started reading some papers on how to generate the curve and algorithms for switching between the 1-dimensional and n-dimensional indices of the curve. Goals for this week are getting these implemented and start building results.