The Cartographers’ Guild is a forum created by and for map makers and aficionados, a place where every aspect of cartography can be admired, examined, learned, and discussed. Our membership consists of professional designers and artists, hobbyists, and amateurs—all are welcome to join and participate in the quest for cartographic skill and knowledge.

Although we specialize in maps of fictional realms, as commonly used in both novels and games (both tabletop and role-playing), many Guild members are also proficient in historical and contemporary maps. Likewise, we specialize in computer-assisted cartography (such as with GIMP, Adobe apps, Campaign Cartographer, Dundjinni, etc.), although many members here also have interest in maps drafted by hand.

If this is your first visit, be sure to check out the FAQ. You will have to register before you can post or view full size images in the forums.

The erosion model in Wilbur and FT looks most reasonable when an editing sample's resolution is on the order of a few tens of meters or smaller. It's plausible up to around a kilometer or so if you're careful. Much above that, though, and the results are unlikely to look particularly plausible. Getting that resolution on an FT map would require a minimum editing resolution of 40000 to get anything even close to reasonable. The 32-bit version of FT has a hard cap of 8190 samples, meaning that you're not going to get anything plausible-looking.

Note that an editing resolution of 40000 samples in FT would take on the order of 21GB of memory for working space, meaning that you're going to be swapping to disk continuously if you don't run out of swap file space first. With the swapping, I would expect to see days to weeks of 100% CPU runtime to run an incise flow operation on a surface of this size. That presumes that you could find a 64-bit version of FT to work with (at last check there isn't one publically available).

The same resolution arguments apply to Wilbur as well, with the exception that Wilbur does have a 64-bit version.

1km / pixel is about the minimum that you'll need to get plausible results. You will probably want to overlap adjacent maps by at least 10% to get plausible erosion joins.

Erosion is a global problem and not particularly amenable to breaking into tiles because the edge conditions really matter, esepecially incoming flows from other areas. For the programmer pedants out there, yes, the system could break the large surface down into arbotrarily many smaller tiles, but it would still be treating the tiles as a single surface for the purposes of the operation.