Question about climates
jbclaypool
Newcomer
I assume that the rainfall amounts are annual amounts. But what does the temperature represent? Average temp, min, max?
Comments
Are you talking about FT3+?
The climate types in FT are based on annual averages. FT calculates rainfall and temperature at 4 points in the orbit and generates an average from those values. It then adds any editing values from the appropriate channel and uses the final average rainfall and temperature as indices for a two-dimensional table of climate types.
FT3+, yes. I looked through various posts on climate on the forum and didn't find anything specific. I knew that FT3 uses a kind of Whittaker table for climates/biomes, but wasn't sure if the temperatures were annual averages or something else.
Appreciate the help as always.
Is it possible to reset the climates to what they would have been before various paint temps, rainfall, etc.? In other words to the original climates there were immediately after a simple create?
Killing climates painted with the climate painting tools (not the image overlay painting for Simple Create, which is something else entirely) involves use of the "No" climate type from the toolbar and a suitable climate painting tool. To reset the temperature and rainfall to their default values, set the rainfall and temperature values to "0" using either a global set or paintbrush, which eliminates the user-defined contribution to the climate model.
Another climate question...or two. 😉 I ran a simple create which included some climates: deserts, boreal forests, temperate forests, etc. There were three deserts--only one came through. Ok, I used the paint climate tool to do it under the tool menu. However, painting the desert only changes to labeled climate to desert, the rainfall amounts remain high. Another anomaly was the creation of tropical shrublands and temperate grasslands in the far north and others as well. Also noticed weird thin line climates on the map. So I reran the simple create: the desert I painted using Tool: Paint Climate was now there, but it still was not a real desert climate--rainfall was 30"+ a year.
This file has been through numerous edits including climate paints and temp/rain raises and lowers. It seems like there is a persistent record that remains despite running simple create.
Any ideas?
Below is what the simple create overlay looks like.
FT's climate painting purely sets the value of climate evaluation: it does not perform goal-seeking to try to force the climate parameters to a state that would generate the appropriate climate. Similarly, Simple Create mode uses the painted climate value only as input to the altitude generation phase and doesn't do goal-seeking. You may have noticed that there are climate types that don't appear in FT's climate table (a chopped Whittaker biome diagram) such as hills and mountains: these types feed into Simple Create's altitude computations. The long-term goal is to have FT do the sort of goal-seeking for climates that you're looking for. I'm also hoping to get FT to generate symbol fields both onscreen and in CC3+ exports because those other climate types would look good as symbol types as well as just altitude cues.
Ok. I'm using Paint Values to set rainfall, temp, and altitude values to correct issues on the maps. The problem I'm having is that setting the values produces unpredictable results. Paint Values: Altitude Offset set to -2000 to correct coastline issues more or less works, mostly, but if I set it to -1000 it actually produces land. Rainfall and temp I have to try to guess what values will actually produce the values I want. For instance, setting temp to 50 F will result in roughly 37F, but 45 F will result in say 24 F, while setting to 60F may actually result in 90 F. Rainfall has similar erratic behavior. Trying Paint Raise or Lower is even more erratic.
Am I wrong that if I use Paint Value (Temperature 37F) then it should paint 37F wherever the brush hits the map?
The Paint Value things mostly paint into the user adjustment channel of the appropriate calculation. For example, temperature is calculated by insolation (affected by Axial Tilt) added to the base temperature (computed from Albedo, Light, and Greenhouse or specified directly) modified by a random amount, and adjusted for altitude (increasing altitude decreases temperature). Finally, the editing offset is added (this is what you paint when you paint temperature). If you paint a value or use global set, the editing channel is set to that value in the painted/selected area. That's not the value you specified, it's the final offset to the average temperature in the affected editing cells (one of the reasons that users don't get to see seasonal variations of temperature and rainfall is that such things would then require per-season editing, which wasn't reasonable given the original system constraints).
Raise and Lower also only affect the appropriate editing offset channel. Every stroke raises or lowers the editing value by the specified amount. If you keep painting in the same area, the value will change by that amount. For example, specifying a temperature of 10 with a Paint Raise tool will raise the temperature by 10 degrees every time you stroke over the area. Many times, it's more reasonable to make a selection, feather it, and do a Global Raise to raise temperatures uniformly over the area than it is to paint weird jumps with the painting tool. Another example would be painting an editing value of -1000 into areas where the land is above 1000: the painted final result will still be above sea level because the net result is still positive
There are, of course, exceptions to the basic "high-resolution procedural model + low resolution painted image" used for most of the basic quantities in FT. For example, painting Climate values completely replaces the calculated information rather than providing an offset (it doesn't really have a physical meaning to change climate from ice into tropical forest because you set a value of 1 somewhere). Global Set has some goal-seekers (the ones without "Edit" in the menu item name), but they have a tendency to fight with the procedural content. Global Set>>Altitude Value, for example, usually results in a pretty roughly area because the fractal function is sampled at a different rate from the user-defined editing values, causing things to go up and down over any single editing cell.