Why AEC and configurator studios stream Unreal instead of optimising it, and when it doesn't pay off

Two industries, one engine, opposite economics#

Games and architectural visualisation both run on Unreal Engine, but the business behind them points in opposite directions.

A game studio ships one build to a very large audience on hardware it does not control. Every hour spent on level of detail, texture budgets, draw-call reduction and shader permutations is paid back across that audience: each player whose laptop can run the game is a sale. Optimisation is part of the product, and it is scheduled and budgeted as such.

An AEC studio (architecture, engineering and construction), or a studio building a car, kitchen or real-estate configurator, works the other way round. The scene comes from someone else’s data, the audience is small and specific, the deadline is fixed by a design review or a sales launch, and the client pays for the experience, not for making it run on weaker computers. Optimisation is a cost with no line item.

Pixel streaming changes which of those constraints matters. Instead of making the scene light enough for every viewer’s machine, the studio runs it on one powerful machine and sends video. The rest of this article explains why that trade usually favours AEC and configurator work, and the cases where it does not.

Why AEC and configurator content is heavy#

The source of the content is the main reason. Unreal’s Datasmith importer brings in scenes from Revit, Archicad, SketchUp, 3ds Max, Rhino, Navisworks and IFC, and from engineering CAD formats such as STEP, CATIA and SOLIDWORKS. Epic describes it as bringing in “entire scenes, potentially containing thousands of objects, each with its materials, pivots, scale, hierarchy, and metadata.”

That data was authored for construction documents and manufacturing, not for real-time rendering:

• Geometry is exact, not efficient. A BIM model describes every mullion, bolt and pipe fitting; a CAD model of a vehicle keeps the interior parts nobody will see. Tessellating curved surfaces from CAD adds more triangles.
• Object counts are high. Thousands of separate objects mean thousands of draw calls unless someone merges them, and merging breaks the object-level metadata that makes BIM useful in a review.
• The model keeps changing. Design reviews happen because the design is still moving. Each revision in Revit or the CAD tool means another import, and any manual optimisation done on the previous import has to be redone or re-checked.

Unreal 5 made heavy geometry far more practical. Nanite, Epic’s virtualised geometry system, is built to render “film-quality source art” with orders of magnitude more triangles than traditional pipelines. But Nanite requires DirectX 12 with Shader Model 6, recommends SSD storage, and still wants a capable GPU with enough video memory for the materials, lighting and textures around that geometry. Lumen global illumination and hardware ray tracing, which clients increasingly expect in visualisation, add to the same bill.

The result is a scene that looks right on the studio’s workstation and does not run, or runs badly, on the machines of the people who need to see it.

Who needs to see it, and what they have#

Consider who opens an AEC or configurator build:

• Clients and project owners, on office laptops chosen for email and spreadsheets.
• Consultants and engineers, often on locked-down corporate machines where installing software needs an IT ticket.
• Site and project managers, frequently on tablets or phones, away from a desk.
• Sales teams and end customers of a configurator, on whatever device they happen to hold.

What these people have in common is that none of them bought a computer to run a real-time 3D engine. Most business laptops use integrated graphics that share system memory with everything else; a workstation GPU sits under a designer’s desk, not a client’s. You cannot ask a client to buy hardware to attend a design review.

The distribution problem nobody budgets for#

Even when a viewer’s machine could cope, getting the build to them is its own project. A packaged Unreal build of a detailed building or product is typically several gigabytes. Sending it means:

• A download link or a physical drive per recipient, and a way to know who has which version.
• An install on each machine, which corporate IT may block or delay.
• Repeating all of it for every revision, and finding out in a meeting that half the room is on last week’s build.
• Supporting each installation: drivers, missing runtimes, antivirus quarantining the executable.

With streaming, the build lives in one place. The studio uploads a new version and every link shows it. Viewers open a browser; nothing is installed. The GPU that renders the scene is chosen by whoever runs the servers, not by whoever received the link.

What streaming changes, concretely#

Pixel Streaming runs the packaged Unreal application on a server with a capable GPU, encodes each rendered frame as video, and sends it to the viewer’s browser over WebRTC, while mouse, keyboard and touch input travel back the other way. Epic’s Pixel Streaming overview describes the model; the architecture article on this site explains the connection in detail.

For an AEC or configurator studio that means:

• The hardware question is answered once. The scene has to run well on the server’s GPU, not on every viewer’s. Server-class cards such as NVIDIA’s RTX PRO 6000 Blackwell, with 96 GB of memory, are the kind of hardware nobody keeps on a client’s desk.
• Optimisation becomes optional, not mandatory. You still want a steady frame rate, and a lighter scene lets more viewers share a GPU, but the deadline no longer depends on getting a BIM model to run on integrated graphics.
• Updates are one upload. Everyone sees the same version, which matters most in design reviews where decisions are recorded against what people saw.
• Any device with a browser can view it, including phones and tablets, because decoding video is something every device already does well.
• The source files never leave your control. Viewers receive pixels, not the model, which some clients and security reviews care about.

When streaming does not pay off#

Streaming is not free and not universal. Be honest with clients about these cases:

• No reliable connection where the viewing happens. Construction sites, trade-show halls and client offices with restrictive firewalls can break or degrade a stream. A packaged build on a capable laptop works offline; a stream does not. Corporate networks that block WebRTC’s UDP traffic need a TURN relay, which the diagnosing-connection-failures guide covers.
• An audience of one or two with capable machines. If the only viewer is the client’s own visualisation lead with a workstation, sending a build is simpler and has no running cost.
• Latency-sensitive interaction. Every input travels to the server and back before the result appears. Walking through a building tolerates this well; fast driving or precise manipulation may not. The latency depends on the distance to the server region and the viewer’s network, so test from where your viewers actually are.
• Long sessions with nobody watching. Metered pricing charges for GPU time; a stream left open on a meeting-room screen all day costs money. Idle timeouts help, and flat pricing removes the problem.
• Very large simultaneous audiences. An interactive stream needs its own engine process and a share of a GPU. A launch event with hundreds of people interacting at the same moment needs hundreds of sessions, which is a capacity and cost question to answer in advance. The session-scaling article explains the model.
• Offline or archival deliverables. If the contract requires a build the client keeps and runs years from now, streaming is a way to review it, not a replacement for delivering it.

How to estimate the cost#

Whoever provides the streaming, the cost comes down to a few inputs you can estimate before quoting a client:

1. Peak concurrent viewers: how many people interact at the same moment, not how many have the link. A design review with twelve invitees may peak at four simultaneous sessions.
2. Session length and frequency: how long each viewer stays, and how often reviews happen.
3. How long the project is live: a two-week review cycle, a six-month sales campaign, or an always-on configurator.
4. Resolution and frame rate: higher settings need more GPU per session, which can reduce how many sessions share one GPU.

Providers price these in two broad ways:

For studios quoting fixed-price projects, the second model is usually easier to sell: the hosting cost is a known monthly number that can go into the proposal, whatever the client’s team does with the link. With metered pricing, estimate generously and state the assumption in the quote.

Whichever model you use, write the assumptions into the client proposal: expected peak viewers, how long the stream stays live after handover, and who pays if either grows.

A checklist before you decide#

• Can the people who need to see the project run the build on their own machines, today, without new hardware?
• Will they view it somewhere with a stable internet connection?
• How many revisions will the build go through before sign-off?
• How many people need to interact with it at the same time, at the peak?
• How long after delivery must it stay available, and who pays for that period?
• Does the client’s security review prefer that source models never leave the studio?

If most answers point to “weak devices, several revisions, several outside viewers”, streaming usually costs less than the optimisation and distribution work it replaces. If the answers are “one capable viewer, offline, one final build”, ship the build.

What this article does not measure#

This is an explanation of the economics, not a benchmark. It contains no measured frame rates, latencies or cost comparisons from specific projects, because those depend on the scene, the server region and the provider. The performance hub on this site covers how to measure latency and quality for your own project before committing to either approach.