detail (read: lies), the biggest problem is that their demo looks like shit. He passes this off as being due to programmer art, but there's a more fundamental reason for it: they cannot support lighting with this method. Not even simple 1 directional lighting.
To explain why, here's a basic outline of how you could brute-force render a voxel scene:
For each pixel:
- Cast a ray (or frustum, if you like) from the camera through the pixel into the scene to find the set of voxels visible to that pixel.
- Get the lit color of each voxel, and blend the results to get the final pixel color.
Now for a large scene where there are hundreds, thousands, or millions of voxels per pixel (like in the demo), that's way too slow. To get around that they use a hierarchical spatial representation, likely an octree. The algorithm becomes:
For each pixel:
- Same ray, but this time find the cell in the spatial partition that is roughly the size of a single pixel. You only need to find 1 cell instead of however many millions of voxels it may contain.
- Get the lit color of that cell, using umm, magic?
The latter algorithm works for unlit geometry simply because each cell in the hierarchy can store the average color of all of the (potentially millions of) voxels it contains. But add in lighting, and there's no simple way to precompute the lighting function for all of those contained voxels. They can all have normals in different directions - there's no guarantee they're even close to one another (imagine if the cell contained a sphere - it would have a normal in every direction). You also wouldn't be able to blend surface properties such as specularity.
So, dynamic lighting is out. But I guess we can use baked-in lighting? The rest of their technique depends on baked-in static environments, so why not do the same for lighting? Well, you'll notice they (mostly) don't have baked in lighting either. There's a reason for that too: recursive instancing.
Recursive instancing is how they manage to have huge worlds (i.e. unlimited
detail) in a reasonable amount of memory. Let's take as an example the clumps of grass in the demo. There are millions (conceivably billions) of them in the world. Even just storing a simple compressed transform for each would cost a huge amount of memory. So instead of storing individual instances, they have the following: several clumps of grass and trees (and elephants) and ground instanced in a group. That group is then instanced multiple times to form larger plots of land. And then that group is instanced several more times to form the entire world (along with a few variations for other things, such as rivers).
This allows for very efficient storage, but the world is necessarily repetitive (as they demonstrate). It's no coincidence that their earlier demos were showing off Sierpinski's pyramids, as that is fundamentally the same method except for procedural placement.
But the biggest drawback of instancing is that all instances of a model are identical. This means, for instance, that the world cannot be dynamically destructible (barring some form of copy-on-write which would cost memory and cpu time proportional to the amount of world modification). More importantly, they cannot bake-in lighting unless all instances happen to have the same exact light (i.e. all at the same absolute world rotation and with identical shadows). The only fix for this is to just duplicate models for each unique lighting condition.
Notice in the Sierpinski's pyramid demo they have lighting, but all instances have the exact same orientation and lighting and the light never moves. And in the latest demo, most of the world is completely unlit. There are a few exceptions to this, such as the elephant with some approximation of AO, and the trees with a ground shadow directly beneath them. Both cases do not vary because in both cases the light is just baked into the color.
So, despite the guy's protestations, these are not trivial issues that can be addressed in the future (or are apparently already fixed but for some reason can't be shown). They are fundamental limitations
of the technique. Now I'm not saying it's impossible to fix these, but it will be very difficult and there will be inevitable compromises to make it work. Such compromises as: limit the world size (see atomontage), or stream in data from vast archives on disk (see Id tech). And that's just if you want to do decent baked-in lighting. Implementing dynamic lighting or destructible terrain is an even bigger problem.
I'll change my tune the moment they have something that looks even comparable to a modern game, but definitely not while they keep showing videos that look worse than many PS1 games (which at least had lighting).