Shadow Analysis Using Mapbox, Unity and OpenStreetMap

We’ve been pushing along with our latest release of Smart World Professional, and we’ve got some elegant tools coming online that will showcase why we went the route we did.  One of the biggest requests from the AEC industry is Shadow/Solar analysis.  There are tons of tools that do this, but they can be expensive, hard to use and even hard to get data for.  That’s why I really like the Mapbox Unity SDK and its 3D buildings.

You can, of course, load your own buildings into Smart World Professional but this is a great way to see how your projects will impact the surrounding city out of the box with our tools.  The Unity SDK really shines with this kind of work.

Cityzenith Smart World Professional IoT

I know, I used the buzzword IoT in my title above.  Stay with me though!  We think about IoT as a link between a physical device (your Nest thermostat for example) and the digital world (your Nest app on your iPhone), but it is so much more.  While we have been working with many IoT providers such as Current by GE we’ve also fundamentally changed how our backend APIs work to embrace this messaging and communication platform.

aws_iot_button-62b50cbaeae340c18aa411d87c86029e188caab0Using AWS IoT Services everything that happens in our backend API can alert our front end apps to their status.  This ties very nicely into our Unity front-end Smart World Professional application because it can tell you exactly what is happening to your data.  Uploading a detailed Revit model?  The conversion to glTF occurs in the background, but you know exactly where the process is and exactly what is going on.  Those throbber graphics web apps throw up while they wait for a response from the API are worthless.  Is the conversion process two thirds the way through or just 10%?  Makes a big difference don’t you think?

Where this really starts to matter is our analytics engine, Mapalyze.  If I’m running a line of sight analysis for a project in downtown Chicago, there is a ton that is going on from the 3D models of all the buildings to trees, cars and the rest that can affect what you can see and can’t see.  Or detailed climate analysis where there are so many variables from the sun, weather (wind, temperature, rain) and human impacts that these models can take a very long time to run.  By building the AWS IoT platform into our backend, we can provide updates on the status of any app, not just ours.  So if you want to call Smart World Professional Mapalyze from within Grasshopper or QGIS, you won’t get a black box.

rabbitmq_logo_strapIn the end what this means is Smart World Professional is “just another IoT device” that you will be able to bring into your own workflows.  Really how this is all supposed to work, isn’t it?  For those who want to get deeper on how we’re doing this, read up on MQTT, there is a standard under here that everyone can work with even if you’re not on the AWS platform.

Thoughts on Cesium.js

cesiumlogoIf 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.

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.