Frozen oceans on satellite map

[tcld]

Here some examples. Based on PR #185, only the last commit is currently relevant.
@pangal Thanks for your awesome work! If you have an idea or just want to do this all yourself, just tell me. :)

Discussion regarding parameters or improved techniques welcome. Here some example images (bigger ones will follow):

Looking at the picture I think I should bring diff_freeze_limit and diff_freeze_chance closer together. Maybe it should even depend on the size of the map.

[ftomassetti]

wow! So much cool stuff is going on in this project!

[j-coppola]

This looks awesome! Thanks for the additions @tcld !

[tcld]

Happy to hear you like it. :)

I am not at all satisfied yet, though. The noise is too much, maybe there should be a modification of the chance-to-freeze depending on how many of the surrounding tiles are frozen/solid.

[tcld]

After a change in the code I found this one:

It is obviously not orbiting its star at a 90-degree angle. =)
That looks better, I think. I'll see how the bigger maps turn out.

[tcld]

And after some "finishing" touches (no worries, these are the last images :P ):

Surrounding tiles are now taken into account and some of the parameters aren't fixed but instead calculated now.
The style of the code is kind of bad, I think. But for a first draft it's good enough. :)

EDIT: The ugly top-border comes from the check for surrounding tiles (since there are no frozen tiles when the iteration starts). Could probably be taken care of with an extra line of code.

[psi29a]

Love the work!

Is the frozen ocean wrapping around to the other side (along the x-axis)?

If not, can we make it so? So that if we wrap around on a cylinder it looks seamless.

[tcld]

No, it isn't wrapping around. How would I do that properly? (I think I saw something like that in temperature.py, right?)

[psi29a]

You can 'cheat' by doing a final pass that blends/blurs the frozen-ocean pixels together.

[tcld]

Wait a moment...if temperature.py actually wraps around (and it does ) then the ice should wrap around automatically since the water freezes wherever the ocean is cold enough.

So I think this problem is not a problem. :P

[tcld]

I checked, it does not nicely wrap. But it's close. (Maybe the fix should happen in temperature.py, though.)

[psi29a]

I suspect you are right, fix that and we fix biomes too. ;)

[j-coppola]

Seems to me like maybe we should have an "icecap" or "ice" biome, which is set at some point earlier in world generation? Conceptually, the draw_satellite function should probably be drawing things that exist in the world's data structure, not necessarily adding new things.

Additionally, certain projects using worldengine may wish to use those tiles as traversable "land" tiles. If the icecaps are set earlier can show up on some of the other map outputs, and it can be saved into the world structure too. That way, in the satellite view map we can just handle the coloring.

Either way, I think the new icecaps look great!

[tcld]

The ice-code could be put into it's own function (somewhere in the simulations-folder) and create a boolean map that is set to True wherever there is frozen ocean. draw_satellite() would then just need to add some color according to the ice-map.

That's probably the better solution since the icy areas shown above are indeed nothing but visual effects.

The code is mostly there, somebody is going to do it. I don't even know how to add variables to the save-files. :P

[esampson]

@psi29a Biomes should already be wrapping properly. The temperature and humidity maps both wrap and they're what determines the biomes. There's no additional noise or random pattern on top of that.

Strangely there were a couple of temperature maps included in this conversation earlier and the first one did not seem to be wrapping around, but I just checked with a temperature map on my system. Were those images cropped? They seem to be at an odd resolution and the first one seems to have the temperature bands shifted. The polar band on the bottom seems very small.

[tcld]

Those temperature-maps were an accident, I dragged in the wrong images.

Maybe I didn't properly handle the orbital-parameter implementation and some of the temperature-maps aren't nicely wrapping? (The orbital parameters are by the way what makes some polar bands really small/large.)

[tcld]

Here are the temperature-maps for the last three worlds (and the generation-parameters...which will probably be useless due to the changes in this PR).

Seed           : 3543
Dimensions     : 960x600
Plates         : 8
Ocean          : 65.00%

Seed           : 15622
Dimensions     : 480x360
Plates         : 13
Ocean          : 65.00%

Seed           : 22638
Dimensions     : 480x360
Plates         : 4
Ocean          : 65.00%

[esampson]

Ah. Ok. You've got code in there that's not in the master. My guess is that that explains why you aren't wrapping properly.

How would orbital parameters shift the equatorial zones? I can see orbital parameters affecting how hot/cold things are and temperature swings throughout the year but unless a planet is tidally locked it seems like each pole spends about half the year pointed to/away from the star (and a tidally locked planet is going to be completely different from what we are seeing).

[tcld]

The zones would slowly shift for a tilted planet; since we aren't simulating time I decided to look at it as if that shift wouldn't be happening. So the "heat-band" moves north and south a little bit, depending on the seed.

The code in here doesn't affect the temperature-map itself, it is mostly about the image-output.

[esampson]

Ah! Yes, they would shift back and forth over the year, but I'm pretty sure our maps are suppose to represent year averages, not current temperatures. Biomes simply don't shift that fast.

[psi29a]

I agree with @esampson

[esampson]

Interesting. This doesn't seem to be wrapping quite properly, either. I wonder if it is because of the 4:3 ratio.

[tcld]

The temperature-maps strangely show very little structure; I didn't notice until @psi29a pointed it out somewhere (much older temperature-maps looked more like the precipitation-maps now). When I first looked at several dozens of WorldEngine-worlds, I only noticed that almost all temperature-maps looked the same - and I wanted to see some variety. The orbital parameters might not be 100% properly simulated but there are some corners to be cut with every part of the simulation. (I much prefer the slightly shifting band.)

@esampson The aspect ratio is an interesting idea.

[tcld]

Here an old temperature-map:
tcld/worldengine-data@f45fe81

I don't know when it was created but the code must have been quite different back then.

[esampson]

Lack of variety is probably because it is tuned to produce a fairly 'real' result. If you look at the temperature.py routine you'll see that there's a variable that weighs between totally random noise and pure latitude/altitude based temperature.

I had forgotten about it and the fact that I wanted to make that a command line parameter as well.

[esampson]

Hmm. Moving to a 2:1 ratio doesn't seem to be fixing it either. Maybe its because it isn't powers of 2? I'll have to look at it in a bit.

[ftomassetti]

Back in the old times temperature maps used to be different my dear...

[tcld]

@esampson: Did you ever find out why the temperature-maps don't always fully wrap?

Once the parent-PRs are polished, I would like to move the ice-cap generation into a new module inside the simulations-folder. That would make it necessary to add a new world-"variable" (a boolean map named maybe ice_map) that can later be drawn by the satellite-method (and maybe made use of by other parts of the simulation). Would that be ok, @ftomassetti / @psi29a ? Or does the use of that kind of map seem too limited to store it with the data? (A change like that would also make it necessary to update the save-routines a bit, including #153 .)

[ftomassetti]

I am in favor of adding the variables: we want WorldEngine to be used as a library and users could take advantage of information about the frozen ocean. Of course many could just ignore it but that is fine.

[tcld]

Ok, I'll add the new variable then. Once #163 and then #185 are out of the way, I'll move the code around and finish this PR. If #153 were to be merged before this PR, I could probably add the new variable to the HDF5-saves myself.

[tcld]

Updated for HDF5.
Data for this PR can be seen here: Mindwerks/worldengine-data#14

PS: Aside from maybe feedback on the used parameters/the algorithm I consider this done.

[tcld]

pyflakes is complaining about a line of code in World_pb2.py, which is generated by Protobuf. Any idea what to do about that aside from manually removing the line? EDIT I removed said line manually.

Also, even though the problems would vanish with new data, the Travis-tests are mostly failing due to a variable having an unknown value. Does that mean that, whenever a variable is added to World, saves will stop to be compatible at all?

[tcld]

Would it be advisable to switch to "proto3"?

[psi29a]

Yes, I've always commented/deleted that one line. It is automatically produced, but never consumed and pyflakes chokes on it.

[psi29a]

Here is the API/docs for proto2 and proto3. Proto3 just extends proto2 and should be backwards compatible.

[tcld]

World.proto has to be changed a bit to make it work for "proto3", I tried. I also found the documentation. ;)
So should I rather use "proto3" or is that something to be left for the future? I assume that the save-files won't be compatible between proto2 and 3 (the result is different according to git).

EDIT: I guess we should stick with proto2, since the data for this PR is already merged (and it is using proto2).^^

[tcld]

@psi29a Could you restart the tests for this, please?

[tcld]

I generated World_pb2.py with Protobuf 3.0, the failed test indicates version 2.6.1. I guess that's a problem, there most likely was no need to use 'syntax="proto2"' in Protobuf 2.

[tcld]

I changed the Protobuf-version for the tests, now everything is fine. :)

[psi29a]

awesome...