In article <395888ED.2795AED3@iname.com>, Jerome <ber### [at] inamecom> 
wrote:

> 	See the attached result: there is much less red than any of
> the others, so this isn't the correct behavior either...

What waveform are you using? You should be using ramp_wave if you want 
to compare this sort of thing. Other waveforms will throw it off, I 
think the default for bozo is sine_wave.


> 	Both make it a completely different function then. The only
> meaningful way yet devised to compute how much two function
> f and g differ is to integrate abs(f()-g()) (or some
> variants involving exposants). Using that distance, my
> function is less different than Nathan's from either the
> truncated or the non truncated original functions

No. The function is the same, only the amplitude is different. It is the 
same function. Your function is different, and has a very different 
distribution. The only reason it resembles the original in any way is 
that the original was faulty.


> 	The attached pic uses the color_map which you said was
> evenly distributed and yet the red is not very present.

Did you use ramp_wave?


> Again, I say that Nathan's function is biased towards the
> middle values (I'll concede that mine and the old one are
> probably biased towards the sides, but Nathan's is no more
> correct)

Nathan's *is* more correct, because it fixes the clipping without 
introducing a bias toward the sides. When designing an isosurface using 
noise3d() or a pigment function, I expect a nice, fairly linear 
function. I often couldn't get the right effect because of the sudden 
"clipping" of the old noise3d(), your function would have a similar 
(though not as severe) problem. The same goes when I am designing 
textures.
Anyway, this looks like it would be better implemented as a pattern 
waveform...it sounds like it will work for any values in the 0-1 range. 
You could also adjust the "flatness" of the ends this way. And I don't 
think the "problems" with functions like multifractals are really as 
severe as you say...people won't have to re-learn them, just adapt to 
the new, corrected noise3d(). Or use #version.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message