POV-Ray

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.

Attached to Project: POV-Ray
Opened by Christoph Lipka - 2009-08-20
Last edited by Christoph Lipka - 2010-11-21

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

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
}
Closed by  Christoph Lipka
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 )

Admin
Christoph Lipka commented on Thursday, 20 August 2009, 11:08 GMT

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.

Admin
Christoph Lipka commented on 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?

Grimbert Jérôme commented on 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 ?)

Admin
Christoph Lipka commented on 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).

Grimbert Jérôme commented on 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)

Admin
Christoph Lipka commented on 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.

Admin
Christoph Lipka commented on Saturday, 19 June 2010, 12:38 GMT

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

Admin
Chris Cason commented on 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.

Admin
Christoph Lipka commented on Sunday, 21 November 2010, 10:36 GMT

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

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing