So let's analyze what I *really* wrote in my first posting - not what you like
to read from it:

------ OP:
> How these things may affect the Matrix, Transform and VProject_Plane stuff there
> is beyond me; but Foresight=0 obviously isn't a good recipe for success.
> IMHO--and in an ideal world-- the code should be rewritten to be more elegant
> and 'all-inclusive,' so to speak--so that a value of zero IS exact alignment.
------

Now here we have a request to make the macro "more elegant and 'all-inclusive'"
- does that sound like the OP desires to impose *additional* requirements on
the caller, like telling the macro what type of spline it is to be dealing
with?

------ Me:
It's fundamentally impossible to do that.
------

This is me referring to the task of making the macro work for the value of zero
(or rewriting the macro in any other way that would make it more elegant).

------ Me:
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.

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.
------

Now, here I do a - very small - excursion about the relationship between a
spline tangent, a spline function, and a derivative - and how that
"near-but-not-quite-zero" parameter comes to be.

Tell me, is there anything in there that is wrong?

Now that a symbolic solution for the derivatives of many functions can be found
is a totally different story: The *definition* is the above.

------ Me:
Of course even POV-SDL macros cannot overcome fundamental mathematical
limitations.
------

Do you disagree on this point?


------ Me:
The only alternative would be to figure out a general formula for f'(t) for the
spline type and parameters in question - but as there is no way to query either
of these from SDL, we're stuck with what the macro does.
------

Here I explicitly *do* mention the option of figuring out a general formula for
f'(t).

I also mention the core problem of "making the macro more elegant": The
impossibility to query an existing spline's type and parameters from SDL.

Note that it's not sufficient to know the *type* of a spline - you also need to
know *all* its control points.

You want to make a macro more elegant by forcing the user to re-supply *all* the
values he has already placed in the spline definition?


That's it, end of that first post of mine.

So: Where was I wrong in this posting? Or where did I miss the OP's intentions?

Post a reply to this message