A UE5 Archviz Pipeline That Actually Holds Up

Why the pipeline matters more than the renderer

Most studios that struggle with UE5 don’t have a renderer problem, they have a pipeline problem. The renderer just exposes it.

In this post I’ll walk through the pipeline I actually use on production projects, the parts that broke when scaled, and the parts that quietly worked.

Intake: never trust the FBX

Every model arrives broken in some way. We assume it. The intake pass:

• Re-pivot to world origin, with a known unit scale.
• Strip co-located duplicates (more common than you’d think).
• Generate Nanite-friendly LODs only where Nanite isn’t appropriate.
• Pre-bake a UV2 lightmap channel for fallbacks.

intake/
  raw/        # untouched client files
  cleaned/    # post-pass FBX/USD
  baked/      # exported to Unreal-ready

Lighting: one author, three deliverables

Cinematic, interactive, and stills come out of the same lighting setup. We don’t re-light per deliverable, we author once and let Sequencer drive the differences.

The discipline isn’t speed. It’s consistency.

Packaging

For interactive deliverables we ship signed Windows builds with a launcher that handles updates. For web, we use Pixel Streaming on a small autoscaling pool.

That’s the shape of it. The rest is taste.