Wilbur, terrain editing now and the future.

[zhar2]

To date I must say that nothing for the purposes of mapping that can handle large scales and export satisfactory data for any use beats Wilbur (I may be wrong though), shame that Wilbur is no longer being developed or that anything similar and better will come along. your thoughts?

[Azélor]

It depends, are you talking about fractal softwares only?
I think Wilbur does a pretty ok job when it does not crash. I do have a lot of problems with it.

Also , I suppose you mean small scale? Large scale and small scale

[zhar2]

Well im currently using 64-bit at 32 GB ram, doesn't crash for me. by large scale I mean a whole planet subdivided and refined over and over. shame it doesn't let you use a console of sorts to write a routine to process tiles. im thinking of buying geocontrol2 to refine terrain and create more unique landscapes but im not sure if can handle large altitude variances or work with large swathes of landscape, if not I might have to subdivide a planet into thousands of calibrated tiles (kina lazy but if its a must) and again im not sure if it can do batches.

[waldronate]

I'm not sure that I would say that Wilbur isn't being developed. It's quite likely that there's been a fair amount of development, just not any public releases for a while. As I understand it, there's just the one developer who is currently working multiple jobs and has small children, leaving little time for Wilbur development (plus, he's getting on in years). Plus, the total revenue-generating properties of the software have been negative for a very long time.

The last update that I had heard about involved turning the entire system inside-out to allow for automated processing (effectively macro record and playback). Wilbur's code base dates back to 1995, which makes it plenty old enough to vote in US elections, but not quite old enough to drink at a bar. There were a number of issues relating to the code even back then and there has been a comparatively huge amount of work done over the last 20 years to keep things going.

A few years back, there were discussions about doing a version of Wilbur that supports tiled surfaces, but the changes needed in the code base were quite extensive and the expected performance properties were pretty poor.

[waldronate]

I think Wilbur does a pretty ok job when it does not crash. I do have a lot of problems with it.

Hmmm... I don't see any bug reports on this behavior. Would you care to elaborate?

That is, what are you trying to do when Wilbur crashes?

What version of Wilbur?

What OS?

How big of a surface are you trying to make?

[zhar2]

Well in my opinion for our purposes Wilbur is one of the most powerful and versatile tools I have seen (thanks waldronate for giving us this awesome tool!!) and yeah a way of giit a series of automated instructions would be awesome.

[Azélor]

Hmmm... I don't see any bug reports on this behavior. Would you care to elaborate?
for example but not precisely: http://www.cartographersguild.com/re...tml#post241313

That is, what are you trying to do when Wilbur crashes?

What version of Wilbur? Wilbur 1.80 (32-bit)

What OS? Windows 7

How big of a surface are you trying to make?

I can't remember the problem exactly since a haven't used it for a while but it happened with different tools... I just played with it today and could not get it to crash.
If it's help, I also used Fractal terrain and it almost never crash.

I think the map was big but it's hard to judge since Wilbur does not use pixels. I know what map it is but I can't remember the exact version (the size are different).
I think it was crashing when I tried to use brushes that are too big.

[Greason Wolfe]

Don't get me wrong. I happen to like Wilbur, and it is probably my most used application when it comes to mapping. Sure it goes wonky on me sometimes, but that usually only happens when I am working with file sizes in the 4k by 4k range. Even then as long as I save frequently it really isn't that much of a problem. As for the crashing issue used as an example from my other thread, with things like that I can usually find some sort of work-around. Besides can you really complain about something you are getting free of charge?

[waldronate]

Memory management has never been Wilbur's strong suit (Fractal Terrains is a bit better in this regard). The code really doesn't do much error checking after allocating memory, which causes crashes when the system runs out of memory. The most recent version is a bit better in this regard, but it's never going to be particularly good at it without rewriting lots and lots of code.

One of the big drivers for pushing the code over to 64-bit in the first place was to relieve memory pressure for larger surfaces (the 32-bit version of Wilbur does get to use 4GB when run on a 64-bit OS version, as compared to only 2GB when run on a 32-bit OS version). That and that I was regularly using a 64-bit OS, of course. What testing I do for Wilbur these days is pretty much all on 64-bit Windows 7, which means that errors for the 32-bit version and for XP will likely persist. It also means that any issues that are Windows 8 specific will probably go unchanged for a while yet as well.

One of the twitchy areas in Wilbur is its undo/redo system. It isn't particularly efficient and tends to fail far more than it should. One goo way to use Wilbur is to reduce the number of undo levels to 1 or 2 via the preferences dialog. There won't be nearly as much in the way of undo buffers clogging up memory that way. Wilbur specifies its surfaces as a number of samples (pixels, if you prefer - those are just samples in a picture [lit: picture elements]) and uses around 9 bytes per sample (4 bytes for the float altitude, 4 bytes for the texture, 1 byte for the selection) for the main workspace and a like amount for each undo level. The processing algorithms are likely to need a few more work areas of about that size each. Plus program use, stack space, and so on. A 4kx4k image needs 16M samples, which is about 151 MB per work area. That's around 1.5GB or so max data usage for a 4kx4k image at the default settings. This number is perilously close to the 2GB limit on a 32-bit OS. There are also some algorithms that have fairly ugly stack usage (the basin fill code is one example), which can trigger a stack overflow error for large and complex surfaces. There is also the possibility that large textures can cause problems for certain video drivers (Wilbur uses the MakeDIBSection to allocate its images; normally this isn't a problem, but it can be). Using the 3D preview will also cause all manner of unexpected memory usage and the video card has quite different limits from the regular OS space.

The short version of the above paragraph is that Wilbur is pretty sloppily made inside in a lot of places. Some of that code is carrying around initial development markers from the early 90s and I didn't worry too much about thing like that then. I was VERY excited when I got a machine with 32MB in it. It's hard to run out of 2GB of virtual memory when you're working on things that fit comfortably in 64MB, including OS, meaning that I just didn't encounter out of memory errors. The 64-bit version is in a similar position now, except that I care about such things a good bit more.

[mad_cat]

I am starting to use Wilbur, having recently discovered it. I am hoping it helps make my mountains more realistic as people seem to be confused by my colour scheme. I haven't figured out how to do it yet, but I have got rivers figured out.