COMPGROUPS.NET | Search | Post Question | Groups | Stream | About | Register

### Camera path using bezier curve & slow motion

• Email
• Follow

```Hi all!
I'm developing a simple Camera path editor using Bezier Curve.
I have exporting, as final result, a simple arrays of points (50 point)
take it by the bezier curver.
Now to use this point in my camera movement i use glulookat function
updating the vector eye with the elements of the array.
The main problem of this behaviour is that i cannot manage the speed,
and i cannot implementing a simple effect of slow motion.
There is way to use this array of point in camera movement and manage
the speed of camera at the same time ?
I would implement a bullet-time effect, so i need to slow down the speed
of the camera.

Thank you, and sorry for my bad english :-))

PiXy

```
 0

See related articles to this posting

```On Sat, 27 Dec 2003 12:43:08 +0100, BugPiX <bugman@quipo.it> wrote:
> Hi all!
> I'm developing a simple Camera path editor using Bezier Curve.
> I have exporting, as final result, a simple arrays of points (50 point)
> take it by the bezier curver.
> Now to use this point in my camera movement i use glulookat function
> updating the vector eye with the elements of the array.
> The main problem of this behaviour is that i cannot manage the speed,
> and i cannot implementing a simple effect of slow motion.
> There is way to use this array of point in camera movement and manage
> the speed of camera at the same time ?
> I would implement a bullet-time effect, so i need to slow down the speed
> of the camera.

Let say that each of the end points of the curve are keyframes. In your
situation each keyframe has position, and two control points. From that
information you can draw the bezier spline.

When you evaluate your splines you use a varying variable, usually called
T, and when evaluating a segment of the spline the T varies from 0 to 1.
This variable is time, and your problem is to map the playing time to the
spline evaluation time.

Your keyframe could look something like this:

struct SKeyframe
{
float	fP[3];		// point in world space
float	fInC[3];	// incoming control point
float	fOutC[3];	// outgoing control point
float	fTime;		// Time of the keyframe.
};

Each bezier segment is described as two keyframes (Previous and Current)
(example curve :):

C1
x
P0    __----_  P1
o-___--       -o
x
C0

P0 = Previous.fP
C0 = Previous.fOutC
C1 = Current.fInC
P1 = Current.fP

Now what you need to add to your current implementation is to handle the
time. Assign each keyframe time. Let's say the the time is in seconds. It
really does not matter what units you use, as long as you use the same
units all over.

Now that you have set time to each of your keyframes, you can calculate
the spline like this:

interpolatePath( float fTime )
{
// Assuming here that there are atleast two keyframes
// and that the time is between the keys..

SKeyframe*	pPrev = 0;
SKeyframe*	pCur = m_pKeyFrames[0];

// Find the corrent segment
for( int i = 1; i < nKeyframes; i++ )
{
pPrev = pCur;
pCur = m_pKeyframes[i]
if( pCur->fTime >= fTime )
{
// found correct pair of keyframes
break;
}
}

// Check here that the keyframes are valid...

// Normalize time to 0..1
float	fT = (fTime - pPrev->fTime) / (pCur->fTime - pPrev->fTime);

// The eval function expects P0, C0, C1, P1
evalBezier( pPrev->fP, pPrev->fOutC, pCur->fInC, pCur->fP, fT );
}

The above code lacks many sanity checks, but you propably will figure out
where to put them.

This way you can slowdown or speed up the movement by varying the time
parameter of each keyframe. Hope this helps...

--memon

cos(pi),sin(pi)            lddoW                      6Jo'3p15u1@uow3w
uow3W                 uow3w~/6Jo'3p15u1'mmm
```
 0

```Mikko 'memon' Mononen wrote:

> ...

I just want to suggest, so store the bezier segments in a bi-tree. That
gives you O(n)=log(n)*k complexity and thus is more performant, than the
simple for search which has a complexity of O(n)=n*k

--
+------------------------------------------------+
| +----------------+ WOLFGANG DRAXINGER          |
| | ,-.   DARKSTAR | lead programmer             |
| |(   ) +---------+ wdraxinger@darkstargames.de |
| | `-' / GAMES /                                |
| +----+''''''''     http://www.darkstargames.de |
+------------------------------------------------+

```
 0

```"Wolfgang Draxinger" <wdraxinger@darkstargames.de> wrote in message
news:bsnhlb\$qdc\$1@svr7.m-online.net...
> I just want to suggest, so store the bezier segments in a bi-tree. That
> gives you O(n)=log(n)*k complexity and thus is more performant, than the
> simple for search which has a complexity of O(n)=n*k

Perhaps even a better choice is to store the indices for
the last pair of bounding keys.  Start the search the
next time at this pair.  The expected search time is O(1).
The idea is to take advantage of time coherency.

--
Dave Eberly
eberly@magic-software.com
http://www.magic-software.com
http://www.wild-magic.com

```
 0

```Dave Eberly wrote:

> Perhaps even a better choice is to store the indices for
> the last pair of bounding keys.  Start the search the
> next time at this pair.  The expected search time is O(1).
> The idea is to take advantage of time coherency.

Yes, this is of course better, when you can predict the time of the next
frame. I just mentiones this, because in our upcomming game, as the
player advances the manipulation of time becomes an essential part of
gameplay and sometimes time even goes backwards. Because of this I had
to implement the bezier frame access as bi-tree.

--
+------------------------------------------------+
| +----------------+ WOLFGANG DRAXINGER          |
| | ,-.   DARKSTAR | lead programmer             |
| |(   ) +---------+ wdraxinger@darkstargames.de |
| | `-' / GAMES /                                |
| +----+''''''''     http://www.darkstargames.de |
+------------------------------------------------+

```
 0

```Mikko 'memon' Mononen wrote:
> On Sat, 27 Dec 2003 12:43:08 +0100, BugPiX <bugman@quipo.it> wrote:
> ....
> ....
> This way you can slowdown or speed up the movement by varying the time
> parameter of each keyframe. Hope this helps...
>
>

Thanks!! In this way should work. But i find a method that, gives point
on a bezier curve (saved by my camera editor in a file), move smoothing
the camera with slow motion or not.
In short words, i evaluate the curve in 50 points (or more / less ), and
saving an array of this point in a file. In my other opengl
application/demos i find a way to use this point, loaded in memory at
the start of application...

PiXy

```
 0

```On Sun, 28 Dec 2003 22:47:14 +0100, Wolfgang Draxinger <wdraxinger@darkstargames.de> wrote:
> Dave Eberly wrote:
>
>> Perhaps even a better choice is to store the indices for
>> the last pair of bounding keys.  Start the search the
>> next time at this pair.  The expected search time is O(1).
>> The idea is to take advantage of time coherency.
>
> Yes, this is of course better, when you can predict the time of the next
> frame. I just mentiones this, because in our upcomming game, as the
> player advances the manipulation of time becomes an essential part of
> gameplay and sometimes time even goes backwards. Because of this I had
> to implement the bezier frame access as bi-tree.

I think the obvious optimisation is to indeed keep track on the previous
found keys, and do these checks:
1) if the requested time is within the segment, use the segment
2) if it's greater try the next segment
3) if it's less try the previous segment
4) else do full search (maybe relative to the current position)

I've never run into troubles with the brute force method, but those
optimisations are simple enough that they might be worth implementing. My
applications usually have also needed editing of the data structures so
the linear array is much easier to handle (at least psychologically, does
not sound that complicated ;).

--memon

cos(pi),sin(pi)            lddoW                      6Jo'3p15u1@uow3w
uow3W                 uow3w~/6Jo'3p15u1'mmm
```
 0

```Mikko 'memon' Mononen wrote:

> I've never run into troubles with the brute force method, but those
> optimisations are simple enough that they might be worth implementing. My
> applications usually have also needed editing of the data structures so
> the linear array is much easier to handle (at least psychologically, does
> not sound that complicated ;).

Actually all my space subdivision code (bi-tree, quad-tree, octree) work
on normal C Array data. For interpolation there's also done some
"mipmapping" on the data.

I even tried this as a LOD technique for terrains, and it really works
great. On my IMHO very old machine (Dual P2 400MHz) the demo runs
smoothly (min ~40 fps), despite the fact, that a 2048x2048 terrain is
rendered using slow glVertex calls. Really strange.

Wolfgang

```
 0

7 Replies
1064 Views

Similar Articles

12/5/2013 8:49:33 AM
page loaded in 2364 ms -0