..my intent is partly to implement a realistic looking erosion procedure and partly to simply try stuff and see what happens and what i learn from the experience..

after researching various documented erosion algorithms my first step was (and will be for a few more attempts) to see what results i get with the simplest implementation. the first simple implementation wasn't so good, but maybe i can combine it with other things later..

here's a bit of my standard musgrave's ridged multifractal implementation.. 8 octaves, lowest two aren't ridged..

and the result:

this postulated erosion drops random raindrops with n amount of soil moving capacity. this moves from pixel to pixel (contiguous 4) until the "drop's" capacity is depleted. deposition was calculated by taking the height difference (an INT in this implementation) and performing a modulus by a static value to determine the amount of material displaced between the two pixels. loop this until out of capacity or no lower pixel. there is no other differentiation, eg. above or below water, slope to neighboring pixels et c.

i know that's really crude but the goal was to see what results are possible with the simplest methods first... in case you decide to try this yourself :)

ftr i think the 'take a modulus by n' strategy is bound to leave artifacts eg. on ~linear slopes, but in practice the results weren't as bad as i expected. while this algo did effectively fill basins, it really did "slump" the heightmap as if it were sand.. removing much of the detail it would be preferable to retain.

if i attempt other methods i'll add them to this thread, with a pragmatic description of the method and intent fwiw.

this algorithm is useful if you need to increment through sine and/or cosine, eg. when dealing with mapping spheres. there are a number of ways to roll this, including removing one of the multiplies. it's been given all sorts of nice names too. because i've buggered around with several methods, i do not recall the deficit of the single mult form. this way is fairly canonical -

// init

cos = 1.0;

sine = 0.0;

w = (2*pi) / # of steps you want in a period or 2 * pi * f/sr for audio

// loop

cos -= w * sine;

sine += w * cos;

it is unstable at rates higher than pi/4 and, while i have seen all sorts of graphs regarding its accuracy, it's quite applicable for anything you're incrementing less than say 100,000 times.. if you're real worried about that, nudge it every couple hundred/thousand iterations as such, but i found no visual difference compared to transcendentals using it for a 4096 wide image, and don't bother to normalise it running for multiple seconds in audio..

leg = cos * cos + sine * sine;

if (leg exists) {leg = sqrt(leg); cos /= leg; sine /= leg;}

of course cos and sine can be initialised at any correctly paired phase values.

(the single mult form is cos -= k * sin; sin += cos; where k = w * w; but i've only used this for the sine output..) ]]>