Can anyone remind me what vnormalize(<0,0,0>) used to return under
previous betas?

I'm trying to get some code (actually Ingo's "param.inc" macro) to work
the same under RC2 as it did before vnormalize(<0,0,0>) became an error.

The docs say "A/vlength(A)", so I tried replacing 
     #declare Norm=vnormalize(vcross(A,B));
with
     #declare Norm = vcross(A,B)/vlength(vcross(A,B));

V3.1 returned <0,0,0>. so I tried
   #if (vlength(vcross(A,B))=0)
     #declare Norm=<0,0,0>;
   #else
     #declare Norm=vnormalize(vcross(A,B));
   #end   

but neither of these produce images that look quite the same as in
previous betas.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

I think the problem isn't the value being returned, but the
internal mess POV-Ray creates to its own internal
data. Like setting a switch when calculating vnormalize
with <0,0,0> which just rips the scene apart.

Thats my experience, calculation works fine, but the
output image is worthless, because objects get deleted,
cut in half or appear as ghosts, but never moved around
to where they shouldn't belong.
I wrote a macro:

#macro VNormalize(_vec)
 #if (vlength(_vec)!=0)
 #local _ret=vnormalize(_vec);
#else
 #local _ret=<0,0,0>;
#end
//Return value:
_ret
#end


Then I simply replaced vnormalize() with VNormalize,
and everything works fine. You could also use any
other value than the above given <0,0,0>, in case
you're in dire need for a unit-length-vector.

Mike Williams wrote:

> Can anyone remind me what vnormalize(<0,0,0>) used to return under
> previous betas?
>
> I'm trying to get some code (actually Ingo's "param.inc" macro) to work
> the same under RC2 as it did before vnormalize(<0,0,0>) became an error.
>
> The docs say "A/vlength(A)", so I tried replacing
>      #declare Norm=vnormalize(vcross(A,B));
> with
>      #declare Norm = vcross(A,B)/vlength(vcross(A,B));
>
> V3.1 returned <0,0,0>. so I tried
>    #if (vlength(vcross(A,B))=0)
>      #declare Norm=<0,0,0>;
>    #else
>      #declare Norm=vnormalize(vcross(A,B));
>    #end
>
> but neither of these produce images that look quite the same as in
> previous betas.
>

--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde

Post a reply to this message

Wasn't it Tim Nikias who wrote:
>Mike Williams wrote:
>
>> Can anyone remind me what vnormalize(<0,0,0>) used to return under
>> previous betas?
>>
>> I'm trying to get some code (actually Ingo's "param.inc" macro) to work
>> the same under RC2 as it did before vnormalize(<0,0,0>) became an error.
>>
>> The docs say "A/vlength(A)", so I tried replacing
>>      #declare Norm=vnormalize(vcross(A,B));
>> with
>>      #declare Norm = vcross(A,B)/vlength(vcross(A,B));
>>
>> V3.1 returned <0,0,0>. so I tried
>>    #if (vlength(vcross(A,B))=0)
>>      #declare Norm=<0,0,0>;
>>    #else
>>      #declare Norm=vnormalize(vcross(A,B));
>>    #end
>>
>> but neither of these produce images that look quite the same as in
>> previous betas.
>>
>I think the problem isn't the value being returned, but the
>internal mess POV-Ray creates to its own internal
>data. Like setting a switch when calculating vnormalize
>with <0,0,0> which just rips the scene apart.
>
>Thats my experience, calculation works fine, but the
>output image is worthless, because objects get deleted,
>cut in half or appear as ghosts, but never moved around
>to where they shouldn't belong.
>I wrote a macro:
>
>#macro VNormalize(_vec)
> #if (vlength(_vec)!=0)
> #local _ret=vnormalize(_vec);
>#else
> #local _ret=<0,0,0>;
>#end
>//Return value:
>_ret
>#end

As I said, I tried <0,0,0> (because that's what v3.1 returns) and the
resulting image doesn't look the same as it did in previous betas. 

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Mike Williams <mik### [at] nospamplease> wrote:

> Can anyone remind me what vnormalize(<0,0,0>) used to return under
> previous betas?

  AFAIK, it returned <NaN, NaN, NaN>, which is obviously not usable.

  (NaN, that is, "Not a Number" is a special floating point value returned
by the math co-processor which means that it's the result of an illegal
operation, which can't have a result.)

  vnormalize(<0,0,0>) can't have a legal return value and thus issuing an
error is the correct behaviour.
  The reason is exactly the same as why 1/0 can't have a legal value.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

in news:K0a### [at] econymdemoncouk Mike Williams wrote:

> I'm trying to get some code (actually Ingo's "param.inc" macro) to
> work the same under RC2 as it did before vnormalize(<0,0,0>) became
> an error. 
> 

Mike,

There should be no need to catch vnormalize(0), unless you calculate 
points that don't "resolve" somehow, stuff like lim->0. Using the FromU
() etc. macros helps. See below example (from a somewhat more recent 
version):

#declare R=1;
#declare F1=function(U,V){R*sin(V)*cos(U)}
#declare F2=function(U,V){R*cos(V)}
#declare F3=function(U,V){R*sin(V)*sin(U)}
object { 
  Parametric (
    F1, F2, F3,
    <0, 2*pi>,
    <FromV(0), pi>, //<0,pi> results in an error
    100,50,""
  )
  pigment {rgb 1}
  finish{specular 0.3}
  rotate <0,0,0>
}

Ingo

Post a reply to this message

Wasn't it ingo who wrote:
>in news:K0a### [at] econymdemoncouk Mike Williams wrote:
>
>> I'm trying to get some code (actually Ingo's "param.inc" macro) to
>> work the same under RC2 as it did before vnormalize(<0,0,0>) became
>> an error. 
>> 
>
>Mike,
>
>There should be no need to catch vnormalize(0), unless you calculate 
>points that don't "resolve" somehow, stuff like lim->0. Using the FromU
>() etc. macros helps. See below example (from a somewhat more recent 
>version):
>
>#declare R=1;
>#declare F1=function(U,V){R*sin(V)*cos(U)}
>#declare F2=function(U,V){R*cos(V)}
>#declare F3=function(U,V){R*sin(V)*sin(U)}
>object { 
>  Parametric (
>    F1, F2, F3,
>    <0, 2*pi>,
>    <FromV(0), pi>, //<0,pi> results in an error
>    100,50,""
>  )
>  pigment {rgb 1}
>  finish{specular 0.3}
>  rotate <0,0,0>
>}
>
>Ingo

I would prefer to retain the "param.inc" versions of the examples on my
Isosurface tutorial page, because they are so much faster than real
parametrics. At the moment over half of them fail to run under RC2.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

In article <3C9AC0CD.62B9B9E6@gmx.de> , Tim Nikias <tim### [at] gmxde>  wrote:

> I think the problem isn't the value being returned, but the
> internal mess POV-Ray creates to its own internal data.

There is no "internal mess" - POV-Ray works perfectly in this case.

> Thats my experience, calculation works fine, but the
> output image is worthless, because objects get deleted,
> cut in half or appear as ghosts, but never moved around
> to where they shouldn't belong.

That is plain wrong!!!  They simply appear misplaced because they are at
invalid positions.  There is *no* valid output for vnormalize(0) because you
cannot normalize a zero-length vector as it is mathematically impossible!

    Thorsten

PS: Your date is by one month behind the real world :-)

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3cc3c03d@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   AFAIK, it returned <NaN, NaN, NaN>, which is obviously not usable.

Unfortunately, the Windows version did not because of a not correctly
implemented standard math library "pow" function in Visual C (the library is
used in both compiles).

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

I've checked my code and the examples I've given to
state what I said.

For one: If objects are misplaced, that may be the case.
But what do you make of the ghost-appearances?
Or parts of objects being cut off? That doesn't make much
sense, but I'm not into the POV-Code that much to
actually know if its not related somehow, at least internally.


Oh, and the month: I've been using the Beta 16 for the photons,
and the RC1 for other tests (aside radiosity), so sometimes the
month is wrong...

Thorsten Froehlich wrote:

> That is plain wrong!!!  They simply appear misplaced because they are at
> invalid positions.  There is *no* valid output for vnormalize(0) because you
> cannot normalize a zero-length vector as it is mathematically impossible!
>
>     Thorsten
>
> PS: Your date is by one month behind the real world :-)
>

--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde

Post a reply to this message

in news:cW9### [at] econymdemoncouk Mike Williams wrote:

> I would prefer to retain the "param.inc" versions of the examples on
> my Isosurface tutorial page, because they are so much faster than
> real parametrics. At the moment over half of them fail to run under
> RC2. 
> 

Think you misunderstood me, the code was from an newer version of
param.inc that accepts functions directly and looks even more like the
parametric object. 

Now to one of your example files (IngoSpline04b.pov), it uses the cubic
spline that returns the same value in the range t=-1 to 0 and t=17 to
18. This results in the vnormalize error. Two solutions: 

1. use an other spline type.

2. move #include "param.inc" to the top of the file,
   change Umin and Umax to:
   #declare Umin =  FromU(0);
   #declare Umax =  ToU(17);

Ingo

Post a reply to this message