Unreal Engine is where you go when visual fidelity is the point. Photoreal lighting, high-detail environments and cinematic presentation are its home ground, which makes it the right engine for high-end games, serious visualisation and anything where the render has to convince a client or a stakeholder.
What We Build in Unreal
- High-fidelity 3D games — where visual quality is a primary requirement.
- Architectural and industrial visualisation — walkthroughs of buildings and plant that do not exist yet.
- Simulation environments — where realism materially affects training value.
- Digital twin experiences — 3D environments connected to real operational data. See digital twin commissioning.
- Interactive product experiences — configurators and demonstrations with real visual weight.
The Trade-Off, Stated Honestly
Unreal’s fidelity comes with cost: heavier assets, higher hardware requirements, larger builds and a steeper learning curve. For a mobile-first project or a lightweight web experience it is usually the wrong tool, and we will say so. Choosing Unreal because it looks impressive in a pitch is a decision you pay for during optimisation.
Fidelity Has to Serve Something
Photoreal rendering earns its cost when the visual is doing real work — convincing a stakeholder, conveying spatial reality accurately, or making a training environment credible enough that behaviour transfers. When it is decoration, the budget is better spent on gameplay, content or getting the product finished.
Tell us about your project and its visual requirements and we will recommend Unity or Unreal on the merits.
Related services
- Game Development — Back to the game development overview.
- 3D Visualization and Digital Twin Services — Related: 3D visualization and digital twin services.
Blueprints, C++, and the Line Between Them
Blueprints are a real programming environment, and shipped games run on them. Designers iterate without waiting on a compile, and gameplay tuning happens at the speed of the idea. The failure mode is a graph large enough that only its author can read it, in a file format that source control cannot merge in any meaningful way, on a team where two people needed to touch it in the same week.
Our default is systems and performance sensitive code in C++, with gameplay composition and tuning exposed to Blueprint on top. What matters more than the exact split is writing the boundary down and revisiting it deliberately, because it drifts quietly and the cost of the drift shows up during optimization.
Source Control Is a Real Decision on Unreal Projects
Unreal projects are asset heavy and largely binary. Uasset files do not merge, so two artists working the same level will produce a conflict that someone has to resolve by discarding work. Perforce with exclusive checkout is the usual answer for that reason. Git with LFS can work, but it needs file locking and discipline, and repository size grows in a way that makes fresh clones slow.
Decide this before the content team starts committing. Alongside it, plan a shared derived data cache for the team and a machine that produces builds, because shader compilation and cook times become a daily tax on everyone otherwise.
Turning On Nanite and Lumen Is a Hardware Decision
The features that make Unreal look the way it does in engine marketing carry a floor for GPU capability. On desktop with a discrete card this is usually fine. On mobile chips, standalone headsets, and older integrated graphics it may not be, and the fallback paths look materially different from the target you approved.
So the question is which users you are prepared to leave behind, answered before the lighting is authored. Retrofitting a lower end path late means reworking lighting and often geometry budgets across the whole project. For standalone VR in particular, the fidelity Unreal is known for generally cannot be carried onto a mobile class headset processor, which is why we steer that work toward Unity. AR and VR Development covers the headset side, and Unity Development Services covers the engine.
Who Will Be Reading This Code in a Year?
An Unreal codebase needs engineers comfortable with C++ and with reading engine source, artists who know the material and lighting workflow, and someone who owns the build machine. If your in house team is web or C# shaped, plan for that gap: budget the handover period, document the pipeline, and decide whether you intend to follow engine releases or stay on the version you shipped on.
Staying put is a defensible choice for a training title with a known audience and a fixed content set. It is a harder choice for a product with a long content roadmap, because platform SDK requirements move underneath you and eventually force the upgrade anyway.
Non-Game Work Has a Different Rhythm
Unreal also gets pointed at architectural walkthroughs, industrial visualization, virtual production, and digital twin environments, and those projects run differently from games. There is often a real CAD or BIM source model that needs cleaning and retopologizing before it can run at frame rate, a client review cycle driven by stakeholders who are not gamers, and an output that may be a video, a packaged application, and a pixel streamed link at the same time.
Budget the data preparation step explicitly. An engineering model imported untouched will not hold frame rate, and finding that out late is what costs the schedule.
One practical note while the engine choice is still open. Engine licensing differs between Unity and Unreal in structure, and both have revised their terms over time, so put the current published terms in front of your finance and legal people now. The questions that matter are not the same for an internally distributed training simulator, a commercial game, and a visualization tool sold to enterprise clients.
Real Geometry In, Real Data In
The geometry side of non-game work starts before Unreal opens. Mechanical CAD is stored as trimmed surfaces rather than triangles, so importing it is a tessellation step with a tolerance you choose, and that tolerance trades triangle count against how round a curved surface looks at close range. BIM exports arrive already triangulated but organized the way a building is constructed, which means every fitting, fastener and duct segment is a separate object, and a few thousand separate objects is a few thousand draw calls before a single light is placed. The work that follows is mostly merging static objects that never move independently, instancing the parts that repeat, deleting interior detail no camera will ever see, replacing per triangle collision with simple primitives, and generating levels of detail.
The data side connects to something else entirely. A twin scene consumes an endpoint your systems already expose, usually HTTP for polling or a WebSocket for push, and not the equipment itself. In most projects a separate service collects, normalizes and serves the values, and the scene is one more client of it. The part that decides success is identifier mapping: each value has to resolve to a named object in the scene. If the operational system and the 3D model do not already share stable IDs, budget for building that mapping and for maintaining it as both sides change.
- Unit scale. CAD is commonly authored in millimeters and Unreal works in centimeters, so an unconverted import is off by a factor of ten and physics behaves accordingly.
- Up axis. Z up and Y up conventions differ between tools. A whole model rotated ninety degrees is easy to correct; a rig authored against the wrong axis is not.
- World origin. Site models exported in survey or map coordinates place geometry kilometers from the origin, where floating point precision shows up as z-fighting and jitter. Rebase to a local origin at import.
- Part names and attributes. These are the only handle a value from an operational system has for finding its object, and they are the first thing a mesh merge destroys.
Multiplayer Is an Architecture Decision
Unreal's networking model is server authoritative. The server owns world state, clients receive replicated properties and remote procedure calls, and any decision you do not want a modified or lagging client to make has to execute on the server. Movement is the one system that arrives with client prediction and server correction already built, through the character movement component; every other system you want predicted, you write yourself. Converting a finished single player project to multiplayer is not a feature addition, it is a rewrite of the gameplay layer, because state that lived in local variables becomes replicated state and code that ran once has to be split into authoritative logic and cosmetic client side effects.
A dedicated server is a separate build target. It is cooked without rendering, it runs headless, and somebody has to host it: processes to keep alive, a UDP port to open (7777 is the engine default), sessions to create and find, and capacity that scales with concurrent sessions. A listen server, where one participant's machine hosts, removes all of that and is often the honest answer for a training exercise with six people on the same network, at the cost of the session ending when the host leaves. Decide which one applies before the session and matchmaking layer is built, because they are not the same code.
Replication cost scales with the number of replicated actors and how often each one updates, not with how interesting the data is. A twin scene with thousands of live objects will saturate a connection long before it troubles the GPU if every object replicates at the default rate, so relevancy, dormancy and update frequency become content decisions rather than engine settings.
Cook Times, Shader Permutations, and Which Hitch You Have
Cooking is the step that converts editor assets into the packaged, platform specific form the shipped application loads, and shader compilation is what makes it slow. Unreal compiles a shader for each combination of material features, quality level, vertex factory and platform, so a material with several static switches expands into hundreds or thousands of permutations, and an edit to a widely used parent material invalidates every child. Iterative cooks reuse previous output only while the target and the settings hold still. Change a project wide rendering setting, a platform target, or the engine version and the next cook is a full one.
Runtime hitching has two common causes that look identical to a stakeholder and need opposite fixes. The first is pipeline state creation: the first time a particular combination of shaders and render state is drawn, the driver builds and compiles it, and the frame stalls. The second is content loading, an asset streamed in or a level chunk resolved on the game thread. The diagnostic is repetition. A pipeline hitch happens once per unique state per install and is gone when you walk the same path a second time in the same session, while a loading hitch returns every time you enter the area. The first is fixed by collecting a pipeline cache from real playthroughs and shipping it with the build. The second is fixed by asset budgets and asynchronous loading. Treating the second as the first, by adding more precaching, produces no improvement.
What Has to Be Decided Before Content Production Starts
The machines an enterprise audience actually has are often not the machines the project assumed. Issued laptops frequently have integrated graphics only. Remote and virtual desktop sessions are common in the same environments, and in those the application gets no usable GPU at all and falls back to a software path that will not hold an interactive frame rate regardless of what the content does. Locked down environments add a separate obstacle: application allowlisting refuses an unsigned executable outright, so code signing, an installer the desktop team can deploy without a person clicking through it, and an allowlisting request all sit inside project scope rather than after delivery.
Get those constraints in writing from whoever administers the fleet rather than from the project sponsor. The sponsor's own laptop is usually not representative, and the answer to "can we install software" is frequently different from the answer to "can we install unsigned software that needs the GPU".
- The target machine specification, plus access to one for regular testing.
- The distribution route and who holds the code signing certificate: an installer the desktop team deploys, a managed software catalog, a storefront, or a hosted stream.
- Whether the source CAD, BIM or purchased 3D assets may be modified and redistributed inside a compiled application. Marketplace licenses commonly permit use in a compiled product while prohibiting redistribution of the source files, which matters if the deliverable includes the project.
- A named approver for look and content, and the review format. A stakeholder without a machine that can run the build reviews recorded video, and that changes what you can reasonably ask them to sign off on.
- For anything reading live data, a credentialed test endpoint with representative payloads, available while the scene is being built rather than at integration.
Frequently Asked Questions
Which version of Unreal should a new project start on?
The newest version that every dependency the project needs already supports, which is often one or two releases behind the current one. Third party plugins that ship C++ have to be compiled against a specific engine version, and a plugin distributed without source cannot move forward until its vendor moves it. Verify this by building a throwaway project with the real plugin set rather than by reading compatibility tables. Once content production starts, a version change is a scheduled piece of work with its own testing pass.
Can an existing Unity project be moved to Unreal?
The art moves, the project does not. Meshes, textures, animation and audio transfer through FBX and standard image formats, though materials generally have to be rebuilt because shader graphs and material inputs do not map one to one between the two engines. Scripts, prefabs, scene setup, animation state machines, UI and physics tuning are written again. Scope it as a new build that reuses an existing art library, not as a conversion.
Does Unreal work for VR projects?
Yes for PC tethered headsets, with a rendering setup that differs from a flat screen project. VR work usually runs the forward renderer with MSAA instead of the deferred renderer with temporal antialiasing, because temporal methods smear during head motion and several deferred features are expensive or unavailable in stereo. The frame budget is the constraint that decides content: 90 Hz leaves roughly 11 milliseconds to draw both eyes, and instanced stereo reduces the cost of the second eye without making it free. The standalone headset case is addressed above.
What should a digital twin scene do when its data source stops responding?
Something visible, and the default behavior of holding the last value received is the one to avoid, because an operator cannot tell a steady reading from a frozen one. Timestamp values at the source, set a staleness threshold per signal, and render unknown as visually distinct from both normal and alarm states. A push connection also needs reconnect with backoff and a way to request current state on reconnect, since a change feed only reports what happened while you were listening. Keeping credentials and network reach in a service behind the scene rather than in the client application also means an outage is a service problem instead of a secret distributed to every installed copy.
How does a finished Unreal application get delivered and installed?
As a packaged build for a specific platform: an executable plus packed content files, normally wrapped in an installer. The editor does not need to be present on the machine that runs it, and the project source is not part of what gets installed. Expect the install to be large, since packaged high fidelity content is measured in gigabytes rather than megabytes, and expect the first launch on a given machine to be slower while the driver builds its pipeline caches. GPU driver version belongs in the stated requirements alongside the card itself, because an old driver can fail on shaders a current build expects.
Can an Unreal application run in a web browser?
Not as a direct export. HTML5 support was removed from the shipped engine years ago and left to community maintenance, so there is no supported browser target comparable to Unity's WebGL builds. The browser route is pixel streaming, where the application runs on a GPU server and sends encoded video to the browser over WebRTC with input traveling back the other way. That gives a low powered client the full render, at the cost of a GPU slice per concurrent viewer, streaming infrastructure to operate, and network latency added to every interaction, which suits a handful of reviewers far better than a public audience.