Mindwerks / worldengine

World generator using simulation of plates, rain shadow, erosion, etc.
MIT License
982 stars 128 forks source link

Temperature variation based on orbital parameters #143

Closed tcld closed 8 years ago

tcld commented 8 years ago

I added a bit of code to give temperature maps a little more character. Something that would be very good to know is: Does the temperature map have an influence on the placement of biomes? I thought I saw something like that but I am not sure anymore. If it did, then this little feature might have very interesting results. :)

Here are some examples of small maps - discussion is welcome, of course: seed_125382_temperature seed_390169381_temperature seed_843443964_temperature seed_1246918379_temperature seed_1321156287_temperature seed_1383445066_temperature seed_1412584252_temperature seed_1638723866_temperature seed_1659093856_temperature seed_1754673645_temperature seed_1887785474_temperature seed_1933237127_temperature

This branch is based off of https://github.com/Mindwerks/worldengine/pull/138 because it is getting a bit difficult to code around all the small changes I made in the numpy-branches without making git hiccup.

A little more information: In theory the obliquity of the planet can go up to 90 degrees but since I used a pretty tight Gaussian distribution that is very unlikely to happen. Values might need a little more fine-tuning.

(PS: This branch, too, won't pass the tests due to the numpy-changes. Sorry.)

Note: This is the only file that actually changed with this branch: https://github.com/Mindwerks/worldengine/pull/143/files#diff-b429ea1c8c5df481eb3e494cbc283f0cL1

EDIT: I noticed that there is already something like the distance-effect at work - maybe the base value inside temperature.py? These effects could stack or cancel each other, so maybe I need to change something about the code. I could use some guidance for that.

psi29a commented 8 years ago

If this helps... here is my implementation: https://github.com/psi29a/worldsynth/blob/master/library/temperature.py

You can have a look at the videos, mine has a more 'finer grain' heatmap generation that is random. https://www.mindwerks.net/2013/03/worldsynth-0-10-0-released/

tcld commented 8 years ago

I didn't know worldsynth had a proper GUI. (I love Qt! :) ) And a weather map! I guess the merge between the projects isn't quite finished yet?

psi29a commented 8 years ago

Feel free to port/borrow/liberate anything you like into WE from WS. :)

WE's GUI is here: https://github.com/Mindwerks/worldengine-gui

We decided to roll with PyQt5, thus making the GUI GPLv3. We keep the WE (library) separate (and MIT) from the GUI (GPLv3).

This is still very much WIP... doesn't have all the things in it that exist in WS, but that is coming too. Sadly it is the lack of time that prevents much development.

ftomassetti commented 8 years ago

I also think there is great code to be uncovered in WorldSynth. @tcld the historical side is that when we merged the project we started from the code of Lands and we imported several pieces from WorldSynth (e.g., erosion). Then we spent a lot of energies on having tests passing on all platforms, supporting new formats, providing binaries etc.

If I think about that, as maintainers we had to focus on a lot of boring stuff :D In the end we did not spend very much time adding new features

tcld commented 8 years ago

I will look into the temperature-code from worldsynth, if I don't forget it. And maybe into the Qt-stuff, although I have not been missing a UI for worldengine so far. (And even though I have a couple of years of experience with Qt, that was all C++ and a bit of QML, I never touched PyQt. I am not sure how much knowledge transfers over.)

esampson commented 8 years ago

Temperature has a definite influence on the placement of biomes. If you look at the beginning of the temperature.py code you will see a section that identifies a certain percentage of the world as 'polar' (the coldest 12.6%), 'alpine' (the next coldest 10.9%), 'boreal' (the next coldest 16.1%), etc. Hydrology does something similar.

These classifications are then used to identify the biomes according to the Holdridge Lifezone Models image

So depending on how you change the temperature and hydrology maps that will definitely have an influence on how the various biomes are placed. As a side note this is one of the areas that I've wanted to 'parameterize'. This way a person could create a planet and say that none of the planet is polar, the coldest 12% is 'alpine', the next coldest 11% is 'boreal', etc. so that a map for a warmer than Earth normal planet will be generated.

tcld commented 8 years ago

Thanks for the information. I don't like to hear that.^^ If I now generated a planet that was really close to the sun, I wouldn't want to see the "coolest 12%" defined as a polar biome. That stuff should come with temperature- instead of percentage-thresholds. It can still be parameterized externally later, but as an absolute instead of a relative value.

esampson commented 8 years ago

An awful lot of the code uses relative values. To change things like temperature and hydrology to absolute numbers would probably require a major rework of code and while this would have certain advantages I think that by and large the same results can be reached just by allowing people to enter alternate figure for the thresholds. If you want to generate a planet that is hotter you don't need to change the relative values. Just tell the code that the coldest 10% is 'cool' followed by a certain amount of 'warm', 'subtropical', and 'tropical'. You will probably also want to tweak around the hydrology percentages.

Simply altering the temperature of the planet based on proximity to the sun is not a very good model. There are a lot of additional variables such as the atmosphere (both density and composition), amount of vegetation (which influences albedo), and amount of water (which also contributes to albedo both in standing water and clouds and which raises the amount of water vapor in the atmosphere).

esampson commented 8 years ago

One other thing I should add; I''m just talking about how the code is written and about how I suspect it will be a lot of work to alter the code. I'm not really pro or against it if someone wants to do it. The biomes code would probably require almost no modification to keep working. All I would have to do is modify the code so that 'polar' is any area below 1.5 Celsius as opposed to the coldest 12.6%.

ftomassetti commented 8 years ago

I think that relative values are more robust because they permit to have a certain results (e.g., no polar areas or 50% of the world is a polar area) easily and they are easy to understand for the user. I think we have already several factors simulated in WorldEngine and we will have more over time: it is difficult to ensure that different combinations produce realistic worlds while relative values help to achieve that.

psi29a commented 8 years ago

From a scientific point of view, thresholds and exact values are best and was the route I chose when doing WS. Relative values and percentages force a sort of... one world view.

If the planet is too close to the sun, you'll likely have less water/hydrology and more deserts as the temperature is hotter (and unusual weather).

ftomassetti commented 8 years ago

Do we want to merge this one or has it been superseded? It needs to be rebased

tcld commented 8 years ago

I will come back to it once all the other stuff is in. The rebase can happen after @esampson 's code is in, my changes are quite small after all.

ftomassetti commented 8 years ago

Ok, so now the next PR to merge is #157, right?

tcld commented 8 years ago

157 needs to be rebased first, it will certainly introduce some merge conflicts. And I added some comments there that should at least be looked at.

161 could technically be merged, if the code was ok.

tcld commented 8 years ago

I rebased this branch and it seems to work. So if somebody has the time to judge the code, it could actually be merged.

ftomassetti commented 8 years ago

Ok, I would merge this. As @esampson said we could consider other parameters later which could influence the temperature but I think this is a good starting point and it has also the benefit of being a parameter easy to understand for many users.