Thanks for your input.

I have tried it now, and unfortunately it has not fixed the problem.  I'm
getting more puzzled by the hour.

Any other suggestions

Post a reply to this message

Felbrigg wrote:
> 
> Thanks for your input.
> 
> I have tried it now, and unfortunately it has not fixed the problem.  I'm
> getting more puzzled by the hour.
> 
> Any other suggestions

After rendering the scene and trying a few things it appears to be a
mathematical precision error. If you scale down the container boxes
the discontinuities you see dissapear, e.g. -

#include "colors.inc"
#include "functions.inc"
global_settings {
                max_trace_level 80
                }
camera  {
        location <-45,5,118>*.5 look_at <-50,-1,138>
       }


background { color <0.25,0.35,0.80> }

#declare DesertScape =
        isosurface {
           function  {y - f_snoise3d(x/350, 0, z/490)*170.5}
           max_gradient 2
                contained_by {box {     <-40000,-180,-10000>*.5,
                                        < 40000, 180, 10000>*.5}}
        texture {pigment { Green }
                }
}


#declare WaterScape =
        isosurface {
           function { y - (f_ripples(x/2,y,z)*0.05) + (f_snoise3d(x/2, 0,z/2)*0.1)}
           max_gradient 2
                contained_by {box {     <-400,-180,-500>*.5,
                                        < 0, 180, 500>*.5}}
        texture {
                pigment { Clear }
                }
        translate <0,-9,0>
        hollow
        scale <1,1,1>

}


object  { WaterScape scale <1.01,1,1.01> rotate <0,100,0>}
object  { DesertScape translate <-100,0,0> scale <1.01,1,1.01>}

light_source { <-10000, 60030, -28500> colour White }


-- 
Ken Tyler

Post a reply to this message

In article <40191833.DC831BDF@pacbell.net> , Ken <tyl### [at] pacbellnet>  
wrote:

> After rendering the scene and trying a few things it appears to be a
> mathematical precision error.

Note: Limits of mathematical precision available on any computer are not an
error of the computer.  And they are not an error in POV-Ray either.  It is
very important to make this clear to new users from the very beginning to
avoid misconceptions about what is an error and what is expected but not
necessarily nice property of floating-point* numbers! :-)

    Thorsten

* For anybody wondering what a floating-point number is, the short answer is
that they use various mathematical "tricks" to allow representation of
values of an almost infinite range with only a small number of digits.  The
"tricks" used in essence reduce precision to ten to 15 leftmost digits of
any number.  Of course, all this is a very simplified explanation!

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <4018e074@news.povray.org>,
 "Felbrigg" <som### [at] microsoftcom> wrote:

> I'm working on a scene that has two isosurfaces ( hills and water ) but
> where they meet I'm getting a line of artifacts.  I've included a much
> simplified version of the scene below in the hope that someone can throw
> some light on the matter for me.  Note : one of the isosurfaces has a
> "Clear" pigment, so you wont see it when it renders, but you will see the
> line of artifacts.  This "clear" isosuface must remain clear as it will
> eventually be water.

You're using the default accuracy, which is low enough that POV gets 
confused when it tries to find the right intersections. At the points 
where the artifacts show up, the green isosurface is just too close to 
the clear one for the solver to work reliably...sometimes the clear one 
is hit first, when it is actually behind the green isosurface, in which 
case the transmitted ray goes off to nowhere. Also, intersections too 
close to the start point of the ray are ignored, to avoid problems where 
rays reflecting off of or refracting through an object immediately hit 
it again due to precision errors. Putting "accuracy 0.0001" in both 
isosurfaces fixed the problem, though rendering will be slower. Higher 
resolution renders may need more accuracy. Antialiasing will help to 
soften or eliminate the artifacts, as well, especially scattered 
single-pixel "dust".

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

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:401930c3$1@news.povray.org...
>
>
> * For anybody wondering what a floating-point number is, the short answer is
> that they use various mathematical "tricks" to allow representation of
> values of an almost infinite range with only a small number of digits.  The
> "tricks" used in essence reduce precision to ten to 15 leftmost digits of
> any number.  Of course, all this is a very simplified explanation!

http://tinyurl.com/272fa

This is a faq wot I wrote on floats - feel free to point out any obvious errors.
(I was inspired to write it when I found a customer storing social-security
numbers as floats!)

Post a reply to this message

Tom Melly <tom### [at] tomandlucouk> wrote:
> This is a faq wot I wrote on floats - feel free to point out any obvious errors.
> (I was inspired to write it when I found a customer storing social-security
> numbers as floats!)

  You might also tell something about comparing floating point numbers
and why for example the comparison sqrt(100)=10 will probably return
false.

  By the way, you could also say "in computer languages there's usually
a shortcut for writing '*10^' by writing 'e' instead. That is, for
example 1234*(10^12) can be written as 1234e12". Then from that point
forward you can use the e-syntax instead of the *10^ one for clarity.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message news:401a3203@news.povray.org...

>   By the way, you could also say "in computer languages there's usually
> a shortcut for writing '*10^' by writing 'e' instead. That is, for
> example 1234*(10^12) can be written as 1234e12". Then from that point
> forward you can use the e-syntax instead of the *10^ one for clarity.

Good idea - although I might not use that notation in the examples as, for the
novices, it might just be another layer of abstraction getting in the way of
understanding the issue.

BTW the graphics on the page (and site) are all rendered in POV. (although if
you wander outside of cgi-bin you'll hit a username/password request).

Post a reply to this message

Thank you vary much Christopher, you've solved it!!  I had to set the
accuray to 0.000001 to be rid of all the artifacts, but its fixed.  Huzzar!

I especially appreciate the explanation.  As I understand it, the accuracy
setting is like increasing the "Zoom" on the ray tracings engine.

I'll post the finished image when its rendered ( probably take most of the
weekend ) so you can see what you've helped along.

Thanks again.

Post a reply to this message

In article <401a832c$1@news.povray.org>,
 "Felbrigg" <som### [at] microsoftcom> wrote:

> Thank you vary much Christopher, you've solved it!!  I had to set the
> accuray to 0.000001 to be rid of all the artifacts, but its fixed.  Huzzar!

That's probably pushing the boundaries of what will work, especially if 
you're using functions that are already stretching machine precision 
limits.


> I especially appreciate the explanation.  As I understand it, the accuracy
> setting is like increasing the "Zoom" on the ray tracings engine.

I'm not sure what you're thinking of, but it just controls the allowable 
error in the isosurface calculations. The isosurface solver just takes a 
series of progressively refined estimates, the accuracy parameter tells 
it when it can stop refining its result and decide it found the 
intersection point. The actual intersection will be somewhere within 
"accuracy" distance of that point. (note that this doesn't necessarily 
mean distance within the scene...scaling can change the relationship 
between what's one unit to the object and what's one unit in the scene)

Anyway, since the value found is not the true value, you can end up with 
a situation where the transparent isosurface is the first one hit, but 
when POV traces a ray from the computed intersection point, it misses 
the green isosurface. Or hits it, decides it's so close to the ray 
origin that it's likely to be an erroneous hit on the transparent 
object, and ignores 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

I've posted the finished image in the povray.binaries.images section, look
for "Cactus Halo".

Thanks for your help.


"Christopher James Huff" <cja### [at] earthlinknet> wrote in message
news:cjameshuff-6DF932.14392730012004@news.povray.org...
> In article <401a832c$1@news.povray.org>,
>  "Felbrigg" <som### [at] microsoftcom> wrote:
>
> > Thank you vary much Christopher, you've solved it!!  I had to set the
> > accuray to 0.000001 to be rid of all the artifacts, but its fixed.
Huzzar!
>
> That's probably pushing the boundaries of what will work, especially if
> you're using functions that are already stretching machine precision
> limits.
>
>
> > I especially appreciate the explanation.  As I understand it, the
accuracy
> > setting is like increasing the "Zoom" on the ray tracings engine.
>
> I'm not sure what you're thinking of, but it just controls the allowable
> error in the isosurface calculations. The isosurface solver just takes a
> series of progressively refined estimates, the accuracy parameter tells
> it when it can stop refining its result and decide it found the
> intersection point. The actual intersection will be somewhere within
> "accuracy" distance of that point. (note that this doesn't necessarily
> mean distance within the scene...scaling can change the relationship
> between what's one unit to the object and what's one unit in the scene)
>
> Anyway, since the value found is not the true value, you can end up with
> a situation where the transparent isosurface is the first one hit, but
> when POV traces a ray from the computed intersection point, it misses
> the green isosurface. Or hits it, decides it's so close to the ray
> origin that it's likely to be an erroneous hit on the transparent
> object, and ignores 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