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

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

> 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

The numbers vnormalize(0) would return on Windows were occasionally just out
of range and not NaNs (not a number).  Floating-point numbers as presented
internally in computers contain several "states", not just numbers.  One other
state is "Infinite".  if one of those ends up in a calculation is propages
through it and essentually caues the whole calculation to return an invalid
result.  If this for some reason happens only to one or two components of a
vector needed in tha clalculation it may still in other calculation of the
intersection result in valid vector components.  If this happens you get a
"partial" problem, i.e. a bit may occasionally appear correct.  However, the
point is that it is "occasionally correct", not always incorrect.

See it like a puzzle (I can't think of a better example):  If you flip all not
connected pieces so the image side is up you do see the whole image, but it is
of course not "the" whole image as you expect it.  What the vnormalize(0) does
here is move the pieces around and occasionally you see something close to
what you expect...

    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

Wasn't it ingo who wrote:
>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. 

When is that going to become available?

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

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

> When is that going to become available?
> 

I'll try and set up a page for it and some other stuff this week, but 
promise nothing.

Ingo

Post a reply to this message

Ah, okay. Thats reasonable. Thanks for the explanation!

Thorsten Froehlich wrote:

> The numbers vnormalize(0) would return on Windows were occasionally just out
> of range and not NaNs (not a number).  Floating-point numbers as presented
> internally in computers contain several "states", not just numbers.  One other
> state is "Infinite".  if one of those ends up in a calculation is propages
> through it and essentually caues the whole calculation to return an invalid
> result.  If this for some reason happens only to one or two components of a
> vector needed in tha clalculation it may still in other calculation of the
> intersection result in valid vector components.  If this happens you get a
> "partial" problem, i.e. a bit may occasionally appear correct.  However, the
> point is that it is "occasionally correct", not always incorrect.
>
> See it like a puzzle (I can't think of a better example):  If you flip all not
> connected pieces so the image side is up you do see the whole image, but it is
> of course not "the" whole image as you expect it.  What the vnormalize(0) does
> here is move the pieces around and occasionally you see something close to
> what you expect...
>
>     Thorsten
>

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

Post a reply to this message