Cesium for Omniverse v0.25.0

Cesium for Unity Samples v1.16.2

CesiumJS 1.131

Performance

We’ve been thrilled with the response to Cesium ion Self-Hosted since its initial release in December – a big thank you to everyone who provided feedback so far. We hope our updates have made Cesium ion Self-Hosted an even more valuable and easy-to-adopt hub for 3D geospatial workflows that leverage the flexibility and power of 3D Tiles. Here are some of the highlights since v1.0.

Access to Google Photorealistic 3D Tiles and Bing Imagery

We’re especially excited to announce that our v1.3 release enables Cesium ion Self-Hosted users to include Google Photorealistic 3D Tiles and Bing imagery in their workflows and applications. Those of you familiar with this data from our SaaS platform already understand how impactful it can be. For example, users can include Google 3D cities in their Cesium Stories – no-code geospatial presentations. Or, they can combine Bing Maps Aerial imagery with Cesium World Terrain and their own data to create the foundation for a high-resolution, precise 3D digital twin. 

Accessing Google and Bing data is easy – just configure a secure connection between a Cesium ion SaaS account and a Cesium ion Self-Hosted account. Any Self-Hosted environment that can connect to the Web can also stream Google and Bing data with SaaS. 

Cesium ion SaaS quotas apply to the use of Bing and Google data with Self-Hosted. Contact your account manager if you need a monthly quota increase.

The hybrid “Web + Closed Network” approach to making Google Photorealistic 3D Tiles and Bing imagery available in Cesium ion Self-Hosted

Customers license Cesium ion Self-Hosted and Cesium 3D Global Content to jumpstart their 3D geospatial projects, and they regularly ask us for access to Google Photorealistic 3D Tiles and high-resolution imagery like Bing’s to get them to the finish line more quickly and with high visual quality. We’re thrilled to now be able to say “yes” to many of these requests.

Cesium ion Self-Hosted with Bing and Google data assets added from Cesium ion SaaS

Existing customers can get started with hybrid data today by upgrading to Cesium ion Self-Hosted v1.3. Not yet a Self-Hosted customer? Contact us to learn more.

Geocoding is a capability that allows user-entered locations to be converted to coordinates, typically so the user can be navigated to that place. Cesium ion SaaS provides geocoding in several user interfaces.

When Self-Hosted is connected to a SaaS account:

Geocoding is available in the Self-Hosted user interfaces for Clips, Stories, and the Location Editor for My Assets. 

Geocoding is available through the Cesium ion Self-Hosted API so you can include geocoding features in your own solutions.

Your Cesium ion SaaS quota applies to the use of geocoding with Self-Hosted. Contact your account manager if you need a monthly quota increase.

Self-Hosted v1.2 added clipping, announced previously for use in SaaS. Clips allow users to download 3D geospatial data as 3D Tiles or glTF to add real-world context to streaming or disconnected applications. For example, users can bring their architectural visions to life in offline presentations or keep security personnel safe with disconnected geospatial intelligence while they navigate dangerous situations.

As of v1.2, Self-Hosted users can import source data from Amazon S3 and export tiled asset data to S3, making it easier to integrate tiling into broader workflows and automated processes. See our documentation for more details.

Self-Hosted v1.3 also includes bash scripts for running the tiling pipeline via command line as an alternative to running it in Docker.  While Docker is still required, this will be easier and more convenient for users unfamiliar with Docker. See our documentation for more details.

Tiler Performance and Quality Improvements

We made multiple tiler updates since December, including:

Significant performance improvements for the reality tiler

Point cloud tiling now supports and preserves all point record format field data (metadata). See our blog post for more details.

Performance and other improvements for the buildings tiler for KML and CITYGML

In addition to streaming Google and Bing data to Self-Hosted, since December, Cesium announced the following new data offerings that can be licensed for use with or without Self-Hosted:

Cesium World Bathymetry and a corresponding version of Cesium OSM Buildings

Cesium Japan 3D Buildings - Sapporo City in Cesium for Unreal

Vexcel 3D Cities data of NYC in Cesium for Unreal.

For information on other Cesium ion Self-Hosted enhancements and fixes, see the full Cesium ion Self-Hosted change log.

We’re proud of how valuable our customers tell us Cesium ion Self-Hosted is to their organizations, and we want to continue advancing. Contact us through your account team or on our community forum to let us know about other ways we can improve Cesium ion Self-Hosted.

Cesium ion Self-Hosted Updates: S3 Integration, Google and Bing Data Available Through Streaming, and More

Today, we’re announcing the new Reality Tiler for 3D photogrammetry and reality models as part of 3D Tiling Pipelines included in Cesium ion and on-premises products. 

The 3D geospatial community has seen explosive growth in the capture, processing, streaming, and consumption of 3D models derived from photogrammetry and reality scans. Because users are capturing higher resolution data more frequently than ever before, our 3D Tiling Pipeline is engineered to produce the most optimized 3D tilesets for streaming, runtime visualization, and analytics.

With thanks to the user community and industry partners who contributed feedback, here are the major features updates:

Improved Scalability and Robustness for Photogrammetry Models

The new Reality Tiler is designed to scale for massive 3D photogrammetry models and improves robustness and error reporting. It takes advantage of multi-core parallelism, out-of-core memory management, and other computer graphics research to scale massive reality models and optimize 3D tilesets. The Reality Tiler decreases the tileset size, and improves tiling speed, runtime load latency, and visual quality compared to the existing 3D Model Tiler. 

Source Data            |Tiler         |Tileset Size|Tiling Time|Avg. Load Time
-----------------------|--------------|------------|-----------|--------------
AGI HQ                 |3D Model Tiler|36 MB       |1:45       |1.48s |
||**Reality Tiler**|**61 MB**        |**0:52**       |**2.54s** |
Osaka                  |3D Model Tiler|4.3 GB      |26:02       |4.64s |
||**Reality Tiler**|**1.74 GB**    |**26:08**       |**3.97s** |
Discovery Space Shuttle |3D Model Tiler|1.7 GB     |17:00:00    |4.36s |
||**Reality Tiler**|**1.61 GB**     |**1:31:39**     |**2.37s** |



Performance comparison between 3D Model Tiler and new Reality Tiler. There may be some variations depending on the source data and model characteristics. 

Visual Comparison between 3D Model Tiler (Left) and the new Reality Tiler (Right). AGI HQ.

Visual Comparison between 3D Model Tiler (Left) and the new Reality Tiler (Right). Osaka, Japan. 

Visual Comparison between 3D Model Tiler (Left) and the new Reality Tiler (Right). Space Shuttle Discovery.

3D Tiles 1.1 Tilesets and Implicit Tiling

The 3D Tiles 1.1 specification is designed for streaming high-resolution, semantically-rich 3D geospatial data to the metaverse. 3D Tiles 1.1 added Implicit Tiling for improved analytics and random access to tiles and several glTF extensions for fine-grained metadata storage.

The Reality Tiler uses Implicit Tiling and glTF extensions to optimize 3D tilesets. Implicit tiling enables random access to any tile, or any number of tiles needed to display or analyze a region. This is useful for large-scale simulations or analytics based on spatial queries or ray marching. It also enables future capabilities like streamlined partial updates to a subset of a 3D tileset.

Implicit Tiling produces predefined levels of detail and bounding volumes in the tileset which can be randomly accessed. Runtime engines can select the best tiles faster for any given view or analytics.

KTX 2.0 is a glTF extension that enables compressed textures for transmission and runtime use across GPU vendors, reducing GPU memory, bandwidth, and power usage. The Reality Tiler uses  KTX 2.0 with ETC1S compression which decreases the texture storage in 3D tilesets by 10-30%, improves loading time by an average of 30%, and decreases runtime GPU memory usage by over 80% compared to 3D tilesets with JPEG textures, while maintaining comparable visual quality. Tiles stream and load faster, while consuming less memory, allowing you to optionally increase the level of detail. KTX 2.0 compression is enabled by default on Cesium ion for all models processed by Reality Tiler. All Cesium runtime engines already support KTX 2.0 to ensure cross-platform functionality.

In addition to KTX 2.0 Texture Compression, the Reality Tiler includes Draco compression for meshes and also adds support for Meshopt compression.

|                         |         | Tileset Size               | GPU Texture Memory     | Avg. Load Time per Tile |
|-------------------------|---------|----------------------------|------------------------|-------------------------|
|        Melbourne        | JPEG    | 7.73 GB                    | 2200 MB                | 199 ms                  |
|                         | **KTX 2.0** | **3.21 GB (58.47% reduction)** | **219 MB (90% reduction)** | **46 ms (76% faster)**      |
|          AGI HQ         | JPEG    | 68 MB                      | 187 MB                 | 19.596 ms               |
|                         | **KTX 2.0** | **61 MB (10% reduction)**      | **24 MB (87% reduction)**  | **19.014 ms (3% faster)**   |
|          Osaka          | JPEG    | 2.58 GB                    | 484 MB                 | 24.364 ms               |
|                         | **KTX 2.0** | **1.74 GB (32% reduction)**    | **64 MB (86% reduction)**  | **19.929 ms (18% faster)**  |
| Discovery Space Shuttle | JPEG    | 2.25 GB                    | 696 MB                 | 28.756 ms               |
|                         | **KTX 2.0** | **1.61 GB (28% reduction)**    | **127 MB (81% reduction)** | **19.769 ms (31% faster)**  |

Tileset Size, GPU Memory, and Load Time Comparison between 3D Tiles 1.1 tilesets using JPEG and KTX 2.0. Runtime usage measured using CesiumJS 1.110.

Visual comparison between 3D Tiles 1.1 tilesets using JPEG (Left) and KTX 2.0 (Right). Visual quality is preserved when using KTX 2.0 compression.

One of the most requested features is support for coordinate reference system information built into the 3D meshes. Previously, models were tiled in local coordinates, which could then be positioned using the 3D geolocating tool on Cesium ion.

The Reality Tiler can convert known projection systems to WGS84 so that they are accurately positioned in a global reference system. Coordinate Reference System support is available to on-premises users at launch as we work to enable this in Cesium ion. Support for projection information in metadata files from various photogrammetry and reality mesh software tools is also on the roadmap.

The new Reality Tiler will be the default for all 3D Capture / Reality Model / Photogrammetry data types. By default, the tileset will be tiled with KTX 2.0 texture compression and Draco geometry compression.

If you are using the Cesium ion REST API to upload your models, you will need to set the sourceType to 3D_CAPTURE with targetVersion to 1.1. Set the geometryCompression to DRACO (default) and set textureFormat to KTX2. For more details, refer to the create a new asset documentation.

We’re excited to share this release with the Cesium community. As we further improve and optimize the pipeline, we’d like your input to help focus our efforts. 

Support for Rich Semantic Metadata using 3D Tiles 1.1: AI-generated semantic metadata is aiding in better decision making and analytics. Preserving and generating semantic metadata information in 3D tilesets can be used for visual styling, autonomous simulation, training, and more. 

Improve coordinate system and metadata support: The automatic parsing of projection information in sidecar files that are often included in 3D Photogrammetry and reality modeling software.

Upgrade path in Cesium ion and Cesium ion on-premises: We’re exploring mechanisms to allow users to upgrade 3D Tiles 1.0 tilesets to 3D Tiles 1.1.

We welcome feedback and feature requests to support your photogrammetry use cases on the Cesium Community Forum.

Try out the new Reality Tiler on Cesium ion today.

New Reality Tiler Optimizes 3D Tiles for Photogrammetry and Reality Models

In order to better serve our users and partners, we are excited to share that Cesium has improved streaming speed in the Asia-Pacific region. Effective immediately, performance for existing Cesium ion applications in this area of the world have significantly improved. 

Users’ own assets as well as Cesium World Terrain, Cesium OSM Buildings, and more, will now stream to end users much faster. This update improves Cesium ion’s speed in Japan by up to 152%, Singapore by 43%, and Australia by 39%.

On the left, a view of Tokyo using Cesium OSM Buildings, Cesium World Terrain, and Sentinel-2 imagery being streamed from Cesium ion into CesiumJS before the change. On the right, the same exact view and application loading much faster after the performance improvements.

Cesium ion Streaming Improvements in APAC Region

Cesium ion stores assets in an Amazon S3 bucket in the us-east-1 region (North Virginia).  In our initiative to drive down per-tile latency and improve streaming performance, we have replicated new and existing assets from us-east-1 to ap-northeast-1 (Tokyo, Japan). The replication will allow newly uploaded assets to be retrieved from ap-northeast-1 within roughly 15 minutes of being uploaded and existing objects should benefit from this immediately with no change to existing Cesium ion Clients.

To accomplish the latency reduction, Cesium ion implemented cross-region replication within Amazon S3 for newly uploaded objects and utilized S3 Batch with S3 inventory reports to replicate existing objects. This has allowed Cesium ion to replicate billions of objects to our destination region quickly and efficiently. To select the most optimal region to fetch assets from, we utilize Lambda@Edge functions to accomplish this and append the region to the request’s URI via our API server. Next, the request will be sent to our CDN that runs on Amazon CloudFront which checks the region in the URI and proxies the request to the appropriate region for origin requests.

Cesium strives to continuously reduce latency for users globally. Sign up for a free community account or sign in to experience these improvements. 

アジア太平洋地域におけるCesium ionの大幅なパフォーマンス改善

皆さんにより良いサービスを提供するため、Cesiumはアジア太平洋地域、特に日本におけるCesium ion のストリーミング速度を大幅に改善しました。これにより、この地域でCesium ionをお使いの方には、アプリケーションのパフォーマンス改善を即座に実感いただけます。

ユーザー自身のアセットだけでなく、Cesium World Terrain、Cesium OSM Buildingsなどが、より速くエンドユーザーにストリーミングされるようになりました。このアップデートにより、日本では最大152％、シンガポールでは43％、オーストラリアでは39％、Cesium ionの速度が向上しました。

Cesium ionは、us-east-1リージョン（米国バージニア州北部）のAmazon S3バケットにアセットを保存しています。 タイルごとのレイテンシを削減し、ストリーミングパフォーマンスを向上させる取り組みとして、新規および既存のアセットをus-east-1からap-northeast-1（日本、東京）にレプリケートしました。このレプリケーションにより、新規にアップロードされたアセットは、アップロードされてからおよそ15分以内にap-northeast-1から取得できるようになり、既存のオブジェクトは、既存のCesium ionクライアントに変更を加えることなく、すぐに利用が可能です。

レイテンシの削減を達成するために、新しくアップロードされたオブジェクトにはAmazon S3内でクロスリージョンレプリケーションを実装し、既存のオブジェクトにはS3インベントリレポートとS3 Batchを利用しました。これにより、Cesium ionは何十億ものオブジェクトを迅速かつ効率的にデスティネーションリージョンにレプリケートできるようになりました。アセットをフェッチするために最適なリージョンを選択するには、Lambda@Edge関数を利用し、APIサーバー経由でリクエストのURIにリージョンを付加しています。次に、リクエストはAmazon CloudFront上で動作するCDNに送られ、CDNはURI内のリージョンをチェックし、オリジンリクエストに対して適切なリージョンにリクエストを送信します。

Major Performance Improvements for Cesium ion in Asia-Pacific

We recently added an option in Cesium for Unreal for smoother transitions between levels of detail with dithered opacity masking. Enabling this option provides a more seamless viewing experience for end users with minimal rendering overhead. 

3D Tiles is an OGC Community Standard that enables seamless streaming and rendering of large datasets while minimizing the network and system costs of doing so. The 3D Tiles hierarchical level-of-detail (HLOD) helps achieve this by enabling different levels-of-detail to be used for different parts of the scene at the same time. Tiles further away from the camera can be streamed and rendered at a lower level-of-detail (LOD) than tiles up close to the camera which are rendered at higher detail. Taken together, these tiles of varying LODs stitch together to cover the entire scene.

This HLOD approach necessitates that tiles often transition between higher and lower levels of detail as users move around the scene. Switching between tiles immediately allows users to see the target detail level as soon as it is loaded and ready to render, but it can feel quite frantic and jarring since the LODs switch so suddenly. This effect is known as “LOD popping.”

Fig 1.0: A typical viewing experience in Cesium for Unreal without any LOD blending. Notice how snappy and frantic tile transitions are.

In most cases, LOD popping can be greatly minimized by making tile transitions slightly longer and more gradual.

To address LOD popping in Cesium for Unreal, we have recently added the Use LOD Transitions option on the Cesium3DTileset actor. Our approach makes a careful tradeoff between LOD popping, tile load latency, and rendering cost. The goal is to ensure that the dithered transition length does not cause notable latency, but still has enough transition overlap to hide the LOD switching. An additional factor taken into account is to avoid too many tiles fading in or out simultaneously as that could lead to a spike in draw calls during camera movements. 

Fig 2.0: A similar viewing scenario to Fig 1.0, except dithered LOD transitions are now enabled. Notice how much smoother the transitions appear in comparison.

Using a translucency-based effect to blend LODs may be tempting, but it comes with several performance drawbacks. In Unreal Engine, translucent objects are rendered in a separate forward-only render pass after the opaque parts of the scene are drawn with the deferred rendering pipeline. The translucency render pass disables depth testing and composites translucent triangles back to front—this requires that translucent triangles are sorted by distance in each frame. The lack of depth testing causes significant overdraw, and the triangle sorting can get quite computationally expensive. Translucent objects are also not written to the depth buffer, which means they cannot be used to occlude other objects during occlusion culling.

It turns out that transparent rendering is complicated because of partial transparency. If a material has opacity values that are always 0 or 1 (fully transparent or fully opaque respectively), rendering the material becomes much easier. In Unreal Engine, this concept is called “opacity masking.” In opacity masked materials, the opacity value is determined in a fragment shader, usually by sampling from an opacity mask texture. This shader code runs during the depth pass in addition to the base opaque pass. This means that apart from the potential extra texture samples during both passes, opacity masked objects get rendered in the exact same way as opaque objects. They can even act as occluders since they get drawn into the depth buffer.

Opacity masking is a flexible and performant technique that is already used in another part of Cesium for Unreal—we use opacity masks to clip 2.5D regions out of tilesets. 

Fig 2.1: A common example of opacity masking in Cesium for Unreal—the Cesium Polygon Raster Overlay can be used to clip 2.5D regions out of tilesets.

Dithering is a concept borrowed from digital signal processing—it refers to the process of adding noise to a digital signal in order to make it appear analog. In Unreal Engine, dithering refers to a screen-space sampling of white noise that is thresholded at a provided grayscale value per-fragment. The threshold value can be ramped up or down over time to get the dithered effect to dissolve into or out of the screen.  

Fig 2.2: Unreal Engine’s “Dither Temporal AA” node samples this tileable, white noise texture using screen-space UVs and thresholds the result against an alpha value.  

The dither value can be used as an opacity mask to roughly mimic partial translucency for a fraction of the cost. When combined with anti-aliasing, dithered opacity masking becomes a rough monte-carlo approximation of translucency. In Cesium for Unreal, the dithered opacity mask threshold is ramped up throughout the LOD transition to fade from the old tile to the new tile.

As the name suggests, the “Dither Temporal AA” material node works best with temporal anti-aliasing (TAA). If TAA is enabled, the sampled noise changes every frame so that the temporal accumulation ends up blending the foreground and background together over several frames to very closely mimic translucency.

As briefly mentioned already, the LOD fading is implemented by changing the dither threshold over time. Both tiles use the same threshold value and as a result get the same screen-space dither value. The fading-in tile however, inverts the dither value before plugging it into the opacity mask. This allows both fading tiles to stitch together water-tight during the transition.

Fig 2.3: A RenderDoc capture of Unreal Engine during a dithered LOD transition—the frame is only partially rendered at this point. In the foreground, several transitioning tiles are seen after the dithered opacity masking is applied. Notice the black, missing pixels that need to be filled in with the complementary dithered tiles.

Fig 2.4: This is the same frame from Fig 2.3, after a few more draw calls. Notice how the complementary transitioning tiles have now been painted in.

Fig 2.5: The depth test result of one of the complementary dithered tiles. Notice how the tiles continue to form a water-tight rendering while avoiding overdraw between fading-in and fading-out tiles.

Dithered opacity masking is significantly more performant than the translucency approach. In comparison to translucency, dithered opacity masking has essentially no overdraw, no depth sorting cost, no extra lighting cost, and no negative effect on occlusion culling. However, the implicit cost of LOD blending remains—both LODs have to be drawn at the same time during the transition period. Transitions also have to be animated with a uniform update every frame. This means that too many tile LOD transitions happening at the same time will lead to a temporary spike in both draw calls and uniform updates. We chose 0.5 seconds as the default transition length to balance transition smoothness, apparent latency, and GPU spikes. Longer transition lengths will lead to bigger spikes and increased latency.

These improvements and others are available as of Cesium for Unreal v1.17.0, available now on Unreal Marketplace and on GitHub. If you already have Cesium for Unreal, update the plugin version from the Epic Games Launcher.

Try out dithered LOD transitions by enabling Use LOD Transitions on any Cesium3DTileset actor. If your tileset uses a custom material, you will have to add the ML_DitherFade material layer to your material.


If you are new to Cesium for Unreal, this is a great time to try it out—check out our Quickstart Tutorial to get started!

Smoother LOD Transitions in Cesium for Unreal with Dithered Opacity Masking

As part of our ongoing effort to optimize Cesium for the smoothest user experience, we’re excited to announce some big improvements to 3D Tiles streaming performance. Combined with the recent WebP support and the latest CesiumJS 1.57 release, 3D Tiles now loads between 2x to 10x faster and loads about 27% to 53% fewer tiles on average!

CesiumJS is positioned to take advantage of data acquisition trends, now and in the future, including higher resolution and more frequent, time-dynamic collects. These changes enable smoother streaming of everything from photogrammetry to point clouds across all devices, from phones to high-end desktops. To take advantage of these features, simply update to the latest CesiumJS 1.57. If you like to get your hands dirty and tune the parameters, see the 1.57 release notes for more details.

We stream 3D Tiles faster by reordering tile requests to prioritize visually significant tiles and by loading fewer tiles, ignoring or delaying unnecessary tiles.

One of the most noticeable improvements is the order in which tiles load. We updated Cesium’s 3D Tiles request pipeline to better prioritize tiles based on how significant they are to the scene. This greatly cuts down the perceived load time since scenes now load visually important tiles first. This allows you to see what you need right away even while details far in the horizon are still streaming in.

To figure out the priority of a tile, several metrics are taken into account such as depth in the tileset, distance to the center of the screen, and distance from the camera.

Tiles colorized by how close they are to the center of the screen. This is a 3D tileset of New York City, captured by Nearmap.

Since we often know where the camera is headed, we can start preloading tiles before we even get there. In practical terms, it means you can now use the flight duration to hide the load time of the final view of the camera flight. For example, if the flight duration is 2 seconds and the time it takes to load all the tiles at the final destination is 2 seconds, all the tiles will be ready by the time the camera gets there.

Preloading the flight destination (right) means tiles can be made available immediately once the camera gets there.

Progressive resolution: load tiles satisfying screen space error at a lower resolution first.

An example load time comparison colorized as a heatmap. Updated system on the right. Blue and purple loaded early while yellow loaded last.

The updated priority system helps get something rendering in all parts of the scene in about half the time as the old system and about half the time to fully resolve all tiles near the center of the screen.

We’ve also added several updates to conserve bandwidth and cull requests that are not necessary. These updates help with streaming efficiency during camera motion to remove tile requests that are no longer needed.

In situations where the camera is moving, a tile may be waiting on a request but no longer be in view. In these cases, we cancel the request. We can also try to predict which tiles are likely unnecessary to request, i.e., likely to go off camera by the time the request resolves.

In virtual reality rendering less effort is placed on the periphery of the screen to render at full fidelity. This is because our visual acuity falls off aggressively from the center of our field of view. Borrowing this idea, the required level of detail can be modified based on an off-center measurement. Requests for these levels of detail on the edge of the screen can be deferred, i.e., they get requested after the camera has been motionless for some period of time.

In terms of total load time, some of these systems can help a lot in specific but common situations (camera flight destination preloading) while others help in all cases (request culling systems). Similarly, the new priority system can help resolve the areas of the screen that are important much faster while also helping with worst-case scenarios like slow bandwidth and screen resolution scaling. Across all data types, we’ve seen dramatic improvements in 3D Tiles load times.

| 3D Tileset| Loading in Flight	| Loading in General|
| ----------- | ----------- | ----------- |
| Photogrammetry| 10.0x faster	| 2.0x faster|
| Point clouds	| 7.1x faster	| 2.8x faster|
| 3D Buildings	| 5.5x faster	| 2.3x faster|

All of these features are on by default in CesiumJS 1.57. Upgrade your app to take advantage of these new features. If you aren’t already using 3D Tiles you can sign up for a free ion community account to tile and host your data.

With the most recent CesiumJS release, terrain and imagery now load 32% faster on average and request significantly fewer tiles - meaning your data usage in Cesium ion is about to go down. This is part of a continuing effort to optimize CesiumJS for the smoothest end user experience across all types of devices, which is increasingly important as more and more 3D geospatial data is available.

High resolution terrain in San Isabel National Forest, Colorado loads in almost instantly

This update provides wins across the entire Cesium platform. Instead of loading every lower level of detail and refining, the new algorithm streams higher resolution tiles sooner so you can view precise terrain features quickly after you zoom in. In particular, the highest resolution terrain loads more than twice as fast for views close to the ground.

Loading a view of the Grand Canyon before and after these performance improvements

Skipping loading in lower resolution tiles also results in less data usage as you interact and navigate around your Cesium apps. We saw a 33% reduction in data usage across different views both close to and far away from the surface. This means your app streaming Cesium World Terrain from Cesium ion can get more views while remaining within your usage limits. It also means better performance on mobile devices, which tend to have less bandwidth and more data restrictions than traditional computers.

|       | Before| After| Results|
| ----------- | ----------- | ----------- | ----------- |
| Grand Canyon| 4.82 seconds	| 3.39 seconds	| 29.6% faster|
| Mount Everest| 5.03 seconds	| 3.85 seconds	| 23.5% faster|
| Cesium Headquarters	| 2.79 seconds	| 1.16 seconds	| 58.2% faster|
| Total data usage	| 19.7 MB	| 13.3 MB	| 32.5% less data|

A big thank you to Kevin Ring and Data 61, the developers of the open source TerriaJS framework, for implementing this feature.

Start tiling and streaming your own terrain and imagery data today by signing up for a free ion community account.

Improved CesiumJS Terrain Rendering = Less Cesium ion Data Usage

Point clouds now load faster than ever in Cesium thanks to Google Draco compression, which we’ve added to the Cesium ion 3D tiling pipeline.

Our 3D tiling pipeline efficiently tiles full-resolution point clouds into 3D Tiles, an OGC community standard, so they can be streamed into CesiumJS for visualization and analysis in the browser.

We had previously collaborated with Google to bring Draco compression optimizations to our tilers for massive mesh-based 3D tilesets, such as massive photogrammetry models and millions of 3D buildings. We saw dramatic results: the compression resulted in 5x smaller file sizes and faster streaming.

So we brought the same technique to massive point clouds, which can be billions of points or more, with each point having multiple attributes. With the open Draco format, we’re producing 3D tilesets with:

7.0x compression for 1mm precision (compared to source LAS)

4.4x compression for 1mm precision (compared to uncompressed 3D Tiles)

Not only does Draco encoding lead to smaller file sizes; it decodes very quickly, so these tilesets stream twice as fast with no loss in visual quality.

This means users can efficiently stream full-resolution point clouds into CesiumJS, even on mobile. The compression preserves all original data, so per-point attributes are all retained and can still be styled for analysis. And it makes it easier than ever to fuse point clouds with other 3D data, such as photogrammetry models or terrain.

Read on for more details about how Draco encoding has led to dramatically smaller file sizes and faster streaming, as well as how we’ve taken best advantage of the available options and optimizations.

High-resolution point cloud of the historic Pharsalia cabins in Virginia, with millimeter precision. Collected by Trimble and shown in CesiumJS.

The point cloud 3D Tiles format already includes several options for compressing point data:

16-bit quantization for each x, y, z position component

Draco, a quantization-based compression method, is an open format that is similar in spirit but offers some key advantages:

Order-optimized encoding: the Draco encoder rearranges points for optimal compression using a KD-tree based encoder.

Generic attributes: Draco can compress generic attributes such as intensity and classification.

Configurable compression: a point cloud can use anywhere between 1 and 31 quantization bits depending on the tolerated lossiness. The compression can be tuned for millimeter or better precision.

Dramatically smaller files with Draco encoding

What does this mean for overall tileset size? We ran the numbers on a section of the Pharsalia cabin point cloud collected by Trimble. The 3D point cloud has 185 million points with color, intensity, and classification attributes.

| 3D Tiles + Gzip    | 3D Tiles Draco + Gzip |
| ----------- | ----------- |
| 1.83 GB      | 0.64 GB       |

|       | Total tileset size |
| ----------- | ----------- |
| Source LAS (Point Format 2)     | 4.48 GB|
| 3D Tiles Uncompressed| 2.93 GB|
| 3D Tiles + Gzip	| 1.83 GB|
| 3D Tiles 16-bit Quantization	| 1.90 GB|
| 3D Tiles 16-bit Quantization + Gzip	| 1.58 GB|
| 3D Tiles Draco (1 mm precision)	| 0.67 GB|
| 3D Tiles Draco (1 mm precision) + Gzip	| 0.64 GB|

7.0x improvement compared to the source LAS

4.4x improvement compared to the uncompressed tileset

2.7x improvement compared to the gzipped tileset

2.4x improvement compared to the 16-bit quantized and gzipped tileset

With Draco compression we were able to produce a tileset that is 7.0x smaller than the source LAS and 2.4x smaller than our previous best case. This is a nice win with no noticeable difference in visual quality. We also confirmed our suspicion that gzip would not help out significantly when applied to an already Draco compressed tileset.

Next we experimented with some of the Draco specific options. First we looked at how different precisions would compare visually. It was pretty obvious once we loaded them side by side in CesiumJS:

While this particular point cloud requires millimeter precision, other point clouds such as those collected from aerial LiDAR may look acceptable with centimeter-scale precision.

At runtime CesiumJS continually streams in new point cloud tiles to refine the current view. Since Draco-compressed tiles are smaller they are faster to download. Once downloaded, they are decoded and sent to the GPU. To improve overall loading speed, CesiumJS decodes point cloud tiles in parallel with Web Workers.

| 3D Tiles + Gzip      | 3D Tiles Draco + Gzip |
| ----------- | ----------- |

For this test we hosted each tileset on Cesium ion with the browser cache disabled:

|       | Refinement speed |
| ----------- | ----------- |
| 3D Tiles      | 9.79 seconds       |
| 3D Tiles Draco (1 mm precision)   | 4.45 seconds        |

Next we ran the same benchmark but with the tilesets hosted on the local disk. Here the CPU decode became the bottleneck and we saw opposite results:

|       | Refinement speed |
| ----------- | ----------- |
| 3D Tiles      | 1.75 seconds       |
| 3D Tiles Draco (1 mm precision)   | 3.36 seconds        |

Overall there is some variability based on network and decoding speed, but in the common case where content is streamed over the web, the Draco tileset is the clear winner. The Draco decoder is fast enough that network speed is often the bottleneck.

For a more in-depth overview of the optimizations we use to load Draco content, check out our previous post Draco for glTF and 3D Tiles. Point clouds use the same two techniques - parallel decoding and GPU dequantization - to get the best performance out of the hardware. We decode on the CPU using Web Workers and the Draco Web Assembly module. The decoder returns array buffers in 16-bit quantized form that we then upload to the GPU. The final decode from 16-bit quantized integers to 32-bit floats occurs on the GPU, which effectively saves us half the GPU memory usage.

We also explored some optimizations on the encoding side. Draco allows us to apply any number of quantization bits to each attribute. In general we found that 8–16 bits works well for positions, and 8 bits is generally sufficient for colors, normals, and generic attributes. Attributes can also be encoded losslessy, so it is possible to write a tileset that contains, for example, lossless positions and lossy intensity values.

The number of quantization bits we use for positions is largely dependent on tile size and our desired precision. For instance, if we are targeting a resolution of one point per centimeter, a one meter cubed tile requires only 7 quantization bits (6.644 to be exact, but rounded up). If instead we want millimeter-scale precision the same tile requires 10 quantization bits. In either case this is a huge improvement over the original 16-bit quantization option.

Because of this flexibility, most tilesets will contain a mix of compression amounts. The tilesets we tested contained tiles that used anywhere from 7 to 16 quantization bits for positions. Considering that most tilesets consist of some large tiles and many more small tiles, the average was close to 8 bits and only the root tile required 16 bits of precision.

You can take advantage of these optimizations today. Any point clouds uploaded to Cesium ion are now Draco encoded, providing a performance boost when streaming them into your Cesium-based app.

Compressing Massive Point Clouds with 3D Tiles and Draco

We're happy to announce that 3D Tiles now supports Google's WebP image format. WebP lossy compression is 25-34% smaller than JPEG images at the equivalent quality, and WebP lossless is 26% smaller in size compared to PNGs.

This means that any 3D Tiles that require massive textures - such as photogrammetry, CAD/BIM, and 3D buildings - can now be compressed to a much smaller file size without sacrificing quality. And, these smaller tilesets are streamed over the network a lot faster. You can see this in action in the animation below.

The 3D tileset using WebP (left) finishes loading ~36% faster than the JPEG version (right). This is a 3D tileset of New York City, captured by Nearmap.

At Cesium, we're constantly thinking about how to improve performance and visual quality. WebP was created to allow web developers to create smaller, richer images that make web pages faster. So we couldn't be more excited to collaborate with Google to bring this modern format to the geospatial world in 3D Tiles as an official glTF extension.

The best way to speed up streaming massive 3D content over the browser is to send less data. This is why Cesium ion uses compression like Draco to compress geometry along with gzip to reduce the amount of data going over the wire whenever possible.

For photogrammetry and 3D buildings, images often make up the largest percentage of the overall tileset size. For example, 78% of the content downloaded while loading the view below is image data.

3D Tileset of Melbourne, Australia, captured by AEROmetrex. The total file size of this tileset is cut down by 39% by switching to WebP images.

The total size of this 3D tileset with JPEG images is 11.3 GB. This was cut down to around 6.85 GB once we switched to WebP images. This means that not only does each view resolve much faster, but the total amount of bandwidth used across the lifetime of the application is also cut down significantly. This also translates to cheaper streaming and storage for services that charge for bandwidth used.

Another way to think about this is that WebP allows us to use higher quality images using the same amount of storage and bandwidth compared to JPEG or PNG.

WebP supports transparency and lossless compression

Another big advantage of using WebP is that, unlike JPEG, it supports images with transparency. Traditionally, if your images required transparency you were forced to use PNG, which could drastically bloat the total file size of the tileset.

In situations where lossless compression is required, WebP's lossless compression is still smaller than PNG. The tables below show the file sizes for the different image formats of the 8192x8192 texture atlas used in a photogrammetry tileset of our headquarters.

| Lossless Compression | Size |
| --- | --- |
| PNG | 63 MB |
| WebP Lossless| 43 MB |

| Lossy Compression | Size |
| --- | --- |
| JPEG | 6.93 MB |
| WebP Lossy | 5.30 MB |

Below is what this image looks like encoded with lossy WebP.

If you can see this image, your browser supports WebP! 

A scaled down WebP lossy version of a texture atlas used in a photogrammetry tileset of AGI headquarters.

While WebP is rapidly gaining adoption, it is not yet supported everywhere. Tilesets that use WebP images require CesiumJS 1.54 and a compatible browser such as Chrome or Firefox 65 or newer.

Creating a 3D tileset with WebP images is an option in Cesium ion today. Try uploading your photogrammetry or CAD/BIM data to Cesium ion and toggling the Use WebP images option.

You can use WebP by activating the highlighted toggle when tiling your data on ion.

This will create a tileset with images using WebP's lossy compression. We've also added new options in the Cesium ion On-Premise command line interface to let you explore changing the quality setting for lossy compression or using lossless compression.

Faster and Smaller 3D Tiles with WebP Image Compression

Continuing with our commitment to produce the highest quality 3D tilesets, we’ve updated Cesium ion and our on-premise tools to produce photogrammetry tilesets delivering improved visual quality with the same or better performance.

To recap, Cesium ion’s photogrammetry tilesets use lightweight, simplified placeholder tiles for smoother streaming. CesiumJS renders these tiles temporarily while full-detail tiles stream in, or at areas far away from the camera where full detail is indistinguishable, which uses fewer network resources.

The updated photogrammetry tiling pipeline produces smoother, less distorted placeholders without significantly increasing tile size, which improves visual quality when loading views over constrained network connections. This is especially apparent with wide views of large-area, high-detail datasets like this 10-centimeter model of Melbourne, Australia, captured by Aerometrex:

Melbourne, Australia, captured by Aerometrex and tiled using different versions of the Cesium ion Photogrammetry tiler. Pre-update tileset on the left, updated tileset on the right. The updated tileset becomes recognizable more quickly.

For a closer look, here’s a comparison of our AGI Headquarters model before and after the tiler updates. This comparison has been slowed down and edited to highlight the first few LOD changes. Observe the difference as the tilesets load:

AGI HQ model, tiled before (left) and after (right) tiler updates. Window and sidewalk lines are smoother and less distorted at low LODs (earlier in the animation) with the updated tileset.

The first tile in the updated tileset presents a better summary of the building without increasing rendering cost or load time. Transitions between levels-of-detail are also smoother and less jarring.

The updated placeholders are also sufficient as-is for far-away views when smooth performance is more important than accuracy, such as on mobile devices with small screens and limited bandwidth. Apps with high-precision modes also benefit when rendering bird’s eye overviews instead of measurement-quality closeups.

Rendering placeholders when acceptable reduces the total number of requests and overall data streamed. Here’s two versions of a distant view over Melbourne with only 23 tiles:

Compare 23 tiles from the earlier tileset on the left with 23 tiles from the updated tileset on the right. Note the reduction in visual artifacts and cleaner appearance.

Reduced visual artifacts make the 23 placeholder tiles usable over a wider range of view distances. This gives developers more flexibility when balancing visual quality against load time and rendering performance.

Try the photogrammetry tiling updates today by signing up for a free ion community account, or evaluating our on-premise 3D Tiling Pipeline.

Cesium ion Photogrammetry Update - Smooth 3D Tiles, Smooth Performance

One of our biggest goals for this year is to improve rendering results when terrain is enabled in CesiumJS. As part of this effort, we’ve added support for new features like textured polygons on terrain and polylines on terrain. Additionally, we decided to make some substantial improvements to the way billboards and labels render when they’re clamped to terrain.