3dtiles: a converter for large scale geospatial data, and a repository documenting itself

Two input formats, one output

The feature list is short and the two conversion targets define what this tool is for.

The first is Osgb to 3D-Tiles, converting OpenSceneGraph Binary format into 3D Tiles format. The second is Shapefile to 3D-Tiles, converting Esri Shapefile data. Both are real-world geospatial inputs that Cesium cannot read directly, which is the problem the project exists to solve.

The README frames the tool as a converter toolkit for efficient conversion of large-scale 3D geospatial data, and the word efficient is the consistent claim. The repository description is blunter about it: the fastest tools for 3dtiles convert in the world.

The six repository topics tell you the format vocabulary in use: 3d-tiles, 3dtiles, b3dm, cesium-3dtiles, gltf and osgb. `b3dm` is the batched 3D model tile that earlier Cesium pipelines used, and `gltf` and `osgb` are the two input sides of the conversion. A `glTF 2.0` status badge sits at the top of the README, linking to the KhronosGroup glTF page.

The licence is Apache-2.0, which is a permissive licence and unusual for a tool of this type in the geospatial world.

Three optional optimisations, and only one is a big win

The optimisation features are listed separately from the conversions, which is correct because they are independent flags rather than part of the pipeline.

Mesh optimization is optional mesh simplification using meshoptimizer for reduced polygon count. Draco Compression is optional Google Draco compression for 3D-Tiles geometry size reduction of 3 to 6x. Texture Compression is optional KTX2 texture compression for faster GPU loading.

The three targets different things and the README is precise about which is which. Mesh simplification reduces polygon count, which helps geometry but costs detail. Draco is the headline number, a 3 to 6x reduction in geometry size. KTX2 is explicitly about faster GPU loading rather than file size, which is a different objective: a texture that stays larger but is laid out for the GPU can render faster, and KTX2 is the container format built for that.

So the honest summary is that Draco is the one to turn on by default, mesh simplification is a judgement call about how much detail your data can lose, and KTX2 matters most if you are loading large textures over a network or into a viewer that streams tiles.

Multi-platform support for Linux, macOS and Windows is listed as a feature in its own right, and Docker support for containerized build and deployment appears alongside it.

Releases are made by pushing a tag

There is no build script in the README, because there are no build instructions. What there is instead is a release procedure, which is more informative about the project than instructions would be.

A stable release is two commands:

# Create and push a version tag
git tag v0.5.0
git push origin v0.5.0

Pushing that tag triggers GitHub Actions, and the README lists what happens next: build for all platforms covering Linux, macOS ARM64, macOS x86_64 and Windows, package binaries with version numbers, generate release notes, create a GitHub Release, and upload platform-specific binaries.

Pre-releases use a suffix on the tag, and three forms are given:

# Alpha version
git tag v0.5.0-alpha.1
git push origin v0.5.0-alpha.1

The note that follows is that pre-release versions are automatically marked as Pre-release on GitHub.

This tells you the whole pipeline is CI-driven, which is confirmed by the four workflow badges at the top of the README for linux, windows, macOS-arm64 and macOS-intel. Pre-built binaries for four platforms is a genuinely useful thing to have, and it is the reason to look at releases before building.

One caution: the tagged releases stop well behind the commits. The most recent tag is v0.4 from July 2021, described as updating the logic for encoding gltf from osgb to support multiple primitives in one geometry, updating drawarray encoding, and adding an osgb config with a switch for PBR materials. Before that, v0.3 in September 2018 added realistic lighting for oblique photography, DXT textures, multi-texture support and single-model gltf and glb output, and 0.2 in August 2018 added parsing of coordinate systems in metadata.xml, DXT compressed textures for osgb, thread-pool processing of model data and displayable shapefile output. The last push was on 2026-08-11, so the tags are stale rather than the project being finished.

The README is an index that points at other READMEs

This is the defining quirk of the repository and worth naming directly: the main README contains no usage instructions at all.

Under a Quick Start heading, there are two links and nothing else. README_EN.md is described as a complete build and usage guide in English, and README_ZH.md as the same guide in Chinese. Those are the only paths to actually using the tool.

Everything technical in the main README is about the project's shape rather than its operation: the feature list, the release procedure, and two wiki links, one for how to build and one for how to debug. That is an unusual arrangement, and it means anyone landing on the repository page from a search has to make one more click before learning anything about how to run the converter.

The tree explains why. There is a `README.md`, a `README_EN.md` and a `README_ZH.md`, so documentation is versioned in the repository rather than on a docs site, and a `docs/` directory sits alongside them. There is also a `.devcontainer/` directory and a `Dockerfile` plus `build-dockerfile.sh`, which means there are at least two documented ways to get a build environment.

Two other files in the tree are suggestive of how the author works: a `todo.txt` at the root, and a `matrix.xlsx` spreadsheet, which in this domain is probably a coordinate transform table given that the older release notes mention parsing coordinate systems from metadata.xml.

A Rust driver over a C++ and vcpkg core

The build files show an unusual shape for a C++ project, and one that explains a fair amount about the repository.

There is a `Cargo.toml` and a `build.rs`, so the build driver is Rust even though the repository language is C++. Reading the manifest, the package is named `_3dtile` at version 0.1.0, edition 2021, authored by fanzhenhua. The dependencies are a compact list: libc, clap 4.5.53 for argument parsing, chrono, rayon for parallel work, serde with derive, serde_json, serde-xml-rs for metadata.xml parsing, log with env_logger, and byteorder.

`clap` and `rayon` are the two that tell you something. Clap means the binary has a real command line interface, so the arguments exist even though the README does not document them. Rayon means the converter is parallel, which fits the thread-pool approach the v0.2 release notes mention.

The build dependency list includes `cmake` and `pkg-config`, so Rust shells out to CMake to build a C++ component. Alongside that there is `CMakeLists.txt`, `vcpkg.json`, `vcpkg-configuration.json` and a `thirdparty/` directory, which is the vcpkg C++ dependency system.

The `Dockerfile` shows the same layering from the other direction. It builds on `rust:1.90.0-bookworm`, forces `linux/amd64` with QEMU emulation and disables Rosetta, installs vcpkg from a git clone with its bootstrap script, installs OpenGL related packages, and then runs `cargo build --release -vv` before copying the resulting executable into a `debian:bookworm-slim` runtime image. The OpenGL dependencies, including mesa and X11 libraries, are the requirement that tells you the core is genuinely C++ and graphics-adjacent.

Where the project is healthy and where it is thin

The activity signals are good. Four GitHub Actions workflows cover the four platforms, the repository is not archived, and 2,310 stars with 671 forks indicates a project people actually depend on rather than merely admire. The last push was on 2026-08-11. The Apache-2.0 licence means commercial use is unencumbered, which matters for a tool in the geospatial supply chain.

The thin parts are documentation and versioning. Three releases in five years, with the newest tagged in 2021, means there is no release history to consult when something changes behaviour, and the version in `Cargo.toml` is 0.1.0 regardless of what the binary actually contains. For a converter where output correctness matters, that is the main practical risk.

The related search terms suggest the audience: Cesium 3D Tiles examples, OSGB to 3dtiles, OGC 3D Tiles, 3D Tiles tools and Py3dtiles. The Py3dtiles reference in particular is a fair comparison point, since it is a Python alternative to a C++ converter, and the Rust driver plus rayon here is the performance answer to it.

The README also does not state which 3D Tiles version it targets, which is the specification detail that most affects compatibility. Nothing in the feature list, the release notes or the file tree names a 3D Tiles version, so that question is left to README_EN.md, the wiki, or reading the output.

Editorial conclusion

3dtiles is most useful if your data arrives as OSGB or shapefile, which is the situation in most Chinese geospatial workflows, and less useful if you already have glTF. The compression options are the part worth knowing, since Draco is described as a 3 to 6x geometry size reduction and KTX2 targets GPU load time rather than file size. What the README does not give you is any usage at all, no command line, no arguments, no example input, because all of that is pushed into README_EN.md and README_ZH.md and the wiki. The releases also stop at v0.4 in 2021 while commits continue, so treat the tags as stale and the pushes as current. Build from source with CMake and vcpkg, or take a platform binary from a release.

Frequently asked questions

Official sources

1. fanvanzh/3dtiles on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases