Maybe a stupid question, wouldn't nice textures (not in the CS meaning) require interpolating between the voxels? I mean, we all know how crap textures (in the CS meaning) look even with bilinear interpolation. A lot of times mip-mapping isn't good enough either.
I can imagine that monochromatic stuff would look right without interpolation but textures (not in the CS meaning) seems to be different.
Or it isn't an issue? Are voxels interpolated anyway? Did my post made any sense written before going sleeping?
One of the most difficult topics I've seen actually.
Cone tracing and other sampling methods work. Also simply relying on voxels to collapse their subtrees into their parents to store information is key. That is from very far away an object that is less than a pixel can merge the color of their main subtrees into a single color. As you move closer the ray only traverses into the first level grabbing the merged color. So in actuality the dataset is only 8 color values (assuming a subtree for the highest levels). This leads a lot of people to realize you don't need to load that much data to get visually amazing detail. It's the same theory behind not loading the highest mip level of a texture since the user can never get close enough to see it. Carmack discussed this technique actually in his 2011 Quakecon speech recently when he talked about how they performed a visibility test so they could lower the quality of a lot of textures the player couldn't get to. In the same way a space station that might be 10 GBs of realistic voxel data would stream the top nodes a la google images and it would look perfectly fine. This is where the idea of automatic level of detail comes from.
Anyway the mipmapping problem with voxel is an interesting one with a lot of approximate solutions. If you want an exact solution though imagine your screen then for each pixel there is a
frustum emanating out with its faces adjacent to the faces of the adjacent pixel's frustum. Your goal is to find a way to pull back all the voxel data inside of the frustum while also discarding voxels that are behind other voxels. In a way it's similar to the optimal octree frustum culling algorithm. (That is the one that uses only addition pretty much and works with unlimited frustum planes.
If you don't know what I mean implement this with a quadtree and you brain will explode with ideas). The caveat is that you start scanning front to back and subtract the frustum generated by voxels that you include. You clip and track the color of the shapes used to create the volume. It is an extraordinarily complicated algorithm that I myself have sketched out on paper. You end up getting back a square region that looks like a bunch of colored regions. You merge all the colors based on their area to get the final pixel value.
As an example if you looked and saw only two voxels in your pixels frustum then it might look like this:
I colored the sides of one voxel differently so the perspective can be seen.
The nice thing about this is that you get amazing anti-aliasing especially if your voxel format defines infinite detail contour data. (That is you have subtrees that loop back around a few times to generate extra detail or nodes that define contours from a map in order to procedurally generate detail).
It's a fun topic with not very much research. A lot of the research papers you find though cover raytracing concepts. I wish someone would invest in making raycasting hardware if only to run via Gaikai or Onlive.
I recommend reading
Laine's papers on SVO stuff.
How this relates to point-cloud rendering I have no idea. I assume they found an interesting algorithm that might be different than the normal raycasting/3DDDA stuff.