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 Tim Attwood - 2009-05-09
Last edited by Chris Cason - 2009-06-14
Opened by Tim Attwood - 2009-05-09
Last edited by Chris Cason - 2009-06-14
FS#17 - square blotches in transparency
There can be square (32×32) blotches in partially transparent objects.
global_settings {
max_trace_level 10
}
camera {
location <-30,10,5>
look_at <0,0,0>
angle 25
}
light_source {
<-100,30,70>
rgb 1
}
difference { // make a dome
sphere { <0,0,0> 5 } // ball
sphere { <0,0,0> 4.9 } // hollow interior
box { <-6,-6,-6> <6,1,6> pigment { rgb <0,0,0> }} // chop off bottom half
pigment { rgbt <1,1,1,0.675> }
}
box {
<-6,-6,-6>, <6,0.99,6>
pigment { rgb <1,1,1> }
rotate <0,45,0>
} // sit it on a box
Closed by Chris Cason
Sunday, 14 June 2009, 07:28 GMT
Reason for closing: Fixed
Additional comments about closing:
Sunday, 14 June 2009, 07:28 GMT
Reason for closing: Fixed
Additional comments about closing:
Fixed in change #4822.
Confirmed with 3.7 beta 32 based development version.
The visual appearance of the artifacts indicates that they must be related to some data local to each render thread; the artifacts are indeed sensitive to the +WTn setting. (See attached file, showing a +WT8 output of the above scene)
Could it be somehow related to the same bug as Isosurface which displayed the same kind of 2 tones blotches, due to not poping all intersections when using shortcut of bounding boxes ?
(the Bounding box short-cut in all_intersection() of isosurface was bogus, for isosurface. Maybe the same kind of optimizations is performed by difference/csg code ? (as the IStack is not reset by the IStack allocation/release, if some intersections are left in the stack, the colour computation (weighted) will give a "bad" answer. )
For information, the scene is not sensible to +MB setting. (so, that's not the bounding box here! But a leftover of intersections could still be true)
Inspection of the IStack handling in the CSG code did not turn up any constructs similar to the problematic isosurface code, nor did the sample scene for this error trip any of the debug assertions I added to catch dirty pooled objects (IStack and a few more), so I'm quite sure we can rule out this error theory.
Closer analysis indicates that there is an issue with the shadow cache mechanism (lightSourceLevel1ShadowCache and lightSourceOtherShadowCache, respectively); disabling these caches will eliminate the artifacts. The composition of the CSG object, being made from both opaque and non-opaque components, is of relevance as well.
Analysis of the exact artifact shape in a slightly modified scene suggest that encountering the opaque part of the CSG object in a shadow ray test will "bump" the thread's shadow cache into a bogus mode, causing the non-opaque CSG components' shadows to be rendered too dark for the remainder of the picture.