The Persistence of Vision Raytracer (POV-Ray).
This is the Bug Tracking System for the POV-Ray project. Before opening a new task, please read How to make a Bug Report
Please do not issue bugs reports against versions earlier than 3.6.
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) - Thursday, 20 August 2009, 11:20 GMT
Opened by Christoph Lipka (clipka) - Thursday, 20 August 2009, 10:16 GMT
Last edited by Christoph Lipka (clipka) - Thursday, 20 August 2009, 11:20 GMT
|
DetailsBounding 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
}
|
This task depends upon
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.