Real-Time Motion Graphics in Game Engines: What Actually Works
A symptom-by-symptom guide to fixing dropped frames, color shifts, bad data, sync faults and crashes in real-time motion graphics built in game engines.
Tomas Lindqvist
Real-time motion graphics in game engines means building animated graphics (scorebugs, lower thirds, data walls, stage visuals, virtual set elements) inside an engine such as Unreal Engine, where every frame is drawn at the moment it is displayed rather than rendered ahead of time and played back as a file. That one difference changes almost everything about how the work is designed, tested and delivered. A pre-rendered animation can take four minutes per frame and nobody cares. A real-time graphic that takes 17 milliseconds when it only has 16.67 drops a frame on live television.
This manual is for the people who have to make it work on the night: broadcast and events producers deciding whether to go real-time, in-house motion teams moving from After Effects or Cinema 4D into an engine, and technical directors who inherit a project that looked great in review and falls apart on the target machine. It is organized by symptom. For each common problem you will find how to recognize it, what usually causes it, how to fix it, and how to stop it from coming back.
The payoff for getting this right is real. Real-time graphics can respond to live data such as scores, votes and feeds, and they can be changed instantly without a re-render. The cost is that they demand different skills and different hardware from pre-rendered work, and most failures trace back to teams that assumed the old workflow would carry over unchanged.
Diagnosing real-time motion graphics problems: a quick symptom map
Before digging into individual problems, it helps to know where to look first. Real-time failures tend to fall into a small number of families: performance (the frame is not finished in time), fidelity (the frame is finished but looks wrong), data (the frame shows the wrong content), signal (the frame is correct but does not reach the switcher cleanly), and operations (everything works but a human cannot drive it reliably). The table below is the triage sheet we suggest pinning next to the operator position during rehearsals.
| Symptom | Most likely cause | First fix to try |
|---|---|---|
| Stutter or hitching during transitions | GPU or game-thread time exceeding the frame budget; assets streaming in on first use | Profile with stat unit on the target machine; preload assets before air |
| Colors or brand reds look wrong on the program feed | Tone mapping or color space mismatch between engine output and broadcast chain | Disable filmic tone mapping for graphics; confirm output color space and range |
| Values on screen are stale or show placeholders | Feed disconnected, schema changed, or no fallback state defined | Check feed timestamp; switch template to a safe manual value |
| Names overflow boxes or collide with other elements | Template designed around sample data, not real data extremes | Apply auto-fit or truncation rules; test with the longest known values |
| Tearing, flicker or drifting sync on the switcher | Output not genlocked, or frame rate mismatch with house reference | Lock output to house sync; match frame rate exactly (59.94 is not 60) |
| Black or frozen output mid-show | Engine crash, driver fault, or GPU overheating | Cut to backup machine or pre-rendered safety graphic |
| Slow project loads, memory warnings | Oversized textures, uncompressed media, unused assets packaged | Audit texture sizes and media; strip unused content |
| Operator fires the wrong graphic or misses cues | Control surface unclear; no rehearsal under show conditions | Simplify the rundown; rehearse with the real operator |
Two rules make this table more useful. First, always reproduce a problem on the hardware that will be used for the show, not on a designer's workstation. The same scene can behave very differently on a machine with a different GPU, driver version or output card. Second, change one thing at a time. Live graphics problems often have two overlapping causes, and fixing both at once hides which one mattered.
Symptom: dropped frames, stutter and hitching on output
How to recognize it
The most common real-time failure is simply that frames arrive late. On a broadcast feed this shows up as a stutter in motion, a hitch at the start of a transition, or text that appears to jump rather than glide. On an LED wall at an event it may look like judder during camera-tracked moves. The tell-tale pattern is that the problem is intermittent: the graphic plays cleanly nine times and hitches on the tenth, or only hitches the first time it is triggered after loading.
Likely causes
Every real-time graphic lives inside a frame budget. At 60 frames per second, each frame must be simulated and drawn in about 16.67 milliseconds. At 50 frames per second, the budget is 20 milliseconds. At 29.97 or 25, you get roughly 33 or 40 milliseconds, but many broadcast workflows still run the engine at the field rate to keep motion smooth. Anything that pushes a single frame over that line causes a drop. The usual offenders are:
- GPU overload: too many translucent layers, heavy post-process effects, high-resolution reflections, particle systems with large overdraw, or global illumination features that are designed for games rather than graphics packages.
- Game-thread spikes: blueprint logic running on every tick, data parsing on the main thread, or large numbers of animated actors being updated individually.
- Asset streaming and shader compilation: the first time a material or texture is used, the engine may need to load it from disk or compile a shader variant. That one-off cost is exactly what causes the "first trigger hitches" pattern.
- Output overhead: capture and playout cards, NDI encoding, or multiple simultaneous outputs add their own cost, which is invisible on a workstation that only renders to a monitor.
The fix
Start with measurement, not guesswork. In Unreal Engine, the stat unit console command shows frame, game-thread, draw-thread and GPU times side by side, which tells you immediately whether the bottleneck is CPU-side logic or GPU rendering. stat gpu breaks GPU time down by pass, and Unreal Insights records traces you can scrub through after a hitch. The profiling tools are documented in the Unreal Engine documentation, and it is worth having one person on the team who knows them well.
Once you know where the time goes, fix the biggest item first. If the GPU is the bottleneck, reduce translucent overdraw (stacked glass panels and glows are expensive), lower post-process quality, replace dynamic shadows on flat graphics with baked or faked ones, and turn off features the graphic does not need. Graphics packages rarely benefit from full-scene global illumination; a clean, controlled look is usually better served by simple lighting and emissive materials. If the game thread is the bottleneck, move logic off per-frame ticks to event-driven updates, batch data parsing, and avoid spawning and destroying actors during a show.
Quick fix: If a graphic only hitches the first time it fires, run a "warm-up" pass before doors open or before going on air.
- Trigger every template and transition once, off air, on the playout machine.
- Keep the level loaded rather than loading sub-levels on demand during the show.
- Use shader precompilation and pipeline caching where your engine version supports it, so variants are not compiled live.
Prevention
Set a written frame budget at the start of the project and give each part of the package a share of it. A useful working target is to keep average GPU time comfortably below the budget (many teams aim for a quarter or so of headroom) because live data, operator actions and output cards will all add load you did not see in testing. Profile weekly on the target hardware, not just at the end. And resist the temptation to add "one more effect" during the final days; that is when most over-budget scenes are born.
Symptom: the on-air look does not match the approved design
How to recognize it
The client signed off a style frame from Photoshop or After Effects. On the program monitor, the brand red is duller, the whites are slightly gray, fine type looks soft or shimmers, and the gradients band. Sometimes the look is right on the engine viewport and wrong only after it passes through the output card and switcher.
Likely causes
Game engines are built to make scenes look like photographs. By default they apply tone mapping, auto exposure, bloom and other camera-like processing that is lovely for a virtual set and wrong for a flat brand graphic, where the exact hex value matters. Other common causes include a mismatch between the engine's output color space and the broadcast chain (for example, full-range versus legal-range video levels), texture compression artifacts on logos and gradients, and anti-aliasing methods that blur or shimmer thin strokes and small text.
The fix
- Isolate graphics from photographic processing. Disable auto exposure and use a fixed exposure. For flat 2D elements, use unlit or emissive materials and, where the pipeline allows, bypass filmic tone mapping so that a brand color entered as a value comes out as that value.
- Agree the color pipeline end to end. Confirm whether the output is Rec. 709 or an HDR format, and whether the output card and switcher expect full or legal range. Test with a color bar pattern and a brand color swatch, measured on a waveform and vectorscope at the switcher, not by eye on a desktop monitor.
- Protect logos and text. Use appropriate compression settings (or none) for UI-style textures, generate mipmaps carefully, and build type from vector or signed-distance-field text rather than low-resolution bitmaps.
- Choose anti-aliasing for graphics, not games. Temporal methods can smear thin lines and fast-moving text. Test alternatives, or render key text layers at a higher internal resolution.
Depth and lens effects are another source of mismatch. A shallow depth of field that looked cinematic in a pre-rendered comp can make a lower third unreadable in real time, and engine bokeh can be expensive. Our guide to depth of field in motion graphics covers when the effect earns its place.
Prevention
Do look development in the engine, not in a separate tool. Style frames made elsewhere are fine as mood references, but the approval that matters is a frame captured from the engine through the real output path. Include a color-managed reference monitor in the review, and write down the agreed values for the brand palette in the color space of the broadcast chain.
Symptom: live data shows the wrong values, stale values or nothing at all
How to recognize it
The scorebug shows last quarter's score. The poll result graphic reads "NaN%". A leaderboard shows a placeholder name from testing. Or the whole data-driven element simply fails to appear. These failures are especially damaging because they are wrong in public, often in front of the people whose names and numbers are being shown.
Likely causes
Live data is one of the main reasons to choose real-time graphics, and it is also one of the main reasons real-time shows go wrong. The typical causes are an untested feed, a schema change by the data provider (a field renamed or a nested object restructured), network interruptions between the venue and the data source, parsing that assumes values will always be present, and no defined behavior when the data is late or invalid. Timing matters too: a feed that updates faster than the animation can play will cause values to change mid-transition.
The fix
When it happens live, the first move is to stop showing wrong information. Every data-driven template should have a manual override that lets the operator type or select a value, and a way to take the element off air cleanly. Then check the feed: when did the last valid update arrive, and does its structure match what the template expects?
The longer-term fix is to put a thin layer between the raw feed and the graphics. That layer, whether a small middleware service or logic inside the engine, should validate each message against an expected schema, reject values that are out of range, timestamp every update so staleness can be detected, and hold the last good value when the feed misbehaves. The graphic should then read from that validated state rather than from the raw feed. Unreal's Remote Control tools, described in the engine documentation, are a common way to expose template parameters to external controllers and data systems in a structured way.
Warning: Never connect a production graphic directly to a feed you have not tested with real traffic. Sample JSON files prove the parser works; they do not prove the feed is reliable, that it updates at the rate you expect, or that its edge cases (ties, withdrawals, zero votes, overtime) render sensibly.
Prevention
Build templates driven by data from the start, and test them with recorded real feeds replayed at speed, including recordings from messy moments. Write down how each template behaves when data is missing, late, or out of range, and rehearse those states. Election and results programming is the extreme case of this problem; our article on election results graphics covers the editorial safeguards that sit alongside the technical ones, and countdown and timer graphics covers clock sources and drift.
Symptom: templates break when real names, numbers and languages arrive
How to recognize it
The lower third that looked perfect with "Jane Smith" overflows with a hyphenated double surname and a long title. A four-digit score pushes into the team logo. A translated version of a graphic truncates mid-word, or accented capitals clip against the top of their text box. These are template failures, and in real-time work they happen on air rather than in a review session.
Likely causes
Designers build around representative sample content, and real content is rarely representative. Engine text systems handle layout differently from design tools, so auto-sizing behavior that worked in After Effects may not exist or may behave differently. Fonts may lack glyphs for some languages, and fallback fonts will silently change the look. Number formatting (thousands separators, decimal marks, currency symbols) varies by market.
The fix
- Define explicit rules for each text field: maximum characters, minimum font size before shrinking stops, whether to wrap to a second line, and what to truncate when all else fails.
- Build the rules into the template so the operator cannot accidentally break them, and flag overflow visually in the control interface before a graphic goes to air.
- Check every font for full coverage of the languages and characters you need, including diacritics and punctuation. License fonts for embedding in the engine project and any playout machines.
- Test with an "ugly data" set: the longest names on the roster, the largest plausible numbers, empty fields, and right-to-left text if relevant.
Many of the same principles apply to editor-facing templates, which we cover in motion graphics templates for editors. For packages that ship in several languages, localizing motion graphics explains how to plan text expansion and script-specific layout.
Prevention
Write the data specification before the design is finished, and design against it. A lower third spec that says "name up to 32 characters, title up to 48 characters, one line each, shrink to 80 percent then truncate with an ellipsis" gives the designer and developer something concrete to test. Broadcast conventions for safe areas, sizing and timing, covered in our piece on broadcast graphics and lower thirds, still apply when the graphic comes from an engine.
Symptom: tearing, flicker, key edges and sync drift at the switcher
How to recognize it
The graphic looks right on the engine machine but the switcher shows a horizontal tear line, periodic stutter every few seconds, a dark or light fringe around keyed elements, or a slow drift where the graphic lags behind program audio or video. On LED walls, you may see tearing between processor sections or rolling artifacts on camera.
Likely causes
Real-time output has to fit into a broadcast or event signal chain that runs on a shared clock. If the engine is not locked to house reference (genlock), its frames will occasionally be early or late relative to everything else, which shows up as periodic stutter or tearing. Frame-rate mismatches are a classic trap: 59.94 and 60 frames per second look almost identical in a settings menu and produce a dropped or repeated frame roughly every 16 to 17 seconds when mixed. Key and fill problems usually come from premultiplied versus straight alpha confusion, which produces fringes around soft edges and glows. Latency drift happens when processing delay in the graphics path is not matched in the audio or video path.
The fix
- Confirm the house standard (resolution, frame rate, interlaced or progressive, SDI or IP such as SMPTE ST 2110 or NDI) and set the engine output to match exactly.
- Genlock the output card to house reference and verify lock status in the card's utility, not just in the engine.
- Check alpha handling: agree whether the switcher expects premultiplied or straight key and fill, and test with a soft-edged gradient over a mid-gray background.
- Measure end-to-end latency with a flash-and-beep test, then apply compensating delays where needed.
For work where graphics must track a live camera, lens and camera tracking data add another synchronization layer. The principles of motion tracking for pre-rendered graphics carry over, with the added constraint that tracking data and video must arrive in step.
Prevention
Get the engineering specification from the broadcast or event technical team in writing at the start, and do a signal test through the real chain early, well before content is final. Signal problems are cheap to fix in week two and very expensive to fix on the day.
Symptom: black, frozen or crashed output in the middle of a show
How to recognize it
This one is unmistakable. The graphics output goes black, freezes on the last frame, or the application closes. Sometimes it is preceded by warning signs: growing memory use, rising GPU temperature, or occasional hitches that become more frequent as the show goes on.
Likely causes
Engines are complex software running on consumer-derived GPU hardware, and they can crash. Common triggers are memory leaks from repeatedly spawning content, driver instability, thermal throttling in poorly ventilated racks or flight cases, unexpected input from a data feed, and unvetted plugin or engine updates installed shortly before the event. Power and cabling faults cause their share too.
The fix
The fix during the show is not technical; it is procedural. A live real-time graphics setup without a backup is a single point of failure, and the most important decision is made before the event: what goes to air when the primary machine fails?
Quick fix: Keep at least one fallback that the director can take in a single button press.
- A second, identical playout machine running the same project, fed the same data and controlled in parallel, routed to a separate switcher input.
- Pre-rendered safety versions of critical graphics (the show open, a neutral scorebug, a holding slate) loaded on a clip player.
- A documented restart procedure with a known time to recover, so the director can decide whether to wait or switch.
Prevention
Plan failover for every live broadcast and event, sized to the stakes. Lock software versions (engine, plugins, GPU driver, output card driver) several weeks before the show and do not update them afterward. Run soak tests: leave the full package cycling through its rundown for longer than the show's duration and watch memory and temperature. Make sure the playout hardware has adequate cooling in its actual installed position, not just on a desk.
Symptom: bloated projects, slow loads and memory warnings
How to recognize it
The project takes many minutes to open. Packaging fails or produces enormous builds. The engine warns about texture streaming pools or video memory, and hitches become more frequent as more graphics are triggered. Handing the project to another machine or another artist becomes a day-long exercise.
Likely causes
Teams moving from pre-rendered workflows are used to working with large source files because render time was the constraint and disk was cheap. In real time, every asset has to fit in memory and be loaded quickly. Frequent causes include 8K textures used on elements that occupy a few hundred pixels on screen, uncompressed video used as texture sources, high-polygon models imported straight from CAD or sculpting tools, and dozens of unused test assets left in the project.
The fix
Audit the project from the largest items down. Resize textures to roughly the largest size they will ever display at on the output raster, with sensible power-of-two dimensions where the engine needs them. Convert video textures to codecs designed for real-time playback. Reduce model complexity or use the engine's geometry systems appropriately for the content. Delete, or move out of the playout project, anything that is not used in the show. The texture and memory statistics commands in the engine help identify the heaviest items.
If your team is bringing heavy 3D assets from a pre-rendered pipeline, our practical guide to 3D in motion graphics covers modeling and texturing choices that translate better into real time.
Prevention
Keep asset sizes controlled from the start with an asset budget: maximum texture resolution by element type, target polygon counts, allowed video formats, and a naming and folder convention. Review new assets against the budget before they are merged into the main project. It is far easier to hold a line than to claw memory back later.
Symptom: the package works but nobody can drive it reliably
How to recognize it
The graphics are technically sound, yet during rehearsal the wrong element fires, cues are late, a graphic stays up after the segment ends, or the operator has to ask the designer which button does what. In the worst cases, only the person who built the project can run it.
Likely causes
Real-time packages are often built by artists and developers who know the project intimately, then handed to operators who do not. Control interfaces are assembled late, show too many parameters, and do not match the rundown order. Rehearsal time is squeezed because content was late. Communication paths between director, producer and graphics operator are not defined.
The fix
- Build a control interface that matches the show, not the project. Group controls by segment, label them in the language the director uses, and hide parameters the operator should not touch.
- Show a preview of the next graphic and its data before it goes to air.
- Assign one operator per output where possible, with a clear call-and-response protocol with the director.
Prevention
Rehearse live operations before events, with the real operator, the real control surface, the real data and the real signal chain. Include failure drills: pull the data cable, crash the primary machine, and practice the switch to backup. A rehearsal that only runs the happy path tells you very little.
Worked example: budgeting an illustrative sports graphics package
The following is an illustrative example rather than a real client project. It shows how the principles above turn into numbers a team can plan against.
Imagine a regional sports broadcaster planning a real-time graphics package for a season of live matches. The house standard is 1080p at 59.94 frames per second over SDI, genlocked. The package includes a persistent scorebug with a live clock and score from the league's data feed, lower thirds for players and commentators, a lineup full-frame, a replay wipe and a half-time statistics wall. Graphics will be built in Unreal Engine using its Motion Design toolset for broadcast-style animation, with a second identical machine as backup.
At 59.94 frames per second, the frame budget is about 16.7 milliseconds. The team decides to keep a quarter of that as headroom for data updates, output overhead and operator actions, leaving a working target of roughly 12.5 milliseconds of GPU time for the busiest moment in the show. They then allocate that target across the heaviest overlapping state, which in this package is the replay wipe playing over the scorebug and a lower third.
| Element in busiest state | Allocated GPU time | Measured on target hardware (first pass) | Action |
|---|---|---|---|
| Scorebug with live clock | 1.5 ms | 1.2 ms | Within budget |
| Lower third with glass panel | 2.5 ms | 4.1 ms | Reduce translucent layers from three to one; fake the blur |
| Replay wipe with particles | 5.0 ms | 7.8 ms | Halve particle count; cut overdraw with smaller sprites |
| Post-processing and output | 3.5 ms | 3.0 ms | Within budget |
| Total | 12.5 ms | 16.1 ms | Over target; fixes required before sign-off |
The first measured total of 16.1 milliseconds is technically inside the 16.7 millisecond frame, which is exactly why it is dangerous: it leaves no margin, and a busy data update would push it over. After the two fixes, the team re-measures at 11.4 milliseconds, then runs a four-hour soak test with a recorded match feed replaying through the validation layer. Memory rises slightly in the first hour and then stays flat, which the team logs as acceptable. Rehearsal day includes a deliberate failover drill in which the primary machine is shut down mid-replay and the director cuts to the backup input.
The numbers here are for illustration; real timings depend on the GPU, resolution, engine version and design. The method is the part to copy: set a budget with headroom, allocate it, measure on the real machine, fix the largest overruns first, and prove stability over longer than the show will run.
Symptom: the team is stuck because the old workflow does not transfer
How to recognize it
Schedules slip, artists are frustrated, and everyone keeps saying "in After Effects this would take ten minutes." Designs keep arriving that cannot run in real time, and developers keep saying no without offering alternatives.
Likely causes
Assuming pre-rendered workflows transfer directly is one of the most common and expensive mistakes in this field. Pre-rendered motion design optimizes for final image quality with unlimited render time; real-time design optimizes for a guaranteed frame rate with interactivity. Techniques that are trivial in a compositor, such as stacked blurs, many layered blend modes or heavy motion blur, can be costly or behave differently in an engine. Meanwhile, the engine offers capabilities that pre-rendered tools lack, such as live data, instant changes and camera-driven interaction, and teams sometimes ignore these because they are still designing for a linear timeline.
Myth: A strong After Effects artist can build a real-time broadcast package in an engine with a few days of tutorials.
Reality: The design eye transfers well, but real-time delivery also needs performance profiling, data integration, signal engineering and live operations skills. Most successful teams pair motion designers with a technical artist or engine developer from day one.
The fix
Restructure the team and the brief. Put a technical artist in design reviews so performance feedback arrives before designs are approved. Write the brief around real-time constraints: target hardware, frame rate, data sources, operating model and failover requirements. Our guide on getting motion graphics briefs and scoping right covers how to capture these requirements early.
Also be clear about where real time is the right tool. If a graphic never changes, never responds to data and is played back identically every time, a pre-rendered file is usually cheaper and more reliable. Our overview of rendering and output for motion covers that side of the decision.
When to bring in help
Bring in specialist help when motion graphics must run live at events or on broadcast. The cost of a failure in front of an audience is far higher than the cost of experienced support, and the skills involved (signal engineering, failover design, live operation) take time to build in-house. A studio that offers animation and motion graphics services can often design the package, build the templates and provide or train operators, while your in-house team keeps ownership of the brand and editorial decisions.
Prevention checklist for real-time motion graphics projects
Most of the symptoms in this manual are preventable, and prevention is cheaper than diagnosis on the day. Use this checklist at kickoff, at design sign-off and again before the first rehearsal.
- Target hardware, GPU model, driver version and output card are specified and available to the team early.
- Frame rate, resolution, color space, video range and signal format match the house or venue standard exactly.
- A written frame budget with headroom exists, and performance is profiled on the target hardware at least weekly.
- Look development and approvals happen on frames captured through the real output path.
- Every data-driven template has a validation layer, a last-good-value fallback and a manual override.
- Data feeds are tested with recorded real traffic, including edge cases and outages.
- Text fields have documented limits and overflow rules, tested with the longest real values and every language in scope.
- An asset budget covers texture sizes, model complexity and video formats, and unused content is removed from the playout project.
- Software versions are locked well before the show, and a soak test longer than the show has passed.
- A backup machine or pre-rendered safety graphics can be taken in one button press, and failover has been rehearsed.
- The operator has rehearsed with the real control surface, real data and real signal chain, including failure drills.
Scenes overloaded with effects deserve a final mention because they cause several of the symptoms above at once: dropped frames, soft or mismatched looks, bloated memory and harder operation. Restraint is a technical virtue in real time as much as an aesthetic one.
Verdict Real-time motion graphics in game engines work when they are treated as live systems rather than animations: budgeted for performance, driven by validated data, locked to the signal chain, backed up and rehearsed. Teams that plan for failure from the first day rarely see it on air, and teams that treat the engine as a faster renderer usually learn these lessons in public.
Where this comes from
- Unreal Engine Documentation — Motion Design
- Unreal Engine Documentation — Unreal Engine 5 documentation
The figures and practices above come from the sources listed.
Working on something like this?
We take on Motion Graphics & Animation work for teams who want it done once, properly. Tell us what you are building and we will tell you honestly whether we are the right studio for it. Start a project.
Where to go next
Spotted something wrong? Report an error on this page. We correct on the page and say what changed.
