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

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

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

"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

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

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

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

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