Bounding box computation for CSG intersection appears to be broken when 
one member is an arbitrarily transformed plane.

POV-Ray 3.6.2 has the same problem (can't test for 3.6.1).

----------------------------------------------------------------------

// +W640 +H480 +MB1

#include "transforms.inc"

camera {
   location  <-0.2, 0.5, -4.0>
   direction 1.5*z
   right     x*image_width/image_height
   look_at   <0.0, 0.0,  0.0>
}

sky_sphere {
   pigment {
     gradient y
     color_map {
       [0.0 rgb <0.6,0.7,1.0>]
       [0.7 rgb <0.0,0.1,0.8>]
     }
   }
}

light_source {
   <0, 0, 0>            // light's position (translated below)
   color rgb <1, 1, 1>  // light's color
   translate <-30, 30, -30>
}

plane {
   y, -1
   pigment { color rgb <0.7,0.5,0.3> }
}

intersection {
   sphere {
     0.0, 1 }
   plane { -x, 0 transform { Shear_Trans(x,y+x*0.3,z) } }
   texture {
     pigment {
       radial
       frequency 8
       color_map {
         [0.00 color rgb <1.0,0.4,0.2> ]
         [0.33 color rgb <0.2,0.4,1.0> ]
         [0.66 color rgb <0.4,1.0,0.2> ]
         [1.00 color rgb <1.0,0.4,0.2> ]
       }
     }
     finish{
       specular 0.6
     }
   }
   rotate -y*5
}

Post a reply to this message

clipka wrote:
> Bounding box computation for CSG intersection appears to be broken when 
> one member is an arbitrarily transformed plane.
> 
> POV-Ray 3.6.2 has the same problem (can't test for 3.6.1).

Without having tested the scene, could it be that the plane has simply been 
flipped by the macro? Is there a minimal scene showing this problem?

	Thorsten

Post a reply to this message

Thorsten Froehlich schrieb:
> Without having tested the scene, could it be that the plane has simply 
> been flipped by the macro? Is there a minimal scene showing this problem?

That's the minimal scene already. Well, aside from texturing that is.

I already identified the root cause though: It turns out that when 
POV-Ray checks for planes being perpendicular to an axis in order to 
take them into account for intersection bounding boxes, it attempts to 
test this by checking whether one of the transformed normal's components 
is equal to +/-1, instead of testing the other components for 0. As the 
vector isn't normalized after the transformation, this gives bad readings.

The effect kicks in whenever the transformation leaves any of the normal 
vector components exactly (or sufficiently close to) +/-1; for instance, 
the following will provoke the problem as well:

   plane { -x, 0 transform { scale 2 rotate z*30 } }

(Omitting the "transform" statement will solve the issue in this case, 
probably because a different mechanism is then used to apply the scaling 
and rotation.)

Post a reply to this message

clipka wrote:
> Thorsten Froehlich schrieb:
>> Without having tested the scene, could it be that the plane has simply 
>> been flipped by the macro? Is there a minimal scene showing this problem?
> 
> That's the minimal scene already. Well, aside from texturing that is.

Scne with macro and include != minimal scene ;-)

> The effect kicks in whenever the transformation leaves any of the normal 
> vector components exactly (or sufficiently close to) +/-1; for instance, 
> the following will provoke the problem as well:
> 
>   plane { -x, 0 transform { scale 2 rotate z*30 } }
> 
> (Omitting the "transform" statement will solve the issue in this case, 
> probably because a different mechanism is then used to apply the scaling 
> and rotation.)

Ok, yes, it should not be a problem to fix the bug my normalizing the plane 
normal after all transforms then. This probably is a rather old bug...

	Thorsten

Post a reply to this message

clipka wrote:
>    plane { -x, 0 transform { scale 2 rotate z*30 } }
> 
> (Omitting the "transform" statement will solve the issue in this case,
> probably because a different mechanism is then used to apply the scaling
> and rotation.)

If you use transform{}, a reverse transformation matrix is applied.
If you don't, scale and rotate will modify the vector and distance directly.
It's similar to how 'translate' in a sphere moves the sphere's center
instead of using a transformation matrix, for optimization.

Post a reply to this message