--- title: "[CryEngine] Eye of the Engine: The Camera" description: Unpacking CryEngine's camera system, from raw input signals to the rendered image. author: Aleks (Quang Trinh Khac, online as tkhquang) published: 2020-10-10 category: Technical tags: - CryEngine - Modding - Camera - Reverse Engineering - Game Development - C++ cover: https://tkhquang.dev/uploads/images/CryEngine.jpg canonical: https://tkhquang.dev/blog/posts/cryengine-eye-of-the-engine-the-camera --- # [CryEngine] Eye of the Engine: The Camera I generate this file from the same source as the page at , so it carries the prose, the code, the tables, and the diagrams as Mermaid source. What has to run in a browser is named where it stands, with the page's address beside it. Cite the canonical URL with the title and the dates above; the rest of the citation guidance is in . --- If you're anything like me, you've probably spent countless hours playing games built on impressive engines like CryEngine and eventually found yourself wondering, "Just how does this all *work* under the hood?" After getting my hands dirty with player movement in a few projects, my curiosity naturally drifted to the camera – that invisible eye through which we experience these digital worlds. This is the story of my dive into CryEngine's camera system, a journey that started with some straightforward ideas and ended up revealing a fascinatingly complex (and sometimes sneaky) piece of engineering. ## First Look: The `CCameraManager` When you start poking around an engine, you often look for "manager" classes, as they usually orchestrate big parts of the system. Sure enough, CryEngine has a `CCameraManager`. When the game fires up, this manager gets created. I dug into its setup code (what we call the constructor) to see what it does: ```cpp title="A peek at what CCameraManager prepares when it's born" showLineNumbers CCameraManager::CCameraManager() { // Seems like a way for special camera events to take over m_pCamOverrides = new CCameraOverrides(); // This looks like the main "eye" or camera itself m_pCameraView = new CCameraView(NULL); // A place to store different camera setups or "styles" m_camNodes.reserve(32); // Adds a default, basic camera AddNullCam(); // ... and it sets up tracking for active and previous cameras ... } ``` So, `CCameraManager` seems equipped to handle `CCameraOverrides` (think dramatic cinematic sweeps or a game taking control to show you something important), it has a primary `CCameraView` object (which likely holds the actual camera properties like position and angle), and it can manage a list of `m_camNodes`, which are probably different pre-set camera behaviors. So I thought, "This must be the central controller!" But, as any good developer knows, assumptions are made to be broken. I set up some digital tripwires (breakpoints) to see when `CCameraManager`'s main `Update` function was being called during normal gameplay. The result? Mostly silence. It wasn't doing much frame-to-frame when I was just running around. It turns out `CCameraManager` has a more specialized role. It's crucial for **in-game movies and scripted sequences** (the kind you might make with CryEngine's TrackView tool). During those, it's busy managing Field of View (FoV), camera shakes, and smoothly switching between different camera views. It also gets involved if you use certain console commands like `cl_cam_orbit 1` in third-person mode. But for our everyday, moment-to-moment view? The main action was happening elsewhere. ## Tracing Camera Movements: From Mouse to Screen If `CCameraManager` wasn't the daily driver, my next thought was to trace the process from the very beginning: when I move my mouse. 1. **Input Detected:** Your mouse movement is picked up by the `CPlayerInput` system. This triggers internal game "actions," like "I want to look left/right" (`OnActionRotateYaw`) or "I want to look up/down" (`OnActionRotatePitch`). 2. **Rotation Processing:** This "intent to look" is then handled by a class often called `CPlayerRotation` (or something similar depending on the game's specifics). This class takes the raw mouse input and: * Applies things like sensitivity and smoothing. * Crucially, it limits how far you can look up or down, so you can't stare directly at your feet or do an owl-like head spin. * Then, it updates the player's orientation. This is where CryEngine (and many engines) does something quite smart. It often uses *two* primary ways to store orientation (using mathematical things called "quaternions," which are great for 3D rotations): * `m_BaseQuat`: This usually defines the direction the player character's *body* is facing. For a first-person shooter, this is mostly about turning left and right (yaw). The body itself tends to stay upright. * `m_ViewQuat`: This is the actual direction the *camera* is looking, taking into account both up/down (pitch) and left/right (yaw) movements from the mouse. *Having separate "direction-keepers" for the body and the camera is key! It lets your character model aim its body generally, while your view (the camera) can look around more freely and precisely. This makes character movement and aiming feel much more natural and responsive.* ```mermaid --- title: Orientation Quaternions --- graph TD UserInput["User Input
e.g., Mouse Delta"] --> BodyOrientation; UserInput --> ViewOrientation; subgraph "Entity/Body Orientation" BodyOrientation["m_BaseQuat
(Yaw Only)"]; BodyIcon([Character Body]); BodyOrientation -- "Defines" --> BodyIcon; end subgraph "Camera/View Orientation" ViewOrientation["m_ViewQuat
(Pitch & Yaw)"]; ViewIcon([Camera View]); ViewOrientation -- "Defines" --> ViewIcon; end %% Styling classDef default fill:#282a36,stroke:#f8f8f2,stroke-width:2px,color:#f8f8f2; class UserInput,BodyOrientation,ViewOrientation,BodyIcon,ViewIcon default; ``` This separation is a big deal for developers and modders because it allows for more realistic character animations (like the head aiming where you're looking) and more sophisticated control schemes. ## The Central Hub: `CPlayer::UpdateView` So where do these `m_BaseQuat` and `m_ViewQuat` values actually get used to position the camera? A lot of this comes together in a central function within the player's code, often something like `CPlayer::UpdateView`. This function seems to be the main conductor for the camera during normal gameplay. Here's a simplified idea of its logic: ```cpp title="Decide what camera logic to use" showLineNumbers void CPlayer::UpdateView(SViewParams& viewParams) { if (/* game is in a special camera mode, like the orbital camera */) { // Then CCameraManager might take control and update things. } else { // For normal gameplay, a dedicated "view" class often does the work. // Give it player info CPlayerView currentViewHandler(*this, viewParams); // It calculates the camera's new position, angle, etc. currentViewHandler.Process(viewParams); // It applies these changes. currentViewHandler.Commit(*this, viewParams); // And sometimes, the character's animations can also nudge the camera a bit if (m_pAnimatedCharacter) { m_pAnimatedCharacter->FilterView(viewParams); } } // At the end, 'viewParams' should hold all the fresh camera info. } ``` When it's not a special `CCameraManager` moment, a class like `CPlayerView` is often the real workhorse. This class typically knows how to handle specific camera types: 1. **It Prepares (`ViewPreProcess`):** Gathers all the data it needs: player's current position, stance (standing, crouching), etc. 2. **It Calculates (`ViewProcess`):** * **First-Person View:** Figures out where the camera "eye" should be based on the character model, applies the `m_ViewQuat` for looking around, and adds effects like "head bob" (the slight up-and-down camera movement when walking) to make it feel more immersive. It also ensures your weapon model is drawn correctly. * **Third-Person View:** Calculates the camera's position behind or around the player, often dealing with tricky things like making sure the camera doesn't clip through walls. 3. **It Finishes (`ViewPostProcess`):** Applies any final touches like camera shake from explosions. 4. **It Applies (`Commit`):** Saves the new camera settings (position, rotation, FoV) into a structure often called `SViewParams`. The animation system can also tweak the final view slightly via calls like `m_pAnimatedCharacter->FilterView(viewParams)`. This allows animations to subtly influence the camera for things like weapon sway or breathing effects, further grounding the camera in the game world. This often links into CryAction, CryEngine's gameplay layer. ## Modding Insights: Playing with the Camera Memory Now, this is where my investigation took an interesting turn. I started looking at how some popular *external* camera modding tools (like those that give you a "free camera" to fly around for screenshots) actually work. These tools can control the camera *without* changing the game's C++ source code. How? It turns out, these tools confirm a key idea: even though many different parts of the code might *calculate* camera information, the game must eventually store the **final, definitive camera state** (position, rotation, FoV) in a specific place in the computer's memory *before* it draws the picture. This "final answer" location is what those mod tools target. Here's the clever trick they often use: 1. **Find the "Master Copy":** Through some serious digital detective work (reverse engineering), modders identify the exact memory addresses where the game stores its current camera X, Y, Z position, its look direction (quaternion), and its Field of View. Think of our `SViewParams` struct – these tools find where *that data* physically lives in memory. 2. **Overwrite the Data:** When the mod tool wants to set its own camera view, it simply writes its calculated position and rotation values directly into those memory locations, replacing whatever the game originally put there! 3. **Tell the Game to Shush (Sometimes):** For even more control, some advanced tools use a tiny piece of very low-level code (assembly language) to intercept the game's own camera update functions. They essentially tell the game, "Hold on, don't write your camera data right now; I'm handling it!" This prevents the game from immediately overwriting the mod's changes. Looking at the code for one such tool (IGCS, adapted for a CryEngine-based game like Kingdom Come: Deliverance), I saw this in action. It had specific memory "offsets" (like coordinates on a map) pointing to exactly where the X coordinate, Y coordinate, Z coordinate, each part of the rotation quaternion, and the FoV were stored for the game's main camera. This discovery was a big "aha!" moment. It means that our `SViewParams` (or whatever the game calls its final camera state structure) isn't just an abstract idea; it has a concrete representation in memory that these tools can find and manipulate. ## Final Output: The View Matrix So, whether it's the game's internal systems (`CPlayerView`, animations, etc.) or an external mod tool overwriting memory, all this work leads to one critical piece of data: the **view matrix**. *(Important Note: CryEngine generally uses a Right-Handed Coordinate System for its 3D math: X points to the Right, Y points Forward (into the scene, away from you), and Z points Up. This is handy to know if you're doing any 3D graphics work yourself, as it's similar to tools like 3ds Max).* ```mermaid graph TD; subgraph "The View Matrix" A["Camera Position (Vec3)"] --> C["View Matrix Construction Logic
(Math combining position & rotation)"]; B["Camera Rotation (Quat)"] --> C; C --> D["View Matrix (Matrix34)
The final set of numbers for the view
[ r.x r.y r.z tx ]
[ u.x u.y u.z ty ]
[ f.x f.y f.z tz ]"]; D --> E["Sent to the Renderer
(The part of the engine
that draws everything)"]; end %% Styling classDef default fill:#282a36,stroke:#f8f8f2,stroke-width:2px,color:#f8f8f2,font-family:monospace; class A,B,C,D,E default; ``` This view matrix is what the rendering part of the engine (the part that draws all the pretty graphics) uses to figure out how to transform all the 3D objects in the world so they look correct from the camera's current viewpoint. If a mod tool has successfully written its own data into the game's camera memory locations, then this view matrix will be built based on the mod's camera, not the game's original one! ## Modder's Toolbox: Useful CVars No matter how you're exploring, these console commands are always useful: * `cl_fov `: Change your Field of View. * `cl_tpvDist `, `cl_tpvYaw `: Often used for tweaking third-person camera distances and angles. * `g_cameraFree <0/1/2>`: A godsend for freely flying the camera around to explore or set up screenshots. `g_cameraFreeMoveSpeed` often accompanies it. * `r_DisplayInfo <0/1>`: Toggles on-screen debug information, which can include current camera coordinates. * `r_DebugCamera <1>` (or similar names): Some games have CVars that draw helpful visual guides for the camera, like its frustum (its cone of vision). And, of course, using a debugger to set breakpoints in functions like `CPlayer::UpdateView` or the methods of `CPlayerView` is incredibly valuable when you have the source code or symbols. ## What All This Means for Us Developers and Modders This whole journey, from poking at `CCameraManager` to seeing how external tools hijack the camera, gives us a much rounder understanding: * **For developers with source access:** The "cleanest" way to modify camera behavior is by understanding and changing the C++ logic in classes like `CPlayerView`, `CPlayerRotation`, or even `CCameraManager` if you're adding new cinematic modes. * **For modders (often without source):** Understanding that there's a final camera state in memory is key. Advanced mods can achieve incredible camera control by finding these memory locations and directly manipulating them, or by hooking the functions that read/write this data. * **The "Ground Truth":** Both approaches confirm that there's a "ground truth" for the camera's state (our `SViewParams` idea) that is absolutely critical. The difference is just *how* you get to change it. --- Exploring CryEngine's camera system was quite an adventure. It started simple, got tricky, but ended fun and rewarding. Remember, as modders, there's always more to uncover. Happy modding, and CryEngine, ***CryMore***!