Editing a world map

[waldronate]

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.

Correct. You can get interesting results with the Wilbur shader as-is, but not correct ones. The linear blend is what kills it (e.g. a bright blue is RGB(0,0,255); if it's present for land and the latitude shader fails to fire, then the result will be RGB(0,0,255)*0.5+RGB(0,0,0)*0.5=RGB(0,0,127), or a dark blue. The system needs some better logic for handling colors. It just takes some programming time.

[johnvanvliet]

i only use wilber to export a 16 bit png DEM image

all the coloring is done with other software

[Azélor]

I tried to follow some of the conversation and I must admit it's quite complicated.
But have you ever considered using a shader of 4 parameters (C,M,Y,K) instead of 3 (R.G.B)? Or more parameters if that is possible.
It could increase the possibilities maybe.

[waldronate]

The CMYK color space is intended for print applications; RGB is intended for driving a color monitor (not that there is a single "CMYK" or "RGB" color space, but those are the basic intent of the two processes). Neither is a perceptual color space such as HLS or others defined for the purpose of being easy for humans to reason about. The choice to use the RGB color space usually comes down to convenient hardware and/or operating system support.

The problems of the Wilbur shader's blending operation are quite well known (to me, at least). It's probably not going to get fixed any time soon. It's far more likely, in fact, that new shaders such as an equation or tree evaluator will appear in the unlikely event that I get some time.

[su_liam]

HLS would be an improvement, but CMYK is actually a smaller gamut. It's really easy to make a muddy mess. You need CMYK for printing, but it has little utility beyond that.

Considerably ninjaed!

[Deadshade]

Correct. You can get interesting results with the Wilbur shader as-is, but not correct ones. The linear blend is what kills it (e.g. a bright blue is RGB(0,0,255); if it's present for land and the latitude shader fails to fire, then the result will be RGB(0,0,255)*0.5+RGB(0,0,0)*0.5=RGB(0,0,127), or a dark blue. The system needs some better logic for handling colors. It just takes some programming time.

Exactly that appears clearly in the example of the code you showed.
However when even I could see the cause of the problem (I never programmed anything serious) and how to heal it by basically replacing the linear blend by 2 lines giving realistic results then it shouldn't take more time than a few hours.
Of course to that adds the time to change the blend tab in order to add one parameter that I introduced - the biomlimit and here I don't know how long it takes to program a change of a tab.
This change would cover in my estimate 90% of a user's needs because when you get altitude and latitude colors right, you get right all you need for a world's creation. The slope and orientation colors are only anecdotic and could be removed altgether because considering such details makes only sense on much smaller scales (subcontinental) and even then for only exceptionnal needs.
Basically the right logics is just avoiding color mixing because its results are unpredictable and this mixing is avoided by just adding limit parameters which serve to cut the space in regions where always only a single shader applies.
Optionnally the boundaries could be blended but here I am already in the fine details.

In the experiments I did, this module of Wilbur shader looked totally independent from everything else so that changing 2 lines shouldn't interfer with the core of the software so there should be no additional interfacing work involved.
Of course it would be nice if that was fixed because then Wilbur could be used almost from the beginning to the end of a world creation process, sparing time to learn another software for the realistic coloring.
But if that was not a target and you don't intend to spend any time with Wilbur anymore then who are we to ask you to change something ?

We live in your world as Everquest designers aptly said one day

[Deadshade]

Now I am struggling with the rivers.
I followed step by step "Fun with Wilbur volume 1" because this is approximately the look I wanted.
It failed.
The incision function didn't do what is shown with the document.
The canyons were less deep and less fractalised.
As this function takes an unholy time despite my rather top end CPU and the preview button didn't seem to do anything, I couldn't experiment with the settings.
I think I have an idea what the settings should qualitatively do (with the exception of the pre, post blurs) but not quantitatively.

I suspect that the result depends on the size of the map (My master map is 5 000x10 000) and yours in the tutorial was probably smaller.
Could you recommend some better setting and the number of incises one shoud do and how the map size impacts these settings ?

Another problem was with the river flow which may be related to the previous one.
When the slider goes to "long rivers" I don't get long rivers but many more short rivers.
When the slider goes to "short rivers" I get much less rivers of all sizes. So the slider rather seemed to do "many rivers" or "few rivers" instead of long and short.

The worst being that among the hudreds of rivers I got, almost none went to the sea. All were extremely short and stopped in the middle of nowhere. Some were cut in several non continuous segments. About any bump on the map even a few 100s m high seemed to generate a river.
Could you explain this problem ?

[Deadshade]

Well having given up on rivers in WIlbur I headed to FT3.
So I got now a semi reasonable map :



FT3 does rivers not so badly and especially it's very fast. There is the small problem that it creates rivers even by temperatures of - 10 but I can GIMP them away.
I am quite happy with the continental shelves . I even created large oceanic features by using low lacunarity fractals in Wilbur but the FT3 shader is too shallow and doesn't show them well.
I would still like to edit the shader especially for the mountains and the deep sea but FT3 apparently doesn't allow shader editing.
Also it seems that rescaling (button remap altitudes ?) doesn't work. I select the continents, specify the max and min and the profile but what I obtain is much higher than the bounds.
Most problems seem relatively details now but one huge that has been plaguing me on different occasions since the beginning remains.

I have again this huge ridge in the sea going from - 500 to - 2500 (remainder of the shelf creation) which looks like a fist in an eye and I can't get rid of it.
I wanted to use rescaling on a selection but see above. Perhaps it can't be solved in FT3 andI'll have to go back to Wilbur.

Can you advise how I can make a smooth transition from the shelf to the intermediary depths around - 2 500 so that this sea cliff doesn't appear anymore but the structure of the shelves is untouched ?

EDIT :
As the input from Wilbur to FT3 was 5 000 x 10 000, I wanted to save in the same resolution. But it seems that there is some limit to the size FT3 would save and help is no help.
Do you know if there is a limit and if yes how big is it for png and bmp formats ?

[waldronate]

The Fill Basins step is important because it enforces a unique flow path across the surface. Without that step, your rivers from Incise Flow become small and fragmented, because the flow channels are themselves small and fragmented. The white noise addition to the surface before the Fill Basins step is also important because it causes the rivers to wind in a pleasing manner instead of just flowing in fairly straight lines. Map Size has a HUGE impact on the perceived final result. The algorithm for finding flow is O(n*n*n), so it's extremely sensitive to surface size. Note that the precipiton-like algorithm that Wilbur implements doesn't guarantee continuous flow patterns, unlike the basin fill operation.

Pretty much everything that you're describing here is due to having discontinuous flow channels. There's no good way that I know to get that without the basin fill step, which has its own artifacts (no lakes, for example). If I get back to working on things, I'd like to allow the option to use the selection as a stopping point for the precipiton operation (it would also be nice to allow the selection to dictate where rivers could be found).

[waldronate]

It's certainly possible that the retail 32-bit version of FT has limits on the export. I don't recall. I just checked my internal build on Windows 7 64-bit and it seemed to generate a 10 000 wide by 5 000 high image without problem (it was slow, but you'd expect that).

The remap altitudes feature is a Wilbur feature that crept into FT; as such, it may not be obeying all of the assumptions of FT.

As far as the step at the edge of the continental shelves go, did you try selecting an appropriate altitude range and blurring the result? Alternatively, select all land (altitude > 0), select>>modify>>expand the selection a bit to encompass the shelf area, then select all land again with a "subtract from selection" followed by a blur.