CrimsonCamera · Lesson 1 of 6
How CrimsonCamera Works
Before you start
- None — start here
Chapters
A stack, not tick code
Instead of writing camera logic in a tick function, you push and pop modular UCrimsonCameraMode classes onto a stack owned by a UCrimsonCameraComponent. Each frame the component decides which mode should be on top, the stack ensures it's present, and then it blends every active mode's output — location, rotation, control rotation, FOV — by weight into the final view.
Why a stack
Because the stack blends by weight, pushing a new mode looks like a smooth transition rather than a cut. Third-person → aim → lock-on each become a push, not a pile of conditional camera code.
How modes blend
| Property | Effect |
| BlendTime | Seconds for a newly-pushed mode to reach full weight |
| BlendFunction | Linear / EaseIn / EaseOut / EaseInOut — the shape of the transition |
| BlendExponent | Sharpness of the Ease functions |
One instance per mode class
The stack caches a single instance per mode class and reuses it, so per-mode state you set (shoulder, zoom) persists across activations — and
Get Camera Mode Instance can hand you that live instance to drive.Choosing the active mode
Two mechanisms decide which mode runs, in this precedence:
| Priority | Source | Use for |
| 1 (wins) | Override stack — PushCameraMode / PopCameraMode, keyed by an owner tag | Event-driven takeovers (aim, lock-on, cutscene); most-recently-pushed wins |
| 2 | Per-tick selection — the Determine Camera Mode event | The base mode computed from game state when no override is active |
What's included
Built-in third-person & top-down modes, shoulder/zoom/lag/recenter, camera shake, occlusion fade, a data-driven lock-on built on the Gameplay Targeting System, and a C++ UI-camera takeover. We build up to the big ones across this course.