Running UE 5.8 Natively in the Browser via WebAssembly & WebGPU (Game Animation Sample)

Community Showcase
, , ,
1

Hey everyone,

Ever since the official HTML5 export pipeline was deprecated back in the UE4 era, the default path for bringing Unreal Engine projects to the web has been cloud Pixel Streaming.

While Pixel Streaming has its place for high-end enterprise showcases, it treats the browser strictly as a video receiver. Over the past year, we have been working on the alternative: compiling the modern Unreal Engine runtime directly to WebAssembly and WebGPU to execute locally on client hardware.

To prove this isn’t limited to static architectural walk-throughs or simplified mobile scenes, we targeted Epic’s official UE 5.8 Game Animation Sample.

Here is what is executing live inside a standard browser tab (desktop and mobile) with zero downloads, zero installers, and zero cloud GPU fees:

The Benchmark: UE 5.8 Game Animation Sample

We specifically chose the 5.8 Animation Sample because it serves as an aggressive stress test of modern gameplay and character animation systems:

  • Dense Motion Matching & Pose Search: Locomotion is entirely trajectory-driven. The runtime continuously queries an indexed database of 500+ animations to choose poses dynamically each frame, rather than relying on traditional state machine blends.
  • Physics Control & Powered Ragdolls: Uses the Physics Control Component with angular and linear joint motors. Characters dynamically absorb physical impacts, ragdoll across obstacle courses, and transition back into motion-matched get-up recoveries based on resting pose analysis.
  • Synchronized Multi-Character Combat: Real-time multi-actor combat logic—including directional tackles, shoves, Spartan kicks, and takedowns—where collision geometry, animation states, and physical reactions resolve synchronously on the same frame.
  • Full Interactive Gameplay Loop: Input handling, camera rigs, character traversal, and StateTree logic all operate in real time inside the browser.

Technical Architecture: Multi-Threaded WASM & WebGPU RHI

Running a production 5.8 gameplay stack in a browser sandbox required solving two coupled bottlenecks: CPU vectorization/threading and browser-side memory churn.

  • SIMD & Worker Threading: Core engine systems, math libraries, and Chaos physics compile to multi-threaded WebAssembly. We leverage -msimd128 autovectorization to ensure skeletal matrix transformations, blend stacks, and quaternion math do not fall back to scalar software emulation. Worker pools are pre-allocated using Pthreads over SharedArrayBuffer with crossOriginIsolated headers, enabling the engine’s TaskGraph to distribute eligible animation and physics workloads across browser web workers.
  • WebGPU RHI & Eliminating V8 GC Hitches: In early builds, dynamically creating transient bind groups (device.createBindGroup()) each frame flooded the JavaScript heap with wrapper objects, triggering destructive ~100 ms V8 Major Garbage Collection freezes. By implementing strict descriptor hashing, bind group/pipeline caching, and decoupling buffer data updates from resource bindings, the JS heap is locked into a flat, predictable plateau, eliminating GC hitches.

Non-Gaming Hardware Telemetry (Lenovo i5 Ultrabook)

While high-end dedicated GPUs (like desktop/laptop RTX cards) easily sustain a locked 60 FPS in this build, validating that the pipeline can run deterministically on low-power, non-gaming hardware without crashing or leaking memory was the critical milestone.

Below is the live runtime telemetry recorded on a standard Lenovo laptop powered by a 15W 12th Gen Intel Core i5-1235U with integrated Intel Iris Xe graphics (16 GB RAM) running at a native 1080p canvas:

  • Adapter: Intel(R) Iris(R) Xe Graphics (gen-12lp 0x46a8)
  • Canvas Resolution: 1920×1011 (DPR 1.00)
  • JavaScript Heap Memory: Held completely flat between 371 MB and 385 MB (zero runaway allocations or GC hitches)
  • WASM Linear Memory: 1,191.8 MiB capacity
  • Tracked GPU Resident Memory: ~399.8 MiB resident (~376 MiB textures, ~23 MiB buffers)
  • Render Load: 180–370 encoded draw calls, 400k–650k direct triangles, 10 compute dispatches
  • Stability: 0 Validation Errors | 0 Device Loss | 0 Out-Of-Memory (OOM) events

Cross-Platform & Mobile Execution

Because WebGPU and WebAssembly are cross-platform web standards, this exact same architecture is not locked to desktop browsers. It scales directly to mobile devices (modern Android and iOS browsers supporting WebGPU), allowing the full character, locomotion, and physics pipeline to execute locally on phones and tablets without going through native app stores.

What Native Browser Gameplay Unlocks

Compiling Unreal Engine gameplay directly to a web link removes distribution barriers across several studio workflows:

  • Instant Playable Demos: Distribute playable vertical slices to publishers, investors, or players via a single URL—bypassing multi-gigabyte downloads, Steam keys, and OS installer warnings.
  • Playable Web Marketing: Replace passive video trailers on landing pages with real combat and traversal mechanics executing live on user hardware.
  • Frictionless Community Playtesting: Drop playable builds directly into Discord channels, forums, or social feeds for instant feedback.

Discussion & Technical Feedback

While running the Game Animation Sample proves the viability of modern character stacks on the web, taking production-scale games to WebGPU comes with clear challenges—sprawling asset streaming budgets, custom third-party plugins, complex compute shaders, and optimizing CPU thread allocation across low-power efficiency cores and mobile chips.

We’d love to hear from other technical directors, engine programmers, and animators. Looking forward to your thoughts.