|
 |
I was trying to make a rounded rectangle pane of glass by union { } of some
cylinders and boxes. That of course is a bad idea because the interior
surfaces. Replaced it by merge, and got a very ugly result. It appears that
the ray tracing on a merged object gets very confused if the ray strikes a
surface that is coincident on more than one element.
I can cure this by intersecting the merged object with a box that's slightly
smaller, to slice off the original surfaces that coincide. The test file below,
adapted from sample file iortest.pov, shows the problem. The plus in the middle
has nasty artifacts (multi-color mottling) in the center of the plus. The one
on the right shows the workaround.
--paul
// This work is licensed under the Creative Commons Attribution 3.0 Unported
License.
// To view a copy of this license, visit
http://creativecommons.org/licenses/by/3.0/
// or send a letter to Creative Commons, 444 Castro Street, Suite 900, Mountain
View,
// California, 94041, USA.
// Persistence Of Vision raytracer sample file.
// This file demonstrates the use of the file "ior.inc" and a few other
// interesting and useful tricks. It can take a bit of time to render,
// (he said, understatingly), because of the transparency and because of
// the 7 element light bank (flourescent tube?). Eliminating some of the
// lights (and adjusting the brightness color, "Watts", accordingly)
// will help quite a bit.
//
// -w320 -h240
// -w800 -h600 +a0.3
#version 3.6;
global_settings {
assumed_gamma 1
max_trace_level 20
}
#include "colors.inc"
#include "shapes.inc"
#include "textures.inc"
#include "glass.inc"
#include "consts.inc" // Index of refraction constants
camera {
location <0, 5, -20>
angle 57
right x*image_width/image_height
look_at <0, 1, 0>
}
// Assemble a bank of lights here, on the ground...
#declare Watts = color 0.5;
#declare Light_Distance = -50;
union {
light_source { <-6, 0, Light_Distance> color Watts }
light_source { <-4, 0, Light_Distance> color Watts }
light_source { <-2, 0, Light_Distance> color Watts }
light_source { < 0, 0, Light_Distance> color Watts }
light_source { < 2, 0, Light_Distance> color Watts }
light_source { < 4, 0, Light_Distance> color Watts }
light_source { < 6, 0, Light_Distance> color Watts }
rotate 60*x // ... and hoist 'em up into the air
pigment { White } // Doesn't do anything but suppresses a parser warning
}
//
plane { z, 100
pigment {
checker color Gray20 color Gray80
scale 10
}
finish {
ambient 0.1
diffuse 0.6
}
rotate <45, 0, 0>
}
// Set up a default texture for all objects that follow that don't already
// have a texture of their own
#default {texture {pigment {color Clear} finish {F_Glass1}}}
#macro plus(m, c)
#if (c)
intersection { box { <-3.1, -3.1, 0.01> < 3.1, 3.1, 0.99> }
#end
#if (m)
merge
#else
union
#end
{
box { <-2.5, -1, 0> <2.5, 1, 1> }
box { <-1, -2.5, 0> <1, 2.5, 1> }
#if (c)
}
#end
interior { ior Diamond_Ior dispersion 1.1
fade_power 2.0 fade_distance .5 fade_color rgb <0, 1, 0.5> }
rotate <-20, 45, 0>
}
#end
object { plus (0, 0) translate <-6, 1, 0> }
object { plus (1, 0) translate y }
object { plus (1, 1) translate <6, 1, 0> }
// end of file mergetest.pov
Post a reply to this message
|
|
|
|
Am 10.05.2018 um 22:20 schrieb pkoning:
> I was trying to make a rounded rectangle pane of glass by union { } of some
> cylinders and boxes. That of course is a bad idea because the interior
> surfaces. Replaced it by merge, and got a very ugly result. It appears that
> the ray tracing on a merged object gets very confused if the ray strikes a
> surface that is coincident on more than one element.
Yes, that's a well-know issue. Wherever there are somewhat coincident
surfaces in a merge, intersection or difference, you can expect trouble.
The reason for those so-called coincident surface artifacts is (in those
case) that POV-Ray needs to test each and every ray-surface intersection
with any single element and see if the intersection is inside or outside
the other elements, to decide whether the surface should be visible or
suppressed. However, intersection points jitter a bit due to the
imperfect nature of floating-point maths, so if the intersections are on
a surface that is coincident with that of another element, the
intersections jitter in and out of that other element, toggling them
from visible to suppressed and back.
It's essentially the raytracing equivalent of Z-fighting.
Post a reply to this message
|
|
|
|
clipka <ano### [at] anonymous org> wrote:
> Am 10.05.2018 um 22:20 schrieb pkoning:
> > I was trying to make a rounded rectangle pane of glass by union { } of some
> > cylinders and boxes. That of course is a bad idea because the interior
> > surfaces. Replaced it by merge, and got a very ugly result. It appears that
> > the ray tracing on a merged object gets very confused if the ray strikes a
> > surface that is coincident on more than one element.
>
> Yes, that's a well-know issue. Wherever there are somewhat coincident
> surfaces in a merge, intersection or difference, you can expect trouble.
>
> The reason for those so-called coincident surface artifacts is (in those
> case) that POV-Ray needs to test each and every ray-surface intersection
> with any single element and see if the intersection is inside or outside
> the other elements, to decide whether the surface should be visible or
> suppressed. However, intersection points jitter a bit due to the
> imperfect nature of floating-point maths, so if the intersections are on
> a surface that is coincident with that of another element, the
> intersections jitter in and out of that other element, toggling them
> from visible to suppressed and back.
That's a great explanation. I saw the same sort of messy thing in FreeCAD.
Offsetting one surface by a hair is a workaround; an extra intersection
operation as I did in the example is another.
What I found curious is that merge shows the artifacts while union doesn't.
Given that this is a well known issue with a straightforward explanation, it
would be great to have it covered in the documentation.
Post a reply to this message
|
|
