Sparse Voxel Octrees

#1 Happy New Year.

#2 My child has been born! I've now been defecated on by Bipeds as well as quadrupeds..

#3 Sparse Voxel Octrees:

I've been spending a great deal of time lately attempting to make heads / tails of the whole 'sparse voxel octree' technology that ID is touting as the 'next big thing'.
You can find a good writeup of similar technologies here at Anteru's blog and get the origional post from PC Perspective.

What piqued my interest in this topic was the latest Windows Graphics Summit, in which we discussed the concept briefly in terms of it's supposed 'silver bullet' to artist content generation.

I did a little digging on the whole 'point cloud' / 'voxel' rendering process, and drummed up some good links.

Jon Olick from ID gave a Siggraph talk on their tech, you can find a discussion on it over at OMPF; a website, IMHO that contains some pretty good resources in terms of raytracing and hardware black-magic. The link provided also contains many sub-links to other great papers on the same topic.

An excellent paper over at Pixar's vault : Point-Based Approximate Color Bleeding echo's a similar desire to work in a point-cloud space, rather than a parameterized mesh/texture space. Their voxel setup allows them to approximate various forms of lighting to be used for near / far geometry. Pixar also has a great chapter in the book Point Based Graphics, that, from what i can tell, was written entirly by the guys over at Pointshop3D (which is an interesting concept in it's own right). The chapter details their point cloud system for the RenderMan system that uses Brick maps and other fun things to access LOD in volume space for various rendering reasons.

Sylvain lefebvre (whom I will always give props to for his research into the texture synthesis relm) has a great derivation that appeared in GPU GEMS2 titled Octree Textures. It's a little different concept, but the same idea in the end;

After going through all this research, and implementing my own version of an SVO system, I came to a couple conclusions that I'd like to share.

After implementing my own version of the system, I've got some thoughts that I figure I can briefly share:

• As far as ray tracing goes, when we discuss making it accessible to the hardware, standard poly/ray ray tracing is quite difficult to map to the hardware. And by this, i mean that it needs to be simple and easy enough to create dedicated hardware set aside to actually produce the system. Like putting LZW on a chip, or a Hardware tessellation unit. Voxel grids on the other hand, are much simpler to implement in the hardware relm for obvious reasons. I can't help but to think that if the future was to design graphics hardware for it, then yes, voxel ray tracing would be easily produced in hardware, and would likely give us a much better performance throughput as far as ray tracing is concerned.


• Voxel data for an entire level takes up an epic crap ton of memory. You can consider that most geometry in videogames right now get away with a few memory tricks by re-using tiling textures, and instanced objects. But for a voxel representation, each one of those pixels (voxels) will be unique; ultimately forcing you to need an out-of-core management system in order to interact and use it properly. Now, IMHO that seems like a stretch to me; I know we're moving in the direction of multi-core systems, which enable out-of-core compression and streaming, but it seems like a step backwards to increase our memory footprint (to a MASSIVE scale) to achieve the same visuals and reduce our ability to handle dynamic environments. Now, you can do this with the proper setup, but I'm simply stating that maybe we could do something else with all that bandwidth; instead of dedicate it to streaming in the same scene representation that we can achieve now


• If you ignore the memory / streaming footprint issue, Voxels make a great deal of sense from the performance perspective. In traditional rasterization, you have the difficulty with overdraw and tessellation problems that occur when dealing with ZBUFFER style rendering. On top of that, we have to implement a great deal of extra LOD systems for geometry and textures in order to effeciently balance the payload when we get sub-pixel tris/texels. Octree Voxel tracing fixes that; As your ray is being cast through the octree, if the children of the current node have a screen space area that's less than a pixel size, return the color of this node instead of moving lower in the tree. That's a pretty interesting concept if you think about it. Hypothetically, you could increase your detail indefinitely. It also removes the need for artists to be concerned with memory footprint / geometry detail, because it's all translated into something that the programmers manage, rather than the artists. Which from my experience is a huge win from the asset creation standpoint.

With the links I've provided, you can find a great deal of other smart people talking about the same idea. To be honest, after implementing the concept myself, I can't see this technology really taking hold of the industry when stacked next to Realtime raytracing in a multi-core universe.

Now, if hardware manufactures came back and started providing dedicated hardware for this type of task, then yea, I can see it catching up, but that's a huge amount of time down the line. I have a feeling this technology is a good idea, but will fall the way of the hype of 'mega texturing.' Great idea, but what about it makes the end user really want to pay the extra money to upgrade their box to buy it?

Just like attempting to implement realtime GI for games; Is the dev time and result enough to squeeze an extra 30k product sales for your title?

If not, move on to something more important; like trying to figure out how to change a dirty diaper in 30 seconds flat..

~Main