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 - 2010-12-18
Last edited by Christoph Lipka - 2011-02-07

FS#182 - multi-textured blobs in intersections / differences broken

Multi-textured blobs are broken with 3.7 beta 40 when used inside an intersection, as can be demonstrated by the following scene:

#default { texture { pigment { rgb 1 } } }

camera {
  right x*image_width/image_height
  location  <0,1.5,-4>
  look_at   <0,1,0>

light_source { <500,500,-500> color rgb 1 }

difference { blob {
  threshold 0.6
  sphere { < 0.75,   0,    0>, 1, 1 texture { pigment { color red 1 } } }
  sphere { <-0.375,  0.65, 0>, 1, 1 texture { pigment { color green 1 } } }
  sphere { <-0.375, -0.65, 0>, 1, 1 }
} }

With POV-Ray 3.7.0 beta 40, the entire blob is rendered with the default texture.

The same problem can be seen with “difference” or “merge” instead of “intersection”.

Omitting the CSG “envelope”, using “union”, or assigning the blob to a variable first and then using it inside an intersection, will yield the expected result.

POV-Ray 3.62 renders all variants as expected.

According to initial analysis, the problem appears to be caused by the dual use of the “MULTITEXTURE_FLAG”, which is used in CSG to indicate use of the “cutaway_textures” feature, and in blobs to indicate per-element texturing. (The same flag is also used in meshes to indicate per-face or per-vertex texturing, so similar problems are to expected there.)

My proposal is to use an entirely separate flag for the “cutaway_textures” feature (the blob and mesh can safely continue to share the MULTITEXTURE_FLAG).

Closed by  Christoph Lipka
Monday, 07 February 2011, 11:07 GMT
Reason for closing:  Fixed
Christoph Lipka commented on Sunday, 19 December 2010, 16:52 GMT

fixed with change #5274

Grimbert Jérôme commented on Wednesday, 05 January 2011, 18:20 GMT

Confirmed as fixed with RC2/#5347 from source on linux 64bits.
The scene in the report is ok now.


Available keyboard shortcuts


Task Details

Task Editing