how to musgrave's ridged multifractal?

[xoxos]

apologies for not recalling the name of the members whose posts drew me here. my introduction thread:
http://www.cartographersguild.com/sh...445#post182445
the map is eight unsmoothed perlin octaves with cosine interpolation.

the references i am finding on musgrave's ridged multifractal point to URLs that no longer exist and were blocked from archive.org

while i have found musgrave's script, i admit that stylistic differences often make it difficult for me to apprehend the intent of other coders.

what i understand is that all, or the larger octaves of this perlin-based algorithm use absolute values. this alone does not a ridge elicit.

i have read that the amplitude of higher octaves is derived from precedent layers (thus the 'fractal' description) i am guessing this is what i have missed.

would anyone care to give me a nudge on this? tia



not sure where i'm going with this.. will explore the terrain generation for a while. i'm way behind on 2 and 3 d. may take it back to audio.

[Redrobes]

You need to look out for posts by Waldronate who knows his noise and fractals. There is also Su-Liam who does a lot of dabbling with noise functions. Have a search on their threads.

There is a noise library libnoise if you can stand to use C/C++ under VC or gcc.

I give away my little app Instant Islands

http://www.viewing.ltd.uk/cgi-bin/vi...nstant_islands

but I am not one to use a soap box to say that noise is a good method for creating good terrain. I think the system needs to know more than mere noise functions to do it well.

[xoxos]

cheers, i hadn't found libnoise previously.

i'd still be interested in a brief english description of the method coming from an audio background, i inline everything. eg. linear interpolation is a + decimal * (b - a) and i would never use a function (lerp?) to perform these things.

for all i know, i may well end up applying the noise techniques to audio more than contributing to this field

[waldronate]

https://engineering.purdue.edu/~eber...ave/musgrave.c has the original C implementation of Musgrave's RidgedMultiFractal procedure. It s tweak of the classic Perlin fBm function with the addition that it uses the absolute value of the current octave's noise function and the previous octave's noise in the output. http://paulbourke.net/texture_colour/perlin/ is a good discussion of the Perlin noise function. http://forums.planetside.co.uk/index.php?topic=1168 looks to have some nice examples of noise to fractal functions.. The basicPerlin-type fractal forgeries are based on a space-filling noise function that gets sampled at progressively larger distances from the original point and with each successive point scaled by 1/2^n to reduce the magnitude of successive additions. The noise function is what's critical for the appearance of the final result. The traditional sinuous rills in the RidgedMultifractal routine come from an absolute value of a cubic-interpolated noise field (it's the cubic interpolation that gives the smooth transitiions).

If you can, I'd recommend locating a copy of Texturing and Modeling: A procedural approach ( http://www.amazon.com/Texturing-Mode...dp/1558608486/ ). Earlier editions of the book are pretty much as good as the latest for the discussion of basic noise functions.

[waldronate]

I am not one to use a soap box to say that noise is a good method for creating good terrain. I think the system needs to know more than mere noise functions to do it well.

http://www.pandromeda.com/ also says that you might want to do more than just basic noise functions (it's where Musgrave ended up).

[xoxos]

waldronate - TY for replies, and i do hope not to take up too much of anyone's attention.

i've been using perlin in audio, and as an audio coder i'm well used to octaves, and certain conventions in procedure. i'll explain my implementation somewhat, which may elicit why i'm seeing things differently.

audio requires speed, so wherever possible, i use INTs, and unsigned ones at that. my noise map is unsigned short[x][y] and each octave is a stored array smaller by a power of two.

(or what i prefer to call a tower of poo)

each octave is stored and cosine interpolation is used at summing each octave to discern any coordinate (i'm familiar with bicubic interpolation but cosine looks well enough and is faster given that i'm using INTs and ^2, so all cosine functions use a ^2 array of float values).

so my variables for each octave range 0 - 65535. i sum them using n^2 for successive octaves.. typical perlin, and squish this range into my desired outcome (0-255 for bitmap output, data is retained in the 2^16 for processing).

it is trivial to use 0 or 65535 for the outcome of each cell, but this doesn't look too different from standard perlin. the outcome of the previous layer is used to determine the magnitude of the subsequent, or something like that?

the approach in musgrave.h is very different from my set of discretised arrays... so i've been searching for a non-code explanation of the procedure

here's an example of output using perlin octaves, no smoothing to illustrate my current progress..
ground.jpg

[xoxos]

(to be unnecessarily thorough..)

if each layer is 0-65535, the summing is as such:

layer 0 65536 / 1 = 65536
layer 1 65536 / 2 = 32768
layer 2 65536 / 4 = 16384
layer 3 65536 / 8 = 8192
layer 4 65536 / 16 = 4096
layer 5 65536 / 32 = 2048
layer 6 65536 / 64 = 1024
layer 7 65536 / 128 = 512
sum of all layers = 130,560

fitting this to a range of 256 for pixelation = divide total by 510 (256 * 510 = 130,560)

as such, i can manipulate the data for each layer without having to recalculate every layer, only resum the output....

given my b/g, using unsigned INTs seems natural to me, it's fast, it's the way i do things.. so eg. a lacunarity coefficient doesn't fit into my method at all.

[xoxos]

unseen post #3....

i have yet to test it, but it looks like i've found my answer.

and, like all frustrating referential answers for programming, it is absurdly simple.. i confused my understanding by using an unsigned range. when casual descriptions said "absolute value" i assumed a switched output (the 0 OR 65535 mentioned above...) because negative outcomes never factored in...

.....what it appears to be, from the reference i have found (pp. 553 Multifractals, Probability and Statistical Mechanics, Applications google preview) is bloody simple...

..referencing audio.. if you have a curvy (interpolated) waveform and rectify it (flip sign of negative samples.. or *absolute* value ...you get a bunch of bumps (eg. sinewave becomes mcdonalds "M" logo) - so the "ridges" are merely (1-McDonalds)... aargh.. so infuriatingly simple.. if that page had still been up it would have saved me about five hours of browsing for the answer....

..i expect i'll be back. i'm not going to duplicate the functionality of wilbur, but i do wish to explore many of these functions TY all

[xoxos]

?? there were two posts before that that were tagged "must be approved by moderator" that had lengthy explanations of my perspective here... i hope they haven't been cast to the abyss....

[xoxos]

well, for the sake of comprehension..... i will reiterate my statements concicely.

i was elaborating on my familiarity with the topic, and posted a map that is visible in my introductory thread indicating my use of 2d perlin. i described my background as an audio coder, my preference for INTs (and unsigned INTs) for speed, and my algorithm (which was a lengthy description) which, as you may now suspect, used unsigned shorts for my height field.. i described how i stored a separate array for each octave for editing, and subsequently why, using unsigned variables, much of the other code i had found was quite different from my own sensibility.

well, i'll take some deep breaths, and report back with hopefully improved results for ridgyness.