WebGL2 and WebGPU live in one 3,044-file engine
PlayCanvas Engine is an MIT-licensed browser runtime for games, interactive product pages, visualizations, and XR. The project README puts WebGL2 and WebGPU behind the same engine and includes WebXR, animation, input, positional audio, and an Ammo.js physics integration. Its asset layer understands glTF 2.0 plus Draco and Basis compression. Gaussian splat rendering is part of the stated feature set rather than an external demo.
The engine can stand alone. An application imports the playcanvas npm package, creates a canvas and an Application, then builds a scene from entities and components. PlayCanvas also maintains a React renderer, web components, a scaffolding command, and a separate browser Editor. That separation matters: a JavaScript team can use the runtime without moving its whole production process into a hosted visual tool, while an art-heavy team can evaluate the Editor as another part of the stack.
Node.js 18+ gets a cube running before production work starts
The documented floor is Node.js 18, and the shortest start is one npm install plus the spinning-cube example. Engine contributors have separate build and documentation commands. The standalone engine manual is the more useful route once the cube is no longer enough, because a real project needs a bundler choice, asset organization, resize handling, loading states, and deployment rules. No PlayCanvas credential is required for the standalone npm path.
Browser delivery moves performance work into your project. glTF 2.0 and compressed textures can reduce transfers, but artists still need budgets for geometry, materials, texture resolution, and shader cost. WebXR requires compatible browsers and devices. Ammo adds another runtime and its own teardown concerns. The engine gives teams the relevant systems; it cannot decide how a scene should degrade on a weak phone or what happens when WebGPU is unavailable.
What happened when we ran it
Our sandbox installed 598 npm packages in 24 seconds, leaving 294 MB on disk. The full build succeeded in 43 seconds. Those are reasonable contributor setup results for a repository containing 3,044 files and about 422,452 lines of source, though the 525.2 MB checkout itself is a substantial download before npm adds its dependency tree. The scan found 7 CI workflow files and a tests directory, but no Dockerfile.
Tests failed with exit code 1 after 6 seconds. Mocha raised ERR_REQUIRE_ESM while html-encoding-sniffer used require() on @exodus/bytes/encoding-lite.js, which Node treated as an ES module. The stack continued through jsdom and Mocha's ESM loader. No project assertion summary appeared, so it would be wrong to describe any engine tests as passing or failing. The result only establishes that the supplied test command did not start cleanly in our Node 22 container.
Npm audit reported 0 known vulnerabilities across all 598 installed packages: 0 critical, high, moderate, or low findings. That is useful evidence for commit 1180f57, not a promise about future dependency resolution. A team evaluating the checkout should reproduce the same install with its lockfile and Node version, then require the complete suite to reach assertions before accepting a dependency update.
Ammo teardown has a specific open memory report
Open issue 9279 describes an app lifecycle that deserves attention in single-page sites. The reporter created and destroyed an Ammo-backed application 200 times and measured roughly 1.1 MB of retained memory per cycle. Their investigation says an Emscripten function-table callback keeps the JavaScript application graph reachable after app.destroy(). The issue also says the older Ammo path without that callback was not affected.
That report does not prove every PlayCanvas application leaks, and it is separate from our sandbox measurements. It does identify a poor fit today: pages that swap many 3D experiences by repeatedly destroying the engine while using Ammo. Test that lifecycle with the exact Ammo build and browser you ship. A single long-lived application or a project without Ammo has a different risk profile, but teardown still deserves a regression test before release.
v2.22.2 arrived three days before this review
GitHub recorded 16,777 stars and 496 open issues and pull requests on September 14, 2026. A separate issue-only query returned 463 open issues, with new reports and proposals updated during September. The repository was pushed the same day. Release v2.22.2 shipped on September 11 with 2 listed material and shadow fixes. These dates show active maintenance, while the queue shows that adopters should search known problems around their chosen subsystems.
Compatibility work is also visible. Issue 9086 tracks deprecated aliases, helpers, and side-effect imports that still need decisions before the old module can be removed. Existing applications should read release notes and budget migration checks instead of pinning indefinitely. For a new browser-first 3D product, PlayCanvas earns a prototype beside Three.js and Babylon.js. The deciding evidence should be scene performance, tool fit, and a passing test setup on the Node version your team supports.