AEC Integrations
Traditionally, 3D renderings in the AEC industry have been purely visual, but one of the advantages of moving our workflow to Unity was the ability to create visualizations that were more interactive and informative.
To that end, one of my team's mandates was to find ways to use our visualizations to build digital twins -- essentially multiple layers of spatial data overlaid on a 3D model of the real world.
One of the advantages of a game engine like Unity over traditional 3D AEC visualization software is its extensibility -- many platforms like ArcGIS had existing Unity plugins, and if they didn't exist it was something we'd be able to build ourselves.
During my three years at HNTB, I ended up working on several integrations that let us market our team as being able to visualize datasets that weren't possible anywhere else.
One of the integrations I spent the most time was Vissim, which is the industry-standard agent-based traffic simulation software. A team came to us with Vissim data for a relatively complex project -- they were replacing a major freeway interchange and wanted to visualize rush hour traffic for all 4 possible replacement options. Fortunately there already existed a Vissim plugin for Unity, but it had several issues. First, each dataset contained 2-3 hours of traffic for tens of thousands of cars, and the plugin took around a minute to load it all. To make matters worse, they wanted users to be able to toggle between all 4 options, as well as morning and afternoon rush hour, meaning a minute of loading any time a user wanted to make a change. To address this, I modified the plugin to use asynchronous loading, meaning it streamed the data rather than trying to load it all at once. This allowed users to toggle between the four alternatives and morning and afternoon with zero loading.
The other major issue was the Vissim data we had only contained 2D data, meaning there was no way to align cars with our 3D environment. To that end I built a tool that used physics raycasting to align the 2D roads with our 3D environment. Some of this worked automatically, but for overpasses and other complex intersections I built a UI to allow us to manually align the roads with the correct surface. When running the application, the cars would get their 2D position from the Vissim data, and then raycast to find the proper height. While aligning the roads was a manual process, we only had to do it once per option, and it allowed us to visualize this 2D dataset in proper 3D.
Probably the most common integration request we received was to be able to pull in geospatial data, specifically from ArcGIS. While I never had the chance to use it on any of our larger projects, we managed to integrate it into two proof of concepts we used to market the capability. The first was a project for pulling in road sign data, where we had a dataset with some basic information about each sign and we wanted to render them as 3D objects in Unity. Using the official ArcGIS plugin to pull in the data, I wrote custom scripts to apply the correct sign template and text and place them in the scene. Users could then click on the signs to view their underlying data and view the sign location in Google Street View, with the eventual goal being to allow them to modify the data to match reality. Since the goal was to create realistic visuals, I wrote a custom retroreflective shader so the signs would respond to lighting similar to actual road signs. We had an incredibly short timeline for this project since it was a proof of concept, and I had never worked this closely with ArcGIS before, so I ended up using Copilot to help me develop the integration. This was my first time using AI to help code, and while I still have mixed feelings about how widely it should be used, it was incredibly helpful for getting me up and running with an API I had never used before.
Another common request was to render 2D GIS linework data like parcel boundaries, land use, easements, etc. on top of our 3D scenes. The challenge here is that trying to place 2D lines in 3D will end up hidden by 3D geometry or, if rendered on top, breaks your sense of perspective. To address this, I developed a shader that renders 2D linework on top when far away but renders as proper 3D when viewed up close. This allows using our 3D environment to either take a traditional top-down view where all linework is visible, or getting up close and seeing the linework in 3D context.
A bit of an unusual request came when doing work on a roadway that would pass by a major airport. The team wanted the visualization to include flights arriving and departing so people could see how that would look in relation to the new freeway. We considered manually adding some planes, but became curious about if we could pull in actual flight data. While most sources of flight data charged money for their API, I found a free data source that had historic flight data that was updated daily. I pulled in a day's worth of flights and created a system for creating planes and animating them, allowing us to add realistic air traffic to this, and future visualizations.
While these integrations were more specialized than our general visualization tools, they greatly expanded our team's capabilities and offerings. By being able to integrate accurate geospatial and simulation data on top of our 3D renderings, we were able to sell our work as more than just visualizations. This meant our work building out a detailed 3D environment could be reused in multiple contexts, helping people make important decisions and extract deeper meaning than from a traditional visualization.
Vissim
One of the integrations I spent the most time was Vissim, which is the industry-standard agent-based traffic simulation software. A team came to us with Vissim data for a relatively complex project -- they were replacing a major freeway interchange and wanted to visualize rush hour traffic for all 4 possible replacement options. Fortunately there already existed a Vissim plugin for Unity, but it had several issues. First, each dataset contained 2-3 hours of traffic for tens of thousands of cars, and the plugin took around a minute to load it all. To make matters worse, they wanted users to be able to toggle between all 4 options, as well as morning and afternoon rush hour, meaning a minute of loading any time a user wanted to make a change. To address this, I modified the plugin to use asynchronous loading, meaning it streamed the data rather than trying to load it all at once. This allowed users to toggle between the four alternatives and morning and afternoon with zero loading.
The other major issue was the Vissim data we had only contained 2D data, meaning there was no way to align cars with our 3D environment. To that end I built a tool that used physics raycasting to align the 2D roads with our 3D environment. Some of this worked automatically, but for overpasses and other complex intersections I built a UI to allow us to manually align the roads with the correct surface. When running the application, the cars would get their 2D position from the Vissim data, and then raycast to find the proper height. While aligning the roads was a manual process, we only had to do it once per option, and it allowed us to visualize this 2D dataset in proper 3D.
ArcGIS
Probably the most common integration request we received was to be able to pull in geospatial data, specifically from ArcGIS. While I never had the chance to use it on any of our larger projects, we managed to integrate it into two proof of concepts we used to market the capability. The first was a project for pulling in road sign data, where we had a dataset with some basic information about each sign and we wanted to render them as 3D objects in Unity. Using the official ArcGIS plugin to pull in the data, I wrote custom scripts to apply the correct sign template and text and place them in the scene. Users could then click on the signs to view their underlying data and view the sign location in Google Street View, with the eventual goal being to allow them to modify the data to match reality. Since the goal was to create realistic visuals, I wrote a custom retroreflective shader so the signs would respond to lighting similar to actual road signs. We had an incredibly short timeline for this project since it was a proof of concept, and I had never worked this closely with ArcGIS before, so I ended up using Copilot to help me develop the integration. This was my first time using AI to help code, and while I still have mixed feelings about how widely it should be used, it was incredibly helpful for getting me up and running with an API I had never used before.
Another common request was to render 2D GIS linework data like parcel boundaries, land use, easements, etc. on top of our 3D scenes. The challenge here is that trying to place 2D lines in 3D will end up hidden by 3D geometry or, if rendered on top, breaks your sense of perspective. To address this, I developed a shader that renders 2D linework on top when far away but renders as proper 3D when viewed up close. This allows using our 3D environment to either take a traditional top-down view where all linework is visible, or getting up close and seeing the linework in 3D context.
Flight Data
A bit of an unusual request came when doing work on a roadway that would pass by a major airport. The team wanted the visualization to include flights arriving and departing so people could see how that would look in relation to the new freeway. We considered manually adding some planes, but became curious about if we could pull in actual flight data. While most sources of flight data charged money for their API, I found a free data source that had historic flight data that was updated daily. I pulled in a day's worth of flights and created a system for creating planes and animating them, allowing us to add realistic air traffic to this, and future visualizations.
While these integrations were more specialized than our general visualization tools, they greatly expanded our team's capabilities and offerings. By being able to integrate accurate geospatial and simulation data on top of our 3D renderings, we were able to sell our work as more than just visualizations. This meant our work building out a detailed 3D environment could be reused in multiple contexts, helping people make important decisions and extract deeper meaning than from a traditional visualization.