Re: importing motion paths

New Message Reply Date view Thread view Subject view Author view

Alejandro Saez (cano++at++krusty.engr.sgi.com)
Mon, 14 Sep 1998 11:13:58 -0500


On Sep 11, 11:18am, Geoff Levner wrote:
> Subject: importing motion paths
> We are looking for a way to import motion paths into Performer, both for
> the observer and for objects in the scene. In particular, we would like
> to be able to edit a spline-based path in a MultiGen scene, then import
> it. MultiGen allows you to create splines, but apparently does not allow
> you to save them!
>
> Does anyone out there have any suggestions?
>
> --
> Geoff Levner -- geoff++at++mclink.it OR glevner++at++hotmail.com
> Via Conca d'Oro 285, 00141 Rome, Italy
> =======================================================================
> List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>-- End of excerpt from Geoff Levner

The problem is that you don't really "save" a spline. The nice thing about
splines is that you can define higher order curves (higher than 1) by
specifying a set of points (wheights). So, without actually knowing if Multigen
saves those points in the database, what you would have to do is :

1) Know what kind of splines Multigen uses, Multigen.. anyone? This is very
important because if you use your own splines it will certainly be a curve but
probably won't correspond to the Multigen path. I guess some sort of Bezier
spline is being used since in this kind of splines the initial and final points
are preserved.
2) Get the knots describing the spline (are they preserved in the OpenFlight
db, again Multigen.. anyone?)
3) Compute the spline by hand.

One final word about splines. If you are using splines for motion description,
most splines, unlike linear interpolation, are not uniformly spaced, that is if
you evaluate the spline at 4 different places but using the same delta u, you
won't get the same delta distance, that is distance0 traveled in (u0, u0+delta
u) won't be the same when evaluating distance1 traveled in (u1, u1+delta u)
This might be a problem since what you usually know is the vehicle's (or
observer's) speed, and thus you know how much the vehicle has advanced from
frame to frame, from there, it is also easy to know where to evaluate a linear
interpolation function to get the updated position. When using a spline this
relation doesn't exist (not easily computed), you know you have to move your
vehicle, say 100 meters, but what u (0->1) of which spline segment gives you a
100 meters of traveled distance? There are 3 ways to go about this (that I know
of):

a) I remeber reading some papers to re-define a spline so it can be uniformly
evaluated. This is equivalent to having the second derivative uniform (not
constant) and if you want constant speed, having the third derivative equal to
zero..(and the second equal to the speed) I guess one could end up describing
the spline basis functions with this...I might still have those papers, if you
want them have me look for them.
b) Linearize your spline (pre-computation), it sounds stupid but for most
vehicle this is all you need.
c) I once wrote a piece of code that would iterate through the spline until I
got a constant speed. The mathematic formulation would be to integrate over the
path to find out exactlly the traveled distance, but I just "linearized" this
distance calculation which is a bit like doing suggestion b), so I dropped it
because it also ate app time.

I know this is not exactly what you asked for... but just in case it might help
you.

-- 
------------------------------------------------------------------------
Alejandro Saez
Software Engineer
Silicon Chile S.A.
                                        Avda. Santa Maria 2560
E-mail: asaez++at++silicon.cl              	Providencia
Phone:  +56 (2) 203 3371 Ext. 107 		Santiago
Fax:    +56 (2) 203 3370                Chile
------------------------------------------------------------------------

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Sep 14 1998 - 08:16:11 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.