Standardizing Terrain & Procedural Generation

[MyEmail]

After discussing with other developers and some considerable thinking on my part, I think OD would benefit vastly from standardizing the terrain so it can be procedurally generated. With a handful of rules that regulate terrain-blocks (including dimensions, interactions with other tiles, and their textures), a simple program could generate hundreds of interchangeable blocks that are each unique and non-repetitive. The textures would be interchangeable across terrain-blocks.

For more advanced generation algorithms could be used to generate erosion effects on the blocks (heat, water, etc), cracks (concrete, bricks, etc), high-poly generation and normal/height/specular backing (for the lighting), and even create seams in the meshes for real-world destructible environments (a explosion goes off and the nearby chunks explode across their seams--the parts flying into the air and crashing on the ground with a burst of dust). Complex chunks (more than 1x1 in size, and going up/down to create cliffs) could also be generated.

From there the block-models could be imported to a editor and painted onto the map--allowing for the user to create just about anything. Plug everything into Bullet and you have a real-world destructible environment.

I am not going to do this for you (the standardizing, or code for the procedural generation), but I would offer my advice to help you do it. 1st is the actual blocks--you need rules that define how the blocks interact with adjacent blocks while being able to add variance (scales and biases to offset the transitioning vertices). 2nd thing is standardizing the textures--a generic way every texture can be formatted so that it can be interchangeable across every type of block. 3rd is writing a test-case example to generate some basic chunks with minimal features (no fancy algorithms for cracks or erosion etc, just 1x1 level-height blocks with scales/biases to offset transitioning vertices). If it works, the final is to go back and add support for the fancy features.

Because procedural generation can sometimes generate pretty ugly looking things, you would need a method of telling it what looks "nice" (or you could just screen everything before adding it to the game). A genetic solver could do this. You provide it with a handful of base-models you already have. It generates a list of 1000 possible solutions (some random, some based off of the base-models you provided). It then displays each model 1 at a time, and you rank how good it looks from 0-10. After you have ranked all 1000 solutions it generates another thousand, and you repeat this process 5-6 times (its not as monotonous as you would think). Just like how this video evolves a picture of Darwin, your solver would generate very nice looking terrain-blocks. This "ranking" would only have to happen once, as after that the solver would know "what looks good" and be able to generate hundreds of "good looking" terrain-blocks.

This could take care of all the art-side of the work for OD's terrain (granted the diffuse-textures would have to be created, but that is fairly easy once standardized).

Let me know what everyone thinks .

[charlie]

Sounds cool but difficult (read: impractical).

Perhaps coming up with a prototype might be more use in convincing a change in development direction than verbose brain dumps like this? Jus' saying.

[MyEmail]

This isn't meant to "change development direction", its meant to be a tool completely separate from your current engine that generates terrain blocks which are compatible with your existing engine.

To show how practical it is, here is a test-case implementation (30 minutes of code C++ code) and a test-tileset it generated of 512 different blocks. It is fast, and will generate varying sized (but interchangeable) block meshes clamped at integral sizes. It supports object-space normal/height baking (although disabled), and can save them as RGBA tga images (RGB for normal, alpha for height).

This does not implement any special features such as erosion, cracks, rock/tree generation, etc although it would be very possible.

[svenskmand]

From what I read here Ogre supports the use of bones to dynamically deform a mesh in game. Given that is true I think the easiest way to make all tiles have a simple skeleton shown in figure 1, the dots indicate the joints in the skeleton. Now when a tile is made clear by digging adjacent tiles or if it was built then the joints of the skeleton that are now not adjacent to other tiles will be perturbed. See figure 2 where the red tile is now exposed on the topleft and bottomleft sides, which means that we need to perturb the red joints, see figure 2.

[MyEmail]

So: simplification on the implementation method--represent each surface of the chunk as a heightmap. From there creating high poly meshes, normal/height backing, and genetic evolution would be a cinch. Plug it all intro a image processing library, and erosion/cracks/etc would be a piece of cake as well.

EDIT: CImg or OpenCV would be able to do the heightmap processing for adding erosion to faces and whatnot.

[MyEmail]

Sorry for the double post. Turns out I have adopted this "procedural terrain generator" for the project I am working on. As to whether it will be released/licensed for od's use I don't know yet. It not only synthesizes terrain blocks but the diffuse-textures as well.

How I have implemented it works well and is simple--here is the process if you guys want to implement one for OD:
1. Load a list of preset heightmaps (ranging from perlin noise to tech-tiles to rock).
2. Each heightmap is used for the heights of a terrain chunk, and a corresponding diffuse-map must accompany each heightmap.
3. Using the initial heightmaps as the first generation, use a genetic solver to breed the second generation.

a. Merge tilesets using a correlated probability function for the cross-over rate. This basically means process the image in chunks, the cross-over probability for each chunk is determined by a linear-fade out from the center to the edge of each chunk. The center of each chunk is less-likely to cross over than the edges, and which genome (heightmap) it crosses-over from is determined by a 50% probability.
b. Diffuse-pixels cross over to a the new organism's diffuse-texture with their corresponding heightmap-pixels.
c. Using a mutation factor calculate in erosion, cracks, chunk-resizing, and other features.
d. Using the heightmap, generate a equal-resolution normal-map and a low-poly mesh of the block.

4. Display each solution/terrain chunk one by one. Rotate it slowly, and apply real-time bump-mapping with a single light and texture it with its diffuse texture. Display each organism until the user hits a numpad key 0-9 to rank it.
5. Breed the next generation, keeping the best-rated solution for elite-selection, and repeat the process.

It takes 10 or so minutes to generate 100 solutions, and it takes awhile to rank each solution. After 10 or so generations it produces some pretty nice results . I guess this turned into more of a texture-synthesis algorithm, at-least until I implement complex tiles (tiles that go vertical for cliffs and whatnot).