|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alright, first off .... I do realize that Colefax's spline macros will solve
this but I'm trying to figure this out.
I wrote a macro to generate splines from a set of points. It uses the
spline feature of 3.5 but calculates the time values to eliminate
acceleration and deceleration along the spline.
It estimates the length of the spline between control points and for the
overall length.
I'm assuming the difference in time between points is proportional to the
segment lengh / overall length.
It works fine for linear splines but quadratic's tend to drift quite a bit.
I even tried writing a length finder where you could set to acceptable error
and the times still drift.
Can anyone point me in the right direction here.
I'll try to clean up the source if anyone wants to see what I've done.
thanks
Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher Johnson <age### [at] hotmailcom> wrote:
> Alright, first off .... I do realize that Colefax's spline macros will
solve
> this but I'm trying to figure this out.
>
> I wrote a macro to generate splines from a set of points. It uses the
> spline feature of 3.5 but calculates the time values to eliminate
> acceleration and deceleration along the spline.
>
> It estimates the length of the spline between control points and for the
> overall length.
> I'm assuming the difference in time between points is proportional to the
> segment lengh / overall length.
>
> It works fine for linear splines but quadratic's tend to drift quite a
bit.
> I even tried writing a length finder where you could set to acceptable
error
> and the times still drift.
>
> Can anyone point me in the right direction here.
As you've discovered, traversing a curved spline at a constant speed is not
that simple. The problem is that not only does each segment travel at its
own speed, but within each segment there is acceleration and deceleration
(generally slower around tighter corners).
Now, I believe that there may be an analytical solution to the problem for
quadratic splines, although this would involve recoding the internal spline
functions. Instead, you may wish to try a solution similar to that I've
used in my Spline Macro file.
The file calculates cubic splines, for which no analytical solution exists.
Therefore, to achieve constant speed the macros actually evaluate the spline
at regular intervals, storing each time value and distance travelled in an
array. This array is then used to estimate the time value needed to return
a point at a particular distance along the spline, and using equally-spaced
distance values allows the spline to be traversed at constant speed.
Post a reply to this message
|
|
| |
| |
|
|
From: Christopher Johnson
Subject: Re: Normalizing a quadratic spline
Date: 13 Jan 2002 00:56:54
Message: <3c4121a6@news.povray.org>
|
|
|
| |
| |
|
|
"Chris Colefax" <chr### [at] tagpovrayorg> wrote in message
news:3c3d8543@news.povray.org...
> As you've discovered, traversing a curved spline at a constant speed is
not
> that simple. The problem is that not only does each segment travel at its
> own speed, but within each segment there is acceleration and deceleration
> (generally slower around tighter corners).
>
> Now, I believe that there may be an analytical solution to the problem for
> quadratic splines, although this would involve recoding the internal
spline
> functions. Instead, you may wish to try a solution similar to that I've
> used in my Spline Macro file.
>
> The file calculates cubic splines, for which no analytical solution
exists.
> Therefore, to achieve constant speed the macros actually evaluate the
spline
> at regular intervals, storing each time value and distance travelled in an
> array. This array is then used to estimate the time value needed to
return
> a point at a particular distance along the spline, and using
equally-spaced
> distance values allows the spline to be traversed at constant speed.
>
Ok, I've moved from quadratic to cubic splines since cubics are much more
smooth. Before I make one more attempt at this, I have two questions.....
1. Using cubic splines (pov 3.5 native), does the number of control points
affect it's evaluation. Basicly, are these treated as local splines or does
it slow down with more points?
2. What are the space requirments for the splines in memory terms. I'm
assuming there is some base amount + a certain value per point (depending on
how much the point needs).
Again, I do realize I'm digging a nice deep hole for myself with this one
but to be honest, I can't let go yet. I have one more idea to try out. So
far I've got a spline pre-processor that re-evaluates the time values for
each point. The next step will have it subdivide the spline and add points
where neccessary. If the number of control points doesn't adversely affect
performance, this might work .... to a degree. Might as well give it a
shot.
Thanks again,
Chris J.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I hate to ask a question of someone who's asking questions themselves, but
could you point me to a place that explains (or explain yourself) how cubic
splines are interpolated? I'm pretty sure they're split up into three cubic
functions - in the X, Y, and Z directions, but what I'm confused about is
when two adjacent points have the same X value; doesn't that cause some zero
or infinite slopes or something? I dunno, I probably have it all wrong. A
little help?
- Slime
[ http://www.slimeland.com/ ]
[ http://www.slimeland.com/images/ ]
Post a reply to this message
|
|
| |
| |
|
|
From: Christopher Johnson
Subject: Re: Normalizing a quadratic spline
Date: 13 Jan 2002 22:58:37
Message: <3c42576d@news.povray.org>
|
|
|
| |
| |
|
|
"Slime" <noo### [at] hotmailcom> wrote in message
news:3c41caa5$1@news.povray.org...
> I hate to ask a question of someone who's asking questions themselves, but
> could you point me to a place that explains (or explain yourself) how
cubic
> splines are interpolated? I'm pretty sure they're split up into three
cubic
> functions - in the X, Y, and Z directions, but what I'm confused about is
> when two adjacent points have the same X value; doesn't that cause some
zero
> or infinite slopes or something? I dunno, I probably have it all wrong. A
> little help?
>
> - Slime
> [ http://www.slimeland.com/ ]
> [ http://www.slimeland.com/images/ ]
>
>
To put it simply (maybe too simply) it's not just one function. It's parts
of different functions blended to fit the control points. The reason you
can have say two points with the same x or y or z is that it's not evaluated
with those terms. The spline is evaluated as 0 at the begining to 1 at the
end. If your looking for the blood and guts math explanation, you'ld have
to check a good computer graphics text on that. Hope that helps some.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|