Hi,

I think I may have found a significant bug in POV-Ray, but if it's not a 
bug then please explain to me why, and how I can work around the problem.

Consider the following source:

------------------------------------------------------------------------
#include "colors.inc"

camera { location <2, 2, -5> look_at <0, 0.5, 0> }
light_source { <0, 3, 0> color rgb <0.7, 0.7, 0.7> }

#declare use_iso = 0;

difference {
     box { <-2.5, -1.1, -2.5>,
           < 2.5, 0,     2.5>
     }

     #if(use_iso)
         // this isosurface _should_ be equivalent to the cylinder below
         isosurface {
             function { pow (x, 2) + pow (z, 2) - 4 }
             max_gradient 5.310
             accuracy .0001
             contained_by {
                 box { <-2.01, -1,  -2.01>,
                       < 2.01, .01,  2.01> }
             }
         }
     #else
         cylinder { <0, -1, 0>, <0, .01, 0>, 2 }
     #end

     pigment { Green }
}
------------------------------------------------------------------------

Try rendering this with use_iso set to 0 and then with it set to 1. I 
would have thought the two should produce pretty much the same result, 
since the isosurface is equivalent to the cylinder.

But the result I get is this: with the cylinder everything works as 
expected, but with the isosurface, the inside of the object is 
completely black, even though there is a light source right next to it.

Is this a bug, or am I doing something wrong? If so, what?

Thanks
Timwi

Post a reply to this message

Wasn't it Timwi who wrote:
>
>Hi,
>
>I think I may have found a significant bug in POV-Ray, but if it's not 
>a bug then please explain to me why, and how I can work around the 
>problem.
>
>Consider the following source:
>
>------------------------------------------------------------------------
>#include "colors.inc"
>
>camera { location <2, 2, -5> look_at <0, 0.5, 0> }
>light_source { <0, 3, 0> color rgb <0.7, 0.7, 0.7> }
>
>#declare use_iso = 0;
>
>difference {
>    box { <-2.5, -1.1, -2.5>,
>          < 2.5, 0,     2.5>
>    }
>
>    #if(use_iso)
>        // this isosurface _should_ be equivalent to the cylinder below
>        isosurface {
>            function { pow (x, 2) + pow (z, 2) - 4 }
>            max_gradient 5.310
>            accuracy .0001
>            contained_by {
>                box { <-2.01, -1,  -2.01>,
>                      < 2.01, .01,  2.01> }
>            }
>        }
>    #else
>        cylinder { <0, -1, 0>, <0, .01, 0>, 2 }
>    #end
>
>    pigment { Green }
>}
>------------------------------------------------------------------------
>
>Try rendering this with use_iso set to 0 and then with it set to 1. I 
>would have thought the two should produce pretty much the same result, 
>since the isosurface is equivalent to the cylinder.
>
>But the result I get is this: with the cylinder everything works as 
>expected, but with the isosurface, the inside of the object is 
>completely black, even though there is a light source right next to it.
>
>Is this a bug, or am I doing something wrong? If so, what?
>
>Thanks
>Timwi

There's two things going on. One of them is you doing something wrong 
and one could possibly be a bug.

When you perform CSG with an isosurface you must either set max_trace 
appropriately or use all_intersections.

That still leaves the bottom of the hole darker when you use the 
isosurface.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Mike Williams wrote:
> Wasn't it Timwi who wrote:
>>
>> Try rendering this with use_iso set to 0 and then with it set to 1. I 
>> would have thought the two should produce pretty much the same result, 
>> since the isosurface is equivalent to the cylinder.
>>
>> But the result I get is this: with the cylinder everything works as 
>> expected, but with the isosurface, the inside of the object is 
>> completely black, even though there is a light source right next to it.
> 
> There's two things going on. One of them is you doing something wrong 
> and one could possibly be a bug.
> 
> When you perform CSG with an isosurface you must either set max_trace 
> appropriately or use all_intersections.

Thanks a lot... although it raises the question: why is that not the 
default? Why is the default something that is, apparently, broken by 
definition (because it doesn't calculate all intersections it needs to 
generate the correct result)?

> That still leaves the bottom of the hole darker when you use the 
> isosurface.

Yeah. Should I report that as a bug?

In my case, I worked around it by having the isosurface cut a little bit 
deeper and then filling up the bottom of the hole with another box... 
but ideally, of course, I shouldn't have to do that.

Thanks
Timwi

Post a reply to this message

Timwi <tim### [at] gmxnet> wrote:
> > When you perform CSG with an isosurface you must either set max_trace 
> > appropriately or use all_intersections.

> Thanks a lot... although it raises the question: why is that not the 
> default? Why is the default something that is, apparently, broken by 
> definition (because it doesn't calculate all intersections it needs to 
> generate the correct result)?

  Efficiency?

-- 
                                                          - Warp

Post a reply to this message

Timwi <tim### [at] gmxnet> wrote:
> Try rendering this with use_iso set to 0 and then with it set to 1. I
> would have thought the two should produce pretty much the same result,
> since the isosurface is equivalent to the cylinder.

As a matter of fact, POV 3.6 *does* produce identical results for cylinder and
isosurface version.

The current POV 3.7 beta renders properly if you add an "inverse" keyword to the
isosurface, for yet unexplained reasons. The beta page does not mention any
intentional change to isosurface behavior, and in fact only lists one single
change related to isosurfaces:

-------------------------------------------
Changes between 3.7.beta.25 and 3.7.beta.26
-------------------------------------------
....
Apply isosurface cache fix suggested by Lukas Winter in
<47c5b8b6$1@news.povray.org>.

So the cache fix might have broken something; however, it may already have been
broken earlier in the 3.7 development process of "C++-ifying" the code.

Post a reply to this message

Timwi <tim### [at] gmxnet> wrote:
> Thanks a lot... although it raises the question: why is that not the
> default? Why is the default something that is, apparently, broken by
> definition (because it doesn't calculate all intersections it needs to
> generate the correct result)?

It can have a significant performance advantage if the object is *not* used in
CSG (or, more specifically, differences or intersections), but directly at
scene level (or in unions).

(But then again, the user could still specify "max_trace 1" to benefit from that
speedup, so making all_intersections the default seems like a reasonable idea to
me. Maybe depending on the #version setting for backward compatibility.)

Post a reply to this message