Cesium for Unity: putting a WGS84 globe and 3D Tiles into a Unity project

What the plugin is for

Cesium for Unity enables building 3D geospatial applications and experiences with 3D Tiles and open standards using Unity. The mechanism is a combination of three things: a high-accuracy full-scale WGS84 globe, open APIs and open standards for spatial indexing such as 3D Tiles, and cloud-based real-world content from Cesium ion.

The WGS84 globe is the part that distinguishes this from putting a heightmap in a Unity scene. A conventional Unity project works in its own local coordinate space, and a globe means the world is Earth, with a defined reference ellipsoid, and everything you place on it has a real position. That is what makes geospatial applications possible rather than merely large map-like scenes.

The primary language is C#, the licence is Apache-2.0, the default branch is main, and the homepage is cesium.com/platform/cesium-for-unity. The recent releases are v1.26.0 from 2026-09-29, v1.25.1 from 2026-09-01 and v1.25.0 from 2026-08-03, and the last push was on 2026-10-21 with the project not archived.

The release cadence is steady, monthly-scale, and the version is on 1.26, which is a good sign for something that is embedded in other people's projects and has to keep working against Unity's own releases.

That tells you the plugin is a platform layer rather than a demo: the same kernel serves a defence simulation and an architecture visualisation, and the differences are in the content and the interaction, not in the geospatial machinery.

The content story, and where Cesium ion fits

The ecosystem section is where the commercial relationship is explained, and it is unusually direct about it.

Cesium for Unity streams real-world 3D content such as high-resolution photogrammetry, terrain, imagery and 3D buildings from Cesium ion and other sources, available as optional commercial subscriptions. The plugin includes Cesium ion integration for instant access to global high-resolution 3D content ready for runtime streaming. Cesium ion users can also use the cloud-based 3D tiling pipelines to create end-to-end workflows to transform massive heterogenous content into semantically-rich 3D Tiles, ready for streaming to Unity.

Two points in that paragraph are worth pulling apart. The first is that the content is a subscription rather than a dependency, and the plugin is not the paid thing. Cesium ion is. That distinction matters for how you license the whole stack.

The second is the tiling pipeline. Photogrammetry captured of a real site can run to terabytes of imagery, and 3D Tiles is the format that makes such content streamable rather than downloadable. So the workflow is capture, tile in the cloud, stream into Unity, and the tiling step is where the volume problem is solved. Without that step the content simply could not be used in a real-time application.

Then the part that is easy to miss. The plugin supports cloud and private network content and services based on open standards and APIs, and you are free to use any combination of supported content sources, standards and APIs with Cesium for Unity. So the commercial platform is not a requirement. A team with its own data pipeline, its own tiles, its own imagery and its own servers can use the plugin and pay nothing to Cesium.

That is a meaningful architectural choice, because it means the plugin is not a client for one company's service but a host for an open format. 3D Tiles is the open standard and it is the unit of streaming, so anything you can tile, you can show.

The README closes the section with a note that using Cesium ion helps support Cesium for Unity development, with a heart emoji. That is a sponsorship appeal rather than a technical requirement, and it is worth separating the two when you read the rest of the documentation.

The Unity integration, and what it inherits from the engine

The Unity Integration section is short and it is the reason to use the plugin rather than write your own Cesium bindings.

Cesium for Unity is tightly integrated with Unity, making it possible to visualize and interact with real-world content in the editor and at runtime. The plugin also has support for Unity game objects, physics, collisions and character interaction. The stated aim is to build on what Unity and geospatial tooling already do well, to create cohesive, interactive and realistic simulations and applications.

The editor-and-runtime point is the one that changes how you work. Content you see in the editor is the same content that appears at runtime, so a designer placing objects on a tile of a city is placing them against the actual streamed geometry, not a placeholder. For a simulation, that difference is the whole game, because a character controller that behaves correctly against a proxy mesh and then falls through a real building is a debugging session you did not need.

And the integration goes the other way too. Unity game objects can participate: physics bodies, colliders and characters work against the streamed world. The content is a tiled mesh hierarchy at the end of the day, and the plugin makes it a scene rather than a special case.

That is what makes the geometry-heavy content usable in an interactive product. A photogrammetry mesh is not something you can walk around in with a character controller unless the tiles come with sensible collision and the runtime streams them in time. The plugin's job is to make the streaming and the interaction line up.

The samples are hosted in a separate repository, CesiumGS/cesium-unity-samples, with a releases page for downloading them, and there is a Quickstart in the Cesium learn documentation. The README also points at the community forum for questions, which is a reasonable route for a plugin that is used across many Unity versions.

Licensing and the samples

The License section is two lines and one of them is the important one.

Apache 2.0, and Cesium for Unity is free for both commercial and non-commercial use.

That is worth pausing on, because the surrounding ecosystem has commercial elements. The plugin itself, which is the code that integrates with Unity, the 3D Tiles streaming, the globe, the physics interaction, is Apache 2.0 and costs nothing to ship in a commercial product. The paid part is the content, and it is optional.

The samples are in a separate repository, cesium-unity-samples, and the README links a releases page for downloading them. The Featured Demos section points at the same repository, with a screenshot of the plugin in use, so the examples are meant to be run rather than read.

The two links at the top are the practical entry points. Download Cesium for Unity Samples takes you to the releases page of the samples repository, and Follow the Quickstart takes you to the Cesium learn documentation for Unity. A community forum exists for questions, which is the sort of arrangement you want from a vendor that supports a plugin across a wide range of Unity versions and use cases.

The documentation structure is also visible in the repository, with the user and contributor documentation hosted separately, and a Developer Setup Guide in the repository itself for people who want to compile and customise the plugin rather than install it from the package manager.

The repository layout, and the package manifest

The top-level listing is the clearest description of what this package actually contains, and it has some unusual entries.

There are Build~/ for the build scripts, Source/ for the runtime code, EditorTests/ and Tests/ for the two test tiers, and Documentation~/ for the documentation, with a .meta file alongside each of those directories. The tilde suffix is the Unity convention for a directory that is not imported into the Unity project, so the documentation and the build machinery live in the repository without cluttering the Unity asset tree. The .meta files are Unity's own metadata, which are committed so that asset references survive a clone.

Then there are the entries that tell you this is not a pure C# package. There is a native~/ directory, which holds the native components, and a Reinterop~/ directory with a Reinterop.dll.meta beside it. Reinterop is the tool that generates the glue between the native code and the managed C# layer, so the native and managed sides are kept in step by generation rather than by hand.

There is a .gitmodules file, so at least one dependency is a git submodule rather than a package, and a ThirdParty.json file that records the third-party components and their versions, which is how a project with native binaries and licences tracks what it is shipping.

There is a WGS84.asset at the root, which is the globe definition itself, checked in as a Unity asset rather than generated at runtime, and a global.json which pins the .NET SDK version the project builds against.

And the package manifest is a Unity package manifest rather than an npm one, and it is worth reading because it encodes the compatibility floor:

{
  "name": "com.cesium.unity",
  "version": "1.26.0",
  "displayName": "Cesium for Unity",
  "description": "Cesium for Unity brings the 3D geospatial ecosystem to Unity. By combining a high-accuracy full-scale WGS84 globe, open APIs and open standards for spatial indexing such as 3D Tiles, and cloud-based real-world content from [Cesium ion](https://cesium.com/cesium-ion) with Unity, this plugin enables 3D geospatial workflows and applications in Unity.",
  "license": "Apache-2.0",
  "unity": "2022.3",
  "author": {
    "name": "Cesium",
    "email": "[email protected]",
    "url": "https://cesium.com"
  },

The unity field says 2022.3, so the minimum Unity version is 2022.3, and the dependencies are four Unity packages:

  "dependencies": {
    "com.unity.mathematics": "1.2.0",
    "com.unity.test-framework": "1.1.31",
    "com.unity.shadergraph": "12.1.6",
    "com.unity.inputsystem": "1.4.2"
  }

So com.unity.mathematics at 1.2.0 for the maths types, com.unity.test-framework at 1.1.31 for the tests, com.unity.shadergraph at 12.1.6 for the shaders, and com.unity.inputsystem at 1.4.2 for input handling. The shadergraph dependency is a hint about the rendering approach, and the input system dependency says the plugin is on Unity's newer input stack rather than the legacy one.

One detail in the scripts is a small piece of good defensive design. The preinstall script prints an error saying this is a Unity package, not an npm package, and exits with status one. Since the file is a package.json, a stray npm install in the repository root would otherwise try to install it, and the guard turns that into a clear message instead of a confusing failure.

How to evaluate it, and what to check first

There are four things to consider.

First, whether you need a globe at all. If your application is terrestrial, indoors, or set on a fictional world, this plugin is far more machinery than you need. The globe implies a real Earth, a WGS84 reference and content that has to be streamed, and those are costs paid for a benefit that only exists in geospatial work.

Second, the content question, which is where the real decisions are. The plugin is free and the content is not, and the options range from Cesium ion subscriptions through your own tiles and imagery on cloud or private network infrastructure. The trade is between convenience and control: ion gives you global high-resolution content immediately and a tiling pipeline for your own captures, while self-hosted gives you no recurring cost and full control over where the data lives, at the cost of running the tiling and the serving yourself. The README is explicit that you are free to use any combination.

Third, the Unity version floor. The manifest pins 2022.3, and the recent releases are monthly, so you are adopting something that tracks Unity's own release cycle. If your project is on a different Unity version, that is the first thing to check, because a plugin that is a compiled package against a specific engine version does not float.

Fourth, the streaming behaviour under interaction. Photogrammetry content is heavy, and the plugin has to stream tiles in time for a character to walk across them. The samples repository is where you can find that out, and the distinction between a scene that looks right when you fly over it and a scene that holds up when you run through it at ground level is the thing worth testing.

What you get is an Apache 2.0 licensed Unity package with a real WGS84 globe, 3D Tiles streaming and working Unity physics and character interaction, backed by a vendor shipping monthly releases and a documentation site with a Quickstart. The costs are the content subscription if you take Cesium ion, the Unity version constraint, and the streaming work you inherit if you go it alone.

Editorial conclusion

Adopt Cesium for Unity if you are building a geospatial application or simulation in Unity that needs real-world terrain, imagery, photogrammetry and buildings on an accurate WGS84 globe, and you want the streamed content to work with Unity's own physics and character interaction. Do not adopt it for a terrestrial, indoor or fictional-world project, since the globe, the WGS84 reference and the streaming are costs that only pay off in geospatial work. Before you commit, check the unity 2022.3 floor against your own project version, decide where the content comes from, because the plugin is free but the high-resolution content is a subscription and running your own tiles and imagery is a real alternative, and test the samples at ground level rather than from the air, since the streaming behaviour under a moving character is the thing most often to surprise you.

Frequently asked questions

Official sources

1. CesiumGS/cesium-unity on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases