Khronos glTF Sample Viewer: WebGL 2.0 Inspection and Development

Why Khronos Uses This Viewer for glTF 2.0

The repository addresses a specific glTF workflow problem: developers need a common browser interface for seeing how a glTF 2.0 scene and its extensions are interpreted by a physically based renderer. It is aimed at asset authors, extension implementers, WebGL developers, and people who need to separate a file problem from a rendering problem. The README identifies it as the official Khronos glTF 2.0 Sample Viewer and states that it uses WebGL 2.0.

This is more than a minimal model preview. The interface can load assets from the glTF Sample Assets collection, accept local glTF or GLB files through drag and drop, expose lighting and tone mapping controls, and run the integrated glTF-Validator. It also provides switches for extensions, animations, debug channels, and material variants. Those controls make the viewer useful for narrowing down why an asset looks or behaves differently from its expected result.

The project is not a general asset conversion suite. There is no documented pipeline for converting DCC formats into glTF, authoring geometry, or exporting an edited scene. Its scope is inspection and renderer feedback. That boundary matters when selecting it for a content pipeline. A DCC application is the relevant place for editing source scenes; this viewer is the place to examine the resulting glTF behavior in the browser.

WebGL 2.0 Rendering and Extension Processing

The repository layout separates the browser application from the renderer source. At the top level, `main.js`, `index.html`, `src/`, and `rollup.config.js` form the viewer application side of the project. The `glTF-Sample-Renderer/` directory is treated as a separate build component by the npm scripts. `package.json` identifies the package as an ES module JavaScript application and starts from `src/main.js`.

The visible data flow begins when a user chooses a sample or drops a glTF or GLB file into the interface. The viewer then exposes controls for camera movement, environment lighting, tone mapping, animation selection, extensions, material variants, and validation. Camera movement uses mouse-based orbiting, panning, and zooming. A dropped HDR panorama changes the environment map, while URL parameters can select a model and set its initial camera state.

Extension support is a central part of the rendering mechanism rather than an incidental claim. The checked list includes Draco and Meshopt compression, texture transforms, BasisU textures, WebP textures, material extensions for transmission, volume, clearcoat, iridescence, sheen, specular behavior, and IOR, plus animation pointers, lights, instancing, and physics. KHR_physics_rigid_bodies is connected to the Physics tab, which appears only when a loaded file contains that extension. According to the README, that tab supports starting, stopping, resetting, stepping, engine selection, and debug visualization for the simulation.

Not every checked item means every related case works. Dense volumes using KHR_materials_diffuse_transmission are marked supported, while sparse volumes using KHR_materials_transmission are not.

Installing the JavaScript Build from package.json

The package manifest does provide the following build command for a checkout that already has the repository and its submodules in place.

First install the JavaScript dependencies. The root `preinstall` script enters `glTF-Sample-Renderer`, installs that component's dependencies, and builds it.

npm install

After installation, the root build command rebuilds `glTF-Sample-Renderer` and then invokes Rollup for the viewer application with a 4096 MB Node.js heap limit.

npm run build

For a first local viewer session, use the development command defined in `package.json`.

npm run dev

That script runs the renderer watcher, the UI watcher, and an `http-server` process. The server changes into `dist` and listens on port 8000 with caching disabled. A successful local session should make the viewer available through the address served by that command. The README controls then apply: click and drag to rotate, use `shift + drag` or the middle mouse button to pan, and use the scroll wheel or right-button drag to zoom.

The manifest does not specify the Node.js version. It also defines `npm test` only as a failing placeholder with the message `Error: no test specified`. Consequently, the repository copy does not document an automated test command that validates a change.

URL-Controlled Loads and Initial Camera State

The viewer supports reproducible initial states through URL parameters. The documented form appends key-value pairs to the sample viewer URL, and the available parameters cover model selection, interface visibility, camera orientation, and camera distance.

For example, `model` loads a glTF or GLB from a specified URL. `noUI` disables the interface. `yaw` controls the orbit around the Y-axis, while `pitch` controls the orbit around the X-axis and accepts values from -90 to 90. `distance` changes the model size relative to its initial camera position. Positive values make the model smaller, and negative values make it larger according to the README.

A concrete URL shape documented by the project is:

?key=value&another_key=another_value

The documented application controls can be combined in the same parameter style, but the README does not provide a complete example URL containing every key. That omission makes the parameter syntax clearer than the interaction between all supported values. Also note that `model` is documented as a URL rather than as a sample selection name.

This facility is useful for linking a reviewer directly to an asset or standardizing a first camera position. It does not replace the GUI settings: the README separately documents model selection, extension toggles, animation controls, material variants, lighting changes, tone mapping, validation, downloadable renderings, camera-property downloads, and file statistics.

Validation Failures in KHR_accessor_float64 and Volume Data

The clearest technical limitation is WebGL 2.0's lack of 64-bit access for every glTF representation the viewer may encounter. The README marks mesh attributes and skins under KHR_accessor_float64 as unsupported because WebGL 2.0 supports only 32-bit values in the relevant operations. The same extension section nevertheless marks animations and KHR_animation_pointer as supported. This is an important boundary: support for float64 animation data does not imply support for float64 mesh attributes or skins.

Another partial feature is KHR_materials_volume_scatter. The README distinguishes dense volumes using KHR_materials_diffuse_transmission from sparse volumes using KHR_materials_transmission. Dense-volume handling is checked, while sparse-volume handling remains unchecked. A file containing the unsupported branch can therefore be materially different from another file that uses the same broader volume subject.

These limitations make validator output especially relevant. The interface includes the glTF-Validator, but the README does not claim that every validation error will be visually rendered. The correct interpretation is narrower: the viewer exposes validation errors alongside its rendering tools, while some valid glTF constructs remain unsupported by its WebGL 2.0 path.

A project requiring those unsupported mesh, skin, or sparse-volume cases should not adopt this viewer as its only compatibility check.

Published Viewer Versus Local Development Workflow

The repository presents two practical ways to use the project. The first is the published glTF 2.0 Sample Viewer linked from the README. That route requires no local source build and is appropriate when the goal is to inspect an asset through the official browser interface. The second is the source workflow in `package.json`, which separates renderer building, application bundling, watchers, and an HTTP server. That route is more relevant to renderer or UI development, but it also introduces repository setup and build requirements.

The difference is therefore operational rather than a different rendering concept. The published app is the ready-made viewer. The local workflow runs `glTF-Sample-Renderer`, uses Rollup for the application, and serves `dist` on port 8000. It also exposes dedicated commands for rebuilding, watching, linting, and formatting JavaScript.

For code maintenance, the relevant commands are defined in the manifest. Linting checks `src/**/*.js`, `main.js`, `rollup.config.js`, and renderer source files.

npm run lint

The formatting check uses Prettier across the same main source groups.

npm run prettier

These checks do not create functional tests because the `test` script is a deliberate failure placeholder. The release record also needs separate attention. Releases are listed for 2022 and 2023, with `v1.0.10` dated 2023-03-08, while the repository's last push was on 2026-10-16. That distinction matters when deciding whether to rely on a published release or track source changes.

Apache-2.0 Licensing and Upgrade Work

The repository is licensed under Apache-2.0. `LICENSE.md` and `LICENSE_BANNER.txt` are top-level entries. This is a factual licensing classification, not legal advice about a particular distribution or application.

The README also lists extensions maintained or proposed by Khronos and links to external extension repositories or specifications. The top-level `THIRDPARTY.md` file indicates that third-party information is maintained in the repository.

Upgrade effort depends on which entry point an organization uses. A team following the published viewer can consume its current release without rebuilding the JavaScript package. A team working from source must account for changes in the root application, `glTF-Sample-Renderer`, Rollup configuration, extensions, and WebGL 2.0 compatibility. The documented lint and formatting commands cover code quality, but the absence of a real test script means the supplied project files do not establish an automated regression path for renderer changes.

Editorial conclusion

Adopt this project if you need Khronos' official interface for inspecting glTF 2.0 features, extensions, animation controls, rendering settings, and validator output. Do not choose it as proof that every glTF asset will render, because WebGL 2.0 limits the viewer's handling of KHR_accessor_float64 for mesh attributes and skins. Before adopting the local workflow, verify that the incomplete setup instructions in this repository copy still cover your submodules and build prerequisites, then confirm that the published release app or your own `npm run dev` build serves correctly on port 8000.

Frequently asked questions

Official sources

1. Issues
2. KhronosGroup/glTF-Sample-Viewer on GitHub
3. License: Apache-2.0
4. README
5. Releases