The big downside is that you have no idea ahead of time what parts end up on screen and which parts don't. With a voxel engine you create a giant tree that allows you to do a quick logarithmic lookup to a voxel for every pixel on the screen (more or less). Suppose you're standing on a hill and look down on the valley below. If the terrain and world below is created by artists and contains many unique objects then you end up with a voxel tree that's terabytes large. You can't keep it in memory, so performance will be awful. The only way (afaik) to keep the memory usage in check is to force reuse everywhere. So you then create ultra high resolution models of 100 different bricks and mortar. The artist then composes those "lego pieces" into different buildings. That would work, but then everything is going to look very repetitive again (which brings us back to square one).
Then of course there are the problems with lighting, animation and so on.
It's actually the reverse! Voxels make it easy to figure out what's on screen and what's not. That's their main advantage over polygons. The main disadvantage is that they are generally slower to render, but as you add more details, polygon renderers waste time on details that are far away or off screen while voxel renderers can discard those more easily, and eventually there's a tipping point.
You're right that lighting and animation are real problems with voxels. Animation in particular is pretty much impossible, which means you have to fall back to polygons for anything that moves or changes, which in modern games is a lot of stuff.
> It's actually the reverse! Voxels make it easy to figure out what's on screen and what's not.
No no, I explicitly said "ahead of time". It's easy to determine what's on screen when you're about to render the frame, but you have to load every single object in memory because every single object is a "candidate" that may end up on the screen, you just don't know ahead of time. You can't cull the voxel tree, even though 99% of the voxel tree won't be used when rending a frame. So the memory overhead is immense.
Voxel trees don't make it easy to discard things that are far away at all, because there aren't any low-resolution objects that you can use for far-away objects. You have to load many objects in memory even when you use them to render just a pixel or two.
The polygon-based worlds we have today use various low-resolution models for when you view at a distance, and as you get closer the higher resolution models "pop in". This tech advertises that you have infinite detail and that there's no need for objects with different level of detail. This means that the complete point cloud of every object has to be loaded in memory and that's a very real problem and it's in complete contradiction to the claims made by the company that artists can create infinitely detailed worlds without having to worry about vertex counts or whatever. Artists have to compose their world out of re-usable high-detail objects or the sparse voxel octree will be way too large. This means the artists will be much more constrained than they are today, not less.
You're wrong. You don't need to know what's visible ahead of time because you can load the tree lazily on demand. Voxels lend themselves naturally to perfect LOD scaling in a way exactly analogous to how mipmaps and megatextures work for 2D textures. There is no analogous algorithm for polygons; polygon mesh LOD is a very hard problem that is solved only imperfectly today and with a huge labor overhead for both artists and programmers. John Carmack himself has proposed voxels as a solution to this problem: http://www.pcper.com/reviews/Graphics-Cards/John-Carmack-id-...
Can't you still have a normal octree or something with segments of the voxels split by their spatial location with voxel subtrees inside of that? I don't understand why you can't apply spatial division techniques to voxels.
I don't think it would accomplish much. But sure, you can precompute which objects are visible in which circumstances and do some culling based on that data.
My understanding is that the problem is that there's just too much stuff that you have to keep in memory if you don't use LoD to distinguish between nearby and far away objects.
What are you going to cull? There's just too much stuff to load in memory. Too much stuff that actually ends up on your screen. Too much point cloud data. Now games use low resolution models and prerendered billboards for far away objects. With a voxel octree you're just SOL, no matter how clever your spatial optimizations.
Unless hard drives (or SSDs) become a few orders of magnitude faster I don't see how the data can be fetched from disk quickly enough.
I think you can, and I think they do; but that still doesn't solve the memory issue, actually it makes it worse since now you have to store multiple 'resolution' versions for the same data.
But if they still need to use 'traditional' techniques like LoD, rendering at various resolutions, etc, then the complexity and running speed can't be all that much faster than a traditional approach. The way I've been reading these articles is that somehow he's got a very fast method of deciding which voxels to show, without any pre-processing or optimisation - just brute force. I'm curious to see the first demo they'll come up with, especially since they only now seem to be at a point where they can render without shading, animation etc, and they make it seem as if those are just implementation details that can be added on an afternoon. We'll see.
Then of course there are the problems with lighting, animation and so on.