If you plan on using this code for a project, please include a reference to this website, and my name. The details of the Creative Commons license I use can be found here.

// Ray-Octree intersection based on
// An Efficient Parametric Algorithm for Octree Traversal (2000)
// by J. Revelles , C. Ureña , M. Lastra
//
// Code by Jeroen Baert - www.forceflow.be - jeroen.baert@cs.kuleuven.be
// Licensed under a Creative Commons Attribute-NonCommercial Sharealike 3.0 Unported license
 
unsigned char a; // because an unsigned char is 8 bits
 
int first_node(double tx0, double ty0, double tz0, double txm, double tym, double tzm){
	unsigned char answer = 0;	// initialize to 00000000
	// select the entry plane and set bits
	if(tx0 > ty0){
		if(tx0 > tz0){ // PLANE YZ
			if(tym < tx0) answer|=2;	// set bit at position 1
			if(tzm < tx0) answer|=1;	// set bit at position 0 			return (int) answer; 		} 	} 	else { 		if(ty0 > tz0){ // PLANE XZ
			if(txm < ty0) answer|=4;	// set bit at position 2
			if(tzm < ty0) answer|=1;	// set bit at position 0
			return (int) answer;
		}
	}
	// PLANE XY
	if(txm < tz0) answer|=4;	// set bit at position 2
	if(tym < tz0) answer|=2;	// set bit at position 1
	return (int) answer;
}
 
int new_node(double txm, int x, double tym, int y, double tzm, int z){
	if(txm < tym){
		if(txm < tzm){return x;}  // YZ plane
	}
	else{
		if(tym < tzm){return y;} // XZ plane
	}
	return z; // XY plane;
}
 
void proc_subtree (double tx0, double ty0, double tz0, double tx1, double ty1, double tz1, Node* node){
	float txm, tym, tzm;
	int currNode;
 
	if(tx1 < 0 || ty1 < 0 || tz1 < 0) return; 	if(node->terminal){
		cout << "Reached leaf node " << node->debug_ID << endl;
		return;
	}
	else{ cout << "Reached node " << node->debug_ID << endl;} 	txm = 0.5*(tx0 + tx1); 	tym = 0.5*(ty0 + ty1); 	tzm = 0.5*(tz0 + tz1); 	currNode = first_node(tx0,ty0,tz0,txm,tym,tzm); 	do{ 		switch (currNode) 		{ 		case 0: {  			proc_subtree(tx0,ty0,tz0,txm,tym,tzm,node->children[a]);
			currNode = new_node(txm,4,tym,2,tzm,1);
			break;}
		case 1: {
			proc_subtree(tx0,ty0,tzm,txm,tym,tz1,node->children[1^a]);
			currNode = new_node(txm,5,tym,3,tz1,8);
			break;}
		case 2: {
			proc_subtree(tx0,tym,tz0,txm,ty1,tzm,node->children[2^a]);
			currNode = new_node(txm,6,ty1,8,tzm,3);
			break;}
		case 3: {
			proc_subtree(tx0,tym,tzm,txm,ty1,tz1,node->children[3^a]);
			currNode = new_node(txm,7,ty1,8,tz1,8);
			break;}
		case 4: {
			proc_subtree(txm,ty0,tz0,tx1,tym,tzm,node->children[4^a]);
			currNode = new_node(tx1,8,tym,6,tzm,5);
			break;}
		case 5: {
			proc_subtree(txm,ty0,tzm,tx1,tym,tz1,node->children[5^a]);
			currNode = new_node(tx1,8,tym,7,tz1,8);
			break;}
		case 6: {
			proc_subtree(txm,tym,tz0,tx1,ty1,tzm,node->children[6^a]);
			currNode = new_node(tx1,8,ty1,8,tzm,7);
			break;}
		case 7: {
			proc_subtree(txm,tym,tzm,tx1,ty1,tz1,node->children[7^a]);
			currNode = 8;
			break;}
		}
	} while (currNodesize[0] - ray.origin[0];
		ray.direction[0] = - ray.direction[0];
		a |= 4 ; //bitwise OR (latest bits are XYZ)
	}
	if(ray.direction[1] < 0){ 		ray.origin[1] = octree->size[1] - ray.origin[1];
		ray.direction[1] = - ray.direction[1];
		a |= 2 ;
	}
	if(ray.direction[2] < 0){ 		ray.origin[2] = octree->size[2] - ray.origin[2];
		ray.direction[2] = - ray.direction[2];
		a |= 1 ;
	}
 
	double divx = 1 / ray.direction[0]; // IEEE stability fix
	double divy = 1 / ray.direction[1];
	double divz = 1 / ray.direction[2];
 
	double tx0 = (octree->min[0] - ray.origin[0]) * divx;
	double tx1 = (octree->max[0] - ray.origin[0]) * divx;
	double ty0 = (octree->min[1] - ray.origin[1]) * divy;
	double ty1 = (octree->max[1] - ray.origin[1]) * divy;
	double tz0 = (octree->min[2] - ray.origin[2]) * divz;
	double tz1 = (octree->max[2] - ray.origin[2]) * divz;
 
	if( max(max(tx0,ty0),tz0) < min(min(tx1,ty1),tz1) ){ 		proc_subtree(tx0,ty0,tz0,tx1,ty1,tz1,octree->root);
	}
}

In table 1 on paper 4, on the discussion of extending the quadtree algorithm to octrees, there’s a table of comparisons needed to select the first node. The selection is implemented using bitwise operators. The error is that for operations concerning the z-axis, the rightmost bit must be altered (0), and not the leftmost (2), since that’s for x-axis operations. Switching 0′s and 2′s results in the right table.

Now there’s three days of my life I will not get back. One could argue that this all depends on the way you arrange your bits, but I suppose it’s universal standard that we read the rightmost bit as the indicator for 1^2 – also, in the rest of the paper, this convention is used.

Anyhow, onwards we go!

Dependencies:

• Visual Studio 2010
• OpenMP
• OpenGL / FreeGlut
• Boost libraries (latest dev checkout)
• Eigen Libraries

Most literature seems to point to an Octree as the most suitable structure for a voxel grid. If you store the parts of the grid that are empty as null pointers, you get a Sparse Voxel Octree (SVO), which everyone is raving about at the moment. Most people have seen the Jon Olick (from Id Software) tech demo by now, but it’s interesting to notice that this technique is nothing new – there are papers from the nineties already explaining algorithms to trace rays through sparse octrees, for raytracing purposes. The fact that instead of storing polygons, you’re storing actual fixed-spaced data points now is a detail, for me.

I’ve already figured out that there are two kinds of algorithms for ray-octree intersection: bottom-up, which works from the leaves back upwards, and top-down, which is basicly depth-first search.

I’ve already found Revelles’ algorithm from 2000, called An efficient parametric algorithm for octree traversal, which looks interesting, but is quite old. This is a top-down algorithm. The most popular bottom-up approach seems to be K. Sung, A DDA Octree Traversal Algorithm for Ray Tracing, Eurographics’91, North Holland-Elsevier, ISBN 0444 89096 3, p. 73-85. Problem is that most DDA Octree traversal algorithms expect the octree to be of equal depth, which is what we don’t want – we want those trees sparse.

In the more recent literature about Sparse Voxel Octrees I’ve managed to read through, (most notably Laine’s work on SVO’s), they all seem to be based on some kind of GPU-implemented version of DDA (Amanatides/Woo style).

I’ll be working my way through some basic papers about octree traversal next week and start coding as soon as possible, since that’s obviously the best way to learn how these things work.

I finished this week by implementing a “workload” renderer: an image with false colors depicting how much work was done on the pixel. Bright red = maximum amount of grid-steps = a lot of work. As expected, these pixels all depict empty space in the grid.

Same image, but now with grayscale and at a higher resolution.

Also, not a blooper, but for some reason, this:

Problem is of course, that most of these models are only offered in triangular mesh form (.ply, .obj files). Also, there’s no real standard for saving volume data. I wanted to avoid coming up with yet another filetype myself, so I ended up using binvox, an excellent tool from Eric Haines, which can convert triangular meshes to binary voxel files (with a small ASCII header). The tool is pretty popular in the Minecraft community, because it allows players to use meshes built from minecraft materials. (You didn’t think this lunatic made that manually, did you?)

Reading the binary voxel data was easy, converting them to my internal data structures wasn’t – spent a lot of time wrestling with Boost’s Multi-Array library (excellent tips and remarks here) – turns out I bumped into a bug which only manifests itself in Debug mode.

Anyhow, here are some renders of well-known animals. I’m going to look into a way to estimate voxel normals in the mesh->data grid process, because without normals, there’s no way to do any correct shading, and a lot of model features (creases,…) get lost.

All of the following pictures were rendered at a 600×600 resolution. All generation times were < 1000 ms, which I think is pretty good for a software-mode only renderer – no hierarchy in voxel trees as well. After I’ve looked into ways of stacking more data into the voxel data points, I’ll probably look at a GPU ray casting implementation.

(Click each image for large version.)

128x128x128 voxel grid - and an error in the color generation

Attempt at shading, all normals pointed forwards. Need real normals.

32x32x32 data grid - even at a low grid resolution, general shape is still good

Armadillo says booh (256x256x256 grid)

Sparsely rendered Stanford Dragon (128x128x128 grid resolution)

Sparsely rendered Stanford dragon, only grayscale (256x256x256 grid)

If you’re experiencing problems (including theme style-induced vomiting), please be vocal about it in the comments.

A good example is the immensely popular Minecraft. It uses a voxel-based representation of the world – this makes it easy to generate and manipulate terrain, which is what Minecraft is all about. However, the end result is still rendered as polygon-based cubes, using hardware acceleration. I’m not saying this is cheating or that notch’s renderer is not a great technical achievement – just pointing out how easy it is to get confused.

So let’s get this straight. This is my view on the terminology:

In direct volume rendering (DVR), you’re rendering a data grid. This is a rectangular 3D volume which contains data points with equidistant spacing. Notice how different this is from traditional mesh-based rendering: a mesh consists of a geometric description of triangles and their position.

• A data point is a single unit of information. It can contain temperature data, a simple boolean, … anything you want.
• A voxel is a volume unit which is defined by 8 data points. These volumes get labeled with a representative data point, the point which is closest to the grid origin. Often, Voxels are also called cells.
• Data points will always be data points, Voxels are just a certain way to group them. What do you call a 2×2 section of a regular 2D image? I’d say pixel block.  Voxels are the 3D analogy of that.

Getting the terminology right is half the work – and you’ve got to be aware of the subtle differences when reading research papers..

• If I render all or a portion of the data grid’s points as a cube, using the representative data point of each Voxel to get my rendering info (color, …), I’m rendering Voxels: I’m rendering the volume spanned by 8 data points, which results in a cube because the grid has equidistant spacing.
• If I shoot a ray from my eye and trace this through the grid, I am not rendering the volume spanned by the Voxel’s datapoints. I’m rendering interpolated datapoints, integrated over a ray starting in my eye. This is a whole different ballpark.

And for those who just dropped in: remember I’m raycasting, not just rendering cubes with OpenGL. I’m now 3 months in my doctorate – hope I’m on the right track and tempo.

I made this capture in a hurry, so don’t mind the yellow circle around the mouse. Also, rendering and capturing the output at the same time introduces heavy load on the CPU cores, which results in choppy video. I could have rendered all the frames to image files and then merge them in a movie, but that somehow felt like cheating on the real-time claim.

Next days/weeks, I’ll be focusing on

• Rewriting the DDA Woo algorithm to be iterative (getNextVoxel() instead of getAllVoxelsOnRay()) and incorporate interpolation
• Add opacity effects
• Finding a good way to sample regular triangular-mesh-models and import them, so I can render some bunnies and dragons.
• Although performance is not a direct goal, implementing a basic space subdivision scheme and formatting the data for it might be interesting.
• A lot of you have mentioned GPU acceleration in the comments – would make things faster, of course, and it’s fairly easy: http://www.daimi.au.dk/~trier/?page_id=98 - I want to experiment with the core rendering stuff first – can I attach material info to my data points, for instance.

So after finding the Windows binaries compiled (and maintained) by Max Martin Payne, I look at the contents of the zip file. I was running a 64-bit Windows installation. I had two freeglut.dll’s to copy to a suitable system folder, one for 32-bit, one for 64-bit.

Logically, I thought I’d place the 32-bit dll under C:\Windows\System32, and the 64-bit dll under C:\Windows\SysWOW64, right? Think again – it’s exactly the other way around.

Reason behind this is that SysWOW64 stands for: System Windows (32) On Windows 64. That folder contains 32-bit libraries for several 32-bit programs that have to be run on the 64-bit system. This means that the System32 folder contains all the 64-bit libraries. The reason Microsoft didn’t change the (now utterly confusing) folder name is because a lot of (badly written) software depends on having a System32 folder where it can look for dll’s, and nowhere else.

I thought someone should write this down. On the internet. Because it could have saved me a fair slice of time.