When a team commits to building interactive installation software, three runtimes cover most of the reasonable options: WebGL (usually via Three.js or Babylon), Unity, and Unreal. All three can produce the same visual output. They differ enormously in what they make easy, what they make hard, and what they cost over the project's life. Here's the honest breakdown.
WebGL / Three.js
Three.js runs in a browser. That's the headline feature and the headline constraint. For a kiosk installation where the software ships as a web app running inside Chrome or Electron, Three.js is remarkably productive. Hiring is easy - web developers are plentiful - and iteration is browser-speed, which is faster than any compiled-runtime option.
The tradeoff is ecosystem depth. Three.js gives you rendering, basic physics, basic post-processing, and raw WebGL access. For anything heavier - cloth sim, advanced shadows, a visual editor, production-quality animations - you're writing it yourself or integrating third-party libraries that may or may not be maintained. For interactive kiosks, data-viz installations, and anything web-delivered, the ceiling is high enough that most projects never hit it. For complex 3D environments with game-engine features, WebGL is the wrong start.
Unity
Unity is the default answer for most interactive installation work that isn't web-delivered. The reasons: enormous talent pool, mature asset ecosystem, reasonable performance on modest hardware, and a well-understood deployment path for Windows and macOS kiosks. The Universal Render Pipeline gets you 80 percent of modern rendering with 20 percent of the work, and the Visual Scripting system means designers can participate without waiting on programmers.
Unity's weaknesses in the installation context are specific. The editor is heavy, which slows iteration. The pricing model has shifted in ways that make long-term deployments uncomfortable. And Unity's asset-pipeline assumptions - build once, run forever - fight projects that need to update content frequently. For a museum exhibit that ships on day one and never changes, Unity is excellent. For an installation that's going to get monthly content drops, the asset pipeline is friction.
Unreal
Unreal is the high-end option. Nanite and Lumen give you film-quality rendering in real-time, the editor is production-grade, and the integration with virtual production tools is the best in the industry. For installations where visual fidelity is the pitch - a themed-attraction set piece, a high-end brand activation, anything that has to compete with cinema - Unreal is the tool to reach for.
The cost is hardware and team. Unreal wants a real GPU, which rules out a lot of lightweight kiosk hardware. Blueprints are powerful but have a steep learning curve. And the iteration speed is slower than Unity - builds take longer, the editor wants more RAM. For the installations that justify Unreal's strengths, the tradeoffs are worth it. For the 90 percent of installations that don't, Unity or WebGL is a faster, cheaper answer.
A practical decision tree
- Browser-deliverable, 2D-or-light-3D, data-viz, or kiosk work: Three.js or Babylon.
- Desktop-deployed interactive with a team you can hire, moderate 3D needs, long-running: Unity.
- High-fidelity 3D, realism is the pitch, virtual production integration needed: Unreal.
- Long-running installation with frequent content updates: favor web-delivered runtimes because the content pipeline is simpler.
- Sensor-heavy interactive with complex hardware I/O: consider TouchDesigner instead of all three, then only use a game engine if TD can't solve it.
Pick the runtime that matches the team, not the runtime that matches the demo reel. A team that's productive in a lesser tool will out-ship a team that's learning a better one.
Switching costs are real
Changing runtimes mid-project is expensive. Changing runtimes between projects is normal, but comes with six to twelve weeks of team ramp-up. Pick deliberately at the start, budget for the learning curve, and give teams time to build competence in one runtime before moving them to another.
