Choose what genuinely needs to be live
A pre-rendered sequence plays back an already finished image. A real-time scene generates its output as it runs, making changes to camera position, lighting, objects or data possible during the show. That flexibility is useful when the production actually needs it. A fixed introduction with no changing information might be simpler as playback, while an analyst’s changing comparison may benefit from a responsive scene.
Write down every variable the production intends to control. Team identity, map selection, camera position and segment lighting are common examples, but each additional variable creates more combinations to test. Separate essential live changes from attractive possibilities that do not serve the programme. This reduces development effort and makes the operator’s job easier when the rundown changes unexpectedly.
Prepare assets for the output, not the portfolio
Detailed models, large textures, animated crowds and complex reflections can look excellent in a still image while overwhelming a live scene. Asset preparation means balancing appearance against the time available to produce each frame. Review geometry, materials, texture sizes and visible detail from the actual broadcast cameras. Objects far outside the intended view may not need the same treatment as the presenter’s immediate surroundings.
Epic Games’ Unreal Engine and Unity are examples of real-time development environments, not guarantees of a particular broadcast result. The engine, plugins, hardware, output format and scene design form a combined system. Confirm software versions and licensing before the production depends on them. Also check rights for models, textures, logos and any game-derived imagery; access to an asset does not automatically include permission for every broadcast use.
Measure the busiest moment
Performance testing should include the most demanding planned shot and transition, not only an empty stage. At 50 frames per second, each frame has a 20-millisecond interval; at 60, the interval is approximately 16.7 milliseconds. That interval is not a promise that all of it is available to one subsystem. Rendering, compositing and output operations must fit the actual pipeline and leave practical headroom.
Measure frame consistency as well as average performance. A scene that usually runs smoothly but stalls during an asset load can still produce a visible on-air fault. Test whether shaders, media and scene variants are ready before they are called. Repeat the test on the deployed machines, at the intended resolution, with tracking, graphics and monitoring enabled. An artist’s development preview is not a substitute for this combined rehearsal.
Understand timing across departments
Several clocks may influence the final image: camera capture, tracking updates, rendering, audio and video output. Genlock can help compatible video devices align their frame timing, while timecode labels moments for identification. These are related operational tools, not interchangeable solutions. A system can carry matching timecode and still have an unwanted delay between the presenter and the digital element beside them.
For IP-based facilities, SMPTE ST 2110 describes professional media transport and SMPTE ST 2059 addresses timing using Precision Time Protocol. AES67 addresses interoperability for high-performance audio-over-IP streaming. These standards are useful reference points for engineering discussions, not a shopping list that every small studio must implement. Ask the technical lead to describe the chosen signal path and how alignment is measured in that specific design.
Give the scene a controlled vocabulary
Operators need named, repeatable states rather than an unrestricted collection of visual controls. Define clear commands such as “analysis ready”, “comparison visible” and “return to neutral”. Document what each command changes and what it leaves untouched. If an operator repeats a command, the system should behave in a known way rather than accidentally advancing to another step or adding the same object twice.
Restrict last-minute changes through a clear approval process. A small material adjustment can affect performance, lighting or visibility elsewhere in the scene. Keep a known-good version, record changes and test the build that will actually go on air. Where several render machines share a scene, confirm they have matching assets and configuration. A backup with outdated content may be less useful than a simpler, current fallback.
Keep the programme moving
Decide how the director can leave the real-time world if output becomes unreliable. That might mean a physical camera, a clean presentation background or a conventional graphic source. The alternative should preserve the editorial purpose of the segment even if it loses visual depth. A dependable show is built around this freedom to simplify, not around making every second dependent on the most elaborate scene.