I've been waiting for the smoke to clear on the battlefield... :-P

"clipka" <nomail@nomail> wrote:

> Are you familiar with calculus?
>
> Exact alignment would mean that the current direction would be the tangent to
> the spline at the current position.

>
> To compute a tangent to an arbitrary curve defined as f(t) (the value of which
> in this case is a vector), you need the derivative f'(t) of that function,
> which is defined as:
>
>     f'(t) = lim(d->0) [f(t+d)-f(t)]/d
>
> which is to say, take two *infinitesimally* close points on the function, and
> divide the difference between the function values by the difference between
> the function parameters.

Yes, completely understood. (It's been ...*awhile*...since I took a calculus
course, and I'm certainly NO expert.) I guess, in the context of the math
discussions here, what I'm looking for IS finding the 'limit' at
delta-*something* = 0. But I see the difficulties (I think!)
>
> As you will see, although this is an exact mathematical definition, it doesn't
> work with d = 0 because you'd get 0/0, which is nonsense.

That piques my curiosity. I thought calculus was the 'prime tool' for getting
that exact tangent. So, do I understand that POV-Ray can't actually calculate
that?  (Sorry if my ignornace is showing.)

But more prosaically, my original question--a rather naive one, as I see
now--was really about the *idea* of being able to set Foresight to zero. As a
way for the macro to 'make better sense' to the user. Of course, I do now see
the practical difficulties involved.  (Here's a REALLY goofball idea: Maybe,
'behind the scenes' in the macro, there could be a little 'hidden' addition of
..001 or something, so that when Foresight IS set to zero, the equations will
still have a little number to work with.)  Silly, I know. Even stupid! :-O  And
not even good coding practice, I would assume.

KW

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:
> I've been waiting for the smoke to clear on the battlefield... :-P

Hm, I think it has cleared now... mainly :}

> Yes, completely understood. (It's been ...*awhile*...since I took a calculus
> course, and I'm certainly NO expert.) I guess, in the context of the math
> discussions here, what I'm looking for IS finding the 'limit' at
> delta-*something* = 0. But I see the difficulties (I think!)
> >
> > As you will see, although this is an exact mathematical definition, it doesn't
> > work with d = 0 because you'd get 0/0, which is nonsense.
>
> That piques my curiosity. I thought calculus was the 'prime tool' for getting
> that exact tangent. So, do I understand that POV-Ray can't actually calculate
> that?  (Sorry if my ignornace is showing.)

It could - as Warp has pointed out quite correctly - if someone programmed it
with the correct precise formula.

The catch here, however, is that this would also require feeding that formula
with all the control point parameters that normally go into the spline
definition already. Unfortunately it's not possible to access that information
via SDL from an arbitrary spline, so you'd have to remember this information
and "manually" feed it into a suitable macro (or function, for that matter).

> But more prosaically, my original question--a rather naive one, as I see
> now--was really about the *idea* of being able to set Foresight to zero. As a
> way for the macro to 'make better sense' to the user. Of course, I do now see
> the practical difficulties involved.  (Here's a REALLY goofball idea: Maybe,
> 'behind the scenes' in the macro, there could be a little 'hidden' addition of
> ..001 or something, so that when Foresight IS set to zero, the equations will
> still have a little number to work with.)  Silly, I know. Even stupid! :-O  And
> not even good coding practice, I would assume.

Indeed, it would deprive the user of choosing for himself how close to zero to
go.

So if you want to go for a "standard almost-zero", the proper way would be to
write a similar macro without that parameter, which would then use a fixed
value.

However, I can also imagine that such a "tweaking screw" can come in handy
occasionally when the results are a bit weird. Maybe some spline taking an
unconventionally sharp turn. It can also serve to smoothen out the transitions
in linear splines a bit, by deliberately setting it somewhat larger than zero.

So all in all, I think the parameter is there for good - provided that you heed
the advice to choose a value not *exactly* zero ;)

Post a reply to this message

> "Kenneth" <kdw### [at] earthlinknet> wrote:
>
> > But more prosaically, my original question--a rather naive one, as I see
> > now--was really about the *idea* of being able to set Foresight to zero. As
> > a way for the macro to 'make better sense' to the user. Of course, I do now
> > see the practical difficulties involved.  (Here's a REALLY goofball idea:
> > Maybe, 'behind the scenes' in the macro, there could be a little 'hidden'
> > addition of .001 or something, so that when Foresight IS set to zero, the
> > equations will still have a little number to work with.) A silly idea...


"clipka" <nomail@nomail> wrote:
> Indeed, it would deprive the user of choosing for himself how close to zero to
> go.
>

And Warp wrote (taken out of context)...
> Two points on the spline gives you an approximation of the direction of
> the spline (which is what is used here). The closer the points are to each
> other, the more accurate the direction will be. Of course one could hastily
> think that you should then use something like 1e-100 as the distance between
> the two points to get a very very very accurate direction. However, the
> drawback of using two points which are too close to each other is that you
> start losing accuracy (due to the limited size of floating point numbers).
> Thus using a distance of 1e-100 is not a good idea, as you will most probably
> get a larger error than with eg. a distance of 1e-10.

That's the only 'real' trouble with the macro (actually more of a mystery than a
problem): how small to make Foresight to get 'bleeding edge' alignment accuracy,
without going so low as to cause the equations to flip the object 90-deg. (I
haven't yet done any tests to see what that value might be.) No mention of it
in the docs, unfortunately. I'm sure there's *some* kind of formula for
determining that--probably based on the 'limited size of floating point
numbers.' But in a practical sense--from the user's standpoint--it would be
useful if the docs actually stated such a lower-limit value, whatever it is.
That would keep any 'surprises' at bay. (Or--egads!--does the value depend on
other parameters like spline type?)

KW

Post a reply to this message

Kenneth <kdw### [at] earthlinknet> wrote:
> That's the only 'real' trouble with the macro (actually more of a mystery than a
> problem): how small to make Foresight to get 'bleeding edge' alignment accuracy,
> without going so low as to cause the equations to flip the object 90-deg.

  You have to consider that after a certain accuracy has been achieved
(by making the distance between the two sample points close enough),
increasing the accuracy even further will have such a small effect that
it will disappear in all the other calculations being made afterwards
(eg. to rotate an object or whatever). Or put in other words: If the
direction is already accurate eg. to the 15th decimal, getting the 16th
decimal correct might be useless because subsequent calculations may have
rounding errors larger than that.

  Also if you think about it in practice, if you use the direction to eg.
reorient an object, after a certain accuracy any further accuracy would
transform the object so little that it will be like a millionth of a pixel
in the final image. The extra accuracy will be lost when actually rendering
the final image (if for nothing else, because pixels use only 8 or at most
16 bits per channel, and any accuracy change beyond a certain point will
be completely lost in the final image).

-- 
                                                          - Warp

Post a reply to this message

> That's the only 'real' trouble with the macro (actually more of a mystery 
> than a
> problem): how small to make Foresight to get 'bleeding edge' alignment 
> accuracy,
> without going so low as to cause the equations to flip the object 90-deg. 
> (I
> haven't yet done any tests to see what that value might be.) No mention of 
> it
> in the docs, unfortunately. I'm sure there's *some* kind of formula for
> determining that--probably based on the 'limited size of floating point
> numbers.' But in a practical sense--from the user's standpoint--it would 
> be
> useful if the docs actually stated such a lower-limit value, whatever it 
> is.
> That would keep any 'surprises' at bay. (Or--egads!--does the value depend 
> on
> other parameters like spline type?)

As Warp pointed out, going to really small values isn't really worth it most 
of the time.

As a rough rule-of-thumb, if R is the minimum radius of curvature in your 
spline, and D is the minimum error acceptable (in degrees) between the 
actual direction and the calculated direction, then use a foresight length F 
of:

F = R * D / 50

For example, if the tightest part of your spline is similar to a circular 
arc of radius 5 units, and you want alignment accuracy to within 1 degree, 
then use a foresight length of 5 * 1 / 50 = 0.1 units.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:

>   You have to consider that after a certain accuracy has been achieved
> (by making the distance between the two sample points close enough),
> increasing the accuracy even further will have such a small effect that
> it will disappear in all the other calculations being made afterwards
> (eg. to rotate an object or whatever)...
>
>   Also if you think about it in practice, if you use the direction to eg.
> reorient an object, after a certain accuracy any further accuracy would
> transform the object so little that it will be like a millionth of a pixel
> in the final image.
>

Yeah, I have to agree--'bleeding edge' accuracy really isn't necessary, from a
practical standpoint.

Yet, from the user's standpoint, the docs still leave out a few details that
would be useful (to avoid 'mysterious behavior'): What exactly *is* meant by a
'low' value for Foresight; and what's the lowest value that we shouldn't go
below. In light of all that's been said, I think the only thing that *is*
needed is a caveat in the docs--perhaps in one of those yellow boxes--something
like this:
"Since it's mathematically difficult to determine EXACT alignment using
Foresight, a recommended lowest value is *-----*."

Not the LOWEST bleeding-edge value, but one that allows some headroom, to avoid
*any* object-flipping. Just an empirically-derived value. That would be enough
to avoid problems, IMO.

KW

Post a reply to this message

"scott" <sco### [at] scottcom> wrote:

>
> As a rough rule-of-thumb, if R is the minimum radius of curvature in your
> spline, and D is the minimum error acceptable (in degrees) between the
> actual direction and the calculated direction, then use a foresight length F
> of:
>
> F = R * D / 50
>
> For example, if the tightest part of your spline is similar to a circular
> arc of radius 5 units, and you want alignment accuracy to within 1 degree,
> then use a foresight length of 5 * 1 / 50 = 0.1 units.

I think *this* would make a good addition to the docs as well! Although it's a
bit technical, there are similar kinds of 'detailed explanations' to be found
in other parts of the docs, for those who want/need them. (And in fact, the
idea that Foresight is actually a 'length' and vector direction--between two
adjacent, interpolated spline points--would be good to advertise too.)

KW

Post a reply to this message

Kenneth <kdw### [at] earthlinknet> wrote:
> Yet, from the user's standpoint, the docs still leave out a few details that
> would be useful (to avoid 'mysterious behavior'): What exactly *is* meant by a
> 'low' value for Foresight;

  The value should be small enough so that such a section of the spline of
that length has no significant curvature. (The more curvature there is in
the section of the spline between the two sample points, the less accurate
the approximated direction vector will be.)

> and what's the lowest value that we shouldn't go
> below. In light of all that's been said, I think the only thing that *is*
> needed is a caveat in the docs--perhaps in one of those yellow boxes--something
> like this:
> "Since it's mathematically difficult to determine EXACT alignment using
> Foresight, a recommended lowest value is *-----*."

  The problem is that there's not really a good lowest (or largest)
recommended value because it depends on the spline itself.

  You can't just say "a value of 1e-10 is recommended" because then if
your spline control points are at huge distances, you will get significant
rounding errors. On the other hand you can't say "a value of 0.1 is
recommended" because if your spline control points use very small values,
you will get significant approximation errors (because the curvature of
the spline will probably be very significant on those distances).

  "A value of 1/100 of the minimum distance between two consecutive control
points" could be closer to working, but could still depend on the spline
(if the curvature is really pronounced at some location, even that value
might not be accurate enough).

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Kenneth <kdw### [at] earthlinknet> wrote:
> > ...In light of all that's been said, I think the only thing that *is*
> > needed is a caveat in the docs--perhaps in one of those yellow boxes--
> > something like this:
> > "Since it's mathematically difficult to determine EXACT alignment using
> > Foresight, a recommended lowest value is *-----*."
>
>   The problem is that there's not really a good lowest (or largest)
> recommended value because it depends on the spline itself.
>

Ah, I had a funny feeling that this might be the case.  Oh well...

Maybe a more prosaic warning in the docs could be this:
"WATCH OUT! You might choose a too-low Foresight value that will flip the
object(s) 90-degrees! If that happens--choose a higher one, dummy!"  ;-P

KW

Post a reply to this message

Kenneth <kdw### [at] earthlinknet> wrote:
> "WATCH OUT! You might choose a too-low Foresight value that will flip the
> object(s) 90-degrees! If that happens--choose a higher one, dummy!"  ;-P

  Actually if you start getting significant rounding errors because the
values involved are too small (for 64-bit floating point), the object
might not flip 90 degrees, but behave otherwise erratically.

-- 
                                                          - Warp

Post a reply to this message