Camera & Transformations: Camera Implementation

Camera Implementation

Now that we understand the mathematical foundations and transformation matrices, let’s implement a flexible camera system for our Vulkan application. We’ll create a camera class that can be used to navigate our 3D scenes. This implementation is designed for a general-purpose 3D application or game engine, and the concepts can be applied to various types of applications, from first-person games to architectural visualization tools.

Camera Types

There are several types of cameras commonly used in 3D applications:

First-Person Camera: Simulates viewing the world through the eyes of a character.
Third-Person Camera: Follows a character from behind or another fixed relative position.
Orbit Camera: Rotates around a fixed point, useful for object inspection.
Free Camera: Allows unrestricted movement in all directions.

For our implementation, we’ll focus on a versatile camera that can be configured for different use cases.

Camera Class Design

Our camera system is built around a Camera class that manages 3D navigation and view generation. Let’s break down the implementation into logical sections to understand both the technical details and design decisions behind each component.

Camera Architecture: Core Data Members and Spatial Representation

First, we establish the fundamental data structures that represent the camera’s position, orientation, and coordinate system within 3D space.

class Camera {
private:
    // Spatial positioning and orientation vectors
    // These form the camera's local coordinate system in world space
    glm::vec3 position;     // Camera's location in world coordinates
    glm::vec3 front;        // Forward direction (where camera is looking)
    glm::vec3 up;           // Camera's local up direction (for roll control)
    glm::vec3 right;        // Camera's local right direction (perpendicular to front and up)
    glm::vec3 worldUp;      // Global up vector reference (typically Y-axis)

The spatial representation uses a right-handed coordinate system where the camera maintains its own local coordinate frame within the world space. The position vector defines where the camera exists, while front, up, and right vectors form an orthonormal basis that defines the camera’s orientation. This approach provides intuitive control where moving along the front vector moves the camera forward, right moves sideways, and up moves vertically relative to the camera’s current orientation.

The worldUp vector serves as a reference point for maintaining proper orientation, typically pointing along the world’s Y-axis. This reference prevents the camera from becoming disoriented during complex rotations and ensures that operations like "level the horizon" have a consistent reference point.

Camera Architecture: Euler Angle Representation and Control Parameters

Next, we define how rotations are represented and controlled, using Euler angles for intuitive user input while managing the mathematical complexities internally.

    // Rotation representation using Euler angles
    // Provides intuitive control while managing gimbal lock and other rotation complexities
    float yaw;              // Horizontal rotation around the world up-axis (left-right looking)
    float pitch;            // Vertical rotation around the camera's right axis (up-down looking)

    // User interaction and behavior parameters
    // These control how the camera responds to input and environmental factors
    float movementSpeed;    // Units per second for translation movement
    float mouseSensitivity; // Multiplier for mouse input to rotation angle conversion
    float zoom;             // Field of view control for perspective projection

Euler angles provide an intuitive interface for camera rotation that maps naturally to user input devices. Yaw controls horizontal rotation (looking left-right), while pitch controls vertical rotation (looking up-down). We deliberately avoid roll for most applications as it can be disorienting for users, though the system could be extended to support it.

The parameter system allows fine-tuning of camera behavior for different use cases. Movement speed can be adjusted for different scene scales, mouse sensitivity can accommodate user preferences and different input devices, and zoom provides dynamic field-of-view control for gameplay or cinematic effects.

Camera Architecture: Internal Methods and State Management

Next, we define the internal methods responsible for maintaining mathematical consistency and updating the camera’s coordinate system when rotations change.

    // Internal coordinate system maintenance
    // Ensures mathematical consistency when orientation changes occur
    void updateCameraVectors();

public:

The updateCameraVectors method serves as the mathematical foundation of the camera system, recalculating the front, right, and up vectors whenever the Euler angles change. This process involves trigonometric calculations that convert the intuitive Euler angle representation into the orthonormal vector basis required for matrix operations and movement calculations.

This approach separates the user-friendly angle interface from the computationally efficient vector operations, allowing the camera to present simple controls while maintaining the mathematical rigor required for accurate 3D transformations.

Camera Architecture: Public Interface and Constructor Design

Next, we establish the public interface that external code uses to create, configure, and interact with camera instances.

    // Constructor with sensible defaults for common use cases
    // Provides flexibility while ensuring the camera starts in a predictable state
    Camera(
        glm::vec3 position = glm::vec3(0.0f, 0.0f, 0.0f),  // Start at world origin
        glm::vec3 up = glm::vec3(0.0f, 1.0f, 0.0f),        // Y-axis as world up
        float yaw = -90.0f,                                 // Look along negative Z-axis (OpenGL convention)
        float pitch = 0.0f                                  // Level horizon
    );

The constructor design reflects common 3D graphics conventions and practical defaults. The default position at the origin provides a predictable starting point, while the Y-axis world up aligns with the standard mathematical coordinate system. The initial yaw of -90° follows OpenGL conventions where the default view looks down the negative Z-axis, creating a right-handed coordinate system that feels natural to users.

The parameter defaults eliminate the need for complex initialization in simple use cases while still allowing full customization when needed for specialized applications.

Camera Architecture: Matrix Generation and Geometric Transformation Interface

Now we define the core mathematical interface that transforms the camera’s spatial representation into the matrices required by graphics pipelines.

    // Matrix generation for graphics pipeline integration
    // These methods bridge between the camera's spatial representation and GPU requirements
    glm::mat4 getViewMatrix() const;
    glm::mat4 getProjectionMatrix(float aspectRatio, float nearPlane = 0.1f, float farPlane = 100.0f) const;

The matrix generation methods serve as the critical bridge between our intuitive camera representation and the mathematical requirements of 3D graphics pipelines. The view matrix transforms world coordinates into camera space, effectively positioning the world relative to the camera’s viewpoint. The projection matrix then transforms camera space into clip space, handling perspective effects and preparing coordinates for rasterization.

The separation of view and projection matrices follows standard graphics pipeline architecture, allowing independent control over camera positioning and perspective characteristics. This design enables techniques like changing field-of-view for zoom effects without recalculating the camera’s spatial relationships.

Camera Architecture: Input Processing and User Interaction

Finally, let’s define how the camera responds to various forms of user input, providing the interface between human interaction and camera movement.

    // Input processing methods for different interaction modalities
    // Each method handles a specific type of user input with appropriate transformations
    void processKeyboard(CameraMovement direction, float deltaTime);     // Keyboard-based translation
    void processMouseMovement(float xOffset, float yOffset, bool constrainPitch = true);  // Mouse-based rotation
    void processMouseScroll(float yOffset);                              // Scroll-based zoom control

    // Property access methods for external systems
    // Provide controlled access to internal state without exposing implementation details
    glm::vec3 getPosition() const { return position; }
    glm::vec3 getFront() const { return front; }
    float getZoom() const { return zoom; }
};

The input processing architecture recognizes that different input modalities serve different purposes in camera control. Keyboard input typically handles discrete directional movement, mouse movement provides continuous rotation control, and scroll wheels offer intuitive zoom adjustment. Each method is designed to handle its specific input type with appropriate mathematical transformations and timing considerations.

The getter methods provide controlled access to internal state, allowing external systems (like audio systems that need listener position, or culling systems that need view direction) to access camera properties without exposing the internal implementation details or allowing uncontrolled modification of the camera’s state.

Camera Movement

We’ll define an enum for camera movement directions:

enum class CameraMovement {
    FORWARD,
    BACKWARD,
    LEFT,
    RIGHT,
    UP,
    DOWN
};

And implement the movement logic:

void Camera::processKeyboard(CameraMovement direction, float deltaTime) {
    float velocity = movementSpeed * deltaTime;

    switch (direction) {
        case CameraMovement::FORWARD:
            position += front * velocity;
            break;
        case CameraMovement::BACKWARD:
            position -= front * velocity;
            break;
        case CameraMovement::LEFT:
            position -= right * velocity;
            break;
        case CameraMovement::RIGHT:
            position += right * velocity;
            break;
        case CameraMovement::UP:
            position += up * velocity;
            break;
        case CameraMovement::DOWN:
            position -= up * velocity;
            break;
    }
}

Handling Input Events

The camera class provides methods to process input, but integrating these with your application’s input system requires careful consideration of different input modalities and their unique characteristics. Let’s break down the input handling implementation to demonstrate both the technical integration and the design principles behind effective camera controls.

Input Integration: Keyboard Input Processing and Movement Translation

First, we handle discrete directional input from keyboards, translating key presses into camera movement commands with proper frame-rate independence.

// Keyboard input processing for camera translation
// Handles discrete directional commands with frame-rate independent timing
void processInput(GLFWwindow* window, Camera& camera, float deltaTime) {
    // WASD movement scheme following standard FPS conventions
    // Each key press translates to a specific directional movement relative to camera orientation
    if (glfwGetKey(window, GLFW_KEY_W) == GLFW_PRESS)
        camera.processKeyboard(CameraMovement::FORWARD, deltaTime);    // Move forward along camera's front vector
    if (glfwGetKey(window, GLFW_KEY_S) == GLFW_PRESS)
        camera.processKeyboard(CameraMovement::BACKWARD, deltaTime);   // Move backward opposite to front vector
    if (glfwGetKey(window, GLFW_KEY_A) == GLFW_PRESS)
        camera.processKeyboard(CameraMovement::LEFT, deltaTime);       // Strafe left along camera's right vector
    if (glfwGetKey(window, GLFW_KEY_D) == GLFW_PRESS)
        camera.processKeyboard(CameraMovement::RIGHT, deltaTime);      // Strafe right along camera's right vector

    // Vertical movement controls for 3D navigation
    // Space and Control provide intuitive up/down movement
    if (glfwGetKey(window, GLFW_KEY_SPACE) == GLFW_PRESS)
        camera.processKeyboard(CameraMovement::UP, deltaTime);         // Move up along camera's up vector
    if (glfwGetKey(window, GLFW_KEY_LEFT_CONTROL) == GLFW_PRESS)
        camera.processKeyboard(CameraMovement::DOWN, deltaTime);       // Move down opposite to up vector
}

The keyboard input processing follows established conventions from first-person games, where WASD keys control horizontal movement and Space/Control handle vertical movement. This mapping feels intuitive to users and provides complete 6-degrees-of-freedom movement control. The frame-rate independence achieved through deltaTime ensures consistent movement speed regardless of rendering performance, which is crucial for predictable user experience across different hardware configurations.

Each movement command uses the camera’s local coordinate system rather than world coordinates. Meaning "forward" always moves in the direction the camera is facing, "right" moves perpendicular to the view direction, and "up" moves along the camera’s local vertical axis. This approach provides intuitive controls that respond naturally to camera orientation changes.

Input Integration: Mouse Movement Processing and Rotation State Management

Now, let’s handle continuous mouse input for camera rotation, managing state persistence and coordinate system conversions for smooth camera control.

// Mouse movement callback for continuous camera rotation
// Manages state persistence and coordinate transformations for smooth rotation control
void mouseCallback(GLFWwindow* window, double xpos, double ypos) {
    // State persistence for calculating movement deltas
    // Static variables maintain state between callback invocations
    static bool firstMouse = true;          // Flag to handle initial mouse position
    static float lastX = 0.0f, lastY = 0.0f;  // Previous mouse position for delta calculation

    // Handle initial mouse position to prevent sudden camera jumps
    // First callback provides absolute position, not relative movement
    if (firstMouse) {
        lastX = xpos;               // Initialize previous position
        lastY = ypos;
        firstMouse = false;         // Disable special handling for subsequent calls
    }

    // Calculate mouse movement deltas since last callback
    // These deltas represent the amount and direction of mouse movement
    float xoffset = xpos - lastX;                   // Horizontal movement (left-right)
    float yoffset = lastY - ypos;                   // Vertical movement (inverted: screen Y increases downward, camera pitch increases upward)

    // Update state for next callback iteration
    lastX = xpos;
    lastY = ypos;

    // Convert mouse movement to camera rotation
    // Delta values drive continuous camera orientation changes
    camera.processMouseMovement(xoffset, yoffset);
}

The mouse callback demonstrates the complexities of handling continuous input in event-driven systems. The static variables maintain state between callback invocations, which is necessary because mouse movement is reported as absolute positions rather than relative deltas. The first-mouse handling prevents jarring camera jumps when the mouse cursor is first captured.

The Y-axis inversion (lastY - ypos) addresses the coordinate system mismatch between screen space (where Y increases downward) and camera space (where positive pitch looks upward). This inversion ensures that moving the mouse upward rotates the camera to look up, matching user expectations from other 3D applications.

Input Integration: Scroll Input Processing and Zoom Control

Next, let’s work on the scroll-wheel input to give us zoom control, providing a simple interface for field-of-view adjustments that feel natural to users.

// Scroll wheel callback for zoom control
// Provides intuitive field-of-view adjustment through scroll wheel interaction
void scrollCallback(GLFWwindow* window, double xoffset, double yoffset) {
    // Direct scroll-to-zoom mapping
    // Positive yoffset (scroll up) typically zooms in, negative (scroll down) zooms out
    camera.processMouseScroll(yoffset);
}

The scroll callback maintains simplicity by directly passing the scroll delta to the camera’s zoom processing method. This design delegates the mathematical details of zoom control to the camera class while providing a clean interface for scroll wheel events. The scroll direction convention (positive for zoom in, negative for zoom out) follows standard user interface patterns.

Input Integration: System Integration and Input Mode Configuration

Finally, we establish the integration between the input callbacks and the windowing system, configuring mouse capture and callback registration for complete camera control.

// Input system initialization and callback registration
// Establishes the connection between windowing system and camera control callbacks
void setupInputCallbacks(GLFWwindow* window) {
    // Register callback functions with the windowing system
    // These establish the event-driven connection between hardware input and camera control
    glfwSetCursorPosCallback(window, mouseCallback);        // Connect mouse movement to camera rotation
    glfwSetScrollCallback(window, scrollCallback);          // Connect scroll wheel to camera zoom

    // Configure mouse capture mode for first-person camera behavior
    // Disabling the cursor provides continuous mouse input without cursor interference
    glfwSetInputMode(window, GLFW_CURSOR, GLFW_CURSOR_DISABLED);
}

The system integration demonstrates how camera controls integrate with the broader application architecture. The callback registration creates the event-driven connection between hardware input and camera responses, while the cursor disabling provides the seamless mouse control expected in 3D applications.

The GLFW_CURSOR_DISABLED mode captures the mouse cursor, allowing unlimited mouse movement without the cursor hitting screen boundaries. This configuration is essential for first-person camera controls where users expect to be able to turn the camera continuously in any direction without cursor limitations.

Note

The specific implementation of input handling will depend on your windowing library and application architecture. The example above uses GLFW, but similar principles apply to other libraries like SDL, Qt, or platform-specific APIs. For more details on input handling with GLFW, refer to the GLFW Input Guide.

Camera Rotation

For camera rotation, we’ll use mouse input to adjust the yaw and pitch angles:

void Camera::processMouseMovement(float xOffset, float yOffset, bool constrainPitch) {
    xOffset *= mouseSensitivity;
    yOffset *= mouseSensitivity;

    yaw += xOffset;
    pitch += yOffset;

    // Constrain pitch to avoid flipping
    if (constrainPitch) {
        pitch = std::clamp(pitch, -89.0f, 89.0f);
    }

    // Update camera vectors based on updated Euler angles
    updateCameraVectors();
}

Updating Camera Vectors

After changing the camera’s orientation, we need to recalculate the front, right, and up vectors:

void Camera::updateCameraVectors() {
    // Calculate the new front vector
    glm::vec3 newFront;
    newFront.x = cos(glm::radians(yaw)) * cos(glm::radians(pitch));
    newFront.y = sin(glm::radians(pitch));
    newFront.z = sin(glm::radians(yaw)) * cos(glm::radians(pitch));
    front = glm::normalize(newFront);

    // Recalculate the right and up vectors
    right = glm::normalize(glm::cross(front, worldUp));
    up = glm::normalize(glm::cross(right, front));
}

View Matrix

The view matrix transforms world coordinates into view coordinates (camera space):

glm::mat4 Camera::getViewMatrix() const {
    return glm::lookAt(position, position + front, up);
}

Projection Matrix

The projection matrix transforms view coordinates into clip coordinates:

glm::mat4 Camera::getProjectionMatrix(float aspectRatio, float nearPlane, float farPlane) const {
    return glm::perspective(glm::radians(zoom), aspectRatio, nearPlane, farPlane);
}

Advanced Topics: Third-Person Camera Implementation

In this section, we’ll explore advanced techniques for implementing a third-person camera that follows a character while avoiding occlusion and maintaining focus on the character.

Third-Person Camera Design

A third-person camera typically needs to:

Follow the character at a specified distance
Maintain a consistent view of the character
Avoid being occluded by objects in the environment
Provide smooth transitions during movement and rotation

Let’s extend our camera class to support these features by building a specialized ThirdPersonCamera that addresses the unique challenges of the character-following camera systems.

Third-Person Camera Architecture: Target Tracking and Spatial Relationship Management

What good is a camera if we can’t use it to target looking at things? Maybe we also want characters to look at each other or to have them look at the camera. Let’s start work on this by figuring out how a 'lookat' system would work and how a camera would track a target.

The getter methods provide controlled access to internal state, allowing external systems (like audio systems that need listener position, or culling systems that need a view direction) to query the camera without tightly coupling to the implementation. This keeps the camera easy to maintain and extend as features are added.

Look-At Basics: Pointing the Camera at Something

Before we automate camera behaviors, let’s build an intuition for “look-at.” The idea is simple: given we know where the camera is: "the eye," we also know what point it should face: "the target," and we also know which way is "up." We want to use that information to construct an orientation that makes the camera face the target while keeping the horizon stable.

Think of it like lining up a real camera:

Eye: “Where am I standing?”
Target: “What am I framing in the center of the viewfinder?”
Up: “Which direction should the top of the frame point (so the picture isn’t tilted)?”

Thus, when we get to the output of "look at," we will have a view orientation. We usually for convenience will use an affine matrix, but it is only an orientation. After all, rotating to "look at" something shouldn’t involve translating to a new position; so the eye will maintain the position throughout our look-at code.

Key takeaways:

“Look-at” defines an orientation, not a position. The position comes from the eye; look-at figures out the directions (forward/right/up) from eye→target and the chosen up.
The up direction should not be parallel to the eye→target direction. If they’re nearly aligned, the camera won’t know how to keep the horizon level (it can “roll unpredictably.”)
You can use look-at for both cameras and objects. Characters can face each other, or you can point a spotlight or turret at a target with the same concept.

In the next section, we’ll take this one-off “point at a target” idea and turn it into a behavior: smooth, continuous camera target tracking that follows moving subjects without jitter or sudden snaps.

Implementation for camera target relationship

First, establish the fundamental relationship between the camera and its target, managing the spatial tracking information that drives all third-person camera behaviors.

class ThirdPersonCamera : public Camera {
private:
    // Target entity tracking and spatial relationship data
    // These properties define the relationship between camera and the character being followed
    glm::vec3 targetPosition;      // Current world position of the target character
    glm::vec3 targetForward;       // Target's forward direction vector for contextual camera positioning

The target tracking system forms the foundation of third-person camera behavior by maintaining a continuous connection between the camera and the character being followed. The targetPosition provides the spatial anchor that the camera revolves around, while targetForward enables context-aware camera positioning that can anticipate where the character is moving or looking.

This approach allows the camera to make intelligent positioning decisions based on the character’s state and orientation, creating more dynamic and responsive camera behavior than simple fixed-offset following.

Third-Person Camera Architecture: Behavioral Configuration and Control Parameters

Now let’s work on the parameters that control how the camera behaves in relation to its target, providing artistic and gameplay control over the camera’s characteristics.

    // Camera behavior configuration parameters
    // These values control the aesthetic and functional characteristics of camera following
    float followDistance;          // Desired distance from target (affects intimacy and field of view)
    float followHeight;            // Height offset above target (provides better scene visibility)
    float followSmoothness;        // Interpolation factor for smooth camera transitions (0 = instant, 1 = never)

The behavioral parameters provide artistic control over the camera’s personality and functional characteristics. Follow distance affects both the visual intimacy with the character and the amount of surrounding environment visible in the frame. Height offset ensures the camera provides good visibility of both the character and the surrounding terrain or obstacles.

The smoothness parameter controls the camera’s responsiveness to target movement, allowing designers to balance between immediate response, (which can feel jerky,) and smooth motion (which can feel laggy). This parameter is crucial for creating camera behavior that feels natural and responsive to different gameplay situations.

Third-Person Camera Architecture: Collision Detection and Occlusion Management

Now, we have a camera system that will work in basic situations. However, let’s briefly talk about the complex problem of environmental occlusion, ensuring the camera maintains visibility of the target even when obstacles interfere with the desired positioning.

    // Occlusion avoidance and collision management
    // These parameters control how the camera responds to environmental obstacles
    float minDistance;             // Minimum allowed distance from target (prevents camera from getting too close)
    float raycastDistance;         // Maximum distance for occlusion detection rays

The occlusion management system addresses one of the most challenging aspects of third-person camera implementation: maintaining visibility when environmental geometry interferes with the desired camera position. The minimum distance prevents the camera from getting uncomfortably close to the character during collision situations, while the raycast distance defines how far the camera looks ahead for potential occlusion issues.

This system enables the camera to proactively respond to environmental constraints, smoothly adjusting its position to maintain optimal visibility without jarring transitions or sudden position changes that can be disorienting to players.

Third-Person Camera Architecture: Internal State Management and Motion Control

To get smooth camera motion, we need to be able to understand the FSM (Finite State Machine) design of the Camera architecture. We manage the internal computational state required for intelligent positioning decisions and to help solve smooth camera motion.

    // Internal computational state for smooth motion control
    // These variables manage the mathematical aspects of camera positioning and movement
    glm::vec3 desiredPosition;     // Target position the camera wants to reach (before collision adjustments)
    glm::vec3 smoothDampVelocity;  // Velocity state for smooth damping interpolation algorithms

public:

The internal state management separates the desired camera behavior from the actual camera position, allowing the system to handle complex scenarios where multiple forces influence camera positioning. The desired position represents where the camera would ideally be placed based on the follow parameters, while the smooth damp velocity enables sophisticated interpolation algorithms that create natural, physics-inspired camera motion.

This separation of concerns allows the camera system to handle conflicts between desired positioning and environmental constraints gracefully, maintaining smooth motion even when the camera must deviate significantly from its preferred location.

Third-Person Camera Architecture: Public Interface and Configuration Control

Now, let’s examine the external interface that allows game code to interact with and configure the third-person camera system in a manner that can avoid tight coupling and can keep the camera as its' own module.

    // Constructor with gameplay-tuned defaults
    // Default values chosen for common third-person game scenarios
    ThirdPersonCamera(
        float followDistance = 5.0f,        // Medium distance providing good character visibility and environment context
        float followHeight = 2.0f,          // Height above target for clear sightlines over low obstacles
        float followSmoothness = 0.1f,      // Moderate smoothing for responsive but stable camera motion
        float minDistance = 1.0f            // Minimum distance to prevent uncomfortable close-ups
    );

    // Core functionality methods for camera behavior control
    void updatePosition(const glm::vec3& targetPos, const glm::vec3& targetFwd, float deltaTime);
    void handleOcclusion(const Scene& scene);
    void orbit(float horizontalAngle, float verticalAngle);

    // Runtime configuration methods for dynamic camera adjustment
    void setFollowDistance(float distance) { followDistance = distance; }
    void setFollowHeight(float height) { followHeight = height; }
    void setFollowSmoothness(float smoothness) { followSmoothness = smoothness; }
};

The public interface design balances ease of use with powerful functionality, providing sensible defaults that work well for common third-person scenarios while allowing full customization when needed. The default values are chosen based on common third-person game requirements: medium distance for good character visibility, moderate height for environmental awareness, and balanced smoothing for responsive yet stable motion.

The method organization separates the core update functionality (which typically runs every frame) from configuration methods (which are called less frequently) and specialized behaviors like orbiting (which might be triggered by specific user input). This design makes it easy to integrate the camera into different game loop architectures while maintaining a clear separation of concerns.

Character Following Algorithm

The core of a third-person camera is the algorithm that positions the camera relative to the character. Here’s an implementation of the updatePosition method:

void ThirdPersonCamera::updatePosition(
    const glm::vec3& targetPos,
    const glm::vec3& targetFwd,
    float deltaTime
) {
    // Update target properties
    targetPosition = targetPos;
    targetForward = glm::normalize(targetFwd);

    // Calculate the desired camera position
    // Position the camera behind and above the character
    glm::vec3 offset = -targetForward * followDistance;
    offset.y = followHeight;

    desiredPosition = targetPosition + offset;

    // Smooth camera movement using exponential smoothing
    position = glm::mix(position, desiredPosition, 1.0f - pow(followSmoothness, deltaTime * 60.0f));

    // Update the camera to look at the target
    front = glm::normalize(targetPosition - position);

    // Recalculate right and up vectors
    right = glm::normalize(glm::cross(front, worldUp));
    up = glm::normalize(glm::cross(right, front));
}

This implementation:

Positions the camera behind the character based on the character’s forward direction
Adds height to give a better view of the character and surroundings
Uses exponential smoothing to create natural camera movement
Always keeps the camera focused on the character

Occlusion Avoidance

One of the most challenging aspects of a third-person camera is handling occlusion - when objects in the environment block the view of the character. Here’s an implementation of occlusion avoidance:

void ThirdPersonCamera::handleOcclusion(const Scene& scene) {
    // Cast a ray from the target to the desired camera position
    Ray ray;
    ray.origin = targetPosition;
    ray.direction = glm::normalize(desiredPosition - targetPosition);

    // Check for intersections with scene objects
    RaycastHit hit;
    if (scene.raycast(ray, hit, glm::length(desiredPosition - targetPosition))) {
        // If there's an intersection, move the camera to the hit point
        // minus a small offset to avoid clipping
        float offsetDistance = 0.2f;
        position = hit.point - (ray.direction * offsetDistance);

        // Ensure we don't get too close to the target
        float currentDistance = glm::length(position - targetPosition);
        if (currentDistance < minDistance) {
            position = targetPosition + ray.direction * minDistance;
        }

        // Update the camera to look at the target
        front = glm::normalize(targetPosition - position);
        right = glm::normalize(glm::cross(front, worldUp));
        up = glm::normalize(glm::cross(right, front));
    }
}

This implementation:

Casts a ray from the character to the desired camera position
If the ray hits an object, moves the camera to the hit point (with a small offset)
Ensures the camera doesn’t get too close to the character
Updates the camera orientation to maintain focus on the character

Performance Considerations for Occlusion Avoidance

When implementing occlusion avoidance, be mindful of performance:

Use simplified collision geometry: For raycasting, use simpler collision shapes than your rendering geometry
Limit the frequency of occlusion checks: You may not need to check every frame on slower devices
Consider spatial partitioning: Use structures like octrees to accelerate raycasts by quickly eliminating objects that can’t possibly intersect with the ray
Optimize for mobile platforms: For performance-constrained devices, consider simplifying the occlusion algorithm or reducing its precision

Implementing Orbit Controls

Many third-person games allow the player to orbit the camera around the character. Here’s how to implement this functionality:

void ThirdPersonCamera::orbit(float horizontalAngle, float verticalAngle) {
    // Update yaw and pitch based on input
    yaw += horizontalAngle;
    pitch += verticalAngle;

    // Constrain pitch to avoid flipping
    pitch = std::clamp(pitch, -89.0f, 89.0f);

    // Calculate the new camera position based on spherical coordinates
    float radius = followDistance;
    float yawRad = glm::radians(yaw);
    float pitchRad = glm::radians(pitch);

    // Convert spherical coordinates to Cartesian
    glm::vec3 offset;
    offset.x = radius * cos(yawRad) * cos(pitchRad);
    offset.y = radius * sin(pitchRad);
    offset.z = radius * sin(yawRad) * cos(pitchRad);

    // Set the desired position
    desiredPosition = targetPosition + offset;

    // Update camera vectors
    front = glm::normalize(targetPosition - desiredPosition);
    right = glm::normalize(glm::cross(front, worldUp));
    up = glm::normalize(glm::cross(right, front));
}

This implementation:

Updates the camera’s yaw and pitch based on user input
Constrains the pitch to prevent the camera from flipping
Calculates a new camera position using spherical coordinates
Keeps the camera focused on the character

Integrating with Character Movement

To create a complete third-person camera system, we need to integrate it with character movement. Here’s an example of how to use the third-person camera in a game loop:

void gameLoop(float deltaTime) {
    // Update character position and orientation based on input
    character.update(deltaTime);

    // Update camera position to follow the character
    thirdPersonCamera.updatePosition(
        character.getPosition(),
        character.getForward(),
        deltaTime
    );

    // Handle camera occlusion
    thirdPersonCamera.handleOcclusion(scene);

    // Process camera orbit input (if any)
    if (mouseInputDetected) {
        thirdPersonCamera.orbit(mouseDeltaX, mouseDeltaY);
    }

    // Get the view and projection matrices for rendering
    glm::mat4 viewMatrix = thirdPersonCamera.getViewMatrix();
    glm::mat4 projMatrix = thirdPersonCamera.getProjectionMatrix(aspectRatio);

    // Use these matrices for rendering the scene
    renderer.render(scene, viewMatrix, projMatrix);
}

Note	For more advanced camera techniques, refer to the Advanced Camera Techniques section in the Appendix.

In the next section, we’ll integrate our camera system with Vulkan to render 3D scenes.

Previous: Transformation Matrices | Next: Vulkan Integration