What material are you using to do this? I don't know of a material that can fit into a cubic centimeter and to have a mole of a mole of it. An electron (one of the least massive thing we can find and control) has a mass of 9.1*10^-31 kg. Putting 10^66 bits in there would result in an object with a mass of 9.1*10^35 kg. The Sun itself only has a mass of about 2*10^30 kg. So you're not only upsetting the balance of the solar system, you're not too far from super-massive black-hole territory (a hundred billion Suns or 2*10^41kg). Do you see how absurd this can get?

Meanwhile, the vector representation of the same thing takes dozens of orders of magnitude less memory.

Well, when you start talking about theoretical memory units with the mass greater than that of a star, it becomes difficult to see it as anything approaching possible.

You can model a pog virtually precisely with a textured cylinder. And spline patches (NURBS can get spheres perfect) can model lots more than just pogs.

And yet, there is not one object around me that requires voxels to model sufficiently. Indeed, I have yet to see such an object.

Recording a 2D image is like photography. Recording a 3D image is like holography. Neither of which has anything to do with producing one from scratch. Which is what rendering is.

Yes there will be. That is without question. All you need to do is look at current multiprocessor systems to see that. A dual-processor machine, even running a multithreaded app, isn't as fast or capable as a single processor machine of twice the clock speed. A 4-processor system isn't even as good as a 3x clock speed increase. The returns have already deminished. It is merely a question of how many processors do we get before the returns aren't significant for doing a single operation. How much can you multithread an application?

But you're wrong. For all you know, you could be plugged into the Matrix and all that is around you is just a signal being beamed into your brain. Or, as Descartes pointed out, that an Evil Demon could be controlling your mind and decieving you about the entire world. If you model a world with surfaces (rather than volumes) such that no one can tell the difference between the surface version and the volume version, there is no difference.

Which was in relation to using different primitives for voxels: spheres rather than cubes. That's very different from modelling with CSG primitives. You aren't trying to approximate a surface with a bunch of spheres at regular intervals. Instead, you're approximating a surface by taking mathematical figures and doing CSG operations on them to create a new object. Indeed, a PolygonBall could be a CSG primitve, as long as the mesh itself is closed.

CSG, btw, happens to be another advantage of ray tracing that you missed.

And how do you plan to store the information? You have to have something there, and that something either has mass (most everything) or energy (the very few massless particles).

The fact that you're already calling for 0.5 molar bytes of information just to get a cubic mile of stuff at reasonably high precision is testimate to the rediculous problems of scale.

Which has precisely what to do with calling for a 0.5 molar bytes of information?

Look at 2D sprites. Notice how the empty space of the rectangle still has to have data for the empty space. Sure, when you're talking about moles of data, you have some pretty good incentives to come up with data reduction methods. But you still have moles of data; the order of magnitude is still accurate.

Also, let's say we store this data as some kind of sparse matrix. The sparse areas just happen to be the surface elements. Which roughly approximates a sequence of texturemaps on polygons.

It's got to go somewhere. Whether it's RAM or local harddrive storage, it has to go somewhere. Storing all of LA at 600 dpi would require truly ungodly storage.

The basic shape is. Anything more can be done given what I say at the end.

Displacement mapping doesn't look fake, becuase it isn't. I'll get to this a bit later.

Yes. I would also argue that JPEG compression, while a nice format for images, is terrible for sound. Also, MP3 compression, while nice for sound, is terrible for images. Both of these statements are true. They are true because sound != images.

That's funny. My computer, 5 years later, still doesn't have 3GB of RAM in it. And I'm really not going to download a 3GB level.

He was off by a bit. It's going to be quite some time before we're going to really start having 3GB levels of games. Granted, the 32-64-bit transition is going to be what takes the most time, but even so, it's going to be awhile.

And one of my professors at CMU wrote a functioning ray tracer on a buisness card. The simple solution isn't always the best. Indeed, in many cases, the simple, brute force approach tends to get progressively worse, not better.

The problem there is filling in the lines. For a 2D creature, 2D vector graphics looks just fine because no one can see inside the vector image. Such a creature sees a 1D projection of the 2D space, so they can't see around the 2D object and notice the emptiness. For us, we can see the holes. Filling those holes with something was the equivalent of a 2D rect-blit, so we may as well do that.

For 3D beings, like us, as long as nobody knows your 3D image is just a shell, it is as solid as any voxel image. There's no need for a 3D rect-blit.

That "trouble" can already easily be solved. Without resorting to either ray tracing or voxels. Observe.

Note: I cannot stand this technique. I really, truly, hate the idea of rendering like this. But it is likely to be the way things go in the future for game scan conversion, so here it is.

How to get microdetailing into rendered images. It is really simple, ultimately. Displacement mapping.

In the scan conversion world, displacement mapping means to take a low poly model, use vertex/fragment (and, eventually primitive) shaders to tessellate it and a texture to apply offsetting to it, and then feed the high-poly resulting model back into the renderer for the final render of the mesh. Of course, the displacement mapping can be done in screen space, such that you end up with a model that is tessellated to the resolution of the screen. No more, no less. One vertex per pixel (or sample, if antialiasing is used).

Now, take this a step further. There are two competing methods for hyper-detailed mesh modelling: subdivision surfaces (taking a mesh and using a subdivision algorithm to produce a smoother one) and spline patches. Either one will work with this method. The spline patches are tessellated directly into the high-density triangles. And the subdivision surfaces just require the use of the subdivision algorithm instead of normal mesh tessellation in the displacement mapping routine, though they have a problem with subdividing irregularly.

Now, here's the important part. The displacement texture, the texture that defines how to shift the new vertex, is procedural. It's can be some Perlin noise or a nice fractal or whatever else looks convincing.

And, unlike voxels or super-high-detailed polys, you can have multiple buffers of data that you're rendering to and rendering from, so you aren't taking up significant room.

Efficient, economical, and sufficient to get the point across. The detail is there, and we didn't need to make black holes worth of memory to do it. Put a little thought into a problem, and you can find an elegant solution to the brute-force methods. And, usually, the elegant solution is better.

BTW, about physics. Microscale particle physics doesn't equal out to what you get on the macroscale. By particle physics, I don't mean hardcore atomic particle physics. I mean the physics of modelling something at 600dpi and expecting to get, for example, friction out of it. It doesn't work. It, also, takes a really long time to do. Not a particularly good mechanism for physical modelling.