Editing a world map

[Deadshade]

I checked with the fill mound command. Nothing works. Both max and add destroy the previously created chain. So unless there is something more I don't understand, this command can create only 1 chain per map but not more.

But I add this post because I have now a really lethal problem which affects all my Learning efforts.
I can no more select with the freehand tool (lasso) in Wilbur. When I left click and draw, after 1 or 2 seconds the selection finishes all by itself and closes the curve by drawing a straight line to the initial point.
Even if I don't move, just left click, move 1 mm and wait, it finishes after 1-2 second. The selection by square works normally.

I checked if it was not a mouse problem and replaced my Wireless mouse by a wired usb mouse. Same result. Can't draw sélections anymore.
Have you any idea what that is and how to cure that ?

Also here is what I see in my histogram after creating just the mountain that can be seen with an add max 2000 (so the world is flat everywhere but on this small place)
As you see the highest point is several trillions high ....


Is it possible that my Wilbur suddenly became rotten ?

[waldronate]

The mystery closing freehand tool is something I used to get back when my old mouse was going a little crazy in the left mouse button. I'm a couple of rodents down the road from that point, though. I was wondering if it might be the 50% view zoom, but my version here also works at that zoom. I expect that you've tried a restart.

One possible reason for the very large values is if the operation is set to divide rather than add and your surface is at a very small value. Note that if you already have those very large values on the map and try an add or max operation that is one-trillionth of the overall terrain height, then you won't be able to see the second operation at all. One thing that you might try is height clip with a max of 3000 or so and see if that bring back the secondary mountain parts.

You might try reinstalling, but be sure to delete the HKEY_CURRENT_USER\Software\Slayton Software\Wilbur when the software is uninstalled to ensure that you get a clean reinstallation.

[waldronate]

It seems that the fractal things are to blame here. There seems to be a scaling problem - It's off by a factor of 10ish at first and gets worse with each successive operation. Try setting a min and max of 0 and 1 followed by Filter>>Fill>>Set Value and an operation of Multiply to scale the selection to you desired height. If I get some time, I'll look into the problem. I don't recall it having this problem in the past, but it seems to have crept in during the last few dozen iterations since I used that feature.

[Deadshade]

The mystery closing freehand tool is something I used to get back when my old mouse was going a little crazy in the left mouse button. I'm a couple of rodents down the road from that point, though. I was wondering if it might be the 50% view zoom, but my version here also works at that zoom. I expect that you've tried a restart.

One possible reason for the very large values is if the operation is set to divide rather than add and your surface is at a very small value. Note that if you already have those very large values on the map and try an add or max operation that is one-trillionth of the overall terrain height, then you won't be able to see the second operation at all. One thing that you might try is height clip with a max of 3000 or so and see if that bring back the secondary mountain parts.

.

I am glad that I am not alone with the LM click. Not sure that the mouse is to be blamed because I tested 2 different, both with the same result as the original Wireless. So it didn't seem to depend on a particular mouse.
However as I shut the computer yesterday, when I restarted today the lasso works again (with the original Wireless).
So let's chalk it up on one of the impenetrable mysteries happening Inside a computer.

For the trillions high mountains I started with a completely flat world (ground on 200 and oceans at -1) and the histogram was showing exactly that . As my purpose was to experiment with the fill mound, the only thing I was doing was to make a selection filling a mound in add mode then redo the same with other settings. All attempts with fractal enabled. As I wanted to understand how to keep the previous mountain when doing the next one, I did nothing else and did this I don't know 10 + times.
Then I checked the histogram and saw what I show in the SS. So I neither used divide nor had a very small (or big) value somewhere. You can also look that despite fractal enabled, my mountain looks completely smooth and in no way similar to the very irregular look you obtain in your example above.

I did only a single operation right now (add min 0 max 1000 noise 0, fractal enabled) and got a crazy Spectrum with everything flat at 200 as expected but the mountain is an almost perfect Planck curve (black body radiation) with maximum frequency around 130 000 and the right tail (max height) at 590 000. The height clip cuts the mountain to just a plateau 3 000 high and the histogram confirms that.
When I do the same thing but fractal disabled, I get a normal result and the heights are correct.
So clearly there is something in the fractal parameters that I didn't dare to tamper with that completely destroys the height distribution.

Yet I would really like to obtain the look that you show above when "Poof. Instant mountain range" - your mountains really look mountain like.
Can you advice on the fractal parameter setting you used to obtain that ragged look ?

EDIT :
With my limited experience I am now able to give feedback about how I feel the different features in Wilbur (and FT3).
- Rivers and canyons. Powerful, realistic and extremely useful.

- Mountain ranges. Nice only when the random generation feature is used. When I try to set mountains where I want them, the results are disappointing and I can't emulate the realistic look that one gets when the world is generated randomly. The fill>mound feature seemed promising but it creates only 1 range and there are the problems mentionned above. I have to focus only on that in my Learning now because at the planet/continental scales it is mandatory that mountain ranges look realistic.

- Lakes. A big weakness. Lakes seem forbidden unless they are at sea level. Yet Bajkal and Aral are important features of the Earth on planetary scale.

- Coloring. A problem in Wilbur because the dependence can be on latitude and altitude only. FT3 can manage that better with the climatic zones but the gradient editing could be more user friendly. An FT3 with gradient management à la GIMP would be an almost perfection.

- Coast line. Like mountains ranges, perfect when the random generator is used. If one has already an idea where the continents are and how they look (what is mostly the case) then there is a sore lack of a simple fractal 2D generator. Going around it and yet getting a true fractal coast cost me 1 week of juggling with Autorealm, GIMP and Wilbur. OK I am a newbie but even an expert would spend proportionally too much time.

Of course the above is in no means a criticism of Wilbur as it is inesperately good for a hobby result that can be used free . I would not say the same for FT3 which is a commercial software. FT3 should certainly improve these features to be able to cover not only random worlds but also editing of existing worlds with an equivalent quality.
Btw I apologize for making you loose your time with some questions - I discovered only now part of the Wilbur documentation on your site - I have downloaded most of it but the one that was labelled "very old" I never looked at because I supposed that it was ... er ... very old so probably irrelevant to the Version I had

Perhaps you could change the wording on your site to "Very old yet comprehensive description of the functionalities. Still applies to 90% + of the current version" (I made up the %tage)

[waldronate]

The fractal parameter item on the mound operation seems to horrible and inconsistent things (it look also like it's multiplying by an accumulated factor of previous fractal parameters, which is not at all what it should be doing). I don't recommend using it at this time. If you set the min to 0 and the max to 1, then it seems to be reasonably well behaved and you can use Filter>>Fill>>Set Value with Multiply and a constant on you selection to get a better height. Not the desired functionality and I can't see anything in the code that would be causing it. It worked once upon a time, though.

It's possible to use the basic mound (no fractal parameters) and follow that with Filter>>Noise>>Fractal Noise using Operation=Multiply and Amplitude=1 to modify the basic mound. You might want to set the XY scales values to 5 and 5 to get the fractal parts a little rougher. The mound is likely to have reduced the maximum height, so Filter>>Mathematical>>Span with low=0 and high=your desired max value should bring things back to the desired range.

You can use an external program such as The GIMP to make a mask for where you want the mountains of a particular height to go and then load that mask as a selection and use mound with fractal parameters on it. Or you can use the mound*fractal process described above.

http://www.cartographersguild.com/ma...rial-lake.html shows an example of how to get lakes in Wilbur.

As far as coastlines go,
http://www.cartographersguild.com/ma...-wilburia.html
http://www.cartographersguild.com/ma...-megatoad.html
http://www.cartographersguild.com/ma...geometria.html
all suggest that it's not too hard to get a reasonable coastline from a mask (I'm too lazy to spend more than an hour on the basic processing.

FT3 and Wilbur share a whole lot of code. However, FT is a good 17 years and three versions from its origins. A lot of things that I know how to do now don't fit effectively into the FT framework without breaking existing things overmuch. The harder that I work to add more feature to FT, the stranger the UI becomes, unfortunately. I've toyed on and off with abandoning it and starting over, but I just don't have a lot of time for even the projects that I have. What Wilbur would really benefit from is the notion of layers. FT has some fixed-function layers (rainfall, temperature, offset, roughness), but a general framework with shaders to transfer from the layers to the visible representation would be ideal. However, FT suffers from a serious problem in that I need to support users with older operating systems and hardware. I still have to support Windows XP, for example, which limits the compilers and libraries that I can use. The same is true of older hardware (OpenCL support, for example, tends not to support very old processors like the Pentium 4).

Don't worry too much about asking questions that might be in the manual. One of the reasons that I try to answer questions at length in a public forum is so that this information might be of use to others as well as being searchable notes for me if I ever get time to redo documentation. One of these years I'll get around to chopping up the existing documentation for use as help files. I did that external html-file help, but never got around to generating content...

[Deadshade]

The fractal parameter item on the mound operation seems to horrible and inconsistent things (it look also like it's multiplying by an accumulated factor of previous fractal parameters, which is not at all what it should be doing). I don't recommend using it at this time. If you set the min to 0 and the max to 1, then it seems to be reasonably well behaved and you can use Filter>>Fill>>Set Value with Multiply and a constant on you selection to get a better height. Not the desired functionality and I can't see anything in the code that would be causing it. It worked once upon a time, though.

Yes it MAY be cumulating (or not resetting) something. And no it is not the primary cause and perhaps not even a cause at all. I did the following :
1) Left Wilbur and started it new so that everything's reset
2) Opened the master .mdr file (flat world with all land at 200), made a selection
3) Fill>Mound with modes add, replace (min 0 max 1000), multiply (min 0 max 5) and fractal enabled
4) Noted the histogram . Go to 1)

In all cases the mountain had the same histogram at better than 1% with max height around 530 000. Multiply was smallest with 525 000 and replace the Highest with 536 000.
So clearly the fill>mound command was doing exactly the same wrong thing regardless of the mode already at the first use. The "off factor" of about 530 exists independently of the mode.
I also wanted to check the sensibility on the fractal setting and changed H (I guess it's the Hurst coefficient) from the default 1 to 3.
The result was a similar histogram but with max height of 394 000. So the fractal parameters have a (small) influence on the "off factor".
To check the dependence on the fractal type, I used fBm. The result was max = 216 000. Again the same order of magnitude.
So whatever does the formula generating the height map, it includes a wrong systematical scale factor that is independent of the mode and probably largely independent of the fractal type and its settings. So the bug must be located in a part that is common to all calculations.

It's possible to use the basic mound (no fractal parameters) and follow that with Filter>>Noise>>Fractal Noise using Operation=Multiply and Amplitude=1 to modify the basic mound. You might want to set the XY scales values to 5 and 5 to get the fractal parts a little rougher. The mound is likely to have reduced the maximum height, so Filter>>Mathematical>>Span with low=0 and high=your desired max value should bring things back to the desired range.

Yes this is the kind of things I was doing on my previous map and contemplated to stay with it. I also included some erosions in the mix.

FT3 and Wilbur share a whole lot of code. However, FT is a good 17 years and three versions from its origins. A lot of things that I know how to do now don't fit effectively into the FT framework without breaking existing things overmuch. The harder that I work to add more feature to FT, the stranger the UI becomes, unfortunately. I've toyed on and off with abandoning it and starting over, but I just don't have a lot of time for even the projects that I have. What Wilbur would really benefit from is the notion of layers. FT has some fixed-function layers (rainfall, temperature, offset, roughness), but a general framework with shaders to transfer from the layers to the visible representation would be ideal. However, FT suffers from a serious problem in that I need to support users with older operating systems and hardware. I still have to support Windows XP, for example, which limits the compilers and libraries that I can use. The same is true of older hardware (OpenCL support, for example, tends not to support very old processors like the Pentium 4).

God I feel with you ! Windows XP ? Is somebody still using that ? Or Pentium based machines ? I'd think that making a poll among existing purchasers of FT would allow you to reduce the hardware/OS span to only a few of cases not older than 5 years (I say 5 because 5 is the upper end of the average life expectancy of a computer system). As your customers probably belong to hardcore computer users (e.g Paintshop afficionados) it's likely that the 5 is rather more like 3. As for Wilbur, you are the only master on the board so you can easily unilaterally decide that older than OS X and CPU Y is no more compatible with Wilbur.

On another note as problems never stop, I have now a new one that I already mentionned on the Profantasy boards. And this one is lethal.
I am no more able to correctly transfer a file from Wilbur to FT and edit it there.
I followed your method "There and back again" and the result is that :

Almost everything is wrong here. This color doesn't exist in FT3. Notice the rainbow like Spectrum on the coastline boundary. Weirder still - the small globe in the FT UI is showing the right FT colors (dark blue for océans and green for continents).
The relief looks wrong too - one would think the continents are below the sea even if checking the heights FT shows correctly that continents are 200 and see 0.
And the worst is that the colors can't be changed - the color lighting tab doesn't work and if I create mountains etc , they still stay in this purple/rainbow colors.

Can you tell me what does that mean and how to cure it ?

EDIT :
I did 2 more interesting tests on the fill mound.
- changing seed changes almost nothing. Same Spectrum, same max at 500 000 and some.
- using plasma type. This type uses only 2 parameters that don't recover with the other tests. Here the impact was huge. The Spectrum was quite different and the max was around 41 000 000.
So this bug or whatever it is appears most clearly in the plasma mode.

[waldronate]

About a quarter of the Windows market is still Windows XP. It sucks, but that's the way it is. And those machines are unlikely to be high-end modern hardware. I made the decision to dump anything without SSE2 support a while back for Wilbur and I'm considering moving that bar up to SSE4.1 or possibly AVX to be able to take advantage of some of the auto-parallelizing and auto-vectorizing features found in modern compilers. I can get the same or better effects by rewriting chunks of the code while still supporting older systems, but that takes time; throwing a compiler switch and getting instant gratification without a lot of work is a whole lot easier.

FT needs to stick with support for older hardware for a while yet. There was a fellow who was publically incensed when I dropped support for his beloved Pentium III, and it's unfortunately the loud, in-public types that tend to have a disproportionate effect on product perception.

The color image that you showed is what I would expect from FT's Normal Map shader (Map>>Show Normal Map). In this case, "normal" isn't "typical", but is rather defined in the computer graphics sense of the outward-facing vector of the sphere adjusted for local altitude differences. The XYZ values of the normal vector are encoded into the RGB channels of the image; the predominantly blue tones are due to the mostly-out nature of the vectors (large up component mapping onto large blue component). This sort of map is useful when placing an FT world into 3D rendering software as it can be used to apply the texture of the topography to a 3D sphere as lighting (bump mapping).

Please select Map>>Show Altitude to show the altitude map that you've become familiar with.

I'm not sure when I'll get back to work on Wilbur or FT for any stretch of time. There is a 6 week-old baby in the house at the moment and my free time is taken up that and with trying to get the CC3+ update out the door for ProFantasy.

[Deadshade]

The color image that you showed is what I would expect from FT's Normal Map shader (Map>>Show Normal Map). In this case, "normal" isn't "typical", but is rather defined in the computer graphics sense of the outward-facing vector of the sphere adjusted for local altitude differences. The XYZ values of the normal vector are encoded into the RGB channels of the image; the predominantly blue tones are due to the mostly-out nature of the vectors (large up component mapping onto large blue component). This sort of map is useful when placing an FT world into 3D rendering software as it can be used to apply the texture of the topography to a 3D sphere as lighting (bump mapping).

Please select Map>>Show Altitude to show the altitude map that you've become familiar with.

Dumb me ! Thanks that solved it !

I'm not sure when I'll get back to work on Wilbur or FT for any stretch of time. There is a 6 week-old baby in the house at the moment and my free time is taken up that and with trying to get the CC3+ update out the door for ProFantasy.

It's you the boss so the priorities are yours .
My 6 week old babies weren't an issue for my activities because at that age they only sleep and feed with a very accurate frequency so the care is trivial.
I wouldn't say the same for 2 years which are what closest approximates hell
However with the time I spent with trying to get at least semi realistic mountains in Wilbur and/or FT, I think I know now enough about the use of the fractal engine for mountains to make some informed comments that I hope may be useful as feedback.

- Of course the bug must go away. It is not possible to do maps if the fractal engine is off by a factor 500 or more.

- I know the mathematics of fractals (from my chaotic dynamic system studies) so this time I focused more on what the fractal settings should do rather than what they show on the screen.

1) H must be approximately (or exactly) the Hurst coefficient. H measures the autocorrelation in a data series and is related to the fractal dimension of the data series (if I remember well we have D=2-H). It must be in [0,1] but 1 (which is the default) should never be used. It means perfect autocorrelation e.g that the data is a perfect straight line. No fractals here. H=0.5 is just Brownian noise. Only low H (below 0.5) is interesting because we have a negative autocorrelation there. H should be the parameter that impacts most the look of the fractal. Btw it is a detail but Wilbur apparently allows H>1 (I tried 3) which makes no sense.

2) Fractals are constructed by self similarity. E.g some function with frequency f1 in some interval on the plane X,Y is drawn with a frequency Lxf1 over the same interval and superposed on the previous function. The proces is repeated O times and the end result is a self similar fractal surface spanning the scales from 1 to 1/L^O. L is the lacunarity (typically 2 for frequency doubling used with fBm). O is the octave number which is trivially constrained by the screen resolution - obviously after a certain number of halving the size of the interval (this is what doubling the spatial frequency does) is just 1 pixel and it makes no sense to halve farther. For 2000 resolution and L = 2, O should be typically around 9. So L and O are uninteresting mundane parameters that have no impact on the look of the fractal and could be set to 2 for L and randomly anywhere between 5 and 10 for O.

3) fgain is only used for multifractals and I don't know exactly what it should do. I randomly tested values between 2 and 40 and saw no obvious difference in the look or the Spectrum (histogram) . Perhaps there is something visible when it's less than 1.

4) So now to the fill mound function and more generally to the fractal parameters. It seems that you strongly constrained and "tamed" the fractals. As the look basically depends only on H and the type, one expects an extremely irregular, ragged look for low H (kind of 0.05) and smooth above 0.5. This is unfortunately not what happens. Almost independently of H all mountains look like an array of perpendicular ellipses in the A,Z and B,Z planes where A is the principal vector of the selection ("crest line") and B is orthogonal to A, what gives them all a smooth hill like look. Any fractal (or noise) operation only acts as a second order perturbation on the ellipsoid so that the shape doesn't change significantly.
This was (and is ) my problem from day 1 - I can't understand why the random created worlds are nicely fractal and realistic in all 3 dimensions while the local effects of the (presumably same) fractal functions (like fill>mound) produce only highly regular and smooth shapes.

As the problem lies clearly in the treatement of the Z dimension, if/when you get back to FT one day, I would suggest that you "unchain" the fractals in the Z dimension.
By "unchaining" I mean typically something like http://www.classes.cs.uchicago.edu/a...eTerrain00.pdf
Already the simplest fBm can make a highly realistic mountain (Figure 2.3) and when one sophisticates with the hybrid multifractal it is nearly perfect (Figure 2.10).
Btw I may be mistaken but I vaguely remember that you perhaps mentionned Musgrave somewhere and if yes then you may be already familiar with this.
Why couldn't the mountains be created with this algorithm which doesn't seem very difficult nor computing power thirsty ?
Of course I neglect here the Pentiums and similar constraints - I am not familiar with programming hardware/OS limitations.

EDIT :
There is one thing I didn't learn yet. Could you point me to some explanation how to create/edit some fractal continental shelves ? One day I would like that my oceans have some color variations too - lighter whitish blue near coasts and deeper blue in deepest abysses. Or perhaps is GIMP better suited for things like that ?

[waldronate]

The 6 week old is the source of a high level of background noise, but it's the frequent requests from its mother to fetch things or to change it that are the source of many disruptions. The 3 year old is also a disruption. I was able to write this posting in only about 4 hours of clock time with all of the disruptions. I suppose it's my own fault for reproducing here at age 50.

Except for a few efficiency modifications, the code shown in the Musgrave paper is EXACTLY the code that has been in use in Wilbur for about 20 years now. The basis function is a bad implementation of the classic Perlin gradient noise function.

One of the fun things about computers is that you can do things that have no physical meaning. In many graphics rendering systems, for example, it is possible to have negative luminance for lights. That's a meaningless physical quantity, but it can be very useful for darkening an area that might be otherwise too bright. Because meaningless things can be useful things, software toys have a tendency to not limit the allowable inputs.

The exact value of the number of octaves needed to avoid aliasing (noise) is octaves = log2(screen resolution) - 2 according to Musgrave in the paper that you cited above. Note that very large surfaces will require a number of octaves larger than 10. A lacunarity value slightly off from 2 gives speed about equal to the "correct" case of 2 while avoiding aliasing for integer-based noise functions. Wilbur and FT want to use sphere radii fairly close to 1 in order to get plausibly-sized "continents"; keeping lacunarity off a little from 2 mitigates aliasing. Note that H should range from 0 to 2 for Musgrave's functions, if I remember correctly.

A quick aside on the basis function that supports the various fractal types: it's classic Perlin noise (see Ken's Academy Award for info). The classic Perlin noise uses a cubic spline interpolant through its lattice positions to get the values. This interpolant is a nice smooth one, but it's definitely not elliptical. In the ridged multifractal function, the ridges are formed by taking the absolute value of the noise function, which exposes where the noise function passes through zero as a curved ridge.

I'm not sure that I understand your comment about the Z dimension. In Wilbur, Every point on the raster has an X (across), a Y (down) and Z (out or altitude) position; the Z position is the computed value. This data can be viewed in many ways, including as a 3D image.

In FT, there is a similar concept except that the raster is a polar one with latitude, longitude, and altitude as the axes.

If you're referring instead to the general shape of the mound function, that is the whole idea of the mound. It takes a white on black image (the selection) and computes the distance function from the edge of the white values inward. It then normalizes the computed distance function to a range of to 1 rather than the pixel distance from the edge. This basic envelope has a profile operator applied to it to allow for non-linear shaping. This distance function forms an envelope that is multiplied by the fractal function to get the initial output of the mound function. This initial output is then scaled to the range of minimum height to maximum height to get the final output, which is then blended with existing surface in a manner specified by Operation. This shaping of a noise function by an envelope is a common operation and is also used in the popular http://www.cartographersguild.com/tu...l-rpg-map.html tutorial here at the guild.

Making Continental Shelves offers some hints on how to do continental shelves in Wilbur.

The Wilbur Shader offers a way to increase lightness for ocean depths. On the Altitude tab are two values "Max" and "Min" under the "Lightness" label on the Sea side. Min is the lightness adjustment at the lowest altitude, while Max is the lightness adjustment at the highest altitude (sea level). Values for these should range from -1 (black) to +1 (white). A value of 0 leaves the color unadjusted from the value retrieved from the color list. You can achieve the same result by hand-tailoring a gradient, but I'm too lazy for things like that.

[Deadshade]

The 6 week old is the source of a high level of background noise, but it's the frequent requests from its mother to fetch things or to change it that are the source of many disruptions.

Aha I thought so . It is more the mother than the new born. And 3 is much, much smoother than 2 - psychologues even say that 3 is (of course statistically) the most pleasant age for the environment in a whole life

Except for a few efficiency modifications, the code shown in the Musgrave paper is EXACTLY the code that has been in use in Wilbur for about 20 years now. The basis function is a bad implementation of the classic Perlin gradient noise function.

OK. Am I wrong that the "Expression field" in the fractal window could be used to implement another basis function ? Or is it something else altogether ?

One of the fun things about computers is that you can do things that have no physical meaning. In many graphics rendering systems, for example, it is possible to have negative luminance for lights. That's a meaningless physical quantity, but it can be very useful for darkening an area that might be otherwise too bright. Because meaningless things can be useful things, software toys have a tendency to not limit the allowable inputs.

Well this may be true. But in the present case H>1 gives D<1 (this should be illegal because the formula for D = 2-H shouldn't work) and D can even get negative. D<1 is still fractal but of the type Cantor dust - plenty of void and little matter. D<0 would be .... well less than a single point
I can't see what it could mean so that, like you think having read somewhere, H >2 should be forbidden as long as we stay in our 4D Universe. Indeed trying H=3 ( D "=" -1) I see no difference to H=1.
But getting H very near to 0 doesn't show a wild chaos that I would expect either .
So this H must be something that doesn't behave quite like the Hurst coefficient. Seems to be much "tamer" for very low values of H.

I'm not sure that I understand your comment about the Z dimension. In Wilbur, Every point on the raster has an X (across), a Y (down) and Z (out or altitude) position; the Z position is the computed value. This data can be viewed in many ways, including as a 3D image.

Yes I saw this command . But I could never get a 3D image like you show. When I select the 3D image I get a completely black square instead. What am I missing here ?

If you're referring instead to the general shape of the mound function, that is the whole idea of the mound. It takes a white on black image (the selection) and computes the distance function from the edge of the white values inward. It then normalizes the computed distance function to a range of to 1 rather than the pixel distance from the edge. This basic envelope has a profile operator applied to it to allow for non-linear shaping. This distance function forms an envelope that is multiplied by the fractal function to get the initial output of the mound function.

Yes this is absolutely what I was referring too. And what I have been saying was that this envelope looked like a smooth regular ellipsoid or triangle or whatever symmetrical shape one wants (using the shaping function doesn't change much the look). Further the multiplication by the fractal function looks like a second order perturbation e.g it doesn't change the regular smooth look in practice. That's why I said that it looked like if the z coordinate (the height field) was hardly impacted by the fractal function. In other words the result is not at all like the 3D mountain image you showed above. To illustrate what I am saying :


Left is fractal off. Second is fractal on, H= 1. Third should be a very chaotic setting with H=0.2. 4th is H=1 with non linear slope. Basically there is no (very slight) difference between all 4. All have a single symmetrical crest line. All have a single peak situated at the intersection of the 2 crest lines. None looks realistic. That's why I was asking myself why couldn't one just apply the algorithm that generates a shape like what you show in your 3D image but instead of applying it to the whole world, one applies it only to the selection with constraint that the basis of the shape smoothly connects to the selection boundary.
Also I have still the question - is it possible make several mounds with fractal on ?
At present when I do one, redo another selection, reapply mound with fractal on, then it draws a mound on the second selection but the first mound disappears.

Making Continental Shelves offers some hints on how to do continental shelves in Wilbur.

Thanks much ! Actually I tried that 2 weeks ago when I was starting to learn Wilbur. But as the commands have another name and are in other tabs, I gave up and forgot it. Now that I am more familiar with the UI, I know that Lighting setting is in Shader Setup, that there is no Point process but the Exponent is Under Filter tab etc, so I could follow the tutorial. Of course it gave horrible results , shoved my continents Under water, created new continents etc but I will play with the settings provided by the tuto to get an effect only on the ocean area and leave the continents untouched.

The Wilbur Shader offers a way to increase lightness for ocean depths. On the Altitude tab are two values "Max" and "Min" under the "Lightness" label on the Sea side. Min is the lightness adjustment at the lowest altitude, while Max is the lightness adjustment at the highest altitude (sea level). Values for these should range from -1 (black) to +1 (white). A value of 0 leaves the color unadjusted from the value retrieved from the color list.

Thanks that looks great. I will play with it too.