PlayCanvas Model Viewer: a glTF viewer you can drop a scene into

Drop a file in, or point a URL at it

The core of the viewer is that it loads any glTF 2.0 scene, and the README claims it is blazingly fast and 100% compliant with the glTF 2.0 spec. There is a live version at playcanvas.com/model-viewer, and the homepage is playcanvas.com/viewer. The interaction model is the browser's own. Embedded glTF and binary glTF can be dragged directly into the 3D view, and to load an unpacked glTF scene you drag its parent folder into the 3D view, which is the detail that matters for anyone with a folder of assets and no desire to zip it. The same drag and drop handles background images, where a single file is treated as an equirectangular projection in PNG, JPG or HDR, with the README pointing at HDRHaven for high quality sources, and six images are treated as cube map faces following one of five naming conventions such as name_posx.png. For a developer, the appeal is that no upload, no account and no import pipeline stands between an asset and a picture of it.

URL parameters that make a link to an asset shareable

Two query parameters are documented, and both exist to make a specific view reproducible. The load or assetUrl parameter specifies the URL of a glTF scene to load, and cameraPosition overrides the initial camera position, with the example given as 0,0,20. The README's own example links a DamagedHelmet glTF binary from the Khronos glTF sample models, combined with the camera position, which is a compact illustration of the two working together. The practical use is a documentation page or an issue report where the link should show a particular model from a particular angle, and the viewer should open there. The set is small, and the README does not document parameters for lighting, environment or background, so anything beyond asset and camera is a matter of the viewer's own interface rather than the URL.

The build is Vite and esbuild, nothing exotic

Building from source needs Node.js v22.22 or later, and two commands:

npm install
npm run build

That invokes Vite and esbuild and outputs the built viewer to the dist folder. To rebuild on saving any source file, the README gives npm run watch. The package manifest confirms the toolchain, with vite at 7.3.5 and esbuild at 0.28.1, and it shows a script layout that separates concerns: fmt and fmt:fix run prettier over src and the config files, lint and lint:fix run eslint over the same set, and develop runs a debug build and the dev server together with concurrently and cross-env setting BUILD_TYPE=debug. The repository top level matches a front-end project with no backend: src, static, lib, a vite.config.mjs, an eslint.config.mjs, a prettier.config.mjs, a renovate.json for dependency updates and a tsconfig.json. The package is published as @playcanvas/model-viewer at version 5.10.0 with the MIT licence.

Running it locally, and the CORS note for local models

Two run modes, and the difference matters if you are loading assets from disk. The How to run section says to run npm run serve and then open a browser and navigate to http://localhost:3000. The Development section says to run npm run develop and navigate to the same address. The interesting detail is the note attached to development mode: to load local models, run npx server --cors in the directory containing the model, which disables CORS. Without that, a model served from a different local origin is blocked by the browser rather than by the viewer, and the symptom is a blank 3D view with an error in the console. The serve package at version 14.2.6 is a development dependency precisely for this. For anyone about to spend an afternoon on a blank canvas, that one note is the answer, and it is worth reading the CORS message rather than assuming the asset is malformed.

The viewer sits on three PlayCanvas libraries

The Model Viewer is built on three open source libraries, and the README is explicit about what each one does. The PlayCanvas Engine powers the Editor's 3D View and the Launch Page, meaning the engine is not just a dependency of the viewer but the thing that gives the viewer and the rest of the PlayCanvas product suite a shared renderer. Observer provides data binding and history, PCUI is the front-end component library, and all three are PlayCanvas projects, so the viewer is a consumer of the company's own stack rather than a third-party assembly. The manifest pins observer at 1.7.1, pcui at 5.8.0 and the engine package playcanvas at 2.19.7, alongside React 19.2.7 and react-dom, TypeScript 5.9.3, sass-embedded for styling and qrious. That combination is the honest description of the project: a React application on the PlayCanvas engine, with the viewer UI built from PCUI components and state bound through Observer.

Testing against local builds of the engine

The README documents a specific workflow for integration testing, and it is the part that tells you this is a component of a larger product rather than a standalone app. To test the integration of these libraries you use npm link. You create a global link from source by changing into the library directory and running npm link, then create a link to that global link by changing into model-viewer and running npm link with the library name. The result is that a local checkout of the engine, Observer or PCUI can be dropped into the viewer without publishing a release, which is how the PlayCanvas team develops the engine and the site together. For an outside adopter this matters less directly, but it explains a design choice visible in the code: the viewer is a thin shell over the engine with no engine code inlined, so the engine version is a dependency decision rather than a fork decision.

What the documentation does not settle

Two gaps are worth naming. The first is the split between the repository description, which calls the project a 3D Model Viewer supporting glTF and 3D Gaussian Splats, and the README, which documents only the glTF 2.0 path in detail. The topics list does include 3d-gaussian-splatting and gaussian-splatting, so the format is in scope for the project, but the loading instructions in the documentation available here cover glTF and GLB, so anyone with a splat scene should verify the workflow in the running viewer rather than assume the drag-and-drop path behaves the same. The second is the maintenance picture. The releases are v5.10.0 on 2026-06-16, v5.9.0 on 2026-02-16 and v5.8.1 on 2026-01-21, and the last push to the repository was on 2026-08-13, so the source tree sits behind the newest tag by a couple of months, which is normal for a repository with a release-please style of tagging. Neither gap is a reason to avoid the project; both are reasons to pin a version and check the running viewer.

Editorial conclusion

The PlayCanvas Model Viewer suits a team that needs a trustworthy glTF 2.0 preview page without writing one, and for asset review, documentation and marketing pages the drag-and-drop workflow plus the load and cameraPosition URL parameters cover most of what is needed. It is the wrong tool if you need to author or edit 3D content, since the viewer loads and displays rather than authoring, and it is the wrong tool for a product page that needs a custom camera rig, annotations or analytics, because you would end up writing that in the PlayCanvas Engine rather than here. Verify first that the asset you care about is a plain glTF 2.0 scene, since the repository description also mentions 3D Gaussian Splats while the README documentation here only describes the glTF path, and note that the last push was on 2026-08-13 with the newest release v5.10.0 from 2026-06-16.

Frequently asked questions

Official sources

1. License: MIT
2. playcanvas/model-viewer on GitHub
3. Project website
4. README
5. Releases