Most of you know that I'm creating a lot of noise generator features. I've
created a new syntax for these:

noise_generator {
 4
 slice 10
 repeat 20
 match_second_derivatives on
}

This works great for patterns.

I realized, though, that people will want something to replace
f_noise3d(x,y,z). So I figured the best solution to this would be to create
a noise_generator function type:

function my_noise_gen {
 noise_generator {
  4
  slice 10
  repeat 20
  match_second_derivatives on
 }
}

which could later be used like my_noise_gen(x,y,z).

I've spent most of today turning the noise generator into an actual object
so that I should be able to do this next. However, one problem remains:
internal functions. These functions (like f_ridged_mf) currently take a
noise generator *number* as an argument. However, this makes it impossible
to use the extra features.

So what I need is some sort of syntax to let the user decide what noise
generator to use with an internal function. I can't come up with anything.
Any suggestions?

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

> function my_noise_gen {
>  noise_generator {
>   4
>   slice 10
>   repeat 20
>   match_second_derivatives on
>  }
> }


Heh, this should be

#declare my_noise_gen = function {
...

My brain was in Javascript mode. =)

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

In article <3db318e9@news.povray.org>, "Slime" <slm### [at] slimelandcom> 
wrote:

> So what I need is some sort of syntax to let the user decide what noise
> generator to use with an internal function. I can't come up with anything.
> Any suggestions?

Maybe we should collaborate. I want to completely redo the noise 
generator syntax, and dump the existing noise_generator code entirely 
(it is too hard to make additions and extensions).

#declare Perlin =
function {perlin_noise {NOISE_GENERATOR_STUFF}}

#declare OldNoise =
function {old_noise {rescale on|off NOISE_GENERATOR_STUFF}}

#declare Lewis =
function {
    lewis_noise {
        cos|cone|scurve|function
        impulses NUM_IMPULSES
        NOISE_GENERATOR_STUFF
    }
}

#declare Perlin4D =
function {
    perlin_4d_noise {
        slice TIME_PARAM
        NOISE_GENERATOR_STUFF
    }
}

NOISE_GENERATOR_STUFF would be:
seed SEED
For creating generators with different seeds.

range MIN, MAX
For setting the output range. Default would be either [-1, 1] or [0, 1].


To use a declared generator:
#declare val = Perlin(1, 2, 3);
#declare val = Perlin4D(1, 2, 3);
#declare val = Perlin4D(1, 2, 3, 4);//slice parameter overridden

pigment {bozo noise_generator Lewis}

function {OldNoise(x, y, z)}

You wouldn't need to declare it:
pigment {bozo noise_generator lewis_noise {...}}

Oh, and any function could be used as a noise generator:
pigment {bozo noise_generator function {pow(sin(Lewis(x, y, z)), 2)}}


I think this could be pulled off without breaking existing scenes.
No scenes depended on the discontinuous second derivatives, so that 
option would be removed (or the old function could be kept as a faster 
option). Don't know what to do about the repeating. It'd be nice if it 
could be done for all the generators without slowing them down.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

> Maybe we should collaborate. I want to completely redo the noise
> generator syntax, and dump the existing noise_generator code entirely
> (it is too hard to make additions and extensions).


Hmm, I like some of these things you propose, and I don't like some of them.

You seem to want to bypass the noise_generator keyword altogether.
Personally, I think that it's a good idea to keep it as a middleman. Here's
what I have working right now:

#declare mynoisegen = noise_generator {
 3
 match_second_derivatives off
}

#declare mynoisegenfunc = function {
 noise_generator{mynoisegen}
}

sphere {
0,1
pigment {
function {mynoisegenfunc(x,y,z)}
}
}

Notice how noise generators are an object that can be declared like any
other, and passed as macro parameters, etc. On a related note, anyone
interested in making fun of me may want to read my last night's blog entry
about the implementation of this ( http://www.slimeland.com/ ).

> seed SEED
> For creating generators with different seeds.

Well, the way the noise generator code works now, the random values are
predetermined when POV-Ray starts up. This makes things a lot faster than if
they were being calculated on the fly: they're merely pulled out of an
array. So I don't think specifying an alternate seed is really a good
option... unless perhaps it were done via a command line parameter or
something...

Anyway, to be honest, my patch was originally just going to be a couple of
bugfixes so that I could do something that POV-Ray's limitations were
preventing me from doing. Now that I've fixed the bugs and made a couple
workarounds, I'm anxious to finish the patch and get back to regular POVing.
Maybe you'll want to download my source code when I release it.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

In article <3db45a23@news.povray.org>, "Slime" <slm### [at] slimelandcom> 
wrote:

> Hmm, I like some of these things you propose, and I don't like some of them.

I'm not surprised. :-)


> You seem to want to bypass the noise_generator keyword altogether.

No, look at the later examples. The noise_generator keyword is used to 
set the noise generator for patterns (and potentially other noise-using 
things). It just seemed kind of redundant to use it for every kind of 
noise generator functions.


> Notice how noise generators are an object that can be declared like any
> other, and passed as macro parameters, etc. On a related note, anyone
> interested in making fun of me may want to read my last night's blog entry
> about the implementation of this ( http://www.slimeland.com/ ).

My first syntax idea had the outer "function {}" block eliminated, which 
would be very similar to that. It fits in with the other special 
functions more this way.
Neither version has more capabilities, just the amount of typing.


> Well, the way the noise generator code works now, the random values are
> predetermined when POV-Ray starts up. This makes things a lot faster than if
> they were being calculated on the fly: they're merely pulled out of an
> array. So I don't think specifying an alternate seed is really a good
> option... unless perhaps it were done via a command line parameter or
> something...

The values would be calculated when the noise generator was created, it 
wouldn't slow anything down but parsing, and that wouldn't take long. 
I've done this in my own tracer, and it works fine.


> Anyway, to be honest, my patch was originally just going to be a couple of
> bugfixes so that I could do something that POV-Ray's limitations were
> preventing me from doing. Now that I've fixed the bugs and made a couple
> workarounds, I'm anxious to finish the patch and get back to regular POVing.
> Maybe you'll want to download my source code when I release it.

Alright.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message