"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