I guess I'll need to read into the fundamentals of voxels and octrees first to gain an understanding.

I really love octrees. They are used everywhere. You can also experiment with a quad-tree in 2-dimensions if you are coding one up. It may be easier to visualize the tree that way.

Also, I edited my first post. When I said you don't need 3 numbers for cubical voxels, I was referring to the numbers corresponding to voxel height, width, depth. you will still probably use three numbers to access the voxel or derive the 3-d location for the voxel (index values are fine if it is a grid).

Ooo Ooo, sorry for a TON of edits, but I also found this page which might be helpful, especially the links which are referenced:
http://gamedev.stackexchange.com/questions/17050/which-data-structure-should-be-used-to-represent-voxel-terrain

I think I understand it now:

1. The root node is just a point in 3d world space, say - (0,0,0) and the length.
2. When I subdivide by splitting along each axis plane, I just offset the centres of each children by length/2 along each axis in both positive and negative directions.
3. Then for each level I use the same function as step 2, recursively subdividing and offsetting the centres relative to their parent node.

I guess in terms of rendering the structure for visualization purposes I could do a number of things - such as rasterizing instances of boxes centred at each node position and scaled at each level. Or raycasting boxes by calculating the min and max of each box derived from the stored data.

Now, in terms of construction of the octree structure based upon triangle data - both Laine and Crassin use the top-down method and it seems as if they test all of the triangle data at each level down from the root node. Crassin then mentions the last step is to go bottom-up to store the information.

Wouldn't it be faster to start from the bottom - voxelize all the triangles, and then build each level of resolution by combining voxels with data in them and using their bounds to create the parent nodes? I'm assuming that this method has already been tried and there must be some reason that it is not preferred - but why?

Wouldn't it be faster to start from the bottom

I don't remember how the Laine paper reconstructs it, but I do believe the Crassin paper does construct bottom-up. They treat the fragments produced from the graphics pipeline as leafe nodes of an octree, and then build the tree up from these leaf nodes in parallel (I think on the compute shader). Essentially the idea you mentioned.

IMHO, building bottom-up or top-down depends on a few things: 1) you use the right construction that makes sense for your application, 2) the construction method you pick is not overly-complicated for your problem 3) parallelize node construction as much as possible. (important if your on the GPU, perhaps not so much if you're on CPU, and perhaps not important at all if it is done as a preprocessing step and you don't have dynamic objects).

Obviously when using the pipeline, it is faster to construct bottom-up since you have the leaf nodes after the fragment shader (all in parallel), but if you're on a CPU or something, you may just want to construct the tree top-down since that way is generally easier.

What would be an efficient way of being able to identify the index of a voxel based on its world space coordinates?
I.e. from a pixel location on the screen, I can use a view to world transformation to obtain the world location of a voxel corresponding to that pixel.

If I stored all voxels in a 3-dimensional array that corresponds with world space coordinates, it would be easy, but then there would be a lot of wasted memory in a sparse structure.

But if I store all voxels in a linear indexed array, how would I derive the correct voxel index from its world space coordinates?

so essentially, it would be most efficient to do a lookup in the octree for a selected voxel based on its world space position? Is this done by searching each level of the octree to see which side of which axis the location of the voxel lies in from top to bottom?
Would this be fast if the operation was repeated for every pixel on the screen at every frame?

back to voxelization for a bit.
The OpenGL Crassin paper states that he uses pretty much the same "conservative surface voxelization" method as in the Schwarz & Seidel method in their "Practical Binary Surface and Solid Voxelization with Direct3D 11" from GPU Pro 3, except Crassin uses the Geometry and Fragment Shaders in OpenGL. From the demo provided by Schwarz & Seidel, I see that their solid voxelization methods seem to be about 15% faster. What would be the disadvantages of solid voxelization?