1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

GPU Terrain Generation Update

Discussion in 'News and Development' started by Benjamin, Apr 20, 2014.

  1. Benjamin

    Benjamin Lead Developer

    • Dev Leader
    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.
    Benjamin, Apr 20, 2014
    Last edited by Benjamin; at Apr 20, 2014
    joppiesaus likes this.
  2. tetryds

    tetryds cus tet, that's it

    • Member
    That looks very nice.
    For every different planet it uses a different noise map or it's the same for all of them?
    I'm not sure how this works, it would be nice to know a bit more, it will be very important to know that when we start to make our own planets.
    Can you explain how it works to generate the planet itself without many technical details?
  3. Benjamin

    Benjamin Lead Developer

    • Dev Leader
    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.
  4. PsychoticLeprechaun

    PsychoticLeprechaun Designer & Web Developer

    • Dev Member
    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.
  5. Benjamin

    Benjamin Lead Developer

    • Dev Leader
    "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 :p
  6. tetryds

    tetryds cus tet, that's it

    • Member
    Break all saves, we are fine with that.
    You should never waste too much time with backwards compatibility, like KSP does, even when there is gameplay already.
    Every aspect that you change on the game will modify the entire experience, and continuing from where you droped would simply ruin that.
    The early game features added would be simply ignored by people who doesn't start over and they will complain that nothing new is being added too.
    After breaking 3 or 4 saves people will get used, or stick to the old one.

    Having that much freedom with terrain generation sounds really amazing, I can't wait to put in pratice several ideas about planets and biomes that i have!
  7. PsychoticLeprechaun

    PsychoticLeprechaun Designer & Web Developer

    • Dev Member
    Yeah, I look forward to this! Shame I will lose my build, but such is life with pre-alpha!
  8. Benjamin

    Benjamin Lead Developer

    • Dev Leader
    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.
  9. Arpak

    Arpak Moderator - Former CM

    • Moderator
    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.
  10. tetryds

    tetryds cus tet, that's it

    • Member
    20MB, wow that is nothing!
    And you mean 100 sub biomes per each biome or 100 sub biomes per all biomes or 100 normal biomes?
    Omg so many biome kinds.
  11. PsychoticLeprechaun

    PsychoticLeprechaun Designer & Web Developer

    • Dev Member
    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.
  12. Benjamin

    Benjamin Lead Developer

    • Dev Leader
    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.
  13. PsychoticLeprechaun

    PsychoticLeprechaun Designer & Web Developer

    • Dev Member
    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!
  14. tetryds

    tetryds cus tet, that's it

    • Member
    100 is a lot, that means that you can have about 12 sub biomes on a world with 8 main biomes!!!
    By the way, I am drawing an "earth-like" humidity and temperature map, humidity also depends on the latitude and altitude, and using that will give a nicer looking effect.
    Will update this post if no replies until I am finished.

    Here is a basic distribution map.
    It only takes in account the latitude, but it's a basic principle of how to have a nice biome distribution.
    I will now make a distribution of Temperature and Humidity depending on the height.
    Following this distribution is up to Ben, but I hope to help figuring out how to distribute the biomes!

    Noise would apply to those lines, to create better distributions, or even turning a Desert spot into Tropical rainforest if enough humidity*
    This graphic doesn't take into account height, it would be like if it was baesd on a flat low lands world.*
    The world doesn't need to take into account the influence of oceans, that would overcomplicate it*
    Last edited: Apr 21, 2014
    tetryds, Apr 21, 2014
    Last edited by tetryds; at Apr 21, 2014
    joppiesaus likes this.
  15. Benjamin

    Benjamin Lead Developer

    • Dev Leader
    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.

    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
    Benjamin, Apr 21, 2014
    Last edited by Benjamin; at Apr 21, 2014
  16. tetryds

    tetryds cus tet, that's it

    • Member
    Ah, I forgot to mention that on this graphic it starts as 0 on the equator and goes up to 90 on the poles indeed!
    Is it better to have multiple x^2 equations or one more comlpex?
    I got that simplification by looking up several maps about temperature, biome distribution, biome characteristics and humidity.
    I cannot find such humidity characteristics on a simplified manner, so i had to look up the positions of the biomes and their descriptions and use the humidity intensity and latitude of them to make the humidity line.
    But remember, this is oversimplistic, if anyone has more detailed information about such distributions please don't hesitate on sharing!

    Btw, I just figured out how to increase the global relative humidity when near the ocean, just use a >1.0 multiplier for heights near 0m sea level.
    When i finish the altitude lines I will go find some functions to emulate all of them.
    Will these parameters and functions be open for the world creators to mess with?

    Here are the height based.
    Tried to keep them as simple as possible, but the temp multiplier is based on Kelvin temperature, it will not let mountain peak temperatures vary that much depending on the latitude, which will be very helpfull.
    Also makes it not possible to have absurd low temperatures on a mountain by the poles.
    Both of them were based on guessings, and nosie apply to them as well.
    If anyone can come up with better graphs, show us please.

    Edit: I also forgot to mention that the noiseless humidity should not pass over 80%, so it would be 88% on a beach, then we don't have places that have continuous raining.

    How is raining going to be held? some random noise that varies with time applied to the map? Rainfall graphs are a bit easier to find on the internet.
    Last edited: Apr 21, 2014
    tetryds, Apr 21, 2014
    Last edited by tetryds; at Apr 21, 2014
    joppiesaus likes this.
  17. Benjamin

    Benjamin Lead Developer

    • Dev Leader
    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.
  18. tetryds

    tetryds cus tet, that's it

    • Member
    Btw, the temperature dependance with the latitude is simply a cosine(lat), considrering the equator as zero, or a sine(lat) if it starts from the top (with a small distortion by one or two parameters).
    It's simple enough, because it roughly has to do with the angle the sun heats the surface of the planet.
    Also, it would be important to control the amplitude of the possible noise for heat, because on jungles and deserts the temperature desn't vary much (again another simple cosine).
    And I'm sure that the humidity can be made with a simple damped and slightly distorted cossine/sine, which would have no more than three parameters on it!
    The altitude variation is just a few lines, what would smoothen it is calculate in Kelvin, as mentioned above.

    I will try with different formulas, and will do everything to stay under 3 parameters, as well as avoid using exponentials (the hardest part).

    Edit: will update this post with everything I can come up with, so its easier for you to choose/tune them as you wish.

    Temperature (from best to worse):
    • Real part of: e^-ix * (cos x)^2 from -pi/2 to +pi/2 (perfect, overcomplicated)
    • (cos x)^(2x) from 0 to +pi/2 (perfect, not that complicated but doesnt work for negative x vaules)
    • (cos x +1)/2 from -pi to +pi (this one is not bad, but its too sharp)
    • (cos x)^2 from -pi/2 to +pi/2 (I like this one but its also sharp on the ends)
    • ((x-90)^2 * (x+90)^2)/90^4 from -90 to +90 (without trigonometrics)
    • ((x-pi/2)^2 * (x+pi/2)^2)/ (pi/2)^4 from -pi/2 to +pi/2 (no trig, using pi, you can put any vaule there it will output a vaule between +1 and 0
    • And Real part of: e^-ix * (cos x)^(x) from 0 to +pi/2 (overkill, but y not? hehe.)


    • (-0.25x + 1) * (cos 3x)^2 from 0 to +pi/2 (this. i misinterpreted some humidity stuff regarding the poles before)
    • (-0.4x + 1) * (cos 6x) +1 from 0 to +pi/2 (as simplified as i could, its not be perfect but just trow a lot of noise on the top of it)

    *the deserts are situated at 30 degrees, I messed up when located Saarah at 20 degrees.*
    Last edited: Apr 22, 2014
    tetryds, Apr 22, 2014
    Last edited by tetryds; at Apr 22, 2014
    joppiesaus likes this.
  19. Benjamin

    Benjamin Lead Developer

    • Dev Leader
    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.
  20. tetryds

    tetryds cus tet, that's it

    • Member
    Updated post above with proper equations.
    Kept it as simple as possible, and fixed a big mistake i have made regarding relative humidity on the poles.
Similar Threads: Terrain Generation
Forum Title Date
News and Development Procedural Heightmap Terrain Generation Jun 27, 2015
News and Development GPU Generation Woes. A setback. Jun 30, 2015

Share This Page