Wilbur questions for Waldronate

[Thorf]

I've been using Wilbur a lot for the past month or two. It's a really excellent little program, and I'm very happy with it.

During all these hours spent in Wilbur, I've come across a few things that I'd like to ask about. So here goes:

1) I'm using Wilbur to develop a world, continent by continent. But I've noticed problems when working with larger sections. My final goal resolution for the world map level is 0.5 km per pixel, which will leave me with a final map of 86,400 x 43,200 pixels. Obviously this is totally impractical for a single file, but it doesn't have to be if you split the world up into sections. Naturally, continents are the easiest section to work with, and even the largest is only a fraction of the full map. Even then, though, working with images of say for example 14,000 x 20,000, or even 11,000 by 11,000, I have found that I encounter problems - specifically, with Fill Basins. It produces a strange effect where large portions of the map get filled in at an oblique angle.

The other problem I encountered was with Precipiton Erosion, on a very large map of 22,000 x 14,000. The erosion seemed to work properly on the left hand portion of the map, but more than half of the right side of the map either experienced less or no erosion.

This all leads me to wonder: I've had none of these problems since reducing my fragment sizes to less than 10,000 pixels square, so could there be some fundamental problems with working on these super size maps?

2) With the 3D viewer, I have been finding that 9,999 pixel square images are too much for it. It's an absolutely invaluable aid to working on a map, though, so I chose a 2,500 pixel square section of my map for testing, to develop an "erosion recipe" for use on larger sections. It works really well at this resolution. Again, is there an in-built limit for what the 3D engine can display?

3) Another problem I've been trying to deal with is regularity of mountain heights - which is to say, all Wilbur's mountains tend to end up at about the same height. This is especially causing me problems since I have to go to Photoshop via PNG to stitch the maps together again, but of course PNGs automatically scale the map from lowest to highest across the greyscale spectrum. Do you have any advice for dealing with this issue?

I've found that using adjustment layers with clouds set to multiply in Photoshop allows easy randomisation of the peaks without causing problems with river systems. But that only helps within each section.

I don't want to swamp you all at once, so that's all for now.

[waldronate]

1) I'm using Wilbur to develop a world, continent by continent. But I've noticed problems when working with larger sections. My final goal resolution for the world map level is 0.5 km per pixel, which will leave me with a final map of 86,400 x 43,200 pixels. Obviously this is totally impractical for a single file, but it doesn't have to be if you split the world up into sections. Naturally, continents are the easiest section to work with, and even the largest is only a fraction of the full map. Even then, though, working with images of say for example 14,000 x 20,000, or even 11,000 by 11,000, I have found that I encounter problems - specifically, with Fill Basins. It produces a strange effect where large portions of the map get filled in at an oblique angle.

The other problem I encountered was with Precipiton Erosion, on a very large map of 22,000 x 14,000. The erosion seemed to work properly on the left hand portion of the map, but more than half of the right side of the map either experienced less or no erosion.

This all leads me to wonder: I've had none of these problems since reducing my fragment sizes to less than 10,000 pixels square, so could there be some fundamental problems with working on these super size maps?

I haven't tried those filters on maps of that size, so I don't have any experience with what the system does in those cases. I just don't have anything like that kind of patience.
The precipiton filter doesn't have any hard-coded limits in the software that I could see. It's possible that the rand() function is biased low, but that's unlikely. I'm not sure what's happening here.
The basin fill algorithm, on the other hand, does have a recursion limit of 10000. The original author had described it as working for "a few million pixels", which was good enough for the 32-bit program. With the 64-bit prorgam, I suppose that the stack size ought to be increased and the recursion limit as well.

2) With the 3D viewer, I have been finding that 9,999 pixel square images are too much for it. It's an absolutely invaluable aid to working on a map, though, so I chose a 2,500 pixel square section of my map for testing, to develop an "erosion recipe" for use on larger sections. It works really well at this resolution. Again, is there an in-built limit for what the 3D engine can display?

There isn't a limit in the code, but there probably is in your system's OpenGL driver. I'm submitting all of the surface points as a single batch, which is probably hitting your system's limits (it's 16 bytes per surface sample, so even the 2500 sample square surface is pushing 100MB to the video card). Like much of Wilbur's code, the OpenGL parts are quite naive in how they approach system resource usage. Rather than having complex code to allow for limited systems, I wrote simple code and kept much of the error-checking at the user level. Such behavior isn't acceptable in a commercial product, but Wilbur is a toy.

3) Another problem I've been trying to deal with is regularity of mountain heights - which is to say, all Wilbur's mountains tend to end up at about the same height. This is especially causing me problems since I have to go to Photoshop via PNG to stitch the maps together again, but of course PNGs automatically scale the map from lowest to highest across the greyscale spectrum. Do you have any advice for dealing with this issue?

The laziest solution is to put a single spot of a known high value and a known low value on each map. That way Wilbur will compute the same high and low for each map. Use the square brush and a 1x1 size

I've found that using adjustment layers with clouds set to multiply in Photoshop allows easy randomisation of the peaks without causing problems with river systems. But that only helps within each section.

It's also possible to do the multiply thing directly in Wilbur. Use Filter>>Noise>>Fractal Noise with Operation set to Multiply.

I don't want to swamp you all at once, so that's all for now.

I wouldn't worry too much about swamping me with questions.

[Thorf]

Thanks for the very useful info!

Your suggestion to add known high and low spots to the map is especially helpful, and I have already implemented it as I begin the process of erosion yet again. I'm finding that it's generally important to get the map right before starting erosion, as it's easier to make changes in the early design and smooth them over with erosion than to tweak the already-eroded map, so I'm going back to my design stage. But thanks for the info about noise. Wilbur has a lot of functions that I haven't played with yet, so it's nice to have learned about another one.

[waldronate]

One thing that I would recommend is to add the high and low spots just before you do the PNG export and remove them (a couple of undo operations should work) before saving the map as an MDR or whatever you're using to keep the data safe from run to run.

[Thorf]

Another quick question: do you know of a quick way to get DEM files from Wilbur? Inspired by the usefulness of Wilbur's 3D preview, I've been trying to find a simple 3D flyover program. This is much harder than it sounds. All I really want is something like Wilbur's 3D preview - nothing fancy - that you can just plug a height map into and look at in 3D from various angles.

The most promising-looking program in this regard seems to be Estierra, but it only works with DEM files.

[Redrobes]

If you can export an hf2 file format then saving up to 2Kx2K hf2 file as height.hf2 and run my little dragon flight app in the same dir would give you that simple 3D viewer. Its what I wanted too so I wrote that.
ViewingDale - getting browser details...

If you cant export an hf2 from wilbur then save an 8bit greyscale png file or bmp file as height.png / height.bmp and it should also work. It will do 16 bit heights if you can obtain the LSB 8 bits as another greyscale as height_minor.png. Also, if you put in a color.png . color.bmp then it will colour the terrain as well. Otherwise it has just movement keys, raise lower landscape and some screen save etc but thats about it.

[waldronate]

Wilbur does have HF2 export, so dragon flight should work for you.

[Thorf]

Redrobes, that's a really great little program. It works a charm with 8 bit greyscale BMPs straight from Wilbur, but I can't seem to get it to load anything else - it just complains that the BMP isn't present. Is there some way to tell it to look for an HF2 or a PNG?

Also, I'm having trouble with the colour file. I'm outputting BMP texture files from Wilbur, with lighting settings off, but when I load it in Dragon Flight it colours the whole terrain seemingly randomly with one of the shades in the colour file. Am I doing something wrong?

In any case, thanks very much for the suggestion. I'll be putting this to good use from now on.

[Redrobes]

Oh - it could be that the online version is not so up to date as the current one you would be given as part of the viewingdale suite patched up but it should be. I'll have a look. Anyway - it should be that you can have either height.bmp, height.png, or height.hf2 and optionally color.bmp, colour.png, height_minor.bmp, height_minor.png as files it would pick up. It should always spread the color image across the whole tile and its always square tiles so if you need odd dimensions then pad them up to the next size (preferably 2^n sized like 1024 or 2048 or whatever). You can press the keys 1-8 to set it to specific 2^n resolutions from 128x128 to 2048x2048 where it maxes out.

Check back a little later on and ill edit in a note saying I have updated it or whether it is already the latest.

EDIT: Ok so it wasnt an old version at 1.08 but it has seen some of those changes in the last few years as unreleased so a) I have released the new version as 1.09 beta. And b) If you find that when you grab it from the web page its still the same one at 2009 file then it means (like me) that your web server is caching the old one. In that case grab the URL of the download button and append _109b to the filename (before the .zip) and it would be the new one. Or, to make that easier - click here

Oh and it also says in the "About..." help section that its at V1.08 hacked about for Outerra inspection - but just ignore that.

[Thorf]

Thanks for the quick reply, Redrobes. I downloaded and installed the latest version. However, I'm still having issues with the colour file. It occurs to me that perhaps I have misinterpreted what the colour file is. I was assuming it is just a coloured version of the bump map, whose colours at each point are used to shade that point, but judging by your reply that's not the case. Sorry if this topic has come up before - I can't seem to find any explanation elsewhere. Can you let me know what the colour file should be like?