Chris Huff wrote:
> This is a known problem, one which I wish would get fixed soon. It also
> occurs with things like the bozo pattern(which is actually identical to
> noise3d()).

Exactly. Another problem I knew people had was that when seen from a
distance, the noise3d() function can have a sort of quilted look to it
because of how the noise function behaves at near-integer values. I
turbulated x and z a bit to get rid of that (or at least disguise it by
varying the lines).

> > The only good solution I can think of would be to modify the f_func.c
> > file (I've made extensive modifications already, so this isn't entirely
> > out of the question) to include an unclipped noise function. (Too bad
> > the function doesn't allow a user-specified pre-clip scaling to avoid
> > that.) I'm not particularly anxious to try that tack if something better
> > can be achieved with the version I'm already using.
> 
> I hope someone does it soon. I don't know enough about that kind of
> function to do anything, but as I understand it, it would be a fairly
> simple modification in one of the hash functions or in the Noise()
> function.
> What are the modifications you have made? Potential new features?

Modifications I've made so far to the function code:

- Added functions floor(), ceil(), if() (like the C ?: operator),
  pi, clock, atan2(), radians(), degrees()
- int_func3d() was completely rewritten and evaluate_interval()
  changed to allow interval (method 1) testing which wasn't possible
  before
- norm_<function> functions added to evaluate an exact normal where
  possible (using a new "normal" keyword as part of an isosurface,
  parametric, or my own isoblob)

I figure an unclipped noise function would probably be extremely
beneficial--especially since raw noise is centered about 0 instead of
0.5. (I also considered running noise through something like a sigmoid
function to constrain it to 0-1, but I think the result would look just
terrible.)

> > I'm going to try some alternate versions like 4*n*(1-n), which should
> > just give me a lot of valleys instead, and see if that works any better.
> > In the meantime, suggestions are still much appreciated.
> 
> You might be able to disguise the plateaus by using multiple calls to
> noise3d() with different values added to the x, y, and z parameters for
> each(to translate the resulting patterns so they don't just reenforce).

Well, I found out that 4*n*(1-n) didn't really work out all that well.
Problem is, of course, that 0.5 (where this hits its maximum) is all too
common a value for noise. Although it doesn't much show in the test
images, this would tend to generate ring-like hills. Squaring or cubing
noise to eliminate the plateaus didn't help either.
My best results came from adding several n*(1-n) values together and
then scaling them to fit within the 0-1 range, but even then the
structures were kind of strange and not very hilly.
I think I'll just go ahead and add an unclipped noise function to the
code; I may as well at this point. I just need something to call it
other than noise3d(), and I'll need to rewrite the interval function to
compensate for the fact that this can reach values beyond the 0-1 limit.

Lummox JR

Post a reply to this message