Voxels have a bad reputation in the graphics community. Back when I was absorbed in this and writing my 3D 'engine' I got to see this debate in its infancy.
There is an intermediate form, non-uniform rational b-splines or NURBs, which the first nVidia card rendered directly. That made it possible for the NV1 graphics card to render a perfect sphere with just 6 NURBs vs triangle based engines which required dozens if not hundreds of triangles to approach the visual quality of that sphere.
Of course 3Dfx (and Matrox, and NEC with their PowerVR architecture) made triangle engines, they needed fewer gates and had far easier texturing pipelines. Once the NV1 was retired I haven't seen hardware NURB support re-emerge (although it would make for a wonderful thing given a multi-billion transistor GPU).
Voxels make the argument that once you get below the oversamping fraction of a pixel, be it 1, 4, or 16, you don't need a complex structure. And while geometry culling using a z-buffer and clipping rectangle is well trod, voxel culling has some subtleties that make it more challenging.
Voxels have, to date, over promised and under delivered.
Notch's analysis is pretty much spot on, with one minor exception, the math. Just like polygon engines don't bother creating layers of polygons to represent solids, a voxel 'rock' or other solid doesn't need to represent the 'inside' with voxels, it only needs to represent the surface of the solid to a degree where you can't see between the voxels. As long as voxel resolution is comfortably above the pixel resolution of the 2D project plane (aka the screen). So lots of data to represent surfaces, but they can be 1 'atom' thick so less than the petabytes he supposed.
Rendering then is the process of taking a rectangular solid which is 1x1 pixel at the screen surface and then expands based on the field of view out from the eye, and once you've gone deep enough into the geometry such that the cross section parallell to the screen has no gaps, you can compute and render that pixel and move on. And, as the Euclideon people point out, since you're not really doing polygons at all, changing the 'complexity' (in terms of surfaces) on the scene doesn't change either the render time or the effective voxel count.
Yes, its pretty abusive of memory bandwidth, since at range the number of voxels that have to be looked at to fill a single pixel can be large. Imagine a 747 airplane flying across the sky at a visual 35,000', if its only 2 x 3 pixels by the time it renders, its still made up of potentially billions of voxels which form the surface you can see.
> a voxel 'rock' or other solid doesn't need to represent the 'inside' with voxels
This seems to contradict Notch's (and Wikipedia's) description of a voxel. They indicate that a 3D space described by voxels has a voxel for each unit in space. The is analogous to having 1 pixel per unit of display space. If this is correct, then a rock would indeed have the inside filled with voxels.
I don't think you are misunderstanding so much as conflating two things, the co-ordinate space / construction of the world and construction of objects within that world.
It's correct to say that every 'point' in a voxel based world can be represented by a voxel in that point. It's incorrect to say that every point in a world has voxel data associated with it. Perhaps this is the place where Euclideon and Notch diverge as well.
Using a quantized world representation view (where co-ordinates in the world are quantized to voxel boundaries) then as a voxel moves through the world space it moves from point to point in that space. So a 'cloud' of voxels has an origin and an orientation in worldspace, that allows the translation of a local voxel space (the object) into world voxel space. Since you can't do sub-voxel positioning it behooves you to have an oversampling rate between voxel space and display pixels as well.
A 'feature' here is that it also allows for fine grain collision detection (harder to do in polygon space) but again its pretty expensive computationally. (boundary surface intersection of the local voxel space with the world voxel space).
What I'm not understanding is the object space. If a voxel's coordinates are implied based on its position, then there would be voxel data for every "point" in the object space. Unless we use a sparse representation of some sort, in which case it seems that we're basically using point clouds.
as I understand it, the disparity in explanations can be attributed to that we're talking about using voxels in a data structure known as a sparse octree, that would in itself be used to optimize the system by, among other things, allowing only the surface information to be stored.
There is an intermediate form, non-uniform rational b-splines or NURBs, which the first nVidia card rendered directly. That made it possible for the NV1 graphics card to render a perfect sphere with just 6 NURBs vs triangle based engines which required dozens if not hundreds of triangles to approach the visual quality of that sphere.
Of course 3Dfx (and Matrox, and NEC with their PowerVR architecture) made triangle engines, they needed fewer gates and had far easier texturing pipelines. Once the NV1 was retired I haven't seen hardware NURB support re-emerge (although it would make for a wonderful thing given a multi-billion transistor GPU).
Voxels make the argument that once you get below the oversamping fraction of a pixel, be it 1, 4, or 16, you don't need a complex structure. And while geometry culling using a z-buffer and clipping rectangle is well trod, voxel culling has some subtleties that make it more challenging.
Voxels have, to date, over promised and under delivered.
Notch's analysis is pretty much spot on, with one minor exception, the math. Just like polygon engines don't bother creating layers of polygons to represent solids, a voxel 'rock' or other solid doesn't need to represent the 'inside' with voxels, it only needs to represent the surface of the solid to a degree where you can't see between the voxels. As long as voxel resolution is comfortably above the pixel resolution of the 2D project plane (aka the screen). So lots of data to represent surfaces, but they can be 1 'atom' thick so less than the petabytes he supposed.
Rendering then is the process of taking a rectangular solid which is 1x1 pixel at the screen surface and then expands based on the field of view out from the eye, and once you've gone deep enough into the geometry such that the cross section parallell to the screen has no gaps, you can compute and render that pixel and move on. And, as the Euclideon people point out, since you're not really doing polygons at all, changing the 'complexity' (in terms of surfaces) on the scene doesn't change either the render time or the effective voxel count.
Yes, its pretty abusive of memory bandwidth, since at range the number of voxels that have to be looked at to fill a single pixel can be large. Imagine a 747 airplane flying across the sky at a visual 35,000', if its only 2 x 3 pixels by the time it renders, its still made up of potentially billions of voxels which form the surface you can see.