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.


FS#209 - Weighted texture of CSG

Attached to Project: POV-Ray
Opened by Grimbert Jérôme (Le_Forgeron) - Thursday, 02 June 2011, 10:33 GMT
Last edited by Christoph Lipka (clipka) - Thursday, 21 June 2012, 23:28 GMT
Task Type Definite Bug
Category Backend → Geometric Primitives
Status Closed
Assigned To No-one
Operating System All
Severity Medium
Priority Normal
Reported Version 3.70 RC3
Due in Version 3.70 RC4
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


in change #3319, csg got a new computation for its weighted textures.

But I’m confused by the computation of the weight: (circa end of csg.cpp file)

COLC weight = 1.0f / min(COLC(textures.size() - firstinserted), 1.0f);

I would have used a max() rather than a min().

It is transparent when there is only one texture, but:

  • should there be no texture (an error...): it would be a division by 0
  • should there be more than 1, the weight of each would be 1. which is without consequence UNLESS there is already some other textures in the list. The right value (from previous code) was 1/n

Or did I get a confusion about min() ?

min(0,1) == 0
min(4,1) == 1

Using max would protect against the division by 0 and the right value when multiple textures are used.

Any thought ?

This task depends upon

Closed by  Christoph Lipka (clipka)
Thursday, 21 June 2012, 23:28 GMT
Reason for closing:  Fixed
Additional comments about closing:  no news, so I guess the fix was effective
Comment by Christoph Lipka (clipka) - Thursday, 02 June 2011, 11:51 GMT
  • Field changed: Status (Unconfirmed → New)

You’ve definitely found something. The following scene showcases how this indeed leads to wrong results:

camera {
  location  <0.0, 0.5, -4.0>
  direction 1.5*z
  right     x*image_width/image_height
  look_at   0.0

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

intersection {
  union {
    sphere { <-.5,-.25,0>, 1 texture { pigment { color rgb 1 } } }
    sphere { <.5,-.25,0>, 1 texture { pigment { color rgb 1 } } }
    sphere { <0,.5,0>, 1 texture { pigment { color rgb 1 } } }
  sphere { <0,0,.5>, 1 }

Note the increase in brightness where the union’s members overlap, which is fully consistent with your code findings; also note that version 3.62 does not show this effect.

Please go ahead. The code is clearly in error here.

Comment by Grimbert Jérôme (Le_Forgeron) - Thursday, 02 June 2011, 13:06 GMT

Thanks for the demo scene, Christoph.

Fix done with #5447
Check done with 3.6 and the demo scene.
(as well as the demo scene using red/green/blue instead of rgb for the contributing sphere/texture)