The Persistence of Vision Raytracer (POV-Ray).

This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.


FS#48 - CSG bounding box computation broken with shearing transformation

Attached to Project: POV-Ray
Opened by Christoph Lipka (clipka) - Thursday, 20 August 2009, 10:16 GMT
Last edited by Christoph Lipka (clipka) - Sunday, 21 November 2010, 10:37 GMT
Task Type Definite Bug
Category Backend → Geometric Primitives
Status Closed
Assigned To Chris Cason (chrisc)
Operating System All
Severity High
Priority High
Reported Version All
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


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 {
      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> ]
      specular 0.6
  rotate -y*5
This task depends upon

Closed by  Christoph Lipka (clipka)
Sunday, 21 November 2010, 10:37 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed for 3.7; new task opened for 3.6 back-port ( FS#171 )
Comment by Christoph Lipka (clipka) - Thursday, 20 August 2009, 11:08 GMT
  • Field changed: Task Type (Possible Bug → Definite Bug)
  • Field changed: Status (Unconfirmed → Investigating)
  • Field changed: Percent Complete (0% → 50%)
  • Task assigned to Christoph Lipka (clipka)

Tracked this down to Quadric::Compute_Plane_Min_Max(), which fails to normalize the normal vector after applying transformations, yet tries to test for parallelity with YZ (or XZ, or XY) by comparing its X (or Y, or Z) component with +/-1.

I’ll change this to test Y and Z (or X and Z, or X and Y) for =0 instead.

Comment by Christoph Lipka (clipka) - Thursday, 20 August 2009, 11:20 GMT

Fixed for 3.7 with change #4867.

Someone should back-port this change to 3.6 codebase I guess. Chris?

Comment by Grimbert Jérôme (Le_Forgeron) - Thursday, 17 September 2009, 20:20 GMT

Could someone explain the interest of computing fabs(fabs(foo)) ?

Wouldn't be enough to compute only fabs(foo) ?

Do we expect fabs to provide a better answer on a sequence of calls ?
why not fabs(fabs(fabs... (only joking)

Please consider revising change #4867.
(or do I just made a fool of myself ?)

Comment by Christoph Lipka (clipka) - Thursday, 17 September 2009, 22:34 GMT

That's defensive programming - just in case fabs() happens to compute the wrong result... >_<

No, you're perfectly right, it's nonsense. I'll fix that.
... done (change #4891).

Comment by Grimbert Jérôme (Le_Forgeron) - Friday, 18 September 2009, 08:40 GMT

I do not know how you corrected (with #4891) yet, but I go an happy morning thinking about that vector:
(bad bad habit, just can't stop thinking...)

If you are testing the unnormalized vector, even by testing if the other two components are near 0 like #4867 did (with double fabs(), ok, thanks for the correction),
what would protect you from silly very small vector ?

If the old code (pre-#4867) was expecting a normalized vector, and it was not, what about simply normalizing into a new temporary vector TT (the normalizing function/macro already exists, it's just a call to make at the beginning of the testing block) and using that TT for the tests ?

It will cost some space on the stack, some time to compute the normalized vector, but as a Compute_... function, it's probably not used during rendering, so we can probably afford to loose some cycles in that function, if the result is better.

I'm just afraid of ending with false-positive in that function when the transformation ends with a <1,2,0.5>*1e-9 as criteria.

(ok I've yet to see #4891, may be it's just ok)

Comment by Christoph Lipka (clipka) - Friday, 18 September 2009, 20:34 GMT

I don't see any risk involved that wouldn't exist otherplace in POV-Ray already: If you do a matrix transformation that effectively scales by some 1e-9, your scene is likely to be riddled with artifacts anyway.

Comment by Christoph Lipka (clipka) - Saturday, 19 June 2010, 12:38 GMT

Chris, do we still back-port this fix to the 3.6 codebase?

Comment by Chris Cason (chrisc) - Monday, 21 June 2010, 19:09 GMT

Yes I'd think so, no harm in having it there even if we don't do another release of the 3.6 series.

Comment by Christoph Lipka (clipka) - Sunday, 21 November 2010, 10:36 GMT

Opened a separate task for 3.6 codebase ( FS#171 ), so we can close this one.