Christopher James Huff <chr### [at] maccom> wrote in news:chrishuff-
1BC### [at] netplexaussieorg

> You still don't understand...no amount of precision will avoid 
> coincident surface problems like the ones in the examples you gave,

I'm afraid that maybe YOU don't understand, I know that coidencident 
surfaces that are *ideal* in same spaces can not be improved (by any 
floating point math).
But I found that i.e. box sized -9.998, +9.998 with checker (scale 1) has 
ALSO this problem. If size was 10.000 etc - I would understand this, but I 
especialy used 9.998 to *avoid* the problem.

Or maybe, this is something connected with topic on .programming :

<cit>
>   POV_SRAND(Hash3d((int)floor(EPoint[X]+Small_Tolerance),
>                    (int)floor(EPoint[Y]+Small_Tolerance),
>                    (int)floor(EPoint[Z]+Small_Tolerance)));
> Why is Small_Tolerance being added to EPoint? That just offsets the
> pattern by a little bit. What's the point?
Probably so that when the cell border is coincident with the surface
being textured there will be no speckling.  This would be the case if
it was applied to a plane facing along a coordiante axis at an
integral distance from the origin.
</cit>

maybe "small tollerance" for checker is 0.001 and therefore using 
coordinates like  W+0.001 (where 0.001 is to AVOID coincidence) is a bad 
idea.

Maybe using small tollerance like 0.0013456 is a better idea - ther would 
be much less chance that some user my use variable like this (0.0013456...) 
in code.



-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message