If you render the following scene, the black and white of the checker pattern is
reversed when viewed through the transparent sphere - is this a bug?

Win 2000, p3 733, pov3.5

#version 3.5;

#include "colors.inc"

global_settings {
  assumed_gamma 1.0
}

camera {
  location  <0.0, 1.0, -5.0>
  look_at   <0.0, 1.0,  0.0>
}


plane{y,-0.001 pigment{checker pigment{Black}, pigment{White}}}


sphere{0,1
  translate y*1
  pigment{rgbt 1}
}



--
#macro A(V,B,C,R)#while(B-256)#if(V-128/B>=0)sphere{0,.5translate<C-4R-1,9>
pigment{rgb<1-C/8R/2C/8>}}#local V=V-128/B;#end#local B=B*2;#local C=C+1;#
end#end A(234,1,0,2)A(85,1,0,1)A(81,1,0,0)light_source{-5 1}//Tom Melly

Post a reply to this message

"Tom Melly" <tom### [at] tomandlucouk> wrote in message
news:3e26e84f$1@news.povray.org...

It's worth noting that adding a point-light makes no difference, and also I seem
to be seeing some odd artifacts on the sphere.

Post a reply to this message

"Tom Melly" <tom### [at] tomandlucouk> wrote in message
news:3e26e9b2@news.povray.org...
> "Tom Melly" <tom### [at] tomandlucouk> wrote in message
> news:3e26e84f$1@news.povray.org...
>
> It's worth noting that adding a point-light makes no difference, and also I
seem
> to be seeing some odd artifacts on the sphere.
>
>

I've posted an image to images in case it's a local bug - also note that it
doesn't afaik affect any other pattern except checker, and it will happily swap
any two colours.

Post a reply to this message

On Thu, 16 Jan 2003 17:13:50 -0000, "Tom Melly" <tom### [at] tomandlucouk> wrote:
> If you render the following scene, the black and white of the checker pattern is
> reversed when viewed through the transparent sphere - is this a bug?

This can be floating point accuracy, but of course needs further
investigation.

ABX

Post a reply to this message

Slime wrote:

> See, the potential problem is that the checker pattern has opposite values
> in the y=(0,1] range than it does in the y=(-1,0] range. So *tiny*
> inaccuracies can cause the pattern to return *opposite* values. To avoid
> this, the pattern is pre-translated internally by y*-0.001. Normally that
> fixes it. However, that is *exactly* where you set the surface of your
> plane, so you're reintroducing the original floating point innacuracies.

I can't believe it ! Someone assumed that the checker patern was much 
more used with a horizontal plane than with a vertical one ?

I find it rather strange that this correction is internaly code, since 
we (users) are used to do corrections ourselves (in case of intersection 
  between objects, things like that). Is this documented somewhere ? I 
guess we all assumed cubes went from 0 to 1, and so on...


-- 
Jul### [at] cnedraorg
http://www.cnedra.org

Post a reply to this message

On Thu, 16 Jan 2003 20:34:37 +0100, Julien Gourdon <jul### [at] cnedraorg> wrote:
> I can't believe it ! Someone assumed that the checker patern was much 
> more used with a horizontal plane than with a vertical one ?

I'm not sure how you have recognize that this is a horizontal plane and not
vertical ... ;-)

ABX

Post a reply to this message

"Slime" <slm### [at] slimelandcom> wrote in message
news:3e26fa99@news.povray.org...

> this, the pattern is pre-translated internally by y*-0.001. Normally that
> fixes it. However, that is *exactly* where you set the surface of your
> plane, so you're reintroducing the original floating point innacuracies.

Ah - that makes sense (as in now you've explained, rather than, doh, why
didn't I think of that). As a suggestion, it might make more sense to
translate by, say, -0.273 (less likely to be picked than 0.001).

Weird all the same.

Post a reply to this message

ABX wrote:

> I'm not sure how you have recognize that this is a horizontal plane and not
> vertical ... ;-)

y normal ? Was not this supposed to be horizontal ? :)

-- 
Jul### [at] cnedraorg
http://www.cnedra.org

Post a reply to this message

"Tom & Lu Melly" <all### [at] tomandlucouk> wrote in message
news:3e270b18@news.povray.org...
>
> "Slime" <slm### [at] slimelandcom> wrote in message
> news:3e26fa99@news.povray.org...
>
> > this, the pattern is pre-translated internally by y*-0.001. Normally
that
> > fixes it. However, that is *exactly* where you set the surface of your
> > plane, so you're reintroducing the original floating point innacuracies.
>
> Ah - that makes sense (as in now you've explained, rather than, doh, why
> didn't I think of that). As a suggestion, it might make more sense to
> translate by, say, -0.273 (less likely to be picked than 0.001).

Admittedly, it probably isn't the ultimate perfect solution. For this to be
okay the surface placement needs to begin at 0, such as plane {y,0 material
{...} translate XYZ} so that translate would be used for moving the whole
thing to prevent erroneous happenings. If textures could dynamically
readjust maybe that would be perfect. Maybe not  :-)

0.001 was picked arbitrarily, as I recall. Or maybe because it was already a
value used in the source code, but I'd be speculating about that. I looked
it up and it is not y*-0.001, it's used on all three axes and is positive
not negative. That is if I'm reading the source code correctly. That part is
rather simple though, you can find the checker pattern in pigment.cpp and
the Small_Tolerance used on it in frame.h.

The problem encountered would happen at some user offset no matter what, I
think, and the 0.001 isn't at 0.0 at least where the most common occurances
of surfaces would align. Of course, a smaller number would become ever less
likely to intersect. Just also becomes a little more obscure.

Someone else might know this. There might be very good reasons to not go to
a smaller value for Small_Tolerance in the first place since it is a factor
for the ray tracing itself I guess.

Post a reply to this message

> I can't believe it ! Someone assumed that the checker patern was much
> more used with a horizontal plane than with a vertical one ?


My mistake. The texture is actually internally translated by
<-0.001,-0.001,-0.001>. Some of those may be positive, I don't know for
sure.

> I find it rather strange that this correction is internaly code, since
> we (users) are used to do corrections ourselves (in case of intersection
>   between objects, things like that). Is this documented somewhere ? I
> guess we all assumed cubes went from 0 to 1, and so on...

Thing is, if they didn't do it, hundreds of new users trying out their first
simple reflective-sphere-on-checkered-plane scene would complain to them,
saying it was a bug.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message