 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Help!
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.
thanks.
#include "colors.inc"
#include "functions.inc"
global_settings {
max_trace_level 80
}
camera {
location <-45,5,118> 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>,
< 40000, 180, 10000>}}
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>,
< 0, 180, 500>}}
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 }
//light_source {<-10000, 60030, -28500> color <1.01,1,1> area_light <3600,
0, 0>, <0, 0, 3600>, 9, 9 adaptive 1 jitter photons { refraction on
reflection on } }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Felbrigg wrote:
>
> Help!
>
> 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.
Sounds like a typical max trace level problem. Try adding this to your scene
file and it should fix your problem -
global_settings
{
max_trace_level 10
}
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks for your attention, but sadly "max trace" is a has been, on this one.
In desperation i've already tried setting it as high as eighty. I've also
tried scaling the isosurfaces with no improvement.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <4018f3af@news.povray.org> , "Felbrigg" <som### [at] microsoft com>
wrote:
> Thanks for your attention, but sadly "max trace" is a has been, on this one.
> In desperation i've already tried setting it as high as eighty. I've also
> tried scaling the isosurfaces with no improvement.
Did you try adding "all_intersections" to the transparent isosurface object?
Thorsten
____________________________________________________
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
