Well, i try to change color with  vector's comparison. Subtraction , or equal
can't give a result to change color.
And  substraction (Pos_-Pos_compare) can't be recognize. I want to change color
when the two vectors are the same, in substraction equal to 0 ,=0.
I use trace() for one vector.

////

#declare PointA = VEq(Pos_,Pos_compare);


sphere{Pos_,.25
 #if (0=PointA)
 pigment{White}
#else
 pigment{Gray30}  #end }


////

Thanks so

Post a reply to this message

Le 27/12/2012 19:28, Albun nous fit lire :
> 
> Well, i try to change color with  vector's comparison. Subtraction , or equal
> can't give a result to change color.
> And  substraction (Pos_-Pos_compare) can't be recognize. I want to change color
> when the two vectors are the same, in substraction equal to 0 ,=0.
> I use trace() for one vector.
> 

Caveat: 3D vectors are using floating point arithmetic, strict equality
is unlikely to occurs due to noise on floating point operations. (e.g. :
A=<2,4,5>/10; B=<2,4,5>/20; C=B+B+B; D=A+B; ... does D == C ? not sure!)

I would recommend computing the square length of the difference, and
testing it for "small enough" (not =0).

#declare DeltaLenSquared = vdot((Pos_ - Pos_compare),(Pos_ - Pos_compare));
#if (DeltaLenSquared < 0.01)

If you want slower (due to a square root):

#declare DeltaLen = vlength(Pos_ - Pos_compare);
#if (DeltaLen < 0.1)


> ////
> 
> #declare PointA = VEq(Pos_,Pos_compare);
> 
> 
> sphere{Pos_,.25
>  #if (0=PointA)
>  pigment{White}
> #else
>  pigment{Gray30}  #end }
> 
> 
> ////
> 
> Thanks so
> 
> 
> 
>

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> I would recommend computing the square length of the difference, and
> testing it for "small enough" (not =0).

I think that povray already does that.

-- 
                                                          - Warp

Post a reply to this message

So, for good result i find the 'near zero value', .25 and .5, not less. I think
it's a gremlin's fake who make noise on floating point operations...


#declare DeltaLenSquared = vdot((Pos_ - Pos_compare),(Pos_ - Pos_compare));
#if (DeltaLenSquared < 0.25)



#declare DeltaLen = vlength(Pos_ - Pos_compare);
#if (DeltaLen < 0.5)


Thanks a lot

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:

>
> Caveat: 3D vectors are using floating point arithmetic, strict equality
> is unlikely to occurs due to noise on floating point operations. (e.g. :
> A=<2,4,5>/10; B=<2,4,5>/20; C=B+B+B; D=A+B; ... does D == C ? not sure!)
>

That's something fundamental that I didn't know. But I just always assumed that
POV-Ray took care of the floating-point discrepancy internally (as Warp
indicates), i.e. safely truncating the errors in some way. Put a different way:
I haven't *noticed* any oddities in my scenes.

Using an even simpler case:  something like #if(1/1 = 1) would cause havoc if it
was only 'statistically' TRUE due to floating-point errors. *Hopefully* that's
not the situation! :-O

It raises a question in my mind, though: Given a particular math equation on an
unchanging set of values, are the floating point errors always the same? As in,
frame-by-frame animation?

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

> Using an even simpler case:  something like #if(1/1 = 1) ...

Actually, a more appropriate example might(?) be #if(pi/pi = 1)

Post a reply to this message

Due to that thing, a constant appear in my 'near-by after sequence' and resolve
the problem.

Post a reply to this message

Am 30.12.2012 07:14, schrieb Kenneth:

> It raises a question in my mind, though: Given a particular math equation on an
> unchanging set of values, are the floating point errors always the same? As in,
> frame-by-frame animation?

Depends.

The floating point errors are deterministic, so with one and the same 
POV-Ray build they are always the same from frame to frame.

However, they may differ between builds, depending on floating point 
compiler settings; for instance, the old x87 instruction set allows for 
either 64-bit or 80-bit interim results, while SSE2 always uses 64-bit; 
and depending on optimization settings, very small numbers may or may 
not be truncated to zero. So if you split up an animation on a 
heterogenous render farm, results may differ between frames. (This is 
true for both SDL math and the actual render math.)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

>
> The floating point errors are deterministic, so with one and the same
> POV-Ray build they are always the same from frame to frame.

Yeah, after my post, I dimly recalled that this topic was discussed long ago; I
should have remembered this fact.
>
> However, they may differ between builds, depending on floating point
> compiler settings... So if you split up an animation on a
> heterogenous render farm, results may differ between frames.

I would imagine that huge render farms (hundreds to thousands of machines, as in
the professional CGI effect companies) would have to be strenuously maintained
to have the same builds etc., across the board, if only to minimize or eliminate
this very situation.

Post a reply to this message