Moving GEFS Online from Google Earth to Cesium
This is a guest post by Xavier Tassin, creator of GEFS-online, about his experience migrating from Google Earth to Cesium. - Sarah
For five years I have been building GEFS-online, a free flight simulator, on the Google Earth plugin. When Google decided to retire the plugin, I made the move to Cesium as it offered the best alternative. I would like to share my experience with making that move.
It is about the same ...
Cesium and Google Earth (GE) are both visualization tools that show a globe with aerial imagery and elevation data while offering an API to interact with.
Porting a simple application from one to the other involves nothing more than adapting the API calls. For example, moving a camera to a specific location, on both platforms, involves a function call with latitude, longitude, and altitude. So if the application abstracts the API calls well enough, it is relatively easy to migrate. Only a few minor changes will have to be made: GE and Cesium reverse the latitude and longitude in their API calls, Cesium loads glTF 3D files instead of COLLADA files, etc.
... but it is different
The major technical difference is the technology behind these two platforms. While GE relied on a plugin, Cesium uses native WebGL. And this brings a lot of advantages, the first being that no download or installation is required: WebGL runs natively in modern web browsers.
Having Cesium running as a JavaScript application makes debugging a breeze compared to GE: setting a breakpoint in the debugger would make the GE plugin crash, the call-stack would not go further than the NAPI interface, etc.
WebGL is pure HTML: the Canvas element fits naturally within the HTML page and can be manipulated in a very simple way (CSS, JS). It used to be a challenge to overlay HTML elements on top of the GE plugin (iFrame shims); it is just natural with Cesium.
Finally, Cesium, thanks to WebGL, is truly cross-platform and also runs on mobile, Linux, or pretty much everything that can run a modern web browser.
The philosophy behind Cesium is also different: it is open source! Everyone is free to look at the code and eventually modify it if needed. This can really speed up bug fixing or at least help to find a workaround to some problems. This also gives some sort of guarantee about the future and the liveliness of the platform.
Dealing with the details
And of course, there are the thousands of little details that will make it a bit more difficult to port from GE to Cesium. “Portage” here really means to keep most of the original application logic and just make it work with the new platform. Here is a non-exhaustive list:
Screen overlays
Because it blocked natural HTML flow, the GE plugin forced developers to use its native “Screen Overlay” API in order to add 2D graphical elements to the scene. All the aviation instruments in GEFS were composed using this API. The non-intuitive coordinate system (reversed y-axis, anchors, etc.) made it tricky.
GEFS is now rendering all the instruments as HTML elements with CSS3 placement and rotation. It’s fast, natural, and much more maintainable.
Ground overlays
GEFS used GE’s “Ground Overlays” to render a shadow under the plane. Cesium currently lacks the ability to “drape” a texture on the ground. The solution so far is to render a square geometry with the texture mapped to it and orient the square to be perpendicular to the ground normal. This also requires depth testing to be disabled in order to prevent part of the geometry being hidden under the ground.
With the recent releases (1.22), Cesium is now able to render drop shadows. While the result is much more realistic than the simple texture trick, it may add a slight performance penalty on weaker systems. The next GEFS version will offer the choice to the users as a preference setting.
3D models
Cesium requires COLLADA models to be converted to a new standard called glTF. While better in principle, this will require some tinkering and learning in order to get nice exports. The Cesium rendering pipeline is slightly different from Google Earth’s, and converted original models may not be quite right on the first try. Online resources may help, but I found that experimenting a bit led me to a decent result.
GE plugin could not load gzipped DAE files. The alternative was to package files into a compressed KMZ archive. This required complicated development workflow (working with uncompressed DAE files) and a specific build process to generate the KMZ before any new deployment.
glTF files can be exported in a binary version (glb) that shrinks the size considerably. On top of that, they are now gzipped before traveling over HTTP, reducing their size even further.
GE plugin could not provide access to elements of a model’s geometry. GEFS implements its own scene-graph to maintain models hierarchy and handle animations (propeller, ailerons, landing gear, etc.). This involves loading hundreds of small, separate models (one for each animated part) and assembling them back in the application. For time constraint reasons, this is still the case. But Cesium allows developers to load a single model, reference any of the meshes in it, and move/rotate them directly. The next step for GEFS will be to take advantage of this.
Conclusion
It has been a relatively easy move with its share of good surprises and a few frustrations. Overall, Cesium has proven stable, robust, and performant, backed by a growing community that helps and supports its members. Open and compliant with modern standards, I believe the future is bright for Cesium as the possibilities are virtually boundless.
