Editing a world map

[waldronate]

It was one of the image results from the images.google.com search "biomes+latitude vs altitude"
https://www.google.com/search?site=&....0.WcQuprYsjtY and shows the classic altitude vs latitude relationship.

I do agree that it's impossible to get a good result without some significant form of climate modeling. A basic climate model needs to take into account axis of rotation and direction of rotation to get the amount and direction of spin on ocean currents and number of poleward cells in the atmospheric Hadley circulation. Then oceanic currents will move the bulk of heat poleward from the equatorial regions (assuming reasonable axis tilt) and exchange heat with the atmosphere. The atmosphere will carry the water evaporated from warmer ocean waters inland on winds (the clouds formed will, of course, reflect sunlight, cooling the planet). Continental size will also determine climatology because water will last only so long in a parcel of air. Huge continents tend to be very dry in the middle. And there are lots of other little considerations in there as well, such as the hard-to-model narrow coastal currents like the Gulf Stream that don't appear at all on coarse simulations. It's a very dynamic set of processes and I've studied them a fair amount over the years. I haven't found one that works well enough for the computational cost yet.

While it is true that average temperature can be very approximately modeled by cos(lat)+b-k*h, it's an insufficient model to work with the processes above because the amount of seasonal heating on land compared to sea is critical. Land heats more strongly than sea, which accounts for things like summer monsoons that pull clouds far inland of where they might otherwise go. Without modeling the variations due to axial tilt (and to orbital parameters and solar variability to some extent), the planet doesn't have seasons. It's the seasonable variability of rainfall vs temperature that's critical to biome models like the Koppen climate classification, if I recall correctly.

FT opted for the simplest thing that could give a user a place to start from to edit in the climate that they wanted. Too many people seem to believe that it's correct, though. Like a lot of FT, it was intended to provide some inspiration, not be physically correct.

[Deadshade]

It was one of the image results from the images.google.com search "biomes+latitude vs altitude"
https://www.google.com/search?site=&....0.WcQuprYsjtY and shows the classic altitude vs latitude relationship.

Yes this one works. A lot of information and some nice pictures. About atmospheric circulation and climate, I already helped a cartographer here with these finer considerations (http://www.cartographersguild.com/re...-advent-2.html)

FT opted for the simplest thing that could give a user a place to start from to edit in the climate that they wanted. Too many people seem to believe that it's correct, though. Like a lot of FT, it was intended to provide some inspiration, not be physically correct.

That's exactly how I see it. I am physicist myself so I don't look for physics in cartography. I did a lot and I mean really a lot of fluid dynamics and it is quite easy in principle - just solve the Navier Stokes equations and you get everything - Gulf streams, clouds, velocity fields , temperatures. In practice they can't unfortunately be solved and numerical schemes work only for very strict conditions on scales, boundaries and initial conditions.
H.Lamb is reputed having said : "I am an old man now, and when I die and go to heaven there are two matters on which I hope for enlightenment. One is quantum electrodynamics, and the other is the turbulent motion of fluids. About the former I am rather optimistic."
I studied both and share his assessment.

That's why the only thing I need here are just 2 independent shaders that can be manually set to paint colors depending on altitudes and latitudes
Btw if you want one day a simple yet rather accurate model of large scale atmospheric circulation (one that doesn't need super computers that can't get it right anyway) or if you are just curious how it works, then I recommend to read : https://dspace.uevora.pt/rdpc/bitstr...%20(IJHMT).pdf . Really not CPU or RAM intensive yet a very good approximation of the dynamics at planetary scales.

Much closer to our interests on this board and same technique applied to construction of river basins : http://home.uevora.pt/~ahr/A.pdf

[waldronate]

The paper on atmospheric dynamics is interesting, as is the river basin one. I'm not sure how useful the river basin paper is in the context of Wilbur and FT, which rely on grid-based systems. It might be more useful in the context of a vector-entity-based system, as might context-sensitive L-system.

[Deadshade]

Now I am really struggling. What I went through before was a breeze compared to shaders. I spent about 1 hour trying to get something reasonable for the colors.

Here is the map I got with only altitude shader activated :


Then I customized the colors for the altitude on ground and for latitudes. Activated both and here is the result :


First is why did the sea turn in this ugly dark color ? Normally activating latitude should only impact land, shouldn't it ?
The polar caps should be pure white and they are a muddy mixture of Brown and grey. Have you any idea why ?

But the impossible task is to get the colors right. Like I said before, the latitude and altitude colors should be treated independently but for the lowest parametrable altitude where the color should be the one of the latitude.
Here even with a very simple shader (3 colors for altitude and 4 for latitude) there are 12 mixtures and 10 weighting couples (taking only values rounded to 0.1) . That makes a total of 120 combinations and it is impossible to predict what color would be where. It is of course impossible to test manually the results by changing either weights or a color in the shader - it would take weeks.
I tried to find a combination that would give white tops for mountains but as you see on the second map, it didn't work everywhere.

Perhaps if there was a slider allowing to define one weight w (the other being 1-w) in the blending tab and it displayed a matrix having in X latitude colors, in Y altitude colors and in the intersection the resulting color, then perhaps some manual adjustment would be wearisome but feasible. However here too an independent coloring concept would be faster, easier and probably giving more realistic results.
There were also parameters like opacity, lightness Min and Max values where I didn't know what the range was and by experimenting didn't unambiguously see how it acted on the colors.

I will now try FT3 to see if a reasonable coloring is more feasible there.

[waldronate]

The blending tab multiplies the result color by the coefficient and then adds the results. If two color results are being blended by 0.5 coefficients, then the result will be result=a*0.5+b*0.5. Wilbur normalizes the sum of the coefficients to 1 as part of a misguided attempt on my part to avoid a clamp step. It does the blending in RGB space, which results in all manner of distortion to the perceived result. More correct, of course, would be to allow for HLS blending instead of RGB as well as allowing for non-normalized coefficients with saturation arithmetic. The ideal solution, of course, would be to implement a full shading tree that takes in primitives like color lists, range masks, surface normal, point position, blending operations and so on to generate the final result.

A general assumption for parameters in the shaders is from 0 to 1 or -1 to +1. Opacity, for example, runs from 0 (transparent) to +1 (opaque) and affects how the shadow intensity applies to the surface. Lightness values run from -1 (fully black) to +1 (fully white). The lightness value is interpolated from Min to Max over the altitude range of the sea depths.

[Deadshade]

Wilbur normalizes the sum of the coefficients to 1 as part of a misguided attempt on my part to avoid a clamp step. It does the blending in RGB space, which results in all manner of distortion to the perceived result.
A general assumption for parameters in the shaders is from 0 to 1 or -1 to +1. Opacity, for example, runs from 0 (transparent) to +1 (opaque) and affects how the shadow intensity applies to the surface. Lightness values run from -1 (fully black) to +1 (fully white). The lightness value is interpolated from Min to Max over the altitude range of the sea depths.

Does that explain why the polar cap is not white even if white is specified and there is no color mixing happening in the polar caps because I set opacity to 1 ?
And why did the sea become dark when I added latitude ? There are no special parameters in the latitude tab.
Just colors and fBm texture so that nothing should be able to modify the sea color. Besides latitude colors apply only to continents so why would there be some color mixing in the sea when its color is specified in altitude tab and showed by the first image above ?

[waldronate]

There is color mixing happening in the polar caps, which converts the white to a medium gray and then blends it with the other active shader. The color shift in the sea is from the same effect as the polar caps. The ice caps portion of the latitude shader occurs on land or sea. The sea latitude color mixed in is RGB(0,0,0)

[Deadshade]

There is color mixing happening in the polar caps, which converts the white to a medium gray and then blends it with the other active shader. The color shift in the sea is from the same effect as the polar caps. The ice caps portion of the latitude shader occurs on land or sea. The sea latitude color mixed in is RGB(0,0,0)

Sorry I didn't understand that.
I set the opacity of the polar cap to 1 (to be sure that nothing shows through) and the color to white. So what gets this white mixed with ? The upper top of the latitude colors (e.g "the ice cap portion of the latitude shader") is white too. Even if it got somehow wrongly mixed despite opacity 1 , it'd do white + white. So that leaves only the sea and this can't be seen because of the opacity . Or so I understood the opacity - as you wrote, opacity = 1 means fully opaque.

Can't understand the sea either. RGB(0,0,0) is black, right ? I have no black in any of the shader. So where would it come from to get mixed with the blue of the sea what I didn't ask for ?

[waldronate]

The basic form of the Wilbur shader is

ColorAlt = RGB(0,0,0)
ColorLat = RGB(0,0,0)
// other shader initialization goes here
if (altitude > sea level)
   if (CoeffAlt > 0)
      // calculate altitude color for land
   endif
   if (CoeffLat > 0)
      // calculate latitude color for land
   endif
   // calculations for other land colors
else
   if (CoeffAlt > 0)
      // calculate altitude color for sea
   endif
   if (CoeffLat > 0)
      // calculate latitude color for sea
   endif
   // calculations for other sea colors
end if

FinalColor = ColorAlt*CoeffAlt + ColorLat*CoeffLat // + contributions from other parts

The default value for a color in the shader is black (RGB(0,0,0)). If a shader computation doesn't create a value, then the default value of black is used. In the case where latitude colors for sea are computed, the non-ice color is left to the default. That's where the black comes from, the default value. In your particular case, the light blue-gray is averaged with the black of the default color and you get a dark color. Because of how the RGB color space works (and your computer's video system hardware and your own eyeballs), there isn't a linear relationship between RGB color and perceived color.

[Deadshade]

The basic form of the Wilbur shader is

ColorAlt = RGB(0,0,0)
ColorLat = RGB(0,0,0)
// other shader initialization goes here
if (altitude > sea level)
   if (CoeffAlt > 0)
      // calculate altitude color for land
   endif
   if (CoeffLat > 0)
      // calculate latitude color for land
   endif
   // calculations for other land colors
else
   if (CoeffAlt > 0)
      // calculate altitude color for sea
   endif
   if (CoeffLat > 0)
      // calculate latitude color for sea
   endif
   // calculations for other sea colors
end if

FinalColor = ColorAlt*CoeffAlt + ColorLat*CoeffLat // + contributions from other parts

The default value for a color in the shader is black (RGB(0,0,0)). If a shader computation doesn't create a value, then the default value of black is used. In the case where latitude colors for sea are computed, the non-ice color is left to the default. That's where the black comes from, the default value. In your particular case, the light blue-gray is averaged with the black of the default color and you get a dark color. Because of how the RGB color space works (and your computer's video system hardware and your own eyeballs), there isn't a linear relationship between RGB color and perceived color.

Thanks even if I am a subzero programmer But if I follow the "ifs" then unless if I severely misunderstood what the ifs do, for the sea it does :

- I don't know what "other shader initialisation" means. I have only 4 - altitude land, altitude sea, latitude land (only) and polar cap. So I assume it is those.
- first if is false so it jumps to else.
- Coefalt is >0 so it takes the alt color for the sea (blue shader)
- Coeflat is >0. So it takes the latitude color (defined only for the land !) and Colorlat becomes equal to the land shader.
- calculation for other sea colors. There are no other sea colors so nothing happens. Note that both for Colorlat and Coloralt the black from initialisation was replaced so there is no black anymore.
- Final color = a x blue + b x whatever land color there is at the latitude.
So in the lines above the black didn't survive and the muddy sea color is just a mixture of blue Coloralt and the greens/browns Colorlat that come from land.
-In any case if what I inferred above is right then this process gives wrong results. The line " if (CoeffLat > 0) // calculate latitude color for sea" should simply be replaced by If Coeflat >0 // "latitude color for sea=transparency" or b=0 (b being defined above) or however one writes that land colors are forbidden to mix with sea colors.

- As for land, the correct line would be : if (CoeffAlt > 0 and Coeflat >0) // If Alt < Biomelimit then Coloralt = Colorlat , Colorlat = Colorlat shader. Followed by // If Alt > Biomelimit then Colorlat = Coloralt , Coloralt = Coloralt shader. Biomelimit is a parameter input in the blending tab and it governs the altitude where the low ground biome stops existing and therefore only the altitude coloring applies. The result is equivalent to have 2 opacity parameters for Alt and Lat land shaders ; 1 below Biomelimit and another above Biomelimit. I treat here the only realistic case where coeflat and coefalt are both non 0. When one of them is 0 then the lines you posted obviously work because there is no mixing.

- I can't see what these lines do for polar caps because the first if depends on their altitude and this one is unknown. If I asume that it is above sea level then Coloralt is the color specified for the polar cap (white) and Colorlat is whatever is in the lat land shader for the highest latitudes (white) So the result should be white + white = white but it isn't. Polar caps color should just be the tautology "Polarcaps color = color specified for polar caps".

What I take from this is that I can exclude the use of Wilbur for coloring tasks if I want to get realistic latitude and altitude colors.
As I said I start trying with FT3 now.