I found a paper on Intel's site. It's from someone at Id Software.
I think it's pretty close to what's behind the cool MegaTexture name.

..basically a very optimized progressive-JPEG-like (edit: actually streams but it's not progressive in the "progressive JPEG" sense) streaming and decompression in real-time. Something very close to what I'm doing recently (as a task in a project, not as a full blown research).

For my implementation I decided to put an extra effort and make it easy to use outside the main application. This means that I'm going hide all my "nice" support classes and types and only expose the bare minimum for anyone to use the proposed functionality.

I set the goal of making a DLL out of this progressive CODEC, but more DLLs for the future.
The reason for a DLL rather than a LIB is that static linking can be pretty tricky. For example I have a global new and delete overload because I normally need 16/64 bytes aligned memory.
It's nice to be able to use a lot of my common library, but it wouldn't be nice to force headers and symbols onto other potential users.

Thinking in a DLL way also makes it easy to write at least one clean class that is easy to understand and document. The class exported in the DLL header is a bare-bones interface with a pointer to an actual hidden implementation class (aka PIMPL).

...basically I'm talking about modularity ! ..back from the dead.. saving the day where the OOP abuse complicates APIs.

cool

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