Thoughts on Cesium.js

If you’ve ever seen Cityzenith before, you would know that the basic premise is a 3D Google Earth like world in the browser. The way we accomplish this is using a JavaScript library called Cesium. There is much to like about Cesium and if you’ve never checked it out I highly encourage you to do so. Not only is Cesium we’ll supported/developed, it has a great community around it and lots of great documentation. Cityzenith had been on Cesium for years and you’ll see our screenshots on the Cesium webpages as a use case. When our customers first see Cesium running in the browser they’re all very excited and impressed with how well it works, how good it looks, and we’ve built a business around it. But in August we decided to go another direction and move to Unity3D. I’ll write more about that move later but this is a post on what worked for us with Cesium, where we had problems and what you can expect if you use it. If people ask me about a 3D solution in the browser, I can still equivocally say that I would recommend Cesium.

Why Did Cityzenith Choose Cesium?

The choice of Cesium predates me, so I was not involved with the decision. That said those who made the decision have explained why they went that way. Cesium was probably not the original choice but at the time in 2014/2015 it was the best solution of a game engine” for our product. We did look at other engines such as Unreal but the 64-bit support and the ease of use in the browser, Cesium won out. In implementing Cesium what were we able to do?

  1. We were able to implement a cross platform 3D world in a browser. That’s not an insignificant accomplishment. Our Cesium team really did an amazing job of making Smart World feel like a regular desktop application even if it was in a browser. No extensions to load, Java or Flash to configure. In a modern browser it basically just worked (more on this though later).
  2. While normally a pain in the rear, the fast updates and quick support for new features on the Cesium project gave us access to new features regularly. We were able to continually update our support for better graphics, performance and features almost by just loading up a new version of Cesium. Of course, in reality it is not that easy but the feature improvements were regular and powerful.
  3. JavaScript is an accessible language. Yes, it has its problems but finding people to code in JavaScript is not difficult. Plus it made it easy to combine other JS libraries we needed into the application.
  4. Open source is very liberating on many levels. Not having to fight a licensing battle and focus on the product is a nice change from other development libraries and SDKs. Also having direct access to the developers. If you don’t follow Patrick Cozzi yet you should. Amazing work and they listen to feedback.
  5. glTF support is second to none. I’ll be talking about glTF soon as well and why we absolutely love it.

Ok, so What Didn’t Work With Cesium? Why Leave It?

There are really only two reasons we have left. Most of everything else we get with Unity we would either have with Cesium very soon or it’s being implemented today. But the two reasons have been killer for Smart World. I don’t think everyone runs into the same problem we have with their apps so this is more of a specific issue with what we are doing rather than a problem with Cesium.

  1. Cross browser support. Remember when I said that we had cross platform support? Well that really only works if you use Google Chrome. Other browser support is poor at best. Microsoft Edge? Yea not going to happen. Being an enterprise app, we don’t always have the latest and greatest browsers that our customers can use. It’s not an IE8 problem but Edge and Firefox support really killed it for us. It got so bad that we had to put up a modal dialog box that basically said you couldn’t use Smart World without Google Chrome. That’s just unacceptable to us and while we tried to work on solving this the reality of support in other browsers was not coming quick enough and I’m not sure it was a problem that Cityzenith could have solved throwing money at the problem.
  2. Performance in the browser. Chrome is many things and one of them is that it is a memory hog. Loading up cities in Chrome really would put a strain on our user’s computers. The browser is great for simpler 3D mapping but streaming gigabytes of data into a browser really tasked computers. We worked on a ton of LOD workarounds but the compromises to make the application work on a typical enterprise desktop or laptop really left a bad taste in our mouths.

Roadmap for Cityzenith

We want to provide the best 3D analytical tools and we’ll continue to do so. Combined with AWS Lambda and AWS IoT services, we’re making a huge leap in how people perform spatial analysis. Not only are we working on our own planning tools such as rooftop solar analysis, LEED-ND analysis and traffic analysis, we’re integrating Rhino Grasshopper plugin support, so anyone can use their existing workflows. As I said above, we’re moving our 3D engine to Unity. In fact we’ll be having a closed beta very soon for our customers to try it out. One of the biggest reasons we went with Unity was Mapbox’s Unity SDK. We are already a big user of Mapbox and thus moving to the SDK made a ton of sense. I’ll go more into this in another article.



Date
October 30, 2017