# supersplat-viewer: a browser viewer for 3D Gaussian splats > The official SuperSplat viewer is a self-contained static site that loads splat scenes in the browser, and its configuration lives almost entirely in URL parameters, which makes it easy to share a view and easy to depend on a surface the project warns can change. **playcanvas/supersplat-viewer** — User-friendly, high-performance viewer for 3D Gaussian splats - Repository: https://github.com/playcanvas/supersplat-viewer - Website: https://superspl.at - Stars: 603 · Forks: 161 - Language: TypeScript - License: MIT - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/playcanvas-supersplat-viewer ## A viewer that ships as a static site SuperSplat Viewer is the official viewer for SuperSplat, and the repository description calls it a user-friendly, high-performance viewer for 3D Gaussian splats. The hosted instance lives at superspl.at, and the documentation links to the PlayCanvas user manual for the import and export workflow, along with the project blog and forum. The deployment model is the first thing to understand. The web app compiles to a simple, self-contained static website. There is no server component described here, no account system and no backend to deploy. The result is a directory of files you can serve from anything that can return bytes over HTTP, including a static host, a bucket, or a local server while you work. The code is TypeScript, published to npm as @playcanvas/supersplat-viewer, with a version that matches the release tag, currently 1.37.0. The engine underneath is PlayCanvas itself, and the package declares the engine as an optional peer dependency at ^2.23.0, which is the detail that decides whether you can embed the viewer inside an existing PlayCanvas application or must ship the engine with it. The audience is threefold: a person who captured a scene and wants to look at it, a team sharing a view of a scan with a colleague, and a developer who wants to drop a splat renderer into a web application without implementing one. ## URL parameters are the whole configuration surface The viewer is configured through query string parameters, and the documentation is upfront that these are subject to change. That single caveat shapes how you should use the tool. The content parameters decide what is loaded. The settings parameter points at a settings.json file, the content parameter at the scene file, and the accepted scene formats are .ply, .sog, .compressed.ply, .meta.json and .lod-meta.json, with a default of ./scene.compressed.ply. A skybox parameter takes an equirectangular image, a poster parameter takes an image shown while the scene loads, and a collision parameter takes a collision asset, either a .glb mesh or voxel data, with voxel accepted as an alias. The UI parameters control the interface. The noui parameter hides the UI overlay, and the documentation notes that the programmatic equivalent is ui: false, which skips building the overlay rather than hiding it. The reticle parameter shows a centre reticle in captured desktop fly or walk mode and is off by default, noanim starts with animation paused, and ministats turns on runtime CPU and GPU performance graphs. A lang parameter overrides the interface language, with German, English, Spanish, French, Japanese, Korean, Brazilian Portuguese, Russian and Simplified Chinese supported and the browser language used by default. For a team, the practical implication is that a shared link is a real configuration file, and it is also a fragile one. A URL that a colleague opens may behave differently once the parameter set changes. ## WebGPU by default, WebGL for XR, and a stochastic mode that is experimental By default the viewer uses WebGPU when it is available, falling back automatically when it is not, and the webgl parameter forces the WebGL renderer instead. The documentation states that the WebGL renderer is also required for WebXR, AR and VR, so the choice of renderer is tied to whether you want immersive mode at all. On top of that sit a set of renderer flags. The aa parameter enables antialiasing in WebGL only. The stochastic parameter selects an experimental unsorted, depth tested splat renderer, with stochastic meaning per pixel quality and stochastic=mobile aimed at phones and headsets, and it is WebGPU only. Two developer knobs go with it: splatSource chooses the data path feeding the renderer, either direct, which is the default and reads the resident files in place, or workbuffer, which reads the engine work buffer, and variant takes comma separated key:value experiment switches over the mode's own switches, with taaSharp:8 given as an example. The remaining flags are ordinary overrides. nofx disables post effects, hpr overrides the highPrecisionRendering setting from the settings file, budget overrides the splat budget in millions of splats, colorize renders with LOD colorization, and fullload loads all streaming LOD data before the first frame. The heatmap parameter switches on the voxel collision debug overlay and requires WebGPU plus voxel collision data, and it is toggled with the V key or from the settings panel. The debug parameter opens the developer debug panel on load, with Ctrl+Shift+D as the toggle. The interesting line here is that the viewer is also a test harness for the renderer, since the experimental paths are reachable from a URL. ## The npm package exposes four entry points, not one The package is not just a wrapper around the website. Its exports map separates the app from the embeddable pieces, and the documentation points to the API reference for embedding, runtime control, UI customisation and settings. ```json "exports": { ".": { "types": "./dist/index.d.ts", "import": "./dist/index.js" }, "./viewer": { "types": "./dist/viewer.d.ts", "import": "./dist/viewer.js" }, "./viewer.css": "./dist/viewer.css", "./settings": { "types": "./dist/settings.d.ts", "import": "./dist/settings.js" } }, ``` The root entry is the package API, the viewer entry is the viewer itself, the settings entry is the settings module, and the stylesheet is exported on its own so an application can bring its own styling decisions. Two package level details matter for adoption. The playcanvas engine is a peer dependency marked optional, so an application that already loads PlayCanvas does not get a second copy, while a standalone use of the viewer needs the engine supplied some other way. And the files array shows what is actually published: the dist output, three files from the public folder, the API documentation, the licence, the manifest and the readme. The package is an ES module with sideEffects false, which is the shape you want for bundler based applications, since unused exports can be dropped from a build. ## Local development needs Node 20 and three commands The development section is short enough to reproduce, which is a good sign for a project that other engineers will need to patch. ```bash git clone https://github.com/playcanvas/supersplat-viewer.git cd supersplat-viewer npm install npm run develop ``` Node.js 20 or later is the stated requirement. The clone step, the dependency install and the develop script that starts the build and the local web server are the whole sequence, and the browser then opens at http://localhost:3000. The repository layout explains how the project is built and shipped. Rollup is the bundler, with a rollup.config.mjs at the root, the TypeScript compiler configuration is in tsconfig.json, and the source sits in src with tests in test. Formatting and linting are handled by Prettier and ESLint with the PlayCanvas shared configuration, and there is a publint entry in the development dependencies, which is a package quality tool that checks the published manifest for problems. Two automation files are worth noticing. A renovate.json file handles dependency updates, which is how a project with this many dependencies keeps them current without a human editing manifests, and a release.sh script sits at the root next to the configuration, alongside a serve.json file for the local static server. The recent commit activity matches this setup, with the last push to the default branch on 2026-10-20 and version 1.37.0 published on 2026-10-02. ## Where the SuperSplat viewer is the wrong tool There are three clear boundaries. The first is authoring. This is a viewer. It loads a scene and lets you look at it, with settings for the render, the interface and the loading experience. It does not capture a scene, and the import and export workflow that produces the .ply, .sog or .compressed.ply files it consumes lives in the wider SuperSplat tooling documented in the user manual. If your task is producing splats rather than viewing them, this is the wrong repository. The second is the stability of the configuration contract. The documentation states that the URL parameters are subject to change, and they are the primary way to configure a shared view. A team that builds a workflow where a colleague is sent a link, or that writes code that generates those links, is depending on a surface the project explicitly reserves the right to change. The parameters are convenient, not a specification. The third is the renderer split. WebGPU is the default path and WebGL is the fallback, and the experimental stochastic renderer with its splatSource and variant knobs is WebGPU only. If your target devices are headsets or phones where you need the WebGL path, the WebGPU experiments are not available to you, and the antialiasing flag is documented as WebGL only, so the two paths do not have identical feature sets. One more practical limit: the viewer is a static site, so serving large splat scenes means serving large files, and the load time is a property of your hosting rather than of the application. ## MIT licensing and a release line that moves often The licence is MIT, with a LICENSE file at the root of the repository and a licence badge in the documentation, so the code can be used, modified and redistributed inside commercial products with the notice retained, and the package is published to npm under the @playcanvas scope. This is not legal advice, but a permissive licence with an application this small is straightforward to accept. The release history shows a fast cadence. Version 1.36.1 and 1.36.2 were both published on 2026-09-29, minutes apart, and 1.37.0 followed on 2026-10-02. The repository is not archived, and the last push was on 2026-10-20. A 1.x line with patch releases within hours of each other is a project that ships continuously rather than on a schedule. The upgrade cost is therefore mostly about your own pinning. The package version, the release tag and the published manifest are all kept in step, and the dependency updates are automated, so a new patch can bring a new PlayCanvas engine version. If you embed the viewer, the playcanvas peer dependency at ^2.23.0 is the contract to watch, and a viewer upgrade that pulls a newer engine is the change most likely to affect you. For an application that only links to the hosted viewer, the same cadence applies to the parameters rather than to your dependencies, which is the risk to plan for there. ## Conclusion supersplat-viewer is the right tool for inspecting, sharing and embedding a Gaussian splat scene in a browser, and for anyone who wants the renderer's WebGPU path or its experimental stochastic renderer without building a scene from scratch. It is the wrong tool for a pipeline that needs a stable, versioned configuration contract, since the URL parameters are explicitly subject to change, and it is the wrong tool for a team that needs to author splats rather than view them. Before adopting, read the API reference in docs/api.md for the embedding entry points, confirm that the optional playcanvas peer dependency is the version your application already uses, and decide whether the WebGL fallback or the WebGPU path is the one you will support. ## FAQ ### What is the SuperSplat Viewer? It is the official viewer for SuperSplat, described as a user-friendly, high-performance viewer for 3D Gaussian splats, published to npm as @playcanvas/supersplat-viewer. The web app compiles to a simple, self-contained static website, and the hosted instance is at superspl.at. ### Which scene formats can the SuperSplat viewer load? The content URL parameter accepts .ply, .sog, .compressed.ply, .meta.json and .lod-meta.json, with a default of ./scene.compressed.ply. A separate settings parameter points at a settings.json file, and there are also parameters for a skybox image, a poster image and a collision asset. ### Does the SuperSplat viewer support WebXR and AR? The viewer uses WebGPU by default and falls back automatically, and a webgl parameter forces the WebGL renderer, which the documentation says is required for WebXR, AR and VR. The experimental stochastic renderer is WebGPU only, and antialiasing is WebGL only. ### How do I run the SuperSplat viewer locally for development? You need Node.js 20 or later, then clone the repository, run npm install and run npm run develop, and open your browser at http://localhost:3000. The project uses Rollup for bundling, ESLint and Prettier for linting and formatting, and Renovate for dependency updates. ### Can I embed the SuperSplat viewer in my own application? Yes. The npm package exposes separate entry points for the main API, the viewer, the viewer stylesheet and the settings module, and the API reference in docs/api.md covers embedding, runtime control, UI customisation and settings. The playcanvas engine is an optional peer dependency at ^2.23.0. ## Sources - [License: MIT](https://github.com/playcanvas/supersplat-viewer/blob/main/LICENSE) - [playcanvas/supersplat-viewer on GitHub](https://github.com/playcanvas/supersplat-viewer) - [Project website](https://superspl.at) - [README](https://github.com/playcanvas/supersplat-viewer/blob/main/README.md) - [Releases](https://github.com/playcanvas/supersplat-viewer/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/playcanvas-supersplat-viewer