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.

Tasklist

FS#17 - square blotches in transparency

Attached to Project: POV-Ray
Opened by Tim Attwood (TimA) - Saturday, 09 May 2009, 23:14 GMT
Last edited by Chris Cason (chrisc) - Sunday, 14 June 2009, 07:28 GMT
Task Type Possible Bug
Category Backend → Texture/Material/Finish
Status Closed
Assigned To Chris Cason (chrisc)
Operating System All
Severity Low
Priority Normal
Reported Version 3.70 beta 32
Due in Version 3.70 beta 33
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

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
This task depends upon

Closed by  Chris Cason (chrisc)
Sunday, 14 June 2009, 07:28 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in change #4822.
Comment by Christoph Lipka (clipka) - Saturday, 09 May 2009, 23:54 GMT
  • Field changed: Status (Unconfirmed → New)

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)

   FS_17.png (20.9 KiB)
Comment by Grimbert Jérôme (Le_Forgeron) - Monday, 11 May 2009, 16:45 GMT

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)

Comment by Christoph Lipka (clipka) - Sunday, 24 May 2009, 21:26 GMT

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.

Loading...