Editing a world map

[waldronate]

Your description of how the sphere sampling works is correct. Your observation about moving the center being similar to changing the seed is correct, but you're missing a practical subtlety (or it's irrelevant to the discussion): If you are using the fractal function to describe large features and find shapes that are almost what you want, then you can move the center slightly and the shape/placement of the features will also move slightly. Moving the center can thus be used for fine-tuning the exact shapes displayed, even if the overall character of the noise if the same. Changing the seed will result in a completely different field at that same location. For most uses, though, you are correct in observing that moving the center isn't helpful. In FT, for example, the center and radii controls are disabled by default and the center is instead computed by hashing the world seed and the radii are controlled by the Land Size slider.

[Deadshade]

Your observation about moving the center being similar to changing the seed is correct, but you're missing a practical subtlety (or it's irrelevant to the discussion): If you are using the fractal function to describe large features and find shapes that are almost what you want, then you can move the center slightly and the shape/placement of the features will also move slightly. .

Actually I didn't quite miss that
In the early days I dreamed that by running random worlds, I would find a mountain configuration that would look similar to what I want. However the probability among billions of possibilities is negligibly small. It might be useful if I have just one or 2 very important features (indeed rather large) that I would want to approximate. But as soon as there are several, I could get by chance probably only 1 so that it is not worth the bother.
At least for what are my needs right now.
If one does a map which has a big flexibility in the location of mountains or big gulfs etc, I would probably try to run a dozen of seeds to see if I get something worth copying.

Ok so I think that I know now enough about coasts, oceans and mountains and it's time to do some eroding and river creating.
I already know that I will run in the similar kind of difficulties e.g I have to force at least 2 of the most important rivers in the right direction.
I already tried to just lower the terrain starting at a mountain range and going in the right general direction. This semi works but to get a wiggly river I had to do it on a pretty large surface and it shows (cliffs, too flat etc). Especially because I have to redo it at every step because otherwise sometimes appear unwanted rivers benefitting form the Lowlands I didn't intend for them.
I am sure that this is a very savage and primitive method and you may orient me on a finer path to knowledge.

Of course I also must not erode the mountains too much. Btw I tried the erosion cycle and it runs for ages and creates too deep canyons.
I also noticed that using hetero terrain with H below 1 can create passable foothills.

[su_liam]

Interestingly, a lot of proprietary apps don't even allow re-seeding of fractals. Bryce is an ancient example. Resetting the seed is a bit of a PITA. Especially with '90s hardware. Even with faster hardware, I'm not always sure it's done right. How much thought did peeling put into the original array of 256 values which, I randomly rearranged in my implementation of Perlin Simplex for PlanetGenesis? I dunno, but it looks… okay, so I can happily wallow in my ignorance. Not entirely sure that isn't causing problems, though.

Waldronate's impl may be better thought out,but that does require programmer think time and maybe program cycles.

Displacing the center of the evaluation surface is a lightweight way of changing the details of the rendered noise without altering the overall character. Also without altering that nasty array.

[Deadshade]

Waldronate's impl may be better thought out,but that does require programmer think time and maybe program cycles.

Displacing the center of the evaluation surface is a lightweight way of changing the details of the rendered noise without altering the overall character. Also without altering that nasty array.

Well Waldronate's implementation is certainly good for a user I am. Rerunning the height field calculation with the same seed and a translated sphere center or with a different seed without moving the center takes apparently about the same time and is pretty fast.
Also I never noticed any apparent problems or glitches connected with reseeding.

[waldronate]

Programs that use the literal implementation of Perlin's noise often bake the permutation table into the code ( http://mrl.nyu.edu/~perlin/noise/ is the reference implementation ). Keeping the table constant this way ensures that there won't be an implementation detail relating to different implementations of the system random noise generator and that the noise function will be constant across machines and operating systems. For those systems, a new world is a matter of selecting new coordinates on the 0 to 255 cube. Implementations like Wilbur (and FT) that instead create the permutation table at run-time can add that extra degree of freedom that generates a new cube of noise for each seed. This technique has the potential to make things a bit less robust across implementations, but that's not a concern for Wilbur. There's a higher startup cost to generate the permutation table dynamically (a few thousand calls to rand() and associated memory swaps), but there is no additional runtime cost.

It's also possible to use an image as the noise input. The character of the noise can therefore be based, for example, on a picture of a child or even the kitchen sink. Unfortunately, most pictures that are interesting to people are uninteresting as a noise function. However, a small 2D texture can make a very fast fractal function when run on the GPU because the system has nice hardware to interpolate on that texture.

One way to force river directions in Wilbur is to (surprise) use a mask that gets loaded as a selection. Basically, select the area along the river network, feather the selection, and then use the Gradient tool with Type=Linear, Blending=Linear, Operation=Add, Low Value=0 and High Value=-100 (or whatever is an appropriate drop). The Low Value is the value at the start of the gradient and the High Value is the value at the end of the stroke. With Low=0 and High=-100, stroke from the highlands toward the river mouth. You can get an effect that won't drop below sea level by using Operation=Multiply, Low Value=1.0 and High Value=0 ; this technique will scale the terrain from its initial altitude at the start of the gradient down to 0 (presumably sea level) at the end of the stroke.

[Deadshade]

One way to force river directions in Wilbur is to (surprise) use a mask that gets loaded as a selection. Basically, select the area along the river network, feather the selection, and then use the Gradient tool with Type=Linear, Blending=Linear, Operation=Add, Low Value=0 and High Value=-100 (or whatever is an appropriate drop). The Low Value is the value at the start of the gradient and the High Value is the value at the end of the stroke. With Low=0 and High=-100, stroke from the highlands toward the river mouth. You can get an effect that won't drop below sea level by using Operation=Multiply, Low Value=1.0 and High Value=0 ; this technique will scale the terrain from its initial altitude at the start of the gradient down to 0 (presumably sea level) at the end of the stroke.

Hehe isn't it nice ? I never saw the gradient function. So as I slowly work through my map towards the end I learn more and more new functions (there are still many I have not even opened especially in the texture tab).

Yesterday I spent 2 hours with the shaders (only the V2) and I must say that it was not conclusive. Here are the comments and problems only related to V2 :

- The color bar on the left in the shader setup is inverted. Topmost color is on South pole and bottom is North pole. This wreaked havoc when I edited the colors before I noticed the problem.
- Even if the values make believe that every color takes the same latitude fraction it doesn't seem to do so (changing offset doesn't make the fractions identical either)
- The fraction of colors shown by the left bar is not the fraction of colors on the continent. For instance it may show a sliver of white on one end yet the white will take 1/3 of the map.
- The fractions on the bar are modified by gamma but I couldn't understand what it modifies on the planet because of the point above. It seems to just contract/expand the central parts while leaving the top/bottom bands unchanged.
- Basically whatever I did, the top and bottom bands (polar areas) were staying absolutely huge. If I changed offset to reduce one polar end, then the other increased and vice versa.

- The altitude coloring was the worst problem. Apparently the shader uses the latitude shader to color mountains. The principle is that as the altitude increases, the color changes from the native latitude color to the color immediately below in the color band.
As "below" means "to the North" because of the inversion already mentionned, a mountain will be colored at the basis with the latitude color (say green jungle for equator color) and at the top yellow desert (because North of jungle band is desert band).
Much worse is a mountain in the southern desert band (around the tropics) which will be colored with lush green at the top because the jungle band is just North of it.
Also when one duplicates a color (to make a band larger) the mountains in his band will be colored with the same color for all altitudes because the band just North of it has the same color.
So when I created a realistic symmetrical color scheme polar->tundra->temperate->desert->jungle-(equator)-jungle->desert->temperate etc, the result made no sense especially in the southern hemisphere.

I think that if you return to Wilbur one day and supposing that the Wilbur shader doesn't already solve that, I would suggest the following improvements to V2 :

1) Make the values (size of the latitude band) editable.
2) Inverse the color band in the edit shader so that north is on top and make it show the relative fractions that will be identical to what will be applied to the planet.
3) The altitude coloring should be disconnected from latitude colors BUT for the basis. It could work like that :
- up to altitude X (editable) the color is the color of the latitude band (jungle for jungle, desert for desert etc). This already exists more or less with the altitude parameter.
- above X is used an altitude shader which is identical for all latitudes. Indeed all mountains have a very similar coloring independent of latitude - a mix of Brown, yellow , grey and white on the top. Of course a mountain in Sahara is not quite the same as a mountain in the Alps. It would be ideal to have an altitude shader for every latitude color but this is a compromise.

I thought that something like this (point 3) could be achieved with the Wilbur Shader because there appear independent latitude and altitude colors but while the altitudes are apparently colored with the altitude bar, I couldn't make the latitude colors work regardless of what I edited. So I don't exclude that some of the above problems are on my end and that I can solve most of it with the Wilbur shader once I know how to make the latitude color tab work.

[waldronate]

The color list editor in Wilbur is an example of a leaky abstraction. It's more or less a direct manipulator on the underlying code, which is less than helpful for most users. The first entry in the list shows up at the first pixel location (pixels are numbered starting at the top by convention on Windows). The last entry shows up at the last pixel location (therefore the bottom). One way to look at it is that the colors on the pixel image go in the same order as the ones on the text list. Most of the gradient editors out there that I've seen tend to have the color list placed horizontally; perhaps this sort of setup is easier for users to handle.

The V2 implementation is a compromise using a single color list. A better solution would be, as you have suggested, to have a 2D image indexed by one parameter such as latitude in one direction and another parameter such as altitude in the other. In FT, there is an "Image Climate" shader that takes in an image and uses one axis on the image as temperature and the other as rainfall. The color at the intersection is used as the basic color for shading. It has a few minor implementation details like point sampling, but it's not too bad otherwise. FT uses rainfall vs temperature because both latitude and altitude are primarily temperature drivers. In the Wilbur V2 shader, what's being displayed is basically a colored temperature map. It's a somewhat visually plausible approximation for climate, but it's missing that whole rainfall thing; Wilbur can't maintain more than one map in memory at a time, so all of that will need to wait until I get layers done in Wilbur.

The biggest problem with the Wilbur Shader is that the results of all of the tabs shown on the Blending tab are a linear RGB blend. This sort of blend tends to be a bit muddy. The V2 shader uses the result of its computation (from 0 to 1) as an index into the color list. A similar result in the Wilbur shader using the Latitude tab, the Altitude tab, and the Blending tab with 0.5 in each of the Latitude and Altitude fields looks quite a bit different.

The latitude tab uses the Map Info to calculate its result. It divides the absolute value of latitude by 90 and then adds an fBm disturbance to that result before using it as an index into the color list. The ice caps parts are defined in the 0 to 1 parameter space for programmer convenience. The ice cap color comes out as a dark color due to the blending implementation. Allowing use of blending modes other than simple scale and sum (or allowing blending coefficients to sum to something other than 1) would probably allow better results.

[Deadshade]

Most of the gradient editors out there that I've seen tend to have the color list placed horizontally; perhaps this sort of setup is easier for users to handle.

Well the easiest for a planet/continent size is a vertical bar that has north at the top and South at the bottom. That way what I see on the bar is what I will see on the planet. V2 is inverted.
Besides the biggest improvement would be if one could edit the latitude band width value. With only this I would of course still get all mountains wrong but 90% of the surface would be correct (especially with the noise button).

FT uses rainfall vs temperature because both latitude and altitude are primarily temperature drivers. In the Wilbur V2 shader, what's being displayed is basically a colored temperature map. It's a somewhat visually plausible approximation for climate, but it's missing that whole rainfall thing

I am familiar with the FT climate map and the coloring that uses the 2 dimensions. I already tried it but the problem is that altitude isn't handled well either.
And no, temperature is not a good proxy for altitude - that's the whole problem with mountains. While altitude and latitude do drive temperatures, they don't drive it in an identical way.
The lapse rate is something like 6°C/km so if you have a 3 km tall mountain in Saudi Arabia, it will have some 20°C at top (hot and dry). The same mountain in the Alps will be on the top below 0 (cold, snowy and wet).
The problem gets more severe at the altitude where one crosses 0°C because above it's only white anyway regardless of the place on the planet where the mountain is.
That's why any even semirealistic altitude coloring needs to color independently from the latitude coloring. FT does reasonably well for sea level (e.g low altitudes) colors but can't do altitudes either - it would do so only if it used the lapse rate which is luckily constant for a whole planet but it doesn't.

The biggest problem with the Wilbur Shader is that the results of all of the tabs shown on the Blending tab are a linear RGB blend. .

OK that allowed me to understand what I missed ! The blending tab
As I didn't know what it was, I didn't look in there. As altitude is 0 in default, it is not surprising that I saw no efefcts when I was editing the altitude tab.
So I will come back to Wilbur shader and see if I can get something reasonable.
If it fails, I'll go to my first idea which was to just use V2 to get a rough latitude sea level coloring and then go to GIMP where I will import the mountain mask and do the mountains and push the temperate regions farther North and South (to reduce the too big polar areas) by hand.
At least I am sure that this will work even if it will take probably much time.

[waldronate]

http://ohs-bio.www1.50megs.com/ch47/...20Zonation.jpg is an example of how latitude and altitude work together to get biome effects. The image is notional, but it's approximately what FT does (FT uses the earth lapse rate for altitude) and a user-specified variance of temperature from equator to pole plus a bit of noise to make it look more plausible. For correctness, it would need to include airflow and sea-land heat exchange.

[Deadshade]

http://ohs-bio.www1.50megs.com/ch47/...20Zonation.jpg is an example of how latitude and altitude work together to get biome effects. The image is notional, but it's approximately what FT does (FT uses the earth lapse rate for altitude) and a user-specified variance of temperature from equator to pole plus a bit of noise to make it look more plausible. For correctness, it would need to include airflow and sea-land heat exchange.

It says "Remote linking forbidden".

Temperature is easy, it takes just one line : T = a.cos(lat) + b - 6.h (h in km) and it is defined all over the planet. Actually it is very accurate for yearly averages.
But biomes (so colors) depend primarily on precipitation and average seasonal temperature min/max and not on yearly average temperatures.

Precipitation is horribly complicated because it is a dynamical question. Even sea atmosphere coupled atmospheric models that run on supercomputers get yearly precipitation wrong, often by large factors
Actually precipitation is not a good variable - the metrics of potential precipitation is "cumulative volume of water saturated air over a surface in a year".
But because it is potential, it is not sufficient - the air may be saturated yet it doesn't rain.

The necessary and sufficient condition is a decrease of temperature.
This can happen in basically 2 ways. Either air rises along a mountain (adiabatic expansion) and then it rains on one side and never on the other side. So the metrics above may give the precipitation amount on mountains.
For example Cap Verde mountains show that remarkably - desertic at the bottom but green average Alp like biome on top. You literally see how the water is condensing when Wind is going over the tops.

Or saturated air meets colder air what happens all the time along fronts.
Unfortunately front formation is a dynamical local process so that it can't be simulated globally. No easy global formula like for temperature. I could write a very approximative statistical realistic model but it would depend on the distance of a point to oceans and dominating averaged air flows and that would be beyond the purpose of these discussions anyway.

That's why I said that the impact of altitude on color cannot be done (semi realistically) unless one tackles the problems above (and this is also true for temperatures because what one needs is the seasonal average of min/max)
So the simplest way would be to have just a shader that allows to color with 2 dimensions relative to lattitude and altitude and adjust both manually