Some effects look good on a desk and do nothing but harm in a stream. Others just keep Sam busy. Here is what to switch off, what to turn down, and why.
This builds on Why Unreal apps wait on one core, which introduces the kitchen, the thousand cooks and Sam at the door.
In Pixel Streaming, the picture is not shown on the machine that makes it. Every dish leaves the kitchen by delivery: it is packed into a box and sent over the internet to the viewer.
The box has a fixed size. Only so much fits in it every second, however good the dish is. A neat dish packs well and arrives looking the way it left. A messy dish, with bits that change all the time, does not fit; the packer has to squash it, and the viewer gets a blurry, blocky version.
So in a stream, every effect is paid for twice: once to make it (Sam and the cooks), and once to pack it (the box). Some effects fail both ways.
The packer is the video encoder, and the box size is the bitrate: how much picture can be sent each second. Epic's own guide puts it plainly: "Disabling motion blur or any effect that increases visual complexity can, in some scenes, significantly decrease encoding complexity, thus resulting in a lower bitrate."
These cost the cooks extra work, and then the packing squashes them, or squashes everything else to make room for them.
| effect | what it does | what happens in a stream | advice |
|---|---|---|---|
| Motion blur | Smears the picture in the direction things move | The smear is new, different detail in every picture, so it is hard to pack. The video already softens fast motion on its own, so the effect is mostly lost, and its cost is not. | switch off |
| Film grain and noise | Adds fine random speckle to every picture | Random speckle is different in every picture, so nothing can be reused from the last one. It eats the box and leaves less room for the scene. Epic notes it helps against colour banding, at the cost of bandwidth. | switch off or very light, only to fight banding |
| Chromatic aberration | Thin coloured fringes along edges, like a cheap lens | Video keeps colour at a quarter of the detail of brightness, so thin colour fringes are smeared away. What is left is a colour smudge. | switch off |
| Anything that flickers or sparkles | Flickering lights, lens flares, shimmering grass and fences, noisy reflections | Detail that changes every picture is the hardest to pack. It turns into crawling blocks, and drags the rest of the picture down with it. | reduce |
| Many post-process volumes | Layers of colour and lighting effects in different areas | Every extra layer of effects makes the picture harder to pack. | keep few |
| Smooth gradients (vignette, big skies, fog) | Soft fades from one shade to another | Fine in moderation. Heavily compressed, a soft fade can break into visible stripes (banding). | watch for stripes |
| Depth of field | Blurs what is out of focus | Blurred areas pack easily, so the stream itself is not harmed. It still costs the cooks; use it where it serves the picture. | fine |
Sam prepares every picture on one processor core, and the stream cannot be faster than Sam. If the app cannot make 60 pictures a second on the machine, no network setting will make the stream do it. These lighten Sam's list:
| change | why Sam is quicker |
|---|---|
| Fewer separate objects: group repeated ones (instancing), merge small ones, use Nanite for detailed ones | Fewer things to ask questions about, for every picture. |
| Cull distance: objects stop being considered beyond a set distance | Far-away objects are dropped early instead of going through the whole list. |
| Fewer moving lights that cast shadows | Each one sends Sam back through the objects it lights. They are among the most common reasons a scene runs slowly. |
| Ray tracing only where it shows: leave small and distant objects out | Every object in ray tracing adds work for Sam in every picture. |
| Static instead of movable for everything that never moves | Sam does not have to check whether it moved. |
| Light per-picture logic: avoid heavy Blueprint work running every frame (Tick) | That logic also runs in a single lane, and every picture waits for it too. |
| Ship the release build (Shipping), not the development build | The development build adds checking work to every lane, Sam's included. |
Some work is simply thrown away in a stream, because the viewer never gets it.
| waste | why it is wasted | instead |
|---|---|---|
| Rendering at a higher resolution than the stream | The picture is shrunk before it is sent. | Render at the resolution you stream. |
| An unlimited frame rate | Pictures beyond what the stream sends are made and dropped, and uneven timing makes the video less smooth. | Lock it, for example to 30 or 60 per second. |
| The sharpest texture levels | At typical stream resolutions the finest texture detail is lost in packing. Unreal's
r.Streaming.MipBias 1 drops one detail level and saves video memory; at stream resolution the difference
is hard to see. | Drop one texture detail level and compare. |
| Top quality settings for effects the box squashes | The extra quality does not survive compression. | Compare the stream, not the desktop, before raising a setting. |
An effect is worth keeping only if it still looks better after it has been packed and delivered. Before deploying, open the app through the stream, on the machine it will run on, and compare with each effect on and off. The desk shows what the cooks made; only the stream shows what the viewer gets.
Last updated