I'm hoping to make an image which will mostly be a series of grassy
hills in the rain. I've got the clouds, I think, and the rain's a task
I'm willing to take a shot at. Grass will be a nightmare of its own and
obviously a lot of fudging is required. I've started working with the
hills, but that's where I've run into the first problems.
I really don't want to generate any height maps for this one. My
preference is to use an isosurface (I'm using the Superpatch) with a
kind of hilly function. I thought of multipying a couple of sine waves
together, but the results on that have so far been pretty terrible.

For those who are interested in knowing more, this is meant to be the
background for a CD cover (I'll be putting an object in the foreground
of the front half), so it will be a 2x1 aspect ratio.
And hey, if anyone has any advice on rendering liquids and radiant
objects (in this case both), *any* advice would be appreciated.

Lummox JR

Post a reply to this message

Wasn't it Lummox JR who wrote:
>I'm hoping to make an image which will mostly be a series of grassy
>hills in the rain. I've got the clouds, I think, and the rain's a task
>I'm willing to take a shot at. Grass will be a nightmare of its own and
>obviously a lot of fudging is required. I've started working with the
>hills, but that's where I've run into the first problems.
>I really don't want to generate any height maps for this one. My
>preference is to use an isosurface (I'm using the Superpatch) with a
>kind of hilly function. I thought of multipying a couple of sine waves
>together, but the results on that have so far been pretty terrible.

Rather than using sin waves, you might find it better to start with an
isosurface of the y plane [ function {abs(y)} ] and then add some random
hilly bumps by subtracting a noise function or a pigment function, like

    function { abs(y) - noise3d(x,0,z)*0.5 }

It's possible to add a suggestion of ground cover (unfortunately, not
particularly grassy) foliage by subtracting another noise or pigment
function at a much smaller scale, like

    function { abs(y) - noise3d(x,0,z)
               -noise3d(x*100,0,z*100)*0.02
             }

-- 
Mike Williams * ##
Gentleman of Leisure

Post a reply to this message

Mike Williams wrote:
> Rather than using sin waves, you might find it better to start with an
> isosurface of the y plane [ function {abs(y)} ] and then add some random
> hilly bumps by subtracting a noise function or a pigment function, like
> 
>     function { abs(y) - noise3d(x,0,z)*0.5 }
> 
> It's possible to add a suggestion of ground cover (unfortunately, not
> particularly grassy) foliage by subtracting another noise or pigment
> function at a much smaller scale, like
> 
>     function { abs(y) - noise3d(x,0,z)
>                -noise3d(x*100,0,z*100)*0.02
>              }

I took your advice on the basic hill structure (haven't gotten as far as
ground cover yet) and used a formula that was basically
y-noise3d(x,0,z), with a little noise added to x and z as well to
turbulate it a bit.
Unfortunately, although the basic shape is right, I've run into an
interesting problem: Because the noise function is clipped to values of
0 to 1, most of the resulting hills have flat surfaces.
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'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.

Lummox JR

Post a reply to this message

Lummox JR wrote:
> 
> Mike Williams wrote:
> > Rather than using sin waves, you might find it better to start with an
> > isosurface of the y plane [ function {abs(y)} ] and then add some random
> > hilly bumps by subtracting a noise function or a pigment function, like
> >
> >     function { abs(y) - noise3d(x,0,z)*0.5 }
> >
> > It's possible to add a suggestion of ground cover (unfortunately, not
> > particularly grassy) foliage by subtracting another noise or pigment
> > function at a much smaller scale, like
> >
> >     function { abs(y) - noise3d(x,0,z)
> >                -noise3d(x*100,0,z*100)*0.02
> >              }
> 
> I took your advice on the basic hill structure (haven't gotten as far as
> ground cover yet) and used a formula that was basically
> y-noise3d(x,0,z), with a little noise added to x and z as well to
> turbulate it a bit.
> Unfortunately, although the basic shape is right, I've run into an
> interesting problem: Because the noise function is clipped to values of
> 0 to 1, most of the resulting hills have flat surfaces.

I vaguely remember someone complaining about a similar problem, and
noting that using dents as a function eliminated the plateaus.

-- 
Xplo Eristotle
http://start.at/xplosion/

Post a reply to this message

In article <38D33F32.944064C4@unforgettable.com>, 
inq### [at] unforgettablecom wrote:

> I vaguely remember someone complaining about a similar problem, and
> noting that using dents as a function eliminated the plateaus.

It doesn't eliminate them, but it makes them less noticeable. It just 
cubes the noise3d function, which makes the change in curvature almost 
invisible.(and I think it is one of the functions which has a special 
evaluation method for normals in the official version)

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <38D### [at] aolcom>, Lummox JR <Lum### [at] aolcom> wrote:

> I took your advice on the basic hill structure (haven't gotten as far as
> ground cover yet) and used a formula that was basically
> y-noise3d(x,0,z), with a little noise added to x and z as well to
> turbulate it a bit.
> Unfortunately, although the basic shape is right, I've run into an
> interesting problem: Because the noise function is clipped to values of
> 0 to 1, most of the resulting hills have flat surfaces.

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()).


> 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?


> 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).

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

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

In article <38D### [at] aolcom>, Lummox JR <Lum### [at] aolcom> wrote:

> 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()

These sound interesting...I notice that they have already been included 
in MegaPOV.


> - int_func3d() was completely rewritten and evaluate_interval()
>   changed to allow interval (method 1) testing which wasn't possible
>   before

Could you clarify this? I don't really understand what you mean.


> - 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)

Is this related to the second normal calculation method, also included 
in MegaPOV?


> 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.

Could you add 4D noise while you are at it? :-)
I think this might be useful for some things, maybe for fire.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff wrote:
> > Modifications I've made so far to the function code:
> >
> > - Added functions floor(), ceil(), if() (like the C ?: operator),
> >   pi, clock, atan2(), radians(), degrees()
> 
> These sound interesting...I notice that they have already been included
> in MegaPOV.

Hmmm... I wonder if they're mine.
All those function changes I sent out to Ron Parker for the Superpatch.
The isoblob patch I don't think is in there, though.

> > - int_func3d() was completely rewritten and evaluate_interval()
> >   changed to allow interval (method 1) testing which wasn't possible
> >   before
> 
> Could you clarify this? I don't really understand what you mean.

Interval testing works for most functions, but it doesn't work for a
function within a function. Example:

#declare F1=function {cub(x)+sqr(y)}
#declare F2=function {F1(x,y)-F1(y,z)}

An isosurface using function F2 can't use method 1 because the intervals
for F1 aren't tested properly. I rewrote int_func3d, which was basically
just an empty do-nothing function, to act the way it was supposed to in
the first place.

> > - 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)
> 
> Is this related to the second normal calculation method, also included
> in MegaPOV?

That I wouldn't know; I haven't seen MegaPOV or its source. For all I
know it might be based on my patch--if you have the source, my name
should be plastered all over f_func.c and several related files if it's
based on my code.

> > 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.
> 
> Could you add 4D noise while you are at it? :-)
> I think this might be useful for some things, maybe for fire.

Funny, but I was thinking along the exact same lines earlier when I was
modifying the code. It occurred to me that it would be nice to have an
N-dimensional noise function. Many a time I've wanted to have 4D noise
for clouds and such. If I understand the Noise() code well enough,
basically all you'd have to do would be to recurse the sucker. This
could extend noise to as many dimensions as you'd want, if it was done
right. (Of course, some preprocessing would help to prevent a lot of
useless recalculations, since speed is always a factor.)
I really don't know how this could be included in the function code
without greatly modifying it, since the code wasn't intended to go past
3 arguments per function. (The so-called 4-argument functions are
actually just a declared function number plus 3 more arguments.) I've
always wanted to see if that could be arbitrarily extended; the
challenge is definitely intriguing enough for me to take it up sometime.

BTW, I've gone ahead and added the Noise_raw function to texture.c. I
gave it a function name "bozo", to avoid having to add one more keyword
to the parser.
I added two new functions while I was in there:

range(v,min,max)  -- basically a shortcut for min(max(v,min),max)
bozo(x,y,z) -- raw noise

Lummox JR

Post a reply to this message

In article <38D### [at] aolcom>, Lummox JR <Lum### [at] aolcom> wrote:

> Hmmm... I wonder if they're mine.

Yep.


> All those function changes I sent out to Ron Parker for the Superpatch.
> The isoblob patch I don't think is in there, though.

In where? MegaPOV, or the source changes you sent to Ron? The isoblob 
patch is included in MegaPOV, if that is what you meant.


> That I wouldn't know; I haven't seen MegaPOV or its source. For all I
> know it might be based on my patch--if you have the source, my name
> should be plastered all over f_func.c and several related files if it's
> based on my code.

Ah, ok. I somehow had the impression you were using MegaPOV source as 
your base. I found the code neatly arranged in a single block starting 
with this:
#ifdef IsoBlobPatch
/* Functions added by Lummox JR, June 1999 */


> I really don't know how this could be included in the function code
> without greatly modifying it, since the code wasn't intended to go past
> 3 arguments per function. (The so-called 4-argument functions are
> actually just a declared function number plus 3 more arguments.) I've
> always wanted to see if that could be arbitrarily extended; the
> challenge is definitely intriguing enough for me to take it up sometime.

I would certainly be interested in the results. It would also be nice to 
allow user defined functions to have a variable number of parameters, 
how possible do you think that would be?


> BTW, I've gone ahead and added the Noise_raw function to texture.c. I
> gave it a function name "bozo", to avoid having to add one more keyword
> to the parser.

Sounds interesting, although the use of "bozo" would have to be changed 
before it is distributed...
Maybe call it rnoise()?


> I added two new functions while I was in there:
> 
> range(v,min,max)  -- basically a shortcut for min(max(v,min),max)

Why not call it "clamp()"? I think it is more explanatory.
BTW, I use this code when I need this function, although having it hard 
coded is probably a good idea:
#declare clamp = function {min(y, max(x, z))}
clamp(value, minimum, maximum)

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message