The Persistence of Vision Raytracer (POV-Ray).
This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.
Opened by Christoph Lipka - 2012-07-06
Last edited by William F Pokorny - 2016-10-11
FS#248 - Implement mechanism to compute direction of a spline
The SDL currently provides no way to compute the exact direction of a spline at a given location, even though mathematically this is a piece of cake: The first-order derivative of any spline section gives you the “speed” as a vector function, and is trivial to compute for polynomial splines (which are behind all spline types that POV-Ray supports); the normalized “speed” vector, in turn, gives the “pure” direction.
For exact direction/speed computations, I propose to extend the SDL invocation syntax as follows to allow for evaluating a spline’s derivative:
SPLINE_INVOCATION:
SPLINE_IDENTIFIER ( FLOAT [, SPLINE_TYPE] [, FLOAT] )
or
SPLINE_INVOCATION:
SPLINE_IDENTIFIER ( FLOAT [, FLOAT] [, SPLINE_TYPE] )
where the second FLOAT will specify the order of derivative to evaluate (defaulting to 0). In order to compute the position, direction, and acceleration of an object traveling along a certain spline, one could then for instance use:
#declare S = spline { ... }
#declare Pos = S(Time);
#declare VSpeed = S(Time,1);
#declare VAccel = S(Time,2);
#declare Dir = vnormalize(VSpeed);
#declare Speed = vlength(VSpeed);
#declare AccelDir = vnormalize(VAccel);
#declare GForce = vlength(VAccel) / 9.81;
Alternatively, a mechanism may be devised to create a spline representing another spline’s derivative; however, it would be debatable whether the syntax should be parameter-like (being an added information that could be overridden again when creating other splines from such a derived spline), or operation-like (converting the spline), and in the latter case how it should affect spline type (and consequently control points); so the spline invocation parameter approach might be more straightforward, with less potential surprises for the user.
Sanity check: linear spline (basic straight lines) is often not derivable at inflexion point (which practically means every declared points).
How do you intend to solve that piece of cake ?
If you choose either the left or right first derivative, there will always be the case in which someone would have wanted the other one... unless the syntax allow to choose the side too ?
The Lagrange's notation for derivative could be used to have : SPLINE_IDENTIFIER ' ( FLOAT, SPLINE_TYPE )
(and so on for the second derivative: SPLINE_IDENTIFIER '' ... the more ', the deeper... may be an upper limit should be enforced)
Usage with number could be SPLINE_IDENTIFIER ^( INTEGER ) ( FLOAT, SPLINE_TYPE )
(mimic the f^(4)(x) notation for the fourth derivative of function f, in Lagrange notation)
Euler's Notation uses a Df (D^2 f for the second and so on), but it's a bit cumbersome to catch just the D letter, and unicode is not yet mainstream enough for a true symbol.
Newton's notation with dot above the symbol is good for ÿ but not for a spline identifier.
Leibniz's notation (dy/dx ) is not practical inside the SDL.
Any way, how to have the left or right one ?
While a spline as a whole may not be derivable at all points, the individual segments of a polynomial spline always are, so handling of inflexion points boils down to choosing which adjacent segment to pick the derivative from; solution is easy: Just make a decision (the two sane options are (A) the "earlier" segment, or (B) the "later" segment, the choice being pretty arbitrary), implement it consistently, document it properly, and live with it.
As for the syntax, none of your suggestions bears any resemblance to established POV-Ray syntax, so consider them not an option (even if you'd get them past my dead body, Thorsten would surley issue a veto).
I agree with Christoph. The derivatives at any point of a compound function (like a spline) depend on which segment the point belongs to, since we differentiate compound functions component-wise. So here it just depends on whether you use < or < = in the spline's source code. (EDIT: "Mathematically" was not quite correct, this is the practical approach.)
As for the first- and second-order derivatives, there is not problem with cubic splines; for other spline types, the derivatives just have to jump somewhere since they cannot be continuous. Which segment to pick is a question of what the spline ist used for, although currently I cannot think of any use-case in which that would be so much important.
I think if the Lagrangian notation is no option, the parameter version (S(Time, 1)) is the one that looks reasonable, doesn't it?
Accidentally posted a similar feature request as #276.
Thanks for the info.
FS#276is now officially marked as a duplicate of this request.So, will there be an attempt to include such a feature soon?
By the way, the derivative value to choose (left/right) could, if really necessary, be configured within the spline declaration, a global_settings statement, or both (the former overriding the latter).
#declare my_spline = spline { linear_spline // etc. left_derivative // or: right_derivative ... }Now tracked on GitHub as #115.