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
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:
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 )
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.
Fixed for 3.7 with change #4867.
Someone should back-port this change to 3.6 codebase I guess. Chris?
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 ?)
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).
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)
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.
Chris, do we still back-port this fix to the 3.6 codebase?
Yes I'd think so, no harm in having it there even if we don't do another release of the 3.6 series.
Opened a separate task for 3.6 codebase (
FS#171), so we can close this one.