camera is jumpy, why?

[suliman]

Hi
I've made a chasecam that im fairly satisfied with (it smoothly "drags" behind my aircraft, speeding up to it when i accelerate and likewise when i turn och slow down). Problem is that its jumpy sometimes, and i dont know what's wrong... Any idea what could make it so?
Its jumpy even at framerates around 100 so i dont think thats to problem...

(posIn and rotIn is position and rotation of the aircraft node it follows, and vel is a scalar describing the movement speed of the aircraft at each moment)

Code: Select all

void player::setChaseCam( vect3d posIn,vect3d rotIn,float vel,float dist/*=1*/,float height/*=1*/,float aimHeight,float heightOffset,float speed/*=1*/,ICameraSceneNode * cam/*=0*/ )
{
    if(!cam)
        return;
 
    double simSpeed=SPEED; //the simulationSpeed of your game
 
    if(!www.moveThem)
        return;
 
    static float camMod=1;
 
    if(ppp->kh.keyDown(KEY_ADD))  //use your input-code here
        camMod+=2.0*simSpeed;
    if(ppp->kh.keyDown(KEY_SUBTRACT))
        camMod-=2.0*simSpeed;
    clamp(camMod,1,2);
 
    //find desired camPos
    float lenght=60.0*camMod*dist;
    height+=15.0*height*camMod;
 
    matrix4 m;
    m.setRotationDegrees(rotIn);
    vector3df dirBack(-1,0,0);
    m.rotateVect(dirBack);
 
    camPos =posIn;
    camPos+=dirBack*lenght;
    camPos.Y+=height+heightOffset;
 
 
    vect3d camNow = cam->getPosition();
    float camSpeed=0.01*speed;
    //  float camSpeed=0.04*pow(vel,1.3f);
 
    float disX=(abs(camPos.X-camNow.X));
    float disY=(abs(camPos.Y-camNow.Y));
    float disZ=(abs(camPos.Z-camNow.Z));
 
    //move-distance this tick
    float deltaX=camSpeed*disX;
    float deltaY=camSpeed*disY;
    float deltaZ=camSpeed*disZ;
 
    //apply move-distance to camPos
    float sp2=simSpeed*200.0;
 
    if(camPos.X>camNow.X)
        camNow.X+=deltaX*sp2;
    if(camPos.X<camNow.X)
        camNow.X-=deltaX*sp2;
 
    if(camPos.Y>camNow.Y)
        camNow.Y+=deltaY*sp2;
    if(camPos.Y<camNow.Y)
        camNow.Y-=deltaY*sp2;
 
    if(camPos.Z>camNow.Z)
        camNow.Z+=deltaZ*sp2;
    if(camPos.Z<camNow.Z)
        camNow.Z-=deltaZ*sp2;
 
    cam->setPosition(camNow);
 
    //set camera target (where cam looks at)
    vect3d camAim=posIn;
    camAim.Y+=height*aimHeight;
    camAim.Y+=heightOffset;
 
    cam->setTarget(camAim);
 
 
    //move cam due to last frames rot
    vect3d pos = cam->getPosition();
    vect3d rot = rotIn;
    m.setRotationDegrees(rot);
    vector3df dir2(1,0,0);
    m.rotateVect(dir2);
    pos += dir2*vel*simSpeed*200.0;
    cam->setPosition(pos);
 
}
 

[CuteAlien]

Sorry, not easy to figure this stuff out. What I can tell you is that I didn't manage to get smooth camera in my H-Craft game until I started working with quaternions. Not sure if my code will be of any help, but you can find it at https://bitbucket.org/mzeilfelder/trunk_hc1 under src/camera.cpp/.h

[suliman]

Oh my...
Thats a lot of code and math for the cam:) Ok ill see what I can understand.

Thanks!
Erik

[CuteAlien]

I won't stop you from learning math of quaternion, but you don't really need it (it's something about complex numbers which not only have i but 3 different imaginary units). What you need to know is that like euler angles or matrices it's yet another way to handle the 3d transformations. And Irrlicht's quaternion class can convert from those to quaternions and back to matrices and/or eulers. And they have one really cool feature which is the "slerp" function. That takes 2 quaternions and interpolates smoothly between them in the shortest possible way. And the interpolation is in the range 0-1 (so 0 is old quaternion, 1 the new one and the rest in between). So you convert your original position/rotation and the target position/rotation you want to 2 quaternions - call the slerp - and then convert the result back and use it.

[mongoose7]

What?? Nothing to do with complex numbers. They consist of a vector (axis) and a (half) angle. What can be more intuitive than that? By comparison, Euler angles are freaky. For example, true Euler angles only affect two axes, like XYX.

[suliman]

But math aside, where do you think the problem lies? Im confused, since even if I simply set the desired cam-pos and cam-target each frame it gets jumpy.

Is it the change in framerate? Or framerate resolution maybe which is based on whole milliseconds since last frame? At 200-300 fps i get smoothness galore, but at 100 or less it gets jumpy (and i cannot demand 200fps at all times:) )

[CuteAlien]

mongoose7: fromAxisAngle seems a little different. Guess Wikipedia has all the math if you got bored on the weekend.

[mongoose7]

Please don't insult my intelligence. From Wikipedia, just for you:

In 3-dimensional space, according to Euler's rotation theorem, any rotation or sequence of rotations of a rigid body or coordinate system about a fixed point is equivalent to a single rotation by a given angle θ about a fixed axis (called Euler axis) that runs through the fixed point. The Euler axis is typically represented by a unit vector u→. Therefore, any rotation in three dimensions can be represented as a combination of a vector u→ and a scalar θ. Quaternions give a simple way to encode this axis–angle representation in four numbers, and can be used to apply the corresponding rotation to a position vector, representing a point relative to the origin in R3.

Note: axis–angle representation in four numbers. I've got no idea what 'fromAxisAngle' is - something you wrote?

[CuteAlien]

@mongoose7: The function I mentioned above is the one in Irrlicht where you can see the conversion of axis-angle to quaternion (it's in the quaternion class - other way round as well). Quaternions contain the same information like axis + angle, but it's another format. You don't have the axis itself in those numbers (but something like normalized_axis*sin(half_angle)).

[mongoose7]

And what, pray tell, is the difference between a normalised axis and an axis? I guess vector normalisation must be something wonderful that converts a vector into a non-vector? A quaternion is (x, y, z, w) where (x, y, z) is the axis and w, I think, is cos(half-angle), normalized so that x^2 + y^2 + z^2 + w^2 = 1. I think this is just about as simple as it could be. (The angle could not be included as itself because you couldn't normalise the resulting 4-vector.) (cos() is used so that the normalisation fails when the angle is 0, and not when the angle is 90 deg. if you used sin() and the angle was 90 deg, the normalisation would be (0, 0, 0, 1) so the axis couldn't be specified. Using cos(), this problem occurs when the angle is 0 deg, but (0, 0, 0, 1) is unambiguous as a zero degree rotation does not need an axis.)

[CuteAlien]

Ah thanks, my fault, I see it now looking at the code again. My problem wasn't the vector normalization (I just added that for completion), but I didn't realize the sin is just another constant here using same value all 3 times. So it's really just the axis scaled by a constant to make it normalized. Wow - never seen that :-)
Thought wikipedia still says it's an extension of complex numbers.

[thanhle]

I think Quaternion was derived from complex number.

It is competing with matrix. But in the end matrix win it's popularity.

There is a new form of Mathematic called rational trigonometry it might be useful at some point in time.

[thanhle]

Back to the camera problem.
If you add simple linear acceleration for your camera at the begining (e.g. increase delta distance at some rate over time), then follow by matrix or quaternion calculation for update, it will be smooth.

Regards,

[suliman]

Hmm im not understanding why i need "matrix or quaternion calculation" for it to be smooth... What is the actual problem with how i do it now? Is it not related to changing fps, then what?
Also, do i not already have linear acceleration?

Cam pos is moved towards the intended goal - with speed based on distance between intended and current pos.
Cam target is simply set to a fixed point (related to the aircrafts pos).

Why do this act jumpy in some situations (never when far away from the intended goal) and act smooth in others?

Thanks for your patience
Erik

[CuteAlien]

Figuring out that kind of stuff also always takes me some hours/days. But check if the angle and movement-distance is smooth over time. So if you start printing out times, angles and movement-lengths after each call then you might see something which is off. Angle and move-distance should probably be close to constant over similar time-steps. Or maybe in this case you don't want constant angles but constant circle-arc-lengths to avoid getting faster when you are further away. Actually on first view I don't even see any time-delta in your code.

Also be aware that 100 fps does not mean much in game development - that's mainly a number for marketing. What you care about for smooth gampeplay is the worst case - not the average case. You can have 99 frames which take 0.01 seconds and 1 frame which takes the other 0.99 seconds and you will have a horrible jerky gameplay despite 100 fps.

If you need more help you need to produce at least a complete test-case. Aka something other people can compile & run and then see the results. The chance that someone writes his own application around your function above just to help you debugging is pretty low.