 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > > Ken Perlin recently updated his perlin noise algorithm with a new
> > > polynomial S-curve function that eliminated second-derivative
> > > discontinuities, maybe that could be of some use as a bounded
function...
> >
> > Do you have any details of this? Sounds quite interesting...
>
> The new polynomial is "1 - r*r*(3 - 2*r)".
Uh, this polynomial doesn't elliminate second derivative discontinuities.
It's the same one currently used for the noise function in POV-Ray. The
second derivative at zero is 6, and the second derivative at 1 is -6.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 13 Oct 2002 22:25:55 -0400, Christopher James Huff
<chr### [at] mac com> wrote:
>The new polynomial is "1 - r*r*(3 - 2*r)".
That looks like the -2*x^3+3*x^2 evaluated in [0;1] - isn't that what
has been used for cubic interpolation for ages now? I've seen this
formula in the source code in a few places, I think cubic_wave is
based on it as well.
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
> In article <3DA99C87.2980A601@dcs.gla.ac.uk>,
> John Williamson <wil### [at] dcsglaacuk> wrote:
>
>>> Ken Perlin recently updated his perlin noise algorithm with a new
>>> polynomial S-curve function that eliminated second-derivative
>>> discontinuities, maybe that could be of some use as a bounded
>>> function...
>>
>> Do you have any details of this? Sounds quite interesting...
>
> The new polynomial is "1 - r*r*(3 - 2*r)".
That's the "old" function, often referred to as "smoothstep function".
That function has a derivative of 6-12*t.
The new function is
6*t^5 - 15*t^4 + 10*t^3
or
t*t*t*(10+t*(6*t-15))
This function has zero first and second derivatives at t=0 and t=1
Details can be found in Ken Perlin's paper at
http://mrl.nyu.edu/~perlin/paper445.pdf
--
Alessandro Falappa
web: http://www.falappa.net/alessandro
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3daa35f2$1@news.povray.org>, "Slime" <slm### [at] slimelandcom>
wrote:
> Uh, this polynomial doesn't elliminate second derivative discontinuities.
> It's the same one currently used for the noise function in POV-Ray. The
> second derivative at zero is 6, and the second derivative at 1 is -6.
Copy/paste error. I thought that looked wrong, but forgot to go back and
check it out...that is the one used in the old noise function, the
correct one is:
#declare scurve = function (r) {6*pow(r, 5) - 15*pow(r, 4) + 10*pow(r,
3)}
This will also work, and may be faster in C, though probably not for POV
functions:
#declare scurve = function (r) {((6*r - 15)*r + 10)*r*r*r}
It is bounded, making it more controllable and possible to optimize, and
seems to do fine at eliminating visible discontinuities.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> the
> correct one is:
> #declare scurve = function (r) {6*pow(r, 5) - 15*pow(r, 4) + 10*pow(r,
> 3)}
Sweet. Since this will probably also elliminate the problems with 3D noise,
maybe I'll implement it as a noise_generator option in my patch.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3daaf81e@news.povray.org>, "Slime" <slm### [at] slimelandcom>
wrote:
> Sweet. Since this will probably also elliminate the problems with 3D noise,
> maybe I'll implement it as a noise_generator option in my patch.
Just replace the SCurve() function in texture.cpp with this
implementation. There are some other optimizations that can be done to
offset the more expensive s-curve function. It will be duplicate work,
since the POV Team is aware of this and probably already has an
implementation, but I don't know of any patches that have been publicly
released.
However, this won't fix all the problems with Perlin noise. The function
still goes to 0 at regular intervals...since the POV version is
re-scaled to the [0, 1] range, it goes to 0.5. If you use a function
with something like "fabs(f_noise() - 0.5)" in it, you will see a grid
pattern. This occurs in POV's implementation (though it doesn't go to
0.5 exactly, probably because of the seed used), my own implementation,
and is visible in Ken Perlin's sample images (use the threshold filter
in some image processing program to see it). This is a result of the way
it is calculated, you can't really get away from it.
There are other noise algorithms, for example, Lewis sparse convolution
noise doesn't have any annoying artifacts that I can find. The drawback
is that it is slower, about half to 1/3 as fast in normal usage from my
experience. (this is normal usage, it has parameters that can make it
arbitrarily slow)
I've done a patch with Lewis noise, I can release it publicly if there
is interest (the POV Team already has it).
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, the point isn't to elliminate the fact that the pattern is *based* on
a grid, it's just to elliminate the 2nd derivative artifact that is most
visible when the function is used as a normal pattern. This definitely does
the trick, though the grid is, of course, still visible, but less visible
and less intrusive.
I'll post a picture as soon as I get this working.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3dab0ca2$1@news.povray.org>, "Slime" <slm### [at] slimelandcom>
wrote:
> Well, the point isn't to elliminate the fact that the pattern is *based* on
> a grid, it's just to elliminate the 2nd derivative artifact that is most
> visible when the function is used as a normal pattern. This definitely does
> the trick, though the grid is, of course, still visible, but less visible
> and less intrusive.
> I'll post a picture as soon as I get this working.
I've done enough looking at pictures of noise. ;-)
I spent a couple days looking for the problem before I figured out the
grid artifacts weren't a problem with my implementation.
My point was that this doesn't fix all the problems. Most of the time
when these changes are mentioned, it is implied that they remove all
grid artifacts.
I could do some more work on Lewis noise and release the patch if you
are interested.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
>> I don't know what is the *correct* or the perfect way to smooth a blob,
>but
>> I just don't like the way the components react to each other sometimes.
>> Sometimes there is a visible edge between two spheres that isn't as smooth
>> as the rest of the blob and usually the appearance of the blob is too
>> smooth.
>
>
>This is due to the exact same mathematical property that causes a similar
>"grid" artifact in the noise function: first derivatives match up, second
>ones don't. It's not an easy problem to solve.
>
> - Slime
>
Actually, I was bothered by this as well, and came up with my own equation
that matches 1st AND 2nd derivatives to 0 at the center and the edge of the
blob component.
In the documentation, they list the blob falloff equation as (1-r^2)^2.
This results in the following values (assuming radius of 1):
Distance from center:
0.0 0.5 1.0
"density" 1.0 0.5625 0.0
1st der. 0.0 -1.5 0.0
2nd der. -4.0 -1.0 8.0
As you can see, the second derivatives are quite large.
My function uses the following equation:
1.0 - (6*r^5 - 15*r^4 + 10*r^3)
This equation yeilds the following values:
Distance from center:
0.0 0.5 1.0
Value 1.0 0.5 1.0
1st der. 0.0 -1.875 0.0
2nd der. 0.0 0.0 0.0
Note that this function has two main advantages over the standard function.
First, it reaches a threshold of 0.5 at exactly half the radius. This
makes calculating the size of your components very precise. Second, the
curvature (i.e. 2nd derivative) is 0 at 0, 0.5, at 1 times the radius. The
benfit of this is that when two components touch, the curvature at the
contact points does not abruptly change (easily noticed if you have a good
eye, but even easier to notice if the surface is reflective/refractive!).
To see this for yourself, calculate the 1st and second derivatives in
symbolic form:
1st: 30*r^2*(r-1)^2
2nd: 120*r*(r-0.5)*(r-1)
Note that the 1st derivative has zeroes (roots) at 0 and 1, whereas the 2nd
derivative has zeroes at 0, 0.5, and 1. Also note that this equation is
symmetric around r=0.5, whereas the standard formula is not. This means
that negative blobs can be used more effectively when placed with the
center at the edge of another component, with the same radius. The
symmetric equations will exactly cancel along the line between the two
components!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>Actually, I was bothered by this as well, and came up with my own equation
>that matches 1st AND 2nd derivatives to 0 at the center and the edge of the
>blob component.
>.......
>My function uses the following equation:
>1.0 - (6*r^5 - 15*r^4 + 10*r^3)
>
I didn't realize that there were more replies after the first page of ten
(I'm new to this newsgroup thing), and apparently I'm not the first that
came up with this particular equation. That being said, I think it would
be worth hardcoding this particular equation for speed, the way the
standard blob function is hardcoded and optimized. We could call it blob2!
Or smooth_blob!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
