how do racing games typically angle cameras to look as nice as they do when turning? How do they make it look natural and gradual, yet still functional?
In: Mathematics
It’s actually pretty hard.
As a rule of thumb, the camera should not be fixed with regard to the vehicle, else it feel “stuck”.
Something what works well is to point the camera towards the point the car will be in a second. When on the road you assume the player will follow the road, but when outside the road it’s harder. You assume the car will continue turning and moving at the speed it is moving. That’s why the camera is more annoying when the car just stopped, it does not know in which direction you are going to go next.
lots of trial and error. bad camera angles make some games nearly unplayable. say the camera adjusts to quickly, making it jump in a disorienting fashion during sequential turns. other games take that as an example of what not to do, and limit how quickly the camera can turn. then it turns out that makes it impossible to see where you’re going after a hard u-turn, so they have to adjust it again. until they find a good balance
What camera angles are we talking about? 3rd person or 1st person helmet or?
Usually you use the vehicle’s velocity vector to derive the follow position and look-at rotation from. Add to that an offset depending on longitudinal speed, and G-force effects to make jumps and bumps look impactful.
Having worked on a racing game that was never released, there are a LOT of ways to do this.
Unfortunately there’s no real rigid set of rules for what you do to make the camera good, you just kind of have to experiment with what works.
One example though…
Rail Guide: Along the expected courses of travel there’s an invisible rail that the camera slides along. It is NOT fixed to the rail, but it is guided strongly by it. When the vehicle is directly under the rail, the camera is on the line. When the vehicle is 1 unit to the left, the camera moves 1 unit to the left. When the vehicle is 2 units to the left, the camera is 1.8 units to the left. The camera follows the car, but the further the car gets from the rail, the less the car pulls on the camera, but the camera still points at the car. This behavior means that when the car is banking widely around a turn, you get that somewhat swooping-to-the-side motion of the camera.
But what about when the car completely leaves the area around the rail, wouldn’t that look weird? Oh yes! So that’s why you have an ability for the car to get so far away that the camera snaps off the rail. Except snap is a bad word, that’s jarring and looks terrible. So what you do is set a max distance between the car and rail and you rig up a smoothed approach. Once the distance gets within a few units of your max, you gradually start to lessen how much control the rail has over the position of the camera. This way as the player leaves the rail, the camera doesn’t suddenly snap into motion relative to the car.
But what about the fact that they can leave the rail at different rates (imagine gradually drifting away, vs not turning at a 90 degree bend)? Well, now you have to get into some predictive stuff. Instead of having that distance where you begin your transition away from the rail be fixed, you set an invisible ball slightly out front of the car and you have your “set point” (which was previously fixed) which can adjust closer/farther to the max level based on the calculated acceleration of distance-change between the forward invisible point and the line. In short, if the invisible point suddenly ‘accelerates’ drastically, this is the situation where the car didn’t take the turn. With a high acceleration you’d want the deviation from your set point to be LARGE, so you start transitioning your camera off the rail sooner.
There’s more detail that can be added, but roughly where I’m getting at is that for really nice and smooth camera work, there’s basically no singular tiny piece of code that’s going to do it. Systems on systems, with systems between to smooth the transition.
The most important advice that I can give is to make your set-point variables easy to adjust. If you are working in Unity, have those variables accessible from the Inspector Tab. The reason for this is that no matter what system you develop, there’s going to be variables to adjust it. A wrong variable can make a perfectly fine system appear like garbage, so there’s going to be a lot of trial and error.
The second most important advice is, don’t settle for the local maxima. If you find a set of variables that is “pretty good” but it’s not actually as good as you want it to be no matter how you tweak the variables, don’t just accept that as the best you can do. Slap another system on. Scrap the whole system and start over.
And on a note from Sid Meier, if a variable is worth adjusting, don’t up it by tiny increments. If you think +/-1 might do, then FIRST try +/-5. It’s hard to quantify small changes, its easy to quantify big changes. If +5 doesn’t do what you want, then switch to the -5. If +5 did what you want but it did it too hard, now you can start narrowing down. Try 2.5 as a shift. Etc.
Good luck!
5 year old explanation is that in most games the camera just points towards the direction the car is actually moving, not the way that it’s facing. This works somewhat because it’s fairly natural to look in the direction that you are moving while in a car, especially the more you’re sliding.
Of course, no external camera is realistic or can ever apply to anything in real life so it’s never going to be right. Best solution by racing sims is to force cockpit-only view and implement VR which solves the problem outright. And it’s also amazing AF. You would never want to race with external cam again after racing in a good sim that supports VR. I might be a shill for saying that but no one is paying me..
The simplest way of doing it is measuring the angle between the camera and the vehicle’s longitudinal axis and using that to control the rate at which the camera rotates around the vehicle’s center point.
As the angle increases, so does the rate at which the camera rotates, until it matches the rate at which the vehicle rotates. At that point, the angle will no longer increase, but the camera will be offset to the side because it lags behind whenever its rate of rotation is less than the vehicle’s rate of rotation. And when you stop turning, the camera will keep turning but as the angle decreases, the camera’s rate of rotation will also decrease, reaching zero when the camera is centered.
You can also control the maximum offset angle by using a different equation for the rate of rotation. Any arbitrary equation will do as long the input is the angle and the output is the rate of rotation. The example I described above is simply [rate of rotation] = [angle]. But you could just as easily do [rate of rotation] = 0.025 * [angle], or you could do silly stuff like [rate of rotation] = e^(cos([angle])) that’ll probably make you nauseous when you try to play the game.
But of course, nothing’s keeping you from also including other variables like the vehicle’s speed, or whether you’re using your TurboNitroSuperBoost or whatever.
I am developing racing game.
To add what other guys have said. It’s complex, but here is start solution. First you need to choose relative target point and rotation of camera. For example: you want camera to be 10m behind car, 3m above ground (or car to be more precise) and to point toward car and road ahead (that’s camera rotation). As car moves, target point moves. Camera itself has max acceleration and max speed, when trying to reach target. So camera is chasing target point, and since it has max acceleration, which acts as inertia, you get smoothing effect, no shaking.
Edit: typo
Most chase cameras actually work as if they were attached to a spring. Imagine a camera that can rotate a little (always keeping the area in from if the car in view) that’s attached to a moderately stiff spring that’s attached to the car.
You can change various properties to change how the chase cam looks:
1. the angle of the spring (how high above the car the camera sits)
2. the stiffness of the spring (too stiff looks jerky, too loose looks too floppy)
3. the length of the spring (how far from the car the camera is)
4. the angle, focal point, and rotation speed of the camera (slow camera rotation with floppy spring means you will likely lose vision of the area in front of the car during a sharper turns)
Edit: formatting
Most engines allow you to ‘stick’ the camera to the vehicle, so for a shortcut you can have your camera ready and set up then make it so that it turns with the car. Is this what modern racers use?
Yes and no. What’s more efficient is to do the above but manually through a code you’ve designed which tells the camera if it should just stick to the vehicle for that particular moment or if the distance between say the car and the ‘bounds’ or edges of the allowed peripheral vision or if it should pull up, back and turn a little more than normal until the car is straightened again.
From you here you would be telling multiple different cameras their own specified angles and transformations and when they should be turned on for the player to see. The actual position is half trial and error and half very, very smart coordinate geometry if the studio is top notch.
Latest Answers