next »

[Orz]

I'm trying to implement a chase camera for a kart racer, and am never really satisfied with the results of my setup.  So far I've tried 2:

Camera A is stationary, and is constrained to stay within an adjustable radius of the kart.  Works well for open areas, but in close corners it's possible to scoot around a corner and be blind until the camera catches up.

Camera B is fixed an adjustable distance behind a "floater" node that lies just above the kart.  When the kart rotates, the "floater" rotates to catch up with it at an adjustable rate.  The main problems are that it restricts the field of view, and goes crazy during crashes as the camera struggles to get behind the kart.  Not sure if this is a problem or not.

I will probably end up doing some combination of these 2, dependent on linear velocity, angular velocity, and proximity to walls.  Curious to see what other people have tried.

[JakobProgsch]

I would try something like: CamPos = CartPos + CamHeight*up - dist*normalize(CartVelocity)

That way you always see towards where you are driving/drifting/uncontrollably hurtling.

[Garthy]

How about basing the target angle of the floater (where the floater is moving to) on the actual velocity of the vehicle (not the vehicle direction), and making the rate of change dependent on the speed (ie. magnitude of the velocity)?

This would cause it to turn slowly when you're moving slowly (say, recovering from a crash) and snap to your current movements more quickly when you're speeding along.

Another thing you could try is combining a number of weighted vectors to determine the target angle of your floater. Some possible inputs would be current velocity, current facing, the "correct" angle to face at a point on the track, and the "correct" angle to face based on a distance down the track.

[maetheec]

Chase camera can get complicated... but it should be easier on a kart racer. May be like putting the camera on a leech... like water skiing? If you're aiming for something like Mario Kart, then I think you don't need any physic or collision... but you need to fade out geometry that's in front of the camera.

[Orz]

Thanks! I should have been using the kart velocity vector all along.  What I really needed to see was where the kart was moving, not where the player wants it to move (kart angle). 

Keeping the camera out of walls is pretty simple.  I cast a ray from player to camera and move the camera to the first intersection with collision geometry.  You can still see inside buildings at extreme angles, but I'm not a perfectionist.

Combining these with an increased follow distance at higher speeds makes a pretty solid default camera.  I eventually want to allow the player to choose from a series of dramatic camera angles (flyby, orbit, Ronin, Battlefield Earth, etc.)  and award them points for completing an entire uninterrupted "shot".

[Gimym TILBERT]

don't move the camera move the near plane instead for better visibility and framing. Advence tips is to have a framing effect when the near plane is moved along with a slight forward offset to indicate there is an obstacle. Even more advance is to have a collision box that scale with the near plane + some margin, perfection might be too much but using that collider to register collision, previous movement and line of visibility, but that's too far, just move the near plane and the camera with a fixed offset.

[Orz]

don't move the camera move the near plane instead for better visibility and framing. Advence tips is to have a framing effect when the near plane is moved along with a slight forward offset to indicate there is an obstacle. Even more advance is to have a collision box that scale with the near plane + some margin, perfection might be too much but using that collider to register collision, previous movement and line of visibility, but that's too far, just move the near plane and the camera with a fixed offset.

That's a good idea.  I have had problems with the player squeezing through alleys smaller than the near field and getting culled out of the scene.  Until now, I thought this was unavoidable.

I like the framing effect when it's used in RPGs.  But the karts go so fast that advance warning of obstacles isn't that useful.  I'll consider it, though.

I have tried the collision box method, and it was too complicated to justify the few times where it was helpful (partly due the narrow alleys I mentioned before).

[Gimym TILBERT]

By framing I mean darkening the corner a bit, with a timer on the alpha it won't be noticeable if time is small, apply the same logic about the forward offset.

Yes the collision require a bit more thought and may not be as useful for a racing game. It prevent the near plane to be actually crossed by an object (wall notably) when we have only one point of reference through raytracing. but there is a bit of management to do it effectively, especially in special case (the corridor is smaller than the collision box) but those case are likely to be rare.