Getting sleepy here.. I had a Melatonin pill of those bought in the USA, made to put asleep bull-sized individuals.

Someone mentioned about posting about graphics, so here is my thoughts about the coming future. Not sure when but it's coming.

First let's think about texture mapping. I remember when Deluxe Paint on the Amiga first implemented perspective projection of images was rather slow and the quality wasn't so good.
The problem was that it would take every single pixel of the source image and try to put it in perspective. This works OK if the perspective image is relatively big respect to the source image, but it's a big waste of calculations if the perspective image is actually using few of the source pixels.

Texture mapping is the same thing. Aside from a few crazy attempts (Sega Saturn and nVidia NV1), texture mapping is done by selecting a texel for each pixel that needs to be drawn (more in case of filtering, but still a fixed number related to the number of pixels).

This works in the assumption that polygons are probably going to be smaller than textures which are big enough to cope with a few bigger polygons.
The real issue is really with perspective projection, where things can get very big or very small and one must take into account this scalability.

Texture mapping is now well optimized and, in combination with mip-mapping, can handle all polygon sizes efficiently.

Enter the geometry: as we put more and more details into geometrical definitions of 3D objects the same problem of not wasting time hitting the same pixels comes up.
A very detailed model with 100,000 quads only really needs about 20,000 quads if it covers 100x200 pixels, for example.
This model will still look pretty ugly when we zoom in into some area that is supposed to be round but that doesn't look so round anymore at that distance.

So basically, we need geometric level of detail (LOD). This is something that was being pursued 10 years ago but that hasn't quite made it yet.
To scale geometry properly one probably needs filtering as it happens with texture mapping. The simplest implementation to understand this is displacement mapping, where one has a texture that can "lift" pixels by crating triangles on the fly.
This is not so easy to implement efficiently in current hardware, but I think it only makes sense... though actually calculating how many triangles one should generate (tessellate) is not trivial to do efficiently.

Still, for the time being it would be good enough if one could use texture samplers to store geometry that would scale nicely without any artifacts.

Another nice solution for geometry LOD is "texture images" from Hoppe which was pushing progressive LOD at Siggraph 97.
Geometry images imply a dense sampling around a whole genus-0 (without any holes) mesh but at the same time it doesn't require explicit primitives definition, no vertex indices, as every triangle/quad is implicit by the grid-like distribution of the texture that makes the geometry image.

mumble mumble