A captured cutscene has no frame budget
Everything else in a game is a negotiation with 16.7 milliseconds. A cutscene that gets captured to a video file is not. It renders once, on a machine you control, at whatever speed you like, and the player sees the result. Ten seconds a frame is fine. Ten minutes a frame is fine.
The left half is what the frame actually is: aliased spokes that crawl and strobe, with hard edges that jump between pixels. The right is the same scene with sixteen samples, which costs sixteen times as much and is free when there is no deadline. Same code, same scene, one loop.
What the budget buys, roughly in order of value
- Supersampling. Render at 4x and downsample, or jitter and accumulate. This is the single largest quality difference and it is about four lines. Every hard edge, every thin element, every high-frequency texture improves at once.
- Real motion blur. Not a screen-space approximation from velocity vectors: actual samples across the shutter interval, which handles rotation, occlusion and overlapping objects correctly because it is not an approximation of anything.
- Ray counts that are absurd in realtime. Five hundred shadow samples. A thousand gather directions. All the noise problems on this site stop being problems.
- Depth of field by actually sampling the lens, which gets the occlusion right at bokeh edges instead of the halo every screen-space blur produces.
- Higher precision throughout. Render at 16 bit, work in linear, and only quantize at the end.
The one thing you must not spend it on
Anything that makes the cutscene look like a different game. If the captured scene has real motion blur, ray-traced shadows and eight times the geometry, the cut back to gameplay is a downgrade the player notices at exactly the moment they take control.
So the budget goes into resolving what is already there, not into adding what is not. Supersampling the same scene is invisible in the sense that matters: the player sees a clean version of the game, not a different one.
The costs nobody mentions
Capturing to video is not free, and these are the reasons to keep some cutscenes realtime:
- File size. A few minutes of high-bitrate video can outweigh the entire rest of a small game, and the bitrate has to be high or the encode undoes the supersampling.
- Resolution and aspect are baked. An ultrawide player gets pillarboxed or cropped. A realtime cutscene just renders wider.
- The player's choices cannot appear in it. No custom character, no chosen name, no state from their playthrough.
- Localisation multiplies it, unless text and audio stay as separate tracks, which is worth designing for on the first cutscene rather than the tenth.
- It cannot be patched cheaply. A one word script change is a re-render and a re-download.
The pipeline detail that decides whether any of this survives
All of the above is undone by the delivery encode if the capture goes out at a normal bitrate. Supersampling produces exactly the fine detail an encoder discards first, so a beautifully rendered capture at 8Mbps can look worse than the realtime version.
Capture lossless or near-lossless, encode once at the highest rate the platform allows, and check the delivered file rather than the master. This is the same rule as grain and dither, and it applies with more force here because the whole point was fine detail.
Rules of thumb
- A captured cutscene has no deadline. Ten seconds a frame is a normal number.
- Supersample first. It is four lines and the largest single improvement available.
- Sample the shutter for real motion blur rather than approximating from velocity.
- Spend the budget resolving the existing scene, never on making it a different scene.
- Keep text and audio as separate tracks from frame one, or localisation multiplies the file.
- Judge it on the encoded file. Fine detail is exactly what the encode throws away.
One email when something new goes up. No newsletter, no schedule, nothing else.
Double opt-in, so watch for a confirmation email. Unsubscribe any time.