Cesium for Omniverse v0.29.0

Cesium for Unity Samples v1.25.1

CesiumJS 1.145

Technical

3D Tiles has become the foundational OGC community standard for the 3D geospatial ecosystem. Massive, heterogeneous 3D geospatial datasets such as 3D photogrammetry and reality models, 3D buildings, point clouds, and Gaussian splats can be encoded as 3D Tiles, optimized for streaming, and rendered with high precision and performance. To power these experiences, Cesium has built robust tiling pipelines to process various types of source data into highly optimized tilesets. Because 3D Tiles is built for interoperability, these tilesets can be seamlessly streamed and visualized across a wide-open ecosystem of runtime engines, including CesiumJS, Cesium for Unreal, Three.js, BabylonJS, QGIS, and Godot. 

To accelerate and streamline how we optimize 3D geospatial data, we are introducing a new concept: composable tiling pipelines. Built on a unified, modular architecture of reusable and configurable components, this new approach offers significantly better flexibility for tiling your data. As always, the evolution of our platform is guided directly by your input. To kick off this community discussion, we’re sharing our vision for composable tiling based on feedback we've gathered so far. We’d love to learn about your current workflows, the challenges you face delivering complex 3D content, and which capabilities you want us to prioritize. 

Google Photorealistic 3D Tiles of Philadelphia, Pennsylvania, USA.

The current generation of tilers are specialized, separate pipelines for each type of data. Terrain, imagery, 3D photogrammetry, point clouds—each of these has a dedicated tiler. As the number of tilers continues to grow, we’ve shifted our thinking from “How can we create a tiler for a new type of data?” to “How can we bring together the best of our algorithms to create the most efficient 3D Tilesets?” Making that leap requires a new architecture. 

It’s more than just a technical upgrade, though: this new architecture sets the stage for faster, more flexible tiling pipelines that better serve the community. We’ve been watching a few key trends unfold, and it’s clearly time to recalibrate and evolve our approach. 

First, datasets are getting larger, with higher resolution and greater detail, and are captured more frequently. We’re moving beyond terabytes in some cases. As such, it's critical that our tiling pipelines scale with such massive datasets. 

Second, datasets are increasingly heterogeneous, often with mixed resolutions. We frequently see design models overlaid on photogrammetry or terrain, all in a single model file. In these cases, the usual approach is to separate the data, tile it into two tilesets and then combine those into a single 3D tileset. This has been an acceptable approach so far, but there is ample room for optimization. 

Finally, many users have asked for more fine-grained configurability and to perform additional customization relevant to their use cases—for example, it’s becoming increasingly important to combine tiling pipelines with data analysis and enrichment workflows, like point cloud classification in Cesium ion. 

We believe a well-executed composable architecture addresses all the above: it paves the way for robust multi-node processing to handle massive datasets; it can naturally handle heterogeneous data; and it is, by design, both flexible and extensible. 

Composability is a well-established concept in software engineering. The idea is to construct a system, usually a program or series of programs, out of small building blocks, or components, where each component is responsible for a relatively small task. The components can then be chained together, or composed, to accomplish more complex tasks. 

In the context of tiling, composability boils down to how we structure data transformations. A point cloud tiling pipeline, for example, might consist of the following steps: load the input data, remove duplicate points and outliers, divide the points into an octree, iteratively merge and simplify octree nodes to fill out a 3D Tiles tree, and, finally, optimize each tile in the tree by applying geometry and attribute compression. Each of these steps could be implemented by a single component in the pipeline, and we can visualize this with a simple node graph: 

A node graph for a possible point cloud tiling pipeline.

The example of a point cloud tiling pipeline is a relatively simple one. To illustrate the power of composable architecture, let’s consider a more complex scenario. Imagine a dataset that consists of CAD data, in the form of implicit surfaces and triangle meshes for organic surfaces. With our current tilers, the data needs to be split into two different datasets as input, tiled individually, and either combined into one tileset with a common root tile or streamed as two different tilesets to the application. With composable tiling pipelines, the process could be configured like the diagram below, producing a single spatially coherent and optimized tileset.

Composable tiling pipeline for dataset with CAD data (implicit surfaces) and triangle mesh data.

This example highlights two distinct advantages of composable architecture. First, the pipeline can seamlessly handle two very different types of data. By setting up a pipeline configured for the input data, there is no need to pre- or post-process the data. 

Second, notice how the process diverges into two paths but then converges back into one. After the implicit surfaces are tessellated, they can be treated just like triangle meshes—in fact, they are triangle meshes at this point. With two separate tilers, we would be doing redundant work to process triangle mesh data. With composable tiling pipelines, we are able to reuse nearly half of the components in the pipeline and streamline the entire process. As we consider larger and more complex pipelines, the ability to reuse as many components as possible becomes increasingly attractive. 

The benefits of a comprehensive approach also extend to runtime performance. Merging two separately optimized tilesets may not produce an optimal result, because the tiling algorithm isn't "aware" of all geometry in each spatial region. This can cause the merged tileset to have excessive geometry in some areas, even if the original tilesets were well balanced. A comprehensive tiling algorithm avoids this issue as it’s "aware" of all the data from the start. 

Configuring composable tiling pipelines 

We’ve described an architecture and explored early examples, but how will users configure tiling pipelines? Our baseline plan is to have a library of off-the-shelf components from which users can choose. We envision a new, web-based GUI, backed by a published JSON schema, with a node graph editor for constructing composable pipelines with these components. Users will be able to drag and drop, arrange, and connect components in a simple graphical interface. Users familiar with Unreal Engine’s node editor or with the Rete.js project should feel right at home. 

A mockup showing the potential look of a graph editor for composable tiling.

The composable tiling pipelines will include preconfigured pipelines for the most common types of tiling workflows. This way, the most common use cases won’t require additional configuration. 

For those who prefer a text editor, or who use the Cesium ion REST API, we expect to enable a JSON scheme that describes a pipeline and specify relevant options. (In fact, the JSON configuration would likely be an underlying implementation detail of the node graph editor.) Here’s what the configuration file for the point cloud example above might look like: 

Example JSON file for a composable point cloud tiling pipeline.

Many of these ideas are still incubating, and we want community needs to guide our roadmap. We’d love to hear from you:  

What capabilities would be most valuable in a composable tiling pipeline? 

What formats, transformations, or integrations would support your workflows? 

How could this architecture help you build better experiences with Cesium? 

Your feedback will help shape the next generation of tiling pipelines. Share your thoughts with us on the community forum. 

Help Us Shape Composable Tiling Pipelines for Next-Gen Workflows 

As Cesium and Bentley Systems have come together to build the comprehensive open platform for the built and natural environment, we’re pairing Bentley’s deep AEC experience with interoperability to serve the community. To bring CAD-style visualization concepts to CesiumJS, our team has built a set of AEC workflow extensions to glTF, the open standard foundational to the new 3D Tiles 2.0. 

CAD users expect specific—yet common and well-established—visualization requirements, including crisp hard edges and silhouettes, lines drawn with precise widths and dash patterns, points sized to convey semantics, textures that hold a consistent on-screen scale at any zoom, and planar fills with well-defined depth and masking behavior. These are standard features in tools like Bentley’s MicroStation and other engineering design environments, and now they are coming to CesiumJS and Cesium for Unreal. Many have already shipped and others are landing soon. 

Infrastructure engineers often want non-photorealistic visualizations of their designs. In CAD-oriented workflows, visualization of the edges of a surface can be as important as visualization of the surface itself. CesiumJS now supports loading and rendering CAD-style edges. 

To accomplish this, we devised new glTF specifications EXT_mesh_primitive_restart and EXT_mesh_primitive_edge_visibility which extend the 3D Tiles format such that edge geometry can be properly embedded inside design model tilesets. 

Powered by these extensions, CesiumJS can now render surfaces with edges superimposed alongside the surfaces and just the edges (no surfaces). 

Experiment with edge display in this Sandcastle. 

Visible edges rendering in CesiumJS alongside surfaces.

A CAD model rendered in CesiumJS with visible edges drawn without any surfaces (wireframe style).

The edge visibility extension encodes one edge type per triangle edge: 

silhouette is drawn only when one adjacent triangle faces the camera and the other faces away. 

hard is always drawn and represents a real sharp edge or boundary. 

repeated hard marks shared hard edges without duplicating them. 

Edge classifications encoded by the extension: hidden edges are never drawn, hard edges are always drawn, and silhouette edges are drawn only when one adjacent triangle faces the camera and the other faces away.

The edge visibility extension also supports edge-level materials and connected edge strings: 

materials defines edge materials separate from triangle surfaces or primitives, so edge appearance can be controlled independently. 

lineStrings defines connected edge segments using primitive restart (EXT_mesh_primitive_restart) for continuous outlines or edges needing different materials. 

CesiumJS introduces a dedicated edge rendering pass that decodes this visibility data, reconstructs the edges as quad-based geometry (to guarantee stable screen space widths across browsers and GPUs), and integrates them with the main surface pass using feature ID and depth comparisons to avoid z-fighting. 

For more information, check out these PRs: 

Add support for GLTF extension: EXT_mesh_primitive_edge_visibility. 

Add EdgeDisplayMode enum for controlling edge rendering. 

CAD workflows often rely on line and point appearance to convey semantics. Line thickness and dash patterns are commonly used to differentiate boundaries, annotations, or feature classes. Point color and size can be used to highlight survey markers, control points, or other features. To accomplish this, we introduced new glTF extensions BENTLEY_materials_line_style and BENTLEY_materials_point_style, which extend the 3D Tiles format such that glTF-embedded lines and points can be styled for design model tilesets, both of which are now supported in CesiumJS. 

CesiumJS rendering edges with width and dash pattern and colorized points with a variety of diameters.

Line styling naturally works well with EXT_mesh_primitive_edge_visibility. Edge visibility determines which edges are drawn, while line styling determines how those edges appear. Used together, edges can achieve unique styling. 

The line styling extension adds two properties to a glTF material, which apply to any line primitive or visible edge that references the material: 

width defines the thickness of the line in screen pixels, ensuring visual consistency regardless of camera distance or world scale. 

pattern defines a repeating on/off dash pattern encoded as a 16-bit unsigned integer, where each bit corresponds to one screen pixel along the line. This is compact, GPU friendly, and expressive enough to cover common CAD line styles, such as solid, dashed, and dotted lines. 

In the case of points, a single styling property is specified (color can be inferred from the material itself): 

diameter is the diameter of each point in CSS pixels. 

Constant level of detail (LOD) textures 

In many engineering and geospatial workflows, textures are used to convey representative surface detail. This can include patterns on terrain, hatching on facades, or material finishes on infrastructure. With standard UV-based texture mapping, however, those patterns don’t remain consistent across different viewing scales. Textures visually shrink as the camera zooms out and grow as it zooms in, making fine detail disappear at distance and appear unnaturally coarse up close. 

We have introduced the glTF extension EXT_textureInfo_constant_lod to support texture consistency. Using this extension, CesiumJS provides a constant LOD texture coordinate generation technique. Rather than relying on baked-in UVs, texture coordinates are computed dynamically each frame to maintain a roughly constant texel-to-pixel ratio on screen as the camera moves. Adjacent scale levels are smoothly blended so transitions between LODs do not appear sudden. 

With EXT_textureInfo_constant_lod support in CesiumJS, the texture maintains a roughly constant on-screen scale as the camera zooms, with adjacent LOD levels smoothly blended.

For the effect to look correct, glTF files need to be authored with the extension in mind. Textures should be designed to tile seamlessly, since they will repeat across surfaces at varying scales. The values baked into the extension must be chosen to match the real-world scale of the model and the expected viewing distances. This includes how often the texture repeats per meter, its offset, and the distance over which the LOD blending applies. 

Planar polygons with filled interiors are fundamental elements in many CAD workflows, where the appearance of a polygon’s interior fill can convey meaning beyond just a flat color. A filled region may need to mask out geometry behind it, sit behind a coplanar hatch pattern or text annotation, or be toggled on and off in a wireframe view. For example, a designer may superimpose some lettering as a label on a wall, expecting that the label always appears on top of the wall and be readable without any interference from the underlying wall geometry. The team created the BENTLEY_materials_planar_fill extension to support these sorts of behaviors as material-level properties within glTF. 

With BENTLEY_materials_planar_fill support in CesiumJS, the textured text (non-lines) and planar polygons exhibit no Z-fighting even though they are coplanar with the red surface (first image).

The extension is applied to a glTF material and signals two things to CesiumJS. First, it indicates that any primitive using the material is planar, so the engine can apply appropriate depth sorting. This ensures associated edges are in front of fills and planar primitives are in front of overlapping nonplanar ones. Second, it exposes a small set of properties that customize how the fill is drawn: 

wireframeFill controls if the fill is shown in a wireframe view (never, always, or only when the user has toggled fill display on). 

backgroundFill causes the fill to be drawn using the view’s background color, which is useful for creating an “invisible” polygon that masks out geometry behind it. 

behind causes the fill to be drawn behind other coplanar geometry that belongs to the same logical object, mitigating z-fighting in cases like hatch patterns over a filled polygon, text inside a filled rectangle, or line work overlaying a solid surface. 

Together, these properties give CAD applications a compact, material-driven way to describe the desired fill behaviors in CesiumJS. 

Support for BENTLEY_materials_planar_fill is upcoming in CesiumJS. 

By bringing these AEC extensions to glTF as part of 3D Tiles 2.0 and into CesiumJS, Cesium and Bentley want to empower the community with open, interoperable, best-in-class technology, benefiting the entire 3D geospatial ecosystem.   

Your input and use cases are what guide our work. Try the Sandcastle and share your feedback on the forum.  

Introducing CAD-Style Workflow Extensions for glTF and 3D Tiles 2.0 

We’re excited to introduce Sandcastle Copilot, an AI-assisted chat panel built into Sandcastle that helps developers create, edit, and debug CesiumJS sandcastles.

CesiumJS Sandcastle has been a cornerstone of the CesiumJS community for years. It's where developers learn the API, prototype scenes, test ideas, validate fixes, and share working examples with one another. Sandcastle Copilot builds on that workflow by helping developers move from a natural-language idea to code they can read, run, and adapt without leaving Sandcastle. By turning natural-language prompts into working code, it lowers the barrier to entry for everyone who wants to build with CesiumJS, regardless of coding ability.

The initial release is Bring-Your-Own-Key (BYOK). Before starting a chat, connect Sandcastle Copilot to an LLM provider you already use, and your requests will be handled by that provider, not by Cesium. This keeps the first version lightweight and gives you control over the model, key, and account behind your conversations. Because requests go directly to your provider, Cesium does not collect or store your prompts, keys, or conversations.

Sandcastle Copilot is built to shorten the loop between idea and working code, whether you're exploring a new API, visualizing a dataset, or prototyping an app against your own data. Here are some things you can do with it:

Ask questions about CesiumJS or the active sample

Ask about a CesiumJS API or the sample you’re currently in, and get answers grounded in the editor and console context rather than generic documentation.

Cesium Sandcastle Copilot ask questions

Describe what you want in plain language, and Copilot proposes the code. Proposed changes appear as diffs in the chat panel, so you review and apply each edit before it touches the editor.

Cesium Sandcastle Copilot scene changes

When something throws, Copilot reads the current editor and console state to help you find and fix the cause, without leaving Sandcastle. 

Cesium Sandcastle Copilot troubleshooting

Sandcastle Copilot has taken shape with input from the CesiumJS community, including the discussion that began in our native AI Copilot feedback thread earlier this year. It follows an AI-driven semantic search, which we rolled out last quarter, as the next piece of AI-assisted tooling inside Sandcastle.

This initial release lays the groundwork for a broader AI-assisted development experience in Sandcastle. BYOK keeps the first version lightweight and flexible. Looking ahead, we're exploring ways to streamline access and setup, expand the Cesium-aware skills available to Sandcastle Copilot, and use community feedback to guide where the experience should go next.

Try Sandcastle Copilot and use the Feedback & Issues link in the app to let us know what you think.

One of the most frequent and long-standing requests from the community has been support for large-scale heterogenous vector data as part of 3D Tiles. We’re excited to share that we’re adding 3D-native vector points, lines, and polygons support to 3D Tiles 2.0. We’re looking for your feedback to help shape the specification and implementations.

Vector data scales quickly with geospatial datasets. Here, traffic volume is displayed on regional road network of 150,000 links (polylines) from OpenPaths transport model. Data courtesy of Atlanta Regional Council. Results do not correspond to any specific transportation planning scenario.

Vector data is widely used in architecture, engineering, construction, and operations, as seen in this 3D design model of a building with annotations, levels, and tags represented as vector data.

Before designing a solution, we conducted an extensive survey of the vector data ecosystem and of use cases, workflows, and widely adopted formats, including Mapbox Vector Tiles (MVT), MapLibre Tiles (MLT), and GeoJSON.

The 3D geospatial community’s use cases have focused on 3D vector data as a gap in current solutions. Use cases such as traditional city-scale road networks with centimeter precision on terrain, highly detailed models of transmission and telecom towers overlayed with vector information, AI-extracted global-scale points of interest at accurate elevations, and 3D-specific engineering tasks like building constructions with detailed design strings and annotations—all require real-time level-of-detail streaming and high-precision 3D rendering and analytics.

There are numerous applications for vector data as 3D Tiles. Here vector data is derived by iTwin Capture AI Analysis from mobile mapping LiDAR.

Green lines mark cracks detected on the Robert Street bridge, St. Paul, Minnesota. Only a 3D-native approach to vector data can capture cracks above and beneath the bridge as seen here. Data courtesy of Collins Engineers, Inc., which leveraged drone photogrammetry and automatic crack detection to operate safer onsite, avoid traffic interruptions, and accelerate and improve bridge inspection and maintenance.

Linework display in EARTHBRAIN Smart Construction Dashboard. These proposed changes to 3D Tiles will enable better streaming and sharing of vector datasets in large, complex engineering projects.

At the same time, we've heard from the community about a plethora of use cases that are sufficiently served by existing 2D and 2.5D tiling solutions, with GeoJSON and Mapbox Vector Tiles as most commonly used solutions. Users have shared their desire to use this content in conjunction with 3D Tiles, such as Google Photorealistic 3D Tiles or a user’s own high-resolution reality mesh.

As we compared the use cases to existing solutions, the current landscape is heavily 2D-focused: optimized for flat map tiles, with limited pathways to 3D, restricting both the perceptual clarity of spatial data and overall scalability. This is insufficient for the high-precision 3D use cases.

To address the need for fully-3D vector content and support existing vector data ecosystems, we are:

extending 3D Tiles to support vector data through the upcoming 3D Tiles 2.0 standard, built on glTF, and

adding runtime support for Mapbox Vector Tiles in CesiumJS and Cesium for Unreal to complement the GeoJSON solution already in place, allowing users to bring their existing vector tiles into Cesium’s open-source ecosystem.

Supporting vector tiling enables efficient streaming and high-performance rendering in a true 3D, Earth-coordinate environment, all while preserving semantic-based operations like metadata querying, styling, and analysis—capabilities essential to traditional vector data use cases. Together, these additions give users an on-ramp for their existing vector workflows and a foundation for next-generation 2D and 3D vector visualization, all within a single, unified ecosystem.

Visualization from prototype: Cracks on the Robert Street bridge that extend both on the road surface and to the side curb, where a traditional 2D vector data visualization will be insufficient. Data, courtesy of Collins Engineers, Inc., is untiled GeoJSON and rendered directly in CesiumJS.

3D Tiles enable smooth streaming of global scale datasets, and support for vector data will  enable powerful streaming capability for vector datasets, too. Here, 300K points assets detected by computer vision by Blyncsy are visualized in CesiumJS.

In designing our approach to tiling vector data, we focused on meeting real community needs and explored both traditional 2D GIS and emerging 3D workflows. We spoke to users across a breadth of industries about their needs. By observing their use cases, we summarized the following initial requirements for a scalable, 3D-native vector format. These needs have informed our design.

Support 3D coordinates with graceful handling of 2D and 2.5D

Support querying and styling of per-element properties

Support 3D coordinates not referenced to Earth, e.g., Mars, Moon

Support flexible tiling schemes, e.g., quadtrees, octrees, k-d-trees, and discrete global grid systems (DGGSs), for cases where tiling schemes based on the Web Mercator projection are not suitable, like polar regions or vertical structures such as buildings or dams

High-fidelity, real-time visualization experience:

Efficient runtime deserialization using runtime-ready binary formats and GPU-ready compression

Accurate display allowing centimeter to millimeter precision, which is often required for aligning vector and non-vector (e.g., scanned) sources

Proposed 3D Tiles 2.0 specification and glTF extensions

In the upcoming 3D Tiles 2.0 specification, vector data will be natively supported by leveraging the same spatial indexing, attribute encoding, and level-of-detail organization that powers 3D meshes and point clouds today. This means users can visualize, query, and work with all of their data together in a single, unified workflow, bringing vector features into the same integrated experience their applications already rely on for 3D content.

3D Tiles will support points, lines, and polygons encoded efficiently as glTF assets. The content can be optionally compressed using Meshopt and Gzip compression for efficient storage and streaming. The proposed specification consists of one new 3D Tiles extension and two proposed glTF extensions:

3DTILES_content_gltf_vector (3D Tiles extension): Identifies tile contents as “vector data,” and informs runtimes on how to interpret that data. Enables vector support in 3D Tiles 1.1, with an equivalent extension planned for 3D Tiles 2.0 soon.

KHR_mesh_primitive_restart (glTF extension): Enables more efficient encoding of LINE_STRIP and LINE_LOOP topology in glTF, used in line and polygon data.

EXT_mesh_polygon (glTF extension): Provides a backwards-compatible representation of polygons for glTF, preserving polygon topology while including runtime-ready triangulation data for high-performance rendering.

glTF extensions including EXT_mesh_features and EXT_structural_metadata will also be used for vector tiles content to encode Feature IDs, properties, and metadata.

Looking Ahead: Cesium's Vector Tiles Roadmap

A high-level overview of vector data workflow for Cesium.

Our work on 3D Tiles specifications is always backed by reference implementations proving the approach and performance and addressing the use cases. We have started implementations for tiling massive vector data and LOD-enabled high-fidelity rendering in CesiumJS and Cesium for Unreal.

The pipeline for vector content in Cesium will consist of three key parts:

An optimized tiling pipeline to create 3D Tiles from vector data, with GeoJSON as the initial input format. As with our existing pipelines, the vector tiling capability will be available both via Cesium ion and for self-hosted services. Additional formats such as GeoPackage, shapefiles, and more will be supported based on community feedback.

glTF for optimized vector tile encoding, streaming, and rendering.

Runtime vector support in CesiumJS, Cesium Native, and Cesium for Unreal, with additional runtimes like Cesium for Unity based on community feedback.

Aiming for a full end-to-end pipeline in the first phase, we have begun with support for GeoJSON as the initial input format. The support includes commercial tiling, hosting, and streaming services in Cesium ion, with runtime support in CesiumJS and Cesium for Unreal. We have also begun supporting Mapbox Vector Tiles in CesiumJS, which will reuse the same rendering pipelines as 3D Tiles, thus benefitting performance improvements.

In the coming months, we will extend styling support, support 3D Tiles and terrain clamping, add more source formats for all our runtimes, and continue performance and robustness improvements.

Visualization from prototype: A 3D design for a hypothetical highway in Coffs Harbour, NSW, Australia as vector tiles, tiled into 3 LODs and produced by Bentley. The geometry carries real elevation values — the road structures are positioned in true 3D space.

Vector data as 3D Tiles: highway design

Visualization from prototype: New York City building footprints represent the full perimeter outline of each building as viewed from directly above. Tiled with 13 LODs. Styling of the polygon as blue and dashed outlines is done at runtime.

Vector data as 3D Tiles: NYC Building footprints

These reference implementations are intended to seed your testing and feedback to align the specification and roadmap to address your use-cases.  

We look forward to collaborating with the community to finalize vector data support in 3D Tiles 2.0 and implementations in Cesium. We need your input to solidify the specification and test the implementation. Please share your use case and observations in the Cesium community forum. We’d love to hear about how you plan to build applications with vector tiles.  

Help Shape Vector Data Support in 3D Tiles

Cesium for Unity is now available to be deployed via WebGPU as part of Cesium for Unity's December 1 release. This was enabled by community support from Brendan Duncan of Unity Technologies.  

Brendan is a staff engineer for Unity. He focuses on web graphics, implementing the WebGL and WebGPU graphics driver used by the Unity web player. This post by Brendan outlines the feature and information on how to build and deploy Cesium for Unity on the Web. 

A popular feature request from the Cesium community has been support for Cesium for Unity in the Unity Web Player. As of v1.20.0, Cesium for Unity can now be deployed on the web, enabling easy-to-share experiences with massive geospatial data streamed through 3D Tiles; no app stores or installs required. 

Web support in Cesium for Unity is made possible through WebAssembly, the technology that Unity leverages to enable content to run at near native speeds in the browser. Cesium for Unity uses a compiler toolchain called Emscripten to compile its core C++ code, including its Cesium Native libraries, to WebAssembly. Additionally, it makes heavy use of multithreading to stream in tile data on worker threads to preserve main thread performance. 

While CesiumJS users are often more familiar with web development—bringing the Cesium viewer into their own stacks and user interfaces—Unity developers simply want to port their applications to the web without extra tools or hassles. With just a URL, users can explore geospatially accurate 3D environments, which enable public-facing applications, educational tools, urban planning visualizations, and interactive mapping experiences. 

First, create a project that uses Cesium for Unity. You can start with the Cesium for Unity Samples or build one from scratch using the Quickstart  tutorial. Once your application is ready to build, setting up Cesium for Unity for Web deployment follows the standard Unity workflow.  

When building for the web, follow these steps: 

Update Cesium for Unity to v1.20.0 or newer: Ensure you are using the latest version of the Cesium for Unity package via the Unity Package Manager. 

Use Unity 6+: These versions are optimized for modern WebGL and WebGPU standards and include the necessary options for multithreaded WebAssembly. 

Configure Multithreading: You must enable Native C/C++ Multithreading in your Unity Player Settings for Web. Cesium for Unity will not build for the web without it. 

Increase Memory Limits: You may want to increase the maximum memory limits for the web player to handle more memory-intensive tilesets. Unity currently supports a maximum memory limit of 4GB. 

Server Headers: When hosting your web build, your server must serve files with COOP (Cross-Origin-Opener-Policy) and COEP (Cross-Origin-Embedder-Policy) headers to allow multithreading. The security requirements can complicate hosting multithreading enabled Web Assembly, but they are necessary due to past exploits of web browsers. 

Web support in Cesium for Unity is currently experimental, so careful optimization may be required for high-memory applications to stay within browser memory limits.

Combining Unity's creative tools, Cesium's geospatial expertise, and the web's universal accessibility creates exciting opportunities for developers working at the intersection of geography and interactive 3D.                           

Together, Cesium for Unity and Web open doors for accessible geospatial applications. Urban planners an share interactive 3D city models with stakeholders through simple web links. Educators can create explorable geographic lessons that students access from any device. Emergency management teams can visualize disaster scenarios using accurate terrain data without specialized software installations. Tourism applications can let users virtually explore destinations in photorealistic 3D. Real estate developers can showcase properties in geographic context. Researchers can create interactive data visualizations that combine scientific datasets with accurate geographic representation. 

With increasing community use, testing, and feedback, Cesium and Unity are actively collaborating to mature the web backend from experimental to full support. As browsers continue to evolve and WebAssembly matures, we're especially interested in opportunities to further narrow the performance gap between web and native applications. 

This is a community-driven effort, so we want developers to test this workflow and tell us what works well and where it falls short. Your feedback directly informs where we invest next.  

Try out web support with Cesium for Unity today and let us know what you think on the community forum.  

With the release of CesiumJS 1.130, users can drape imagery layers on 3D Tiles, allowing developers more freedom to combine geospatial data from different sources. Reality meshes, CAD/BIM data, and point clouds can be uploaded to Cesium ion and converted into 3D Tiles for efficient streaming and visualization. Now, imagery data like Bing Maps imagery or OpenStreetMap imagery can be layered on top, creating more powerful 3D geospatial applications. This addition addresses a long-standing community request and supports a wide range of use cases.

An example of draping imagery on 3D Tiles: Google Photorealistic 3D Tiles with Google Roadmap tiles overlay providing street and label data.

Use case 1: Orthophotography over reality meshes 

Existing reality mesh datasets can be augmented with high-quality, curated orthophotography imagery data. In this example, Bing Maps Aerial imagery is added to a 3D Tiles point cloud dataset without color data.

Use case 2: Sensor data layers over 3D Tiles 

The results of sensor coverage data, satellite imagery, or AI-based classification can be mapped on 3D Tiles to visualize the results of different analysis workflows. Here is an example where the user can select different imagery layers provided by NASA Earth Data, to overlay information like the biomass or population density over Photorealistic 3D Tiles.  

An example of draping imagery on 3D Tiles: Google Photorealistic 3D Tiles with information about the population density, provided by NASA Earth Data.

Use case 3: Adding contextual information over 3D Tiles 

Imagery can also be used as overlays to provide additional geospatial context about roads, buildings, or other points of interest. For example, imagery data that provides geospatial information can be draped over existing 3D Tiles datasets. 

An example of draping imagery on 3D Tiles: Bing Maps Labels draped over a tileset that was loaded from iTwin reality data.

This new feature is similar to the existing functionality of draping 3D Tiles on terrain data, so users can seamlessly leverage it with little effort. This simple example shows how to drape imagery data on 3D Tiles. The Cesium3DTileset class now offers a set of imagery layers, and these can be used exactly the same way as imagery layers for terrain in CesiumJS. This means adding the imagery to the to the tileset can be done with a single line of code: 

```js
tileset.imageryLayers.addImageryProvider( 

  await Cesium.createWorldImageryAsync({ 

    style: Cesium.IonWorldImageryStyle.AERIAL, 

  }) 

); 

The imagery layers that are added to a tileset are added as an ImageryLayer object. This object has several properties that affect the visual appearance of the imagery data as it is draped on the 3D Tiles data. Users can modify the alpha value (opacity), brightness, or saturation. This sandcastle showcases the ability to modify properties in real time. 

The first release of draping imagery over 3D Tiles that is part of CesiumJS 1.130 includes functionality that serves most use cases. There are several possible extensions or functionalities that can be added based on community input—for example, user controls to align existing imagery data with the 3D Tiles or to "upsample" the 3D Tiles geometry with imagery resolution that is higher than the geometry with large geographics extent. 

We welcome feedback about the draping functionality and thoughts about further use cases that should be supported via this community thread. 

Draping Imagery over 3D Tiles in CesiumJS 

Cesium ion SaaS and Cesium ion Self-Hosted utilize containers to provide Cesium ion. Containers are cloud-native, lightweight, and stand-alone software packages that include everything needed to run a piece of software: the code, runtime, system tools, libraries, and settings. This encapsulation ensures that the software runs consistently across various computing environments, from development to testing and production, regardless of the underlying infrastructure. At the heart of any container is the base image, and Cesium has recently updated base images to use the Red Hat Enterprise Linux Universal Base Image as deployed by Iron Bank. Because containers are smaller than virtual machines, it reduces the surface area to patch and update as part of the software stack. 

Containers are smaller than virtual machines, reducing the surface area to patch and update as part of the software stack.

Iron Bank was created and is maintained by the US Department of Defense (DoD)’s Platform One group. The goal of Iron Bank is to provide trusted and vetted container images that can speed up deployment of commercial and open source software across the DoD. This is possible because there is an open process by which images are created and because the images are continuously monitored and continually updated for Common Vulnerabilities and Exposures (CVEs) as part of the process that builds these images. Trust is an important part of what we do at Cesium, so it’s important that we are able to trust the source of our base container images and that our users are able to trust that we work to ensure a secure product for them. 

CVEs don’t exist only in the base image itself, although that is where most of them are found. To ensure we stay on top of security reports and prevent releasing vulnerabilities to our users, Cesium also scans for CVEs. CVEs are tracked through various internet databases, with contributions by companies, security researchers, and developers. CVEs generally are reported against software as they are discovered and can appear at any layer in your container—the operating system, your build tools, or your software dependencies. At Cesium, we use open source tools like Grype to identify CVEs and then mitigate them by constantly updating our dependencies or removing unnecessary pieces of software from our containers. We run these tools in our continuous integration/continuous deployment (CI/CD) pipelines, so that no release happens without security checks. 

Creating a trusted software supply chain 

Another important consideration that has received more attention lately is the software supply chain. People consuming software are now more concerned about where their software comes from, how it’s built, and what other software is packaged inside the software they bought. With Iron Bank as the base image, there is a known and open source of the bottom layers of the container stack, including the system libraries and programs that are built on top of the operating system. 

Additionally, Cesium takes great care to analyze the JavaScript libraries we’re directly dependent on, as well as those that may be nested inside, to ensure that we are looking at what licenses the software is bundled with, if it contains any vulnerabilities, and if there are updates we should be using. To do this, we generate a Software Bill of Materials (SBOM) using Syft, which analyzes not just the software we’re using but also the dependencies of that software. Using those SBOMs and a tool called Grant, we can determine what licenses our dependencies have so that we can avoid any unfavorable licenses. A full view of what this scanning looks like is illustrated below. 

In addition to monitoring for CVEs, Cesium also continually monitors our software for security vulnerabilities through Static Application Security Testing (SAST) and secret scanning. SAST analyzes application code to identify potential security vulnerabilities that can be mitigated prior to release. It looks for things like SQL injection, cross-site scripting, and buffer overflows. Secret scanning helps ensure that authentication parameters are not stored in the code, containers, configuration files, or other areas in the released product. The reports generated from these tools allow us to harden our code and provide assurances to users about the security of the Cesium ion environment. 

Software security can be hard, and it’s important to be vigilant and confident in the measures taken to ensure your software and your users’ data are secure. In addition to vetting our own software, vetting containers and their stacks can be very complex. Fortunately, we can rely on a solid base with Iron Bank and use sophisticated tools from the open source community to ensure that we are always following security best practices. 

Use Cesium ion Self-Hosted to support corporate policies or create air-gapped solutions that meet strict security requirements and can be deployed to remote, disconnected environments. Learn more about using Cesium in your own environment. 

Cesium ion Uses Iron Bank Container Images for Software Security 

Author’s note: Many thanks to my colleague Jeshurun Hembd for his significant contributions to these results. This is part 2 in a series about visual quality improvements in CesiumJS; read part 1 here.

With the growing adoption of Cesium for Unreal and Cesium for Unity, developers of native applications have raised the bar for visual quality in Cesium apps. Specialized game engine features—like dynamic sun and sky lighting components, light probes, and global illumination systems—now can be applied to geospatial use cases. The CesiumJS squad has been working to bring browser-based geospatial apps to a new level with dynamic approaches to lighting.

glTF model of a polished metal sphere reflecting the environment, rendered in CesiumJS using improved image-based lighting and an HDR-image environment map.

Good lighting is essential to make the most out of physically based rendering, or PBR, a rendering technique common to both models and 3D Tiles. Think of a polished metal sphere: It’d appear flat and dull without anything interesting to reflect. To complement recent rendering improvements we’ve made to the glTF material model in CesiumJS, we’ve shipped several enhancements to our lighting system over the last few releases, including:

Refinements to the image-based lighting pipeline

New York Buildings 3D Tileset, rendered in CesiumJS with ambient occlusion before these lighting updates (left, version 1.121) and after (right, version 1.125). The overall effect of the changes is more realistic lighting and more easily understood model form.

There are many strategies for lighting, but one tried-and-true method that’s been a part of CesiumJS for several years is image-based lighting, or IBL. Lighting for glTF PBR models and 3D Tiles combines a single directional light source (i.e., the sun) and IBL to simulate a variety of dynamic lighting conditions, such as the precise position of the sun based on time and geospatial location or scattering of light through the atmosphere.

glTF model, courtesy of noe-3d.at on Sketchfab, rendered in CesiumJS with directional lighting (left), image-based lighting (middle), and a combination of directional and image-based lighting (right). The combination results in the most apparent dimension and sense of place when viewing the model.

IBL is an appealing approach because it simulates a complex lighting environment—like hemispheric lighting from the sky, diffuse reflections from the ground, and any other light sources in a scene—with a single environment map. This map encodes a high dynamic range of lighting info in an omnidirectional texture, typically with an HDR image supplied by the user or a procedural texture generated at runtime.

While users have been able to import their own environment maps, this required offline use of external tooling like Khronos’s glTF IBL Sampler for preprocessing, making it less accessible to those without a knowledge of lighting pipelines. With our recent work, we can now use dynamic environment maps in CesiumJS that adapt to changes in time of day, atmospheric conditions, or model positioning. This means CesiumJS developers get the full benefits of IBL without any additional configuration.

Created on the GPU, dynamic environment maps can be updated in near-real time to reflect the current sun position and model location. When time of day, atmosphere settings, or model position change significantly, the environment map can be updated in the background over a few frames.

The Damaged Helmet glTF sample model rendered in CesiumJS with default procedural lighting in version 1.121 (left) and with dynamic environment maps in version 1.125 (right).

For apps with more specific lighting needs, there are options that can be adjusted, like the overall intensity of the light or the color reflected by the ground.

Our existing shaders for simulating the sky atmosphere based on time of day were flexible enough to be reused by adapting the viewing angle to the model origin. This means we can simulate lighting conditions at sunrise or sunset but also high up in the atmosphere for aircraft and satellites.

A glTF model of a polished metal sphere reflecting the environment at morning (left), noon (middle), and evening (right), as rendered with dynamic environment maps in CesiumJS.

From the environment map, we can determine both the diffuse lighting as well as the specular reflections on any model or 3D tileset. For low-roughness materials like polished metals, the environment map can be used to look up the reflection coming from any particular direction. Rougher objects scatter light and therefore reflect light in a more diffuse way. To represent this, we need to compute the average light contribution across a range of angles representative of the degree of scattering, an operation which involves sampling the environment map hundreds, if not thousands, of times. 

To optimize runtime performance, we precompute values on the GPU when a model is first loaded and then store them in data structures for lookup at runtime. The environment map is stored as a cubemap for quick lookup based on the direction of the reflected ray. Specular maps corresponding to various material roughness levels are stored in texture mipmaps that are used to sample the specular radiance. Finally, diffuse irradiance—that is the sum of all incoming light for any particular direction—is represented with third-order spherical harmonic coefficients, a total of nine sets of RBG values.

Data structures used for IBL precomputed on the GPU in CesiumJS: From the environment map, a cubemap is created with each increasing mipmap level representing the specular reflections of materials with increasing roughness. The most diffuse lighting is stored as an array of spherical harmonic coefficients.

Help Us Shape Composable Tiling Pipelines for Next-Gen Workflows

Introducing CAD-Style Workflow Extensions for glTF and 3D Tiles 2.0

Introducing CesiumJS Sandcastle Copilot

Help Shape Vector Data Support in 3D Tiles

Introducing Cesium for Unity Web

Draping Imagery over 3D Tiles in CesiumJS

Cesium ion Uses Iron Bank Container Images for Software Security