3DTilesRendererJS: rendering 3D Tiles in three.js, Babylon.js and r3f

What 3DTilesRendererJS is for, and who it is aimed at

3D Tiles is a streaming format for large geospatial scenes: a tileset is a tree of tiles with bounding volumes, geometric error values and content references, so a client can load coarse geometry first and refine as the camera moves. The format was specified by Cesium, and the reference implementation lives in CesiumJS, which brings its own scene, camera and globe abstractions. 3DTilesRendererJS takes the other path. It renders 3D Tiles inside a scene graph you already own, and the README states that it supports both Three.js and Babylon.js, with a third entry point for react-three-fiber. That is the whole pitch. If your application is a three.js viewer with your own camera controls, lighting and post-processing, this package adds tileset traversal and tile loading to it instead of asking you to move into a different engine. The audience is therefore narrow and specific: web developers who already ship three.js or Babylon.js applications and need to display b3dm, glTF-backed tiles, terrain or point cloud tilesets on a globe or a local site. The repository topics list b3dm, gltf, terrain, tileset and gis, which matches that reading. A team with no existing renderer investment gets less from it, because they would be adopting three.js or Babylon.js at the same time.

How the renderer, the plugin layer and the three engine entry points fit together

The package is published as one npm package with several subpath exports rather than as separate packages. The package.json maps 3d-tiles-renderer/core, 3d-tiles-renderer/three, 3d-tiles-renderer/babylonjs and 3d-tiles-renderer/r3f to separate build files, each with its own type declarations under src/. The core entry holds the engine-agnostic parts, and the three and babylonjs entries adapt them to a specific scene graph. Plugins are split the same way: 3d-tiles-renderer/core/plugins, 3d-tiles-renderer/three/plugins and 3d-tiles-renderer/babylonjs/plugins. That layout tells you where to look when something breaks. A tileset traversal bug belongs in core; a material or texture problem belongs in the three or babylonjs renderer; an imagery overlay or point cloud format problem belongs in the plugin entry for your engine. The examples in the README are organised along the same seam. Core examples cover multiple tilesets, a Kitchen Sink page with all options, and VR. External provider examples cover Cesium Ion, Google Photorealistic Tiles and PLATEAU city data over Cesium World Terrain, and the README notes those require a Google Tiles API Key or a Cesium Ion API Key. Customisation examples cover custom materials, offscreen shadows and texture overlays. The plugin examples are the longest list: metadata, tile LoD fade transition, Deep Zoom images, Potree point clouds, TMS and XYZ map tiles, WMTS, WMS, quantized mesh overlays, load regions, GeoJSON overlays, and Mapbox Vector Tiles via PMTiles. Each of those is a plugin, not a core capability, which means you opt into the formats you actually serve.

Installing 3DTilesRendererJS and loading a tileset from three.js

The README gives one installation command and it is the same for every engine entry point, because they all ship in the same package. Run it in your project directory and the package is added to your dependencies.

npm install 3d-tiles-renderer --save

After that, the subpath exports decide what you import. A three.js application imports from 3d-tiles-renderer/three, and the README points at USAGE.md and src/three/renderer/API.md for the setup details. The package is type: module with sideEffects set to false, so imports are ESM and tree-shakeable in a bundler that understands the exports map. The repository ships example/three/ and example/r3f/ directories alongside the published source, and the npm start script runs vite against vite.config.js, which builds and serves those examples locally. That is the fastest way to see a working configuration before writing your own: start the dev server, open the Mars example, then read the corresponding file in example/three/ to see which objects are constructed and in what order. The README does not spell out the constructor sequence in the installation section itself, so treat USAGE.md and the API reference as the authoritative source rather than guessing at method names. If a tileset or geometry does not load or render properly, the README asks you to open an issue and notes that example data is needed to add and test features, which is a practical hint: a bug report with a small public tileset is more likely to move than one without.

Plugins are where the format coverage actually lives

Reading the README table carefully, the plugin list is longer than the core feature list. Point clouds in Potree format, Deep Zoom images, TMS and XYZ raster tiles, WMTS, WMS, quantized mesh terrain with overlays, GeoJSON, and Mapbox Vector Tiles through PMTiles are all plugin entries. That is a deliberate design choice: the renderer core stays close to the 3D Tiles specification, and everything that is a different format wrapped into a tile pipeline sits behind a plugin boundary. The practical consequence is that your dependency surface is your problem. If you need WMTS imagery draped over terrain, you import from 3d-tiles-renderer/three/plugins and you inherit whatever that plugin pulls in. If you only serve b3dm and glTF tiles, you never touch the plugin entry and your bundle stays smaller. The plugin guide for three.js lives at src/three/plugins/README.md, with a separate API reference at src/three/plugins/API.md, and the README also links a community plugins section under src/three/plugins for plugins maintained outside the repository. Community plugins are a different maintenance story from the ones in src/, and the README does not make promises about them. Check whether the plugin you need is in the repository or in the community list before you plan around it.

The hard cache cap and other gotchas the README flags

The README has a Gotchas section, and its first bullet is that cache limits are a hard cap. That is a real constraint with a real failure mode: when the tile cache is full, the renderer cannot keep everything the camera has visited, and tiles are evicted. On a slow connection or a fast camera path, that shows up as tiles being requested again after they were dropped, which looks like stutter rather than a loading error. The README does not document a rollback or downgrade procedure, and it does not give a migration path between minor versions in the excerpt available; the CHANGELOG.md file at the repository root is where release-to-release changes are recorded, so read it before bumping. The second limitation is stated plainly in the introduction: the renderer supports most of the 3D Tiles spec features with a few exceptions, and the README links a Feature Complete Milestone for information on which features are not yet implemented. That milestone is the honest answer to whether a given tileset will render. If your pipeline uses a spec feature outside the implemented set, the renderer is the wrong tool, and no amount of configuration will fix it. The third constraint is external: the Cesium Ion, Google Photorealistic and PLATEAU examples require a Google Tiles API Key or a Cesium Ion API Key, so those paths carry a third-party account and its terms on top of the Apache-2.0 licence of this package.

CesiumJS, iTowns and Giro3D: what changes when you pick this renderer

The obvious alternative is CesiumJS, the reference implementation of 3D Tiles. The difference is architectural, not cosmetic. CesiumJS owns the scene, the camera, the globe and the tile scheduling, and you extend it through its own APIs. 3DTilesRendererJS owns none of that. It plugs tileset traversal and tile loading into a three.js or Babylon.js scene you built, so your camera controls, materials, shadows and render loop stay yours. If you want a globe with a fixed set of controls and you do not care which engine draws it, CesiumJS removes a layer of work. If you have an existing three.js application and a globe is one panel inside it, CesiumJS means running two renderers. The README's community resources list names other frameworks in the same space: iTowns, described as a framework for visualising and interacting with 2D and 3D geospatial data on the web, and Giro3D, described as a framework for heterogeneous geospatial data across 2D, 2.5D and 3D. Both are frameworks rather than renderers, so they make the same trade as CesiumJS in the opposite direction from this package. The README also lists integrations that show the intended shape of adoption: three-geospatial for clouds and atmosphere alongside this renderer, an official MapLibre example that syncs a three.js layer, a threepipe plugin, the 3DBAG viewer for Dutch building data, and official Babylon.js documentation for loading 3D Tiles.

Maintenance, licence and what upgrading costs you

The repository is not archived, and the last push was on 2026-09-28, so the project is being worked on. The release cadence visible in the recent releases supports that: v0.5.1 on 2026-08-07, v0.5.2 on 2026-08-24, and v0.5.3 on 2026-09-18. Those are patch releases at roughly two to four week intervals, which suggests incremental fixes rather than long quiet stretches, though the release notes do not describe what each release changed. The version number is still 0.x, and the package.json ships type: module with an exports map that includes a ./src/* passthrough, which means the public surface includes paths under src/ that are not covered by a semver-stable entry point. Importing through 3d-tiles-renderer/three rather than reaching into src/three/... is the safer habit, because the subpath exports are the documented interface. The licence is Apache-2.0, which permits commercial and closed-source use and includes an explicit patent grant; the LICENSE file is at the repository root. Apache-2.0 also requires that you keep the licence and notice files when you redistribute, and it does not grant trademark rights, so the NASA name and the project name are not yours to use in a product. That is a description of the licence text, not legal advice; route the specifics through your own counsel. Upgrade cost is dominated by the plugin boundary: a renderer change in core can ripple into three and babylonjs adapters, so a minor bump is worth testing against the tilesets you actually serve rather than only against the examples.

Editorial conclusion

Adopt it if you are already building a three.js, Babylon.js or r3f scene and want 3D Tiles content inside that scene graph rather than a separate geospatial engine. Do not adopt it if your project needs the full 3D Tiles specification today, since the README points at a Feature Complete Milestone for what is still missing, and do not adopt it expecting rollback or downgrade instructions the README does not document. Verify first that your tileset loads in the Kitchen Sink example, that your cache budget matches the hard cap described in the Gotchas, and that you can read the source in src/three/renderer/API.md when a plugin misbehaves.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. NASA-AMMOS/3DTilesRendererJS on GitHub
3. Project website
4. README
5. Releases