Procedural Building Generation in Unreal Engine 3

The information content of something is rigidly bounded by the size of the code and the size of the input. Compress the CD's image with an "optimal" compressor (don't forget the decompression code in the total), add a couple of bytes for your random seed, done.

It doesn't matter how gloriously complicated the end result may be. The fact that you can precisely reconstruct the end result with the contents of the original CD, plus your randomization seed, plus your psuedorandom algorithm, means that that is all there is.

You can add more information by pulling from some random source that is irreducible, such as a quantum random number stream. Then, to reconstruct the result, you'd need to be fed the previously-random numbers as well.

It isn't actually possible for computation to add information. It is always bounded by the computation specification plus the input data. It can chew it and mangle it and present it and yea verily project entire universes from it, but the very definition of a computation's information content is basically the minimal seed necessary to recreate it.

See http://lesswrong.com/lw/vh/complexity_and_intelligence/ , which, incidentally, directly takes on your question about fractals in a subsequent post.

These techniques are routinely used in the demoscene for making 4Kb/64Kb intros. In this kind of intros almost everything is generated procedurally, not only meshes, but also textures and sound.

If you are interested you can watch one of these examples:

- Elevated (4K intro) Binary: http://www.scene.org/file.php?file=%2Fparties%2F2009%2Fbreak... Youtube video: http://www.youtube.com/watch?v=_YWMGuh15nE

- .kkrieger (96K game) Binary: http://kk.kema.at/files/kkrieger-beta.zip Gameplay video: http://www.youtube.com/watch?v=z5U4hEzZzaE

The point of information is that you want to convey a particular piece of information. A particular sequence of bits, say. Compressibility is about how many 'physical' bits are needed to convey the original information.

When cities are random, your odds of getting a particular city you might have wanted are very low indeed. This means that the channel is noisy and you will need very many repeats to get the original information.

If on the other hand the randomness is from a PRNG, you could ship the engine and the seed value and go from there. The compression ratio would depend largely on how large map files are vs the engine + seed.

In one sense this is a classic time and space tradeoff. In the case of randomly generated maps it's about externalising the cost of map making onto the user.

Consider the first correspondence. Suppose you knew a certain class of strings arose from a probability distribution. Then you can talk about the strings that are most likely to occur, or, more useful in general, about the individual characters that are most likely to occur given a history of previous characters. Using this, you can make a compression algorithm that will map (symbol, probability) or (symbol + history, conditional probability) starting from the highest probability, to the numbers 0, 1, 2 ...

This is arithmetic coding.

http://en.wikipedia.org/wiki/Arithmetic_coding

The result is optimal in terms of expected compressed string length assuming the strings you use this on really do come from that distribution.

Now consider the other way around. Suppose you have a lossless compression algorithm. Find the (uncompressed symbol, compressed symbol) pair (possibly with context) that achieves the highest compression. Assign that a high probability. Then find the next pair. Assign that a slightly lower probability (This can be done in a more principled manner than I'm alluding here). Then you have yourself a probability distribution.

More on data compression theory:

http://en.wikipedia.org/wiki/Data_compression

But what happens once you have a probability distribution over some data type, is that you may cast the problem of automatically generating instance of that data type as sampling from the distribution. Many procedural generation algorithms that give nondeterministic results (and the useful ones do, otherwise the work the modeler has to do is fundamentally the same) can be re-cast as sampling from a probability distribution; look at what the algorithm is generating and learn the distribution.

Note that this is uncomputable in general for the same reason Kolmogorov complexity is. This is known as Solomonoff induction:

http://singinst.org/blog/2007/06/25/solomonoff-induction/

So to answer your original questions:

1. The information (as in information entropy) in the algorithm in the CD is the entropy of the true probability distribution from which your levels originate.

2. And yes, in principle you can use the correspondence between data compression and procedural generation to generate instances of any arbitrary data type, not just 3D game levels. It may be hard to design a probability distribution that will create well-formatted instances though :)

Either the building mesh is generated procedurally when the level is loaded or it is generated and 'baked' in to the static level mesh at compile time (it's not entirely clear from the doc which method it uses).

IIRC, many games use a procedural foliage generator for trees and shrubberies.