GPU Terrain Generation Update

I got the Base Biome and terrain generation working on the GPU.

Here's a pic. The green is the height: http://imgur.com/MvzajaI

So the base biome generation was relatively easy to get on the GPU. I just had to port the code to glsl and pass in the data via uniforms. A downside is that we can only pass 1024 variables to the GPU, so we are limited on the number of terrain functions a planet can have. This is reasonable though, since the more functions you have, the slower it runs.

Now the next step is to get the sub-biome generation algorithm running on the GPU. This is WAY harder. The current sub biome system is recursive, and requires a lot of variables that can't all fit into the shader. (GPUs are quite limited) I might need to completely redesign the way the sub-biome generation algorithm works.

So anyways, if you guys have any algorithmic ideas for how to do a sub biome system let me know. The only solution is probably recursive. Which can be unrolled into an iterative approach, but it requires us to send a lot of info to the GPU. If we want 300 types of biomes to exist on a planet we simply can't send that much info. But perhaps a preprocessing step on the CPU could help quite a bit.

Either way, I'll figure something out.

Sure. All of the planets use the same shader (glsl code) to generate terrain. However each has its own unique set of terrain noise functions. For instance, I could define a mountain function that has high amplitude noise in some spots, that gives a mountain effect. All of these noise functions are added together to get the final product of the terrain. For instance if you take oceans + mountains + hills + volcanoes ect. you get a convincing world.

Biomes are generated similarly. 2 noise functions determine temperature and rainfall, and then we use those two values and X and Y coordinates on a base biome graph. So for instance, high temperature and high rainfall = jungle. Low temperature low rainfall = Tundra. This base biome system works easily on the GPU. However, it is much more complicated when we do sub-biomes. For example, oases in deserts, mushroom forest in swamps. These biomes are not base biomes, rather they are biomes that appear inside the base biomes depending on certain factors. Ideally, we would be able to have infinite sub-biomes so that each biome would have lots of really interesting stuff. However, this kind of implementation on the GPU doesn't really work since we cant send enough data to describe it.

I am going to mess around with textures. Perhaps we can describe the sub-biome system using clever texture lookups, but I am afraid I may need to rewrite the sub-biome system to not be infinitely recursive.

Could improving the resolution of the temperature & rainfall variables work towards solving this issue? This could allow you to have a more high resolution texture for determining biomes, and things such as oases could exist inside that texture? Or perhaps keep the same texture for general biome, and a second texture which you use with a couple extra variables to determine sub-biomes.

"Or perhaps keep the same texture for general biome, and a second texture which you use with a couple extra variables to determine sub-biomes."

That is the idea I had for the new system. Each base biome gets its own texture that determines sub-biomes. It would no longer be recursive, but it would be a HELL of a lot faster and would be implementable on the GPU The only issue is that when people make worlds, they will need to be able to easily draw these biome maps. So I will need to include a simple painting tool. Should be easy.

I think this is definitely the method I will use. I have been scratching my head for two days, and the 2 layer lookup table approach seems to be the most optimal way to do this. It WILL break all old saves, but that's ok its pre-alpha

Yeah, I look forward to this! Shame I will lose my build, but such is life with pre-alpha!

I have figured out the overhead for doing a system like this, and it's looking pretty good!

Each base biome will require 1 sub-biome lookup texture. We probably should not use temperature and rainfall as X and Y on this map, since it will not work very well for irregularly distributed base biomes. Each sub-biome will require 1 texture for interpolation reasons, and probably 6-8 variables. So we should be able to have 100 or more biomes in a world with no issues. I do believe that is plenty If we limit the size of the textures to x256 we should have very little VRAM usage. I think I calculated about 20MB of VRAM used for 100 biomes as a worst case scenario. Compared to the VRAM used for the geometry that is nothing.

As for breaking saves I think we can all agree that since SoA is in such an early state that save breaking isn't a big issue, if you have a cool building you could just use it on the older version or something.

I do believe that Ben means biomes & sub-biomes as a whole. That said, 100 does sound plenty on a per planet basis! It is a worthy sacrifice to have that sort of limit on biomes when it gives us great benefits in performance and other areas.

Yep biomes as a whole. And the limit might be a little higher than 100 if I can do some clever things, though I dont think it needs to be much higher than that.

Yeah, 100 certainly seems enough, if clever means a fair bit of work and not a significant number more biomes, I personally don't think it would yield much worth - I can't even begin to think of 100 biomes for just one planet!

This is great! What source did you use to come up with this? Currently latitude does not affect humidity, and for temperature it is simply linear. We need to figure out a mathematical function that can emulate this. So t(L) = ? and h(L) = ? for L = abs(latitude). t(L) and h(L) are clamped between 0 and 255 when used for texture lookups, but don't actually have to be in that range. It can be higher or lower.

Currently:
t(L) = tnoise(pos) + 110.0 - (lattitude*200.0)
h(L) = hnoise(pos)

where hnoise and tnoise are just some random noise functions to make distribution less uniform.

EDIT: lattitude in this equation is actually not true lattitude. It is instead the Y coordinate of the normal for that position on the world. So at the equator, lattitude = 0. At the poles, lattitude = 1

The equations will probably not be open for modification in the beginning, but we will possibly expose them with scripting or GLSL in the future. We can expose any related variables very easily however. Rain will be applied based on cloud cover, and cloud cover will appear based on humidity most likely.

Great! I can definitely do the cos temperature dependance and any other formulae you come up with. As for the variation of the temperature and rainfall via noise, that is up to the user. They can do pretty much whatever they want with the world editor.