PDA

View Full Version : Erosion of a DEM



cantab
09-27-2011, 10:56 AM
I'm trying to understand how to get realistic erosion features, given a DEM.

I know Wilbur can do it, and does it very well, but obviously I don't know how. I'd like to get an understanding of how this should work.

eViLe_eAgLe
09-27-2011, 06:59 PM
Theres bryce? But seriously theres some Wilbur tuts on Ridgenet.. You could even send Waldonrate a PM the maker of Wilbur and Fractal Terrains.

cantab
09-27-2011, 10:29 PM
Just realised I wasn't clear before. I'm not so much after how to use Wilbur, I'm after understanding how it does what it does, in terms of the kind of algorithms that might work.

waldronate
09-28-2011, 01:09 AM
From the Wilbur mailing list:

The basis of the precipiton algorithm is that an agent (a "drop", "precipiton", or "waterbot" depending on which piece of literature is used) is placed onto the surface at a start point and moves downhill, performing the appropriate movement of water and sediment as it goes. The algorithm in Wilbur is the most primitive possible, as it merely moves some fraction of the difference between the current point and the most steeply downhill point between those two points. The then moves to the point that it deposited sedmient on and goes again. This algorithm doesn't necessarily leave the surface in a correctly-connected state, but the results are visually appealing for the most part and it's fairly quick.

The number of passes for the algorithm is really just a description of the "amount of time" that the landscape "gets rained on". If you hit cancel partway through a pass you'll just get a smaller number of drops running across the surface.

The notion of a "pass" in the precipiton process is somewhat of a misnomer. In the original implementation, a pass processed every sample on the surface in a raster pattern. These days, a "pass" just means that it is generating the same number of random start points as there are samples in the image. The original implementation had some very specific errors caused by the way that points were being handled. The easiest-to-code solution to those errors was to use random start points instead of a raster pattern. An ordered pattern over the surface would have worked as well, but would have been somewhat more difficult to code.

The incise flow operation is very simple: the path of steepest descent among the eight closest neightbors is computed for every sample on the surface. For every sample on that surface, that descent map is used to send an agent downstream until it hits a pit or exits the map. On the way, the agent adds one to another map that counts the number of times the cell has been visited. This operation is a slow one, but the result is a connectivity map of the surface that counts how many cells can get to a particular cell (basically, a flow map). The logarithm of this count can be subtracted from the surface (that's the incise flow part). The logarithm of this flow map can also be thresholded and called "rivers". Much like the precipiton algorthm described above, this algorithm has only a limited connection with the real world. The results are, again, visually appealing and so are somewhat useful for certain tasks.

Note that when the visit count map is blurred before being applied to the surface that it can result in an overly large amount of surface being removed where counts are high, typically at the junction of major flows. This excess removal manifests as little basins that shouldn't be there if this were a fluvial process. I added a little pieces of code that puts an absolute maximum on the amount removed, which is why the "Amount" value leaves flat-bottomed valleys if set above 1. It's another example of a bug that was useful for certain visual effects.

cantab
09-28-2011, 10:47 AM
Thanks. It sounds like your incise flow is fairly similar to what I've been trying, but I didn't think of using the logarithm (I tried the square root).

waldronate
09-28-2011, 11:58 AM
The fractional exponent that you use will greatly affect the results. I recommend having that item be configurable unless/until you find one you like.