# Camera Systems — Mathematics Used

Through this blog I will be talking about the Math I used while making the camera systems and also be explaining why I used those particular values.

MoveToTarget() — This function follows the Target which has been assigned in the inspector. The first thing that I did in this part was calculating the ‘targetPosition’ of the camera.

Formula I used:

In the above code, ‘targetPositionOffset’ is a value that the user can set for the X,Y,Z axis in the inspector. This just adds the current position of the target and moves the camera up through the Y axis and also pushes the camera forward through the Z axis. This is so that the camera height and zoom are set at a certain level such that the entire character is visible.

The next thing I did was add a camera destination based on the rotation settings in the inspector.

Euler Angles are used when one needs to change the orientation of an object. The rotation happens in degrees. The x, y, and z angles represent a rotation z degrees around the z axis, x degrees around the x axis, and y degrees around the y axis (in that order). So we need to adjust the destination in accordance to the forward axis and I also wanted to push the camera away from the player and that’s the reason for me using ‘-Vector3.forward’. The destination also needed to be updated in relation to the targetPosition that we set above and therefore use the above formula to constantly keep updating the destination.

The next step was to check for collision and readjust the destination of there is a wall or any other obstacle in the way and make the camera focus on the player such that there is no occlusion of any sort.

So once again using Euler angles and instead of pulling the camera back, I push the camera into the target so that the target in unobstructed throughout the game.

Next I used the SmoothDamp() for both the destination and the adjusted destination. The SmoothDamp() gradually changes a value towards a desired value over time. So this function used the position of the player, destination/adjusted destination and referenced the camera velocity.

The next code was for the camera to look at the target.

Quaternions are used to represent rotations. Quaternion.LookRotation creates a rotation with the specified forward and upwards directions. Returns the computed quaternion. If used to orient a Transform, the Z axis will be aligned with forward/ and the Y axis with upwards if these vectors are orthogonal. Logs an error if the forward direction is zero.

Quaternion.Lerp interpolates between the rotation of the camera(from) and rotation of the target(to) by time and normalizes the result afterwards. The parameter time is clamped to the range [0, 1].

The next set of code involves the calculations of the orbit rotations for the x and y axis.

This is pretty straight forward. It involved the multiplication of both the vertical and horizontal orbit input which can be changed in the inspector with the orbit smooth versions of both the axis and multiplied by time so that the orbiting is independent of the frame rate.

My major calculations took place when I was calculating the clipping planes for the camera.

The easiest way to explain the clipping planes will be using the below diagram.

The z axis never changes because the clipping requires only horizontal and vertical values. The vertical for avoid looking above the roof when the player jumps and horizontal to avoid seeing through the wall.

These were some of the math I used while developing the camera systems and also I hope I was able to justify the reasons for using them.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.