Bringing AAA Visuals to the AEC Industry

DAVID WILLARD: Welcome, everybody. If you're attending this class, you are attending Bringing AAA Visuals to the AEC Industry. Very appropriately named session that talks about how we are creating very large visualization projects or very large projects, infrastructure, roads, you name it. So before we get too deep into some of those slides, I'd like to try to introduce our team to you. So next slide, please.

Off the bat, we have a little bit larger team than what was shown today. Unfortunately, one of our team members cannot be here today to help present, but he is one of our very key members to helping with some of the workflows, tools, and visuals that you'll see us showing some examples of and some of the tools we'll be talking about today. So myself, I'm Dave Willard. I lead up HNTB's immersive media team. It's basically a team that focuses on providing real time visuals for design through completion and digital twins of project delivery. We also have today with us Philip Luhn, and Philip is our creative lead on our projects.

So everything that goes out the door, how it looks, how it acts, how it interacts from the real time side is all being led by Philip on our project teams. And then we have Adam who unfortunately cannot be here. Adam is actually what I always call and joke with our zeros and ones person. He is the one, when, with Phil and I and others and clients come up with ideas of how can we do something, how can we integrate with something in a different tool, you name it, Adam is our go-to for that, and we work with Adam to be able to develop some of the tools that you've seen here today. Next.

So some of the deliverables that our project focuses on or our project team's focused on is, of course, we do a lot of the traditional stuff. But our main focus on the visualization side within the immersive media team is really to focus on more real time. And on top of that, not only on just real time deliverables, but on all of the workflows, tools, and processes to be able to get to those deliverables.

So you'll notice in our presentation there today, there's going to be a very heavy focus on building design and analysis application integrations, pushing those tools, and using gaming engine technology to pull in all of the pieces and parts that Philip will be showing later. And also from that point, being able to decide with our clients what type of deliverables are needed now that we've put the two core pieces in place.

So do you want web delivery, interactive, real time, whatever it might be, or are we going more of the traditional deliverables of renderings, photo match, and animations? But all the way, no matter what deliverable that we are focused on, we utilize what we call a rapid visualization approach. And that approach really is the ideal of everything we do, everything we develop, everything we create from a visualization deliverable. We keep in mind this rapid visualization approach. Next.

So before we get too far into the weeds, let's do a quick example of some of our work that we have. So what you see here today is basically an example of how we can turn in these very massive projects into real time interactive. So in this case, this project for Cape Cod, there's two major bridges. There's Sagamore Bridge and Bourne Bridge. And then there's also multiple design alternatives for the intersections or inner interchanges leading up to the bridges on both ends.

So the project team came to us with a need to be able to present this to the public. Public meetings, the feedback that they gathered, you name it, and the ultimate goal would be to show all these design alternatives and be able to come back from those meetings and be able to select a preferred alternative. So what you see here is the tool that we put together. This is basically a screen captured video of a real time web application that allows you to select between the different design alternatives that you see here on the screen.

Also lets you see, as you saw earlier, to fly in between the different bridges within this environment. Again, there's no edges to our environment so we're using some technology that we'll discuss a little bit later as well. We do what we call scripted and unscripted presentations, meaning we embed pre-saved views and video flyover paths within our model, and we also allow the ability of getting out of that and letting the viewers navigate 100% anywhere they want to go within this scene.

So unscripted and scripted. We do that for very many purposes. A lot of us in the room here today are used to those kind of visualization types of deliverables and presentations. So in this case, everything is streaming, everything is being pre-saved for the scripted piece. And then we have the ability of on-offs for various types of data. That data can be traffic, it can be video flyovers, it can be geospatial, which you'll see some examples of later. But all of this put together, these are the types of examples, at least for a public meeting, that we put together for presentations. Next.

This is another example of a real time 3D web environment that we've created for the Bolivar feasibility study. Bolivar is currently in the middle of doing feasibility studies on multiple bridge design alternatives. Again, we have the ability of being able to select between those alternatives and being able to give the end viewer, whether that's the client or multiple stakeholders, you name it, the ability to be able to navigate through these scenes and be able to visualize what that might look like given the surrounding environment around the project.

So a lot of new powerful ways of being able to take these large projects and push them in front of people in a way that they can completely navigate themselves. In this case, more pre-saved views that you can send the viewer back and forth to. And then from any view, you can, in real time, move around those views. We also have, in the similar format, pre-saved information. In this case, we have all the geospatial feature layers embedded within this real time model.

So in this case, there are shipwrecks that are located in the subsurface or subsurface utilities. There's shipping lanes. There's a lot of different geospatial features that are very important when you're designing bridges across shipping channels. So what you see here is our custom integrations that we've written to be able to bring in all of those geospatial features into the gaming engine environment and let the viewers control that data on and off. Next.

And another one of our examples is this project. This is a project we're currently working on. This is the Illinois Tollway Plaza project. This is a series of tollways, about 30 plus different tollways that are being improved along the highway. And basically what we have here is an example of how we can bring in those proposed developments into each one of the locations, never really exit this environment that you're seeing here today, but be able to fly in between all of the different tollways that we want to be able to show the public, here's what those improvements are going to be.

Another nice example of this project is the ability of embedding traffic, like you see here. This can be traffic that comes from Vissim traffic analysis data, of which many engineering firms have adopted today. It also integrates the architectural models. That can be Revit models, SketchUp models, whatever they might be. And again, the ability of flying through this. So eventually, up at the top where it says Halstead, we'll be able to show all of those different types of tollways and click between them.

What you're seeing now is a brand new tool we're developing. It's called IMQC. We built this for internal purposes only, mainly to be able to see how can we get our visualizations in real time out to our clients who are going to be reviewing and approving these types of environments that we're building for them. So we basically built an internal comments and markup type of tool that allow that entire team to drop pins of comments, do various things like let's get measurements, you name it, with this tool.

But all of that information and the comments and feedback are being collected in the background in a way that the Philips and I and the Adams of the world can quickly go to within the editor and see all these comments. And now we have a visual QC tool that we can see, OK, here's some areas we need to address in our 3D models, you name it.

This is a nice new tool also because it opens the door up for us to be able to integrate a comment in and feedback into more public information type of applications. HNTB has one called PIMA, and PIMA basically is a public information feedback type of application. Think about how we can integrate these 3D models into those types of applications. Now we provide the public something very powerful that they can visualize. And we all know a picture says thousand words when it comes to be able to understanding what's happening in our communities. Next.

And of course, here are some examples of just some of the traditional types of work that our team does. Again, a lot of this is still done on the gaming engine backends. So in this case, we have quite a few renderings, intersections. Of course, we can do animations, you name it, but just a quick snapshot of some of the type of work that we've done on the traditional side. Next, please.

So when I first started off the presentation, I mentioned that our team has a heavy focus on rapid visualization. So what is rapid visualization? Well, for our team, it's really a look back and an age old technique that's been used. If you've ever taken an art class in high school or college, you name it, there's a visualization technique out there called rapid visualization. And it's nothing more than the process of starting things with a sketch and gradually building details on top of those sketch to build out the final image that you want to present.

Whether that's a painting, maybe it's a rendering of a building, whatever it might be. But this age old technique has been included or been used for many, many years for hand artists, and our team adopts this heavily when it comes to our visualization services. So basically, what is it? I explained it. It's pretty easy. It's the ability of adding details through a series of stages until you get to the ultimate picture. But what is the ultimate purpose of rapid visualization? And that really is to just take the ideal from a concept to a final deliverable. And that principle can be applied to everything on the visualization side. Next.

Some of you might recognize the LODs or level of development on what we call building information modeling. That's a verb. It's the act of building information models, whether that be buildings, civil, roadways, highways, interchanges, bridges, you name it. The industry, AEC industry in general has started to adopt the level of development when it comes to building information models for each of their types of industries.

And when you think about it, that's really not that much far removed from what artists have started back in the day with their technique of rapid visualization. It's really a way of gradually adding more detail. In BIM's case, or building information modeling's case, it's really about adding more detail to geometry and adding more detail to the metadata or the information that's attached to that geometry. So in a way, you can say that the AEC has adopted rapid visualization on the building information side. Next.

So how have we adopted rapid visualization on our visualization deliverables side? Well, we use rapid visualization mainly to be able to solve problems and increase efficiencies when we're building these very large environments that Phil will be sharing here pretty soon. So what does that mean? Well, it means that our focus on our team is to build out gaming engine technology that has heavier and much tighter integrations with all the applications that the AEC industry is using.

Meaning if you have the Autodesk applications out there of Civil 3D, the Revits, the InfraWorks, whatever it might be, or Bentley, OpenRoads, OpenBridge, whatever they're using, everything within HNTB, there's multiple app platforms being used to develop design applications or design models. So our team focuses on how can we integrate tighter with those. So by adopting gaming engine technology and starting to develop out some of the tools that you will see, we have started to build that tighter integration we talked about.

We also have started adopting a lot more integrations or relationships with third party vendors to be able to help pull in data that we don't necessarily want to be able to model ourselves or want to model ourselves but data we know is important to be able to provide existing context in the surrounding environments within our proposed development projects. We also build out custom development and creation editing tools that you'll see. All, again, ways of trying to use rapid visualization techniques to make things faster to delivery.

So our ultimate goal, really, with adopting these kinds of technologies and this technique of rapid visualization, is how can we make visualizations a byproduct of design and not something that always has to run parallel with design to where design models get updated. We have to come back and we have to manually update the viz to always reflect the latest design.

Our goal, Phil and I and Adam's on the development side is, how can we decrease that amount of time between application design changes to visualizations? Or, how can we remove that time altogether to where an architect or a design engineer can publish their latest model that they want to share with the world or share with the internal teams and automatically update our visualizations on the other end? Meaning the next time you open up that web browser for a real time 3D environment, it shows their latest work and Philip and I have never had to do a thing to make sure it shows their latest work. That's our ultimate goal. We're still a little ways away from that, but we continue to work towards that. Next.

So I mentioned how we continue to work towards these tighter integrations and these less amount of time between design changes and the visualizations. Here's just a quick list of some of the tools that we're working on or have completed in various versions and continue to update. But Cesium data editing tools. We use a lot of Cesium here lately, and Philip will show you some examples of how we're using that Cesium data. Basically the outside context of our projects that we don't want to model but we want to bring in for context.

So we've developed out some ongoing tools for Cesium to be able to edit that data in multiple ways to be able to bring that data in that we need. We also have created some automation for vegetation. Who likes planting trees, especially when there's a thousand of them in your scenes? We've been working on some automated methods of being able to pull those trees in automatically and basically randomize and plant trees for you without you having to do the thousand single clips every time that you want to put a tree down.

We've built some integrations, custom integration with Vissim traffic integrations, so we're able to now bring in Vissim traffic analysis, have automated animated traffic, railways, people. Anything that's embedded within that analysis data, we now have the capability of pulling that directly into our gaming engine environments and being able to visually and interactively change time of days and be able to show our clients or all stakeholders, where does that traffic look like at 3 o'clock in the afternoon? What's it look like at 6:00 in the afternoon? And not really have to wait on a visualization all the way through that to see that.

So we built some tools that you'll see also on that one. Pavement marking tools and workflows. If you've been in visualization for as many years as I have, seeing the grays on my chin, you'll know that pavement markings and workflows have never been a fun one. But we have some pretty nice tips and tricks that we can show you on that. You've seen an example of the IMQC, which is a tool of being able to add comments and markers within the 3D environments that we're building. And we built those tools mainly to help save ourselves and be able to decrease the amount of effort that goes into reviewing our type of visualizations.

Also working on visualizations for geospatial integration and data querying. We see this as a big step towards digital twin deliverables. Also working on SnapShot, which is basically a tool that allows the viewer to render out their own high resolution image if they want to. PIMA integration. Again, we have a public information applications within HNTB. We're working steadily to be able to integrate our 3D environments with PIMA.

And then, of course, there's various tools out there that we're working on. Autodesk Navisworks for construction sequencing. Being able to create automated integrations to where if a schedule changes within Navisworks, it changes in our visualizations, and our viewers can scroll through time via the web browser. Little things like this is really what we have started to identify in our minds of, here's some time savers.

What are the things that you typically take us forever to do? How can we decrease the amount of time to do that? At the same time, giving some very powerful visualization tools back to our viewers. Next. So basically, I'm going to hand off to Phil now, and Phil is going to go through some of these tools that I've mentioned and then give you some ideas of how we built some of those examples that we shown earlier. Phil, take it away.

PHILIP LUHN: Thanks, Dave. So yeah, like Dave mentioned, I'm going to show you some of these tools and how they work. I'm going to try to show you a little bit of how we build up our scenes. Getting those AAA visuals, it's not just a one step process. We layer things on top of each other to get our end result. So first, Unity is our main game engine that we use for doing our visualizations.

And the big question any time we start a project is, which render pipeline do we want to use? Do we want to use universal render pipeline or high definition pipeline? So as a group, we've chosen URP. So despite the fact you can get more high quality visuals sometimes with HDRP, really, URP fits our needs better given the size of our team and the speed at which we're developing these projects.

Also allows us more flexibility in the platforms to which we publish. We do standalone, we do web via pixel streaming, and then VR. It just tends to be more performant than HDRP. And then with the recent news from Unity that the next gen release after Unity 6 will be combining URP and HDRP, we feel we're on the right track just staying with URP, and hopefully we'll be in a good spot to transition to what they're calling the Unified Renderer in the next version of Unity after Unity 6.

So the first major tool that we use that you've heard Dave mentioned is Cesium. And Cesium, if you're not familiar with it, it's an open platform for software applications for displaying 3D geospatial data. And how this works is it's a plugin for Unity, and with that plugin, we can pull in the various types of data that Cesium has available to us. So it's streamed real time. It requires an internet connection, obviously, because it's streaming from the web.

But specifically, we like to utilize the Google Photorealistic 3D Tiles, which is a relatively new addition to Cesium. I think it's been available for Unity maybe a little over a year or so. And what this helps us do is fill in the backgrounds of our environment, and it really creates the illusion of an infinite world within our scene, where, in the past, there's lots of hand modeling and trying to recreate all of that background environment by hand.

So I'm going to show you real quick here. So here's the empty Unity scene that everyone is familiar with. As soon as we bring in Cesium, you can see the tiles loading in real time. And here is the Bolivar environment that Dave showed earlier. This is just raw, untouched Cesium data, the 3D Google tiles. And this is where we start every project. We bind our point of focus for the project, and then this is our starting point is our Cesium data of that project.

So let me talk a little bit about our Cesium workflow. Our workflow obviously involves more than just dropping in our 3D tiles. We have several custom tools that we've developed and tailormade to fit our needs for our projects. So obviously, step one, import Cesium. And then you have our CesiumGeoreference gameObject, and Google tiles is the data set that we always start with. So an important part of when we start a project is setting our reference point for the project and sticking with that reference point.

This makes future revisions a lot easier if we have a reference point to which we stick to. Typically we try to use this reference point from the incoming CAD models. For instance, InfraWorks exports a reference point in the state plane coordinates. So then from there, we can take those state plane coordinates and we can convert them to latitude, longitude. And latitude, longitude is how we align everything with Cesium, which works in latitude, longitude coordinates.

So like I mentioned, once those coordinates are established and everything is imported into the scene, it's put at Unity's world origin, which makes everything easy. 0, 0, 0. There's no offsets to deal with. And then some of the other settings that we typically tweak for Cesium, step one, frustum culling. I usually turn that off. And what that does is it stops tiles from popping up in the background. I'll give you an example here.

So as we turn, sometimes you get tiles kind of popping in and out. Turning that off, then it helps eliminate some of that. And I'll show you later how that's even more beneficial when we're dealing with water masking. Camera view distance. The default in Unity, I believe, is 5,000, 5,000 meters, which is not nearly far enough when you have what's essentially the entire world in your horizon. So we usually increase that to 25,000 to 50,000.

That, combined with some haze in the distance, really makes the world look infinite at that point. And then to go along with that, we use Cinemachine a lot, which involves virtual cameras. So if you have multiple additional virtual cameras, we also want to make sure that that view distance is increased on those as well. So let's talk about some of our custom tools that we've created for Cesium. First one is the Poly Excluder.

And what this does is it allows us to draw splines, and anything within that spline will be cut out of the Cesium data. So the benefit of that, obviously, is if we're importing, let's say, a replacement alignment of highway and we want to get rid of the existing one that's in the Google tiles, this allows us to do that. It allows us to eliminate anything popping up through our imported models.

And this particular tool we developed in-house before Cesium supported this feature for Unity. Anyway, it's now available for Unity. They have what they call a Cartographic Polygon. We found actually that our custom tool works a little better than Cesium's anyway, so we've continued to stick with that tool. Main reason is our updates in real time. So I'll show you in a minute here. When you move the splines, the Cesium data gets cut out in real time.

And if you're using Cesium's Cartographic Polygon, you have to refresh the tile set in order to see those changes. So switch to the-- sample some of the tools here. So here you can see this is an area of terrain that's been cut out with our custom tool. And it's just as easy as moving the points of the spline and everything gets cut out. And again, it's real time, which is real nice, where, if you're using Cesium's tool, you would have to refresh the tile set every time you wanted to see this update. So that's one of the main benefits that we've had with our own custom tool.

Next tool that we developed is called the Box Excluder. It's very similar to the Poly Excluder but instead it uses a box volume, and anything within that volume will be cut out of the scene. It's very nice if we want to cut out something maybe above the ground but not the ground itself. So in this case, you can see in the images, it's nice for cutting out trees. We can cut out individual trees and then replace those kind of clunky, chunky Google tree models with some nice speed tree models.

And again, that works in real time. So here's an example here. The Box Excluder. We used it to move this building here. You just drag it and anything within the bounds of that box are very quickly cut out of the Cesium data. The only caveat with this one it is kind of restrained to the orientation of the tiles that are loaded, so that you're stuck with a square cutout based on the orientation of the streaming tiles.

Now we have these Spline Terrain. So let's say we cut these holes into the terrain. For example, maybe you've got a large area of trees that you want to replace with your nice speed trees. Then you're stuck with a hole and you've got to fill that hole somehow. So we've got Spline Terrain, which it will refer to the spline that we've drawn here.

All you do is Generate Terrain and it fills that hole with the terrain. And then that standard terrain, which you can sculpt just like any other Unity terrain. Raise the height. Lower the height. Paint it. Make it blend into the environment. And then you can populate it with your updated models, your tree models.

And then the next tool, this was a big one for us to get working. Pretty happy with how it turned out. It's a custom Water Mask Shader. So as you saw in the previous scene, when you pull the Cesium in, the water is satellite imagery from Google. It's just whatever the satellite sees, that's what your water looks like. There's no reflections, there's no waves, not very visually appealing. So what we did is we created a custom shader and we've replaced the Google water with our own water material.

So how do we do that is we've exported black and white GeoTIFF tiles. We used ArcGIS to generate those tiles, and those are uploaded to Cesium Ion as a custom asset. In ArcGIS, what we do is I create a custom tile layer based on OpenStreetMap just making the water white and the land black. And I've found OpenStreetMap works best because it has the most accurate boundaries for the bodies of water. A thing to look at, though, is the detail changes depending on your zoom resolution with ArcGIS.

So if you have lots of intricate water boundaries, you do need to create higher resolution and a higher number of tiles. So like I said, it pulls into Cesium as a raster overlay, and then the shader replaces white in the raster overlay with our custom water material. And then again, frustum culling should be disabled so that you don't get tiles popping in and out.

So once we've got that raster overlay created, then you can see you've got the water all mashed out, and it's just in as a raster overlay. So if you turn that overlay off, you see the old water. And then as soon as our mask is applied, you get that nice reflective water. Can apply animation, waves, reflections. So here's just a quick rundown of the workflow. The original Google tiles. Here's what our map looks like in ArcGIS, the black and the white. And then that's uploaded to Cesium Ion, which is then streamed into the scene.

And then lastly, one of the main things we implement in our scenes is environment lighting, and for that, we've chosen to use a plugin. We like to use Enviro. It's pretty well performant. It supports all the different render pipelines, so there's no issues with URP. So it's a very nice system. Get volumetric clouds. You can animate the clouds. You can change the weather from cloudy to sunny to thunderstorm, and it all animates in real time if you choose.

And it's a nice time of day system as well. You get your dramatic sunrise sunset renders as well. And it also supports location. So once we import it, we match the latitude and longitude that we are using for Cesium, and it provides very accurate sun lighting. There's been models I've brought in where, once I match those coordinates, the shadows will overlap each other, the baked in Google Earth shadows and then the shadows being generated by Enviro.

And then we do obviously tweak our settings as needed. Lower the quality of the clouds a little bit just to help with performance. And then depending on the scene, we'll increase or decrease the fog distance and maybe give the sky a little bit of a bluer tint to make it look a little more dramatic. So another tool that we like to use is Pixyz, which Unity now, I believe, owns. And they recently released version 3.

So this is very helpful for us when we are using large CAD based models that will cause issues importing either into Unity or even just into 3ds Max. So a use case scenario that works well for Pixyz is the linear decorations models that come from InfraWorks. So the linear decorations typically includes road markings, concrete barriers, guardrails, anything that is a long linear piece that's part of the model.

So the downside that we've run into a lot with InfraWorks is their lane markings, for example, instead of it just being a four vertex polygon, it comes in as a six sided polygon, and each line is a separate object in the file. So that causes lots of issues when importing into Unity or 3ds Max. So we found that Pixyz actually works really great for this.

We can import the FBX, we can merge by material, as you can see here with the Pixyz settings, and it'll automatically merge all those meshes, sometimes 20,000, sometimes 40,000, and it'll merge it into maybe 8, 10 meshes with shared materials. Then from there, either we can use as is in Unity. Like road markings, you don't need to do much with those material-wise.

But if there is something we need to make changes, we can then export from Unity back to FBX using Unity's FBX exporter. And then from there, we can do further revisions within 3ds Max. So Substance 3D, Adobe Substance 3D. I like to use this for generating our materials. And the reason for that is it makes tweaking of materials very easy.

First of all, there's a plugin for Unity, so we can import native substance materials directly into our projects and make tweaks to those materials directly into our projects. There's no need to use Substance Painter or just making materials. We don't need to use sampler. We can do everything directly in Unity.

In the event that we have a material-- let's say we're importing something from 3ds Max or InfraWorks-- it's using the Autodesk Material Library. Sometimes all you've got is a base color map. You don't have metallic maps, you don't have normal maps. In that case, Substance Sampler actually is a really good application to use. We can pull those Autodesk material textures into sampler.

And then from there, we can generate metallic maps, normal maps, and then from there, you're using the full PBR workflow when it comes to your materials. And then another thing to note on the EC side, the Substance 3D Asset Library has a large collection of models as well, not just materials. So there's a lot of city furniture items that are helpful. There's streetlights and road signs and benches and garbage cans and all that type of stuff. So that's a nice resource as well.

Just, your mileage may vary just depending on the accuracy of some of those models. And then post-processing. We don't go too crazy with this. I think less is more when it comes to post-processing, especially in this industry. We're not trying to be overly flashy, so we keep it pretty simple. We use some tone mapping, a little bit of bloom, motion blur. And then there's a few features that we do use third party plugins for because they're not currently implemented into URP.

So automatic exposure and then our screen space reflections. So the hope is with the Unified Renderer coming out, maybe we won't have to rely on third party extensions for those anymore. The hope is they'll be built into the new renderer. So that's how we set up our scenes, getting all the base in there. So now we're at the point where we're ready to start populating the scene with our design models. So the first step is unfortunately, we do need to do cleanup of some of these CAD models.

Like Dave said, our ultimate goal would be to go straight from design model to Unity with us not having to touch these models. But unfortunately, right now, this is where we're at. So we do need to do some cleanup. So I'd like to import the meshes and consolidate materials, combine meshes when possible so there's not 20,000, 40,000 meshes.

It's more performant for Unity on that side. Sometimes, kind of like with the linear decorations, we can skip the step with 3ds Max. Pixyz allows us to skip the step for certain types of models that maybe don't need quite so much work. But for the most part, we'll bring them into Max and clean them up. Large areas of terrain. Sometimes we get terrain from InfraWorks.

Just because of the way the roadways are being constructed or the bridges are being constructed, there'll be changes to the landscape, obviously. So we'll get pieces of terrain from InfraWorks. Typically what we do with those is first we will combine them to a single mesh in Max, because they tend to come in tiled with individual textures on them. We'll combine them into a single mesh and then bake a single texture onto that.

From that point, we can then convert that terrain into Unity terrain in the Unity engine and work with it as you would a typical Unity terrain. Another thing to keep in mind when we work with these meshes is we sometimes have multiple FBX files coming in, five, six different files. I always make a point to rename all of the objects in the scene in between each import, because oftentimes there will be similar names or identical names between those objects and they will overwrite each other if you don't use the right import options.

So just to be on the safe side, I typically rename them. And then another tool that I like to use to combine meshes in 3ds Max is the SiNi tools. It's a set of plugins that helps combine objects. It's similar to Pixyz in its functionality where you can combine meshes by material or separate meshes by material, and it just tends to work a little better than some of the default Max options. And then lastly, we revise the UVs as needed.

Sometimes they're not consistent from material to material, so we need to make sure they're the same as far as the tiling on the materials. Sometimes there's roads that come in where maybe we want to have the material follow the flow of the road, so we'll have to do a spline based UV mapping on those to make that look a little more realistic. So once we prep everything, then we can bring that CAD model into our scene.

Then you'll see. Here's our model in the scene, and all these, all the different components have been merged to be a little more efficient as far as number of materials, and everything's properly named. So this is this process with importing our CAD models. So typically, we're working with FBX still. We've done a little looking at USD, but for now, FBX has been meeting our needs.

So FBX for now. As I touched on earlier, the world origin is preserved, meaning the origin of the model that came in from InfraWorks or whatever the design model is. And again, that just makes future revisions a lot easier if we're not dealing with offsets. So for instance, InfraWorks, they export along with the FBX file a POS file, and that includes our state plane coordinates. It switches easting and northing. So what we do with that is there's several websites that do that conversion for you.

So I will plug those into the website, along with the region that it's located in, and then that gives us the latitude and longitude coordinates that allows us to place it in the scene. So if we happen to not have a world origin at zero, we do have this coordinate aligner tool where we plug in our latitude, longitude, and it'll automatically, using part of the Cesium API, it will align that object to the proper position in world space.

So one thing we've noticed is we do tend to have to make some manual adjustments to the rotation of the model. Typically we're talking, like, a half a degree, a quarter of a degree. A very small amount. I think we're just looking at some of the issues that come with the Earth being round and our models not factoring that in. In CAD software, it's kind of assumed that the entire model is being drawn on a flat plane, and the Earth, obviously, is not a flat plane.

So besides the manual rotation, how do we deal with that? Over a 10 mile distance, you're looking at a height difference from the beginning of your model to the end of the model of 66.69 feet. So that means if you're doing a 10 mile stretch of highway, the beginning of your highway, it lines up perfectly with our Cesium data, the highway we're cutting out. But then by the time you get to the end, your highway is hanging 66 feet in the air.

So that's something we've been trying to deal with, because it is very noticeable, obviously. We're still a work in progress, but we're using a curvature vertex shader. And if anyone is familiar with Subway Surfers or Animal Crossing-- I know my kids play those games on their phone-- they use what's called a world curvature shader. So we started thinking maybe we can use that same process here. Turns out you can. We've tested it.

We've got a six and a half mile long alignment that we're working with and drop the shader on it. And it's an unoptimized 40 million polygon model, and just like that, we curved it and it seems to be working well. I think that's going to be our solution moving forward on dealing with that curvature of the Earth. And then like I mentioned earlier, we convert that imported mesh terrain to Unity terrain. It makes it a lot easier to work with.

Sometimes that InfraWorks terrain tends to be a little sharp. The edges are kind of sharp and it's not optimized to look realistic. So once it's into Unity terrain, from there, we can smooth it and sculpt it and put nice textures on it, make it look a little more impressive. For that one, we also use a plugin called Mesh Terrain from the Unity Asset Store.

OK. Real world tree data. Just like Dave touched on earlier, we've implemented a solution to use actual real world data for trees. Couple different reasons. We're using some of these Google 3D tiles and we don't like how the trees look, they're kind of blocky and chunky and up close, they just don't look good.

That's one reason we'll use it. We'll cut out the trees, put our own terrain, and then pop in our speed trees. Another option is sometimes we're working with rural areas and there isn't true 3D Google tile for that area. One example was the Cape Cod project that Dave showed earlier. It's all just elevation data. There's no 3D Google data. So that's a good way to place trees in an area like that. So the step that we use is first we'll download lidar point cloud data. And this is freely available from the USGS National Map site.

So far, most areas we've looked at, this has been readily available. So we load that data into Global Mapper and perform feature detection. And what that'll do is it'll detect, OK, this is a tree, this is a building, this is a power line, and what we can do is we can export that whole list of trees to a CSV. And that gives us the latitude and longitude coordinates of each tree, it gives us the height of the tree, and the spread of the tree as well.

So from there, we import that in Unity, and then using our custom tree parser utility, we can very quickly populate the entire area with these trees. And the script gives us a little bit of flexibility. We can set height ranges for types of trees. For instance, let's say any tree between 20 and 30 meters tall should be an oak tree, or any tree between 0 and 10 meters tall should be a maple tree. That sort of thing.

And it can be multiple types as well. So there's different ways to randomize it and make it look very natural in the end. And then lastly, we convert these trees to terrainData so that their locations and types and all that are stored within the terrainData rather than being a hierarchy in Unity with 10,000 trees placed in your hierarchy. And another tool that we use, which Dave mentioned, is roadway markings. Typically these roadway markings, they come as part of the design models.

Sometimes they're usable as is and sometimes they need a lot of work. As I mentioned earlier, InfraWorks tends to make heavy road marking meshes, which is not ideal. Six sided meshes. Oftentimes the vertices are not welded. So we needed to find a way around this and to make that a little more efficient. So we've created a tool to draw roadway markings, and it uses Unity splines. So it's as simple as just drawing the spline, and it'll automatically create the marking to the width that we want.