The Procedural

I keep saying it. Few people keep listening. So i'll just keep saying it:

"Next Gen Hardware is perfect for procedural content"

And, some new software being used in a new XBLA game proved my point yet again.

The company boasts that they are accomplishing upwards into 70%+ texture compression using their new software. But in reality, they aren't doing anything close to 'traditional' compression algorithms.

Rather than taking an image in, compressing it, and then returning a result, the software requires you to composite your texture in their application, and the resulting filesize that is saved out, is crazy small.

After looking at some online posts about this topic, I've got a decent grasp of what they are doing, and although i'm not too impressed about the tech, i'm impressed that someone had the gumption to actually DO it on the scale they are.

Essencially, they have produced a procedural texture creation tool, that stacks a bit of Texture Synthesis functionality on top of it. What is stored to disk, is a descriptor file, which tells the composite software at runtime how to put the source images back together. Which, apparently that process is pretty fast (or so i'm told).

It's about damn time someone else realized this!

Although Carmack disagrees, there is huge compression potential when you store the source information for a texture, rather than the entire texutre itself. For example:

A 512x512 greyscale image is 1mb, storing the input data for this image would be like saving the adobe photoshop file to disk. Yes, saving the PSD file would kill your memory. But, what if your source data wasn't the same size as the output? What if your source data was at a smaller resolution, and infact, sumated only 1/8th of your output?

That's where this all comes into play. That's where it's less expensive to store the input data, and compose @ runtime. This is a process called 'Data Amplification' (for those of you whom don't know). And it's a goddamn powerful concept. Storing information to create a 128x128 texture, which can also create a 512x512 texture (w/o upsampling or any other specific issues with visalization) is a very powerful tool!

Currently, we store mipmaps for graphics. This idea is to increase texture cache effeciency when viewing texels in the distance of the scene that are less that 1 pixel per 1 texel. This is a great idea.
One downfall to it, is that you can never get closer in resolution than the largest texture. That is, if your mip 0 is 512x512, you can NEVER zoom in farther w/o seeing pixelization with standard mipmapping. We use techniques to 'hide' this fact (detail mapping, virtual textures) but in reality, we're just thinking about it all wrong.

But that's a different post..

~Main