I've just created an isosurface object which is a flat block
with a random rippled surface, but there are what appears
to be a grid of creases running across the surface 1 unit
apart.

Is this a feature of the isosurface or f_noise3d() and is
there any way to avoid this ? (I have tried the different
noise generators, and changing the isosurface accuracy and
max_gradient).

Thanks,

Bernard

// example code
#include "functions.inc"

global_settings { noise_generator 2 }

light_source { <0,90,0> color rgb <1,1,1> }

camera {right <image_width/image_height,0,0> location y*7.5 look_at 0 }

isosurface
{
    function{y-f_noise3d(x,0,z)}
    max_gradient 2
    contained_by{ box{<-6,-1,-4>,<6,2,4>}}
    pigment { rgb <0.25,1,0> }
    finish {phong 0.28 phong_size 16}
}

Post a reply to this message

"Bernard Hatt" <bmh### [at] arkadydemoncouk> wrote in message
news:41F95C5E.1609E60A@arkady.demon.co.uk...
>
> I've just created an isosurface object which is a flat block
> with a random rippled surface, but there are what appears
> to be a grid of creases running across the surface 1 unit
> apart.
>

I rendered the sample-scene and saw what you meant. This rings a vague
bell...

http://news.povray.org/povray.advanced-users/thread/%3C3d14a873%40news.povra
y.org%3E/

but that's from 3.5RC6 days, and implies it was a known issue that would be
resolved, so I'm a bit lost. It seems odd that I've never noticed it - I use
f_noise3d fairly frequently.

Post a reply to this message

> Is this a feature of the isosurface or f_noise3d() and is
> there any way to avoid this ?

This is a "feature" of f_noise3d. Regardless of which noise generator you
use, each one is internally based off of some sort of interpolation between
points on a grid, and this becomes much more apparent when it is used as a
physical surface - especially with reflection or specular highlights.

Your best bet is to somehow modify the pattern so that this isn't a problem.
I had a little luck with adding turbulence to the noise function:

 #declare noisefunc = function { pigment {
  bozo
  color_map {[0 rgb 0][1 rgb 1]}
  warp {
   turbulence 3
   octaves 2
   lambda 4
   omega .2
  }
  scale 4
 } }
 function{y-noisefunc(x,0,z).red}

But of course this looks different and even the turbulence is based off of
the same function as f_noise3d is, so it doesn't completely solve the
problem. Fiddle with the turbulence parameters.

If you can't find another pattern that works well, you can always make your
own in a 2D image editor like Photoshop.

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

Post a reply to this message

Tom Melly wrote:
> I rendered the sample-scene and saw what you meant. This rings a vague
> bell...
> 
> http://news.povray.org/povray.advanced-users/thread/%3C3d14a873%40news.povra
> y.org%3E/
> 
> but that's from 3.5RC6 days, and implies it was a known issue that would be
> resolved, so I'm a bit lost. It seems odd that I've never noticed it - I use
> f_noise3d fairly frequently.

Thanks for the info, looking at the discussion and the code it is
quite a complex problem...

I can't help feeling there must be an algorithm which doesn't suffer
from these problems, I might have a play around and see if I can
find one..

Regards,

Bernard

Post a reply to this message

Slime wrote:

> This is a "feature" of f_noise3d. Regardless of which noise generator you
> use, each one is internally based off of some sort of interpolation between
> points on a grid, and this becomes much more apparent when it is used as a
> physical surface - especially with reflection or specular highlights.
> 
> Your best bet is to somehow modify the pattern so that this isn't a problem.
> I had a little luck with adding turbulence to the noise function:

[...]

Thanks for the workaround code, it does look quite good. I'll
experiment with it and f_waves/f_ripples to see what I can
produce.

Regards,

Bernard

Post a reply to this message

In article <41FC85EB.F2421F3A@arkady.demon.co.uk>,
 Bernard Hatt <bmh### [at] arkadydemoncouk> wrote:

> Thanks for the info, looking at the discussion and the code it is
> quite a complex problem...

There are two similar problems. One is a discontinuity in the second 
derivative of the noise function at points on the lattice...this one is 
fixed, as far as I know. The second problem is more fundamental, a 
lattice of points with values near 0.5 (maybe not exact, due to the way 
POV transforms the output range of the noise function)...all POV-Ray's 
noise generators have this problem, and it is not "fixable".


> I can't help feeling there must be an algorithm which doesn't suffer
> from these problems, I might have a play around and see if I can
> find one..

There are algorithms that don't suffer from the lattice artifact. I've 
been polishing up a patch that implements one of them, the Lewis sparse 
convolution noise algorithm. However, there is a tradeoff in speed.

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

"Christopher James Huff" <cja### [at] earthlinknet> wrote in message
news:cjameshuff-0D7CA7.14273931012005@news.povray.org...

> There are two similar problems. One is a discontinuity in the second
> derivative of the noise function at points on the lattice...this one is
> fixed, as far as I know. The second problem is more fundamental, a
> lattice of points with values near 0.5 (maybe not exact, due to the way
> POV transforms the output range of the noise function)...all POV-Ray's
> noise generators have this problem, and it is not "fixable".

I'll take your word for it - I just remain mystified why it's never been a
noticeable artifact in any iso I've made with f_noise. <goes off to play
with f_noise>

Post a reply to this message

Bernard Hatt wrote:
> Thanks for the workaround code, it does look quite good. I'll
> experiment with it and f_waves/f_ripples to see what I can
> produce.

If anyone is interested, having now played around a bit, a simple
solution was to replace the isosurface with a height_field which
also renders much quicker.

height_field
{
        function 128,128 {f_bozo(x*12+6,y*12-6,z)}
        smooth
        translate <-0.5,0,-0.5>
        scale <12,1,12>
        pigment { rgb <0.25,1,0> }
        finish {phong 0.28 phong_size 16}
}

Regards,

Bernard

Post a reply to this message