Experimenting with a Mini Cesium Implementation in Rust

Hello everyone! Over the past year, I’ve been working on building a mini Cesium in Rust, and it has finally reached a presentable stage. This post is a short update on the project’s progress.

First, I’m very grateful to the Cesium team for their open-source work over the years. I’ve learned a lot from these projects — enough to eventually try building one myself.

The project is written almost entirely in safe Rust. The only `unsafe` code lives in the FFI bindings to Draco, which I’ve already published separately as [draco_decoder]( crates.io: Rust Package Registry ).

The Rust ecosystem has come a long way in the past few years, so I didn’t have to reinvent everything. Bevy is an excellent game engine with a high-performance ECS, and I use it as my graphics backend — it’s much easier to work with than raw wgpu. The Bevy ecosystem also offers [big_space]( crates.io: Rust Package Registry ), a plugin that solves floating-point precision problems with a floating origin.

That said, building a Cesium still required a lot of work on my side:

- A custom coordinate-system hierarchy that supports solar-system-scale simulation with sufficient precision.

- [Draco decoding]( crates.io: Rust Package Registry ) in Rust and glTF parsing in Bevy, on both native and wasm32.

- A Rust rewrite of most of Cesium’s geospatial math, referencing both CesiumJS and cesium-native.

- A planet controller — I previously contributed a similar one to cesium-unreal ([PR #1489]( Add screenspacecontroller support for cesium unreal by jiangheng90 · Pull Request #1489 · CesiumGS/cesium-unreal · GitHub )).

- A system for running heavy computation in plain Web Workers, without SharedArrayBuffer.

- Coordinate computation adapted to ECEF, integrated with Bevy’s atmosphere.

- A mini implementation of 3D Tiles with terrain and imagery.

From the start, Wasm and WebGPU support has been one of the most important design goals — on par with native. Even though I spent a lot of time optimizing the Wasm build, the Chrome 149 update caused a performance regression on macOS, where WebGPU now runs even worse than WebGL, which is a real shame. Wasm performance in general is still disappointing, with low frame rates.

Since the project is at a very early stage, there is no timeline for open-sourcing it yet, and this post makes no promises on that front.

Here are some screenshots of what it looks like now:

7 Likes