AU Class
AU Class
class - AU

CIMIC brings your largest ACC AEC models into Unity and Esri ArcGIS

Partager ce cours
Rechercher des mots-clés dans les vidéos, les diapositives des présentations et les supports de cours :

Description

Using open source tools and open formats, CIMIC is federating their largest 3D architectural models, directly from ACC and into the Unity game engine. They show record loading times and record rendering speeds with the largest of federated scenes, while keeping ACC versioning, filtering and coloring, of single elements. This case study compares different pipelines that were explored before choosing the final result. Topics include ArcGIS Maps SDK for Unity, IFC, I3S, OBJ, USD, FBX, 3D-Tiles and glTF. Learn how you can integrate ACC 3D models into your own game engine using APS, open source tools and open formats.

Principaux enseignements

  • Master integration of 3D models from ACC to Unity.
  • Compare pipelines for optimal processing, loading & rendering performance.
  • Discover best practices for maintaining features such as versioning and coloring when federating 3D models into game engines.

Intervenants

  • Jovan Harrod
    Jovan is a Product Manager at CIMIC's software company, IDD Tech, where he manages Tobe Builder and TobeMaps. He has over 10 years of experience in the immersive technologies space, having worked as a Unity developer doing rapid prototyping of Augmented, Virtual, and Mixed Reality solutions to increase communication efficiency in the Mining and AEC sectors before progressing into product management. He has worked with various pipelines and tools for getting BIM and GIS data into Unity, such as forge-convert-utils, forgetoolkit, FBX, 3D Tiles, Mapbox SDK for Unity, and ArcGIS Maps SDK for Unity. He holds a bachelor's degree in mining engineering and a Master of Philosophy from the University of Queensland.
  • Avatar de Michael Beale
    Michael Beale
    Michael Beale is a Senior Developer Consultant since July 2017 for the Autodesk Developer Network and Forge Development Partner Program. Before joining the Forge Platform Team, Michael worked on Autodesk Homestyler, Cloud Rendering, Stereo Panorama Service (pano.autodesk.com) and A360 Interactive Cloud Renderer before working on the ‘Forge Viewer’ and Viewing APIs. Twitter: @micbeale Blog: https://aps.autodesk.com/author/michael-beale
  • Ken Panitz
    Ken Panitz leads the development teams for Tobe Builder and Tobe Maps at IDD Tech. With 23 years of delivery experience in the Oil, Gas, and Infrastructure sectors, including significant mega project delivery at CIMIC Group, Australia's largest construction contractor, Ken has a proven track record in executing complex projects across multiple sectors. He is a member of CIMIC's Innovation Council and has previously led innovation and lean initiatives within the business, overseeing the delivery of more than 130 innovation projects over the last 10 years. As a director of Lean Construction ANZ, Ken leverages lean thinking, such as Deming cycles (PDCA), to ensure the digital tools he develops translate intent into action and measurement into insight. His leadership drives technological advancements and fosters innovation and efficiency in digital delivery, enhancing stakeholder and subcontractor alignment throughout project initiation and delivery. As the leader of Virtual Construction at IDD Tech, CIMIC's new software development business, Ken ensures alignment between the desires of numerous delivery teams and the features and workflows the software requires.
Video Player is loading.
Current Time 0:00
Duration 0:00
Loaded: 0%
Stream Type LIVE
Remaining Time 0:00
 
1x
  • Chapters
  • descriptions off, selected
  • subtitles off, selected
      Transcript

      [VIDEO PLAYBACK]

      [MUSIC PLAYING]

      - I'm here at the Esri User Conference 2024 in San Diego. Autodesk and Esri started partnering more closely together about seven years ago, so we have a great track record. The last 18 to 24 months has been a lot of momentum, a lot of product integrations.

      And I'm excited because while the companies have been partnering really well together, we have work to do to get our joint customers to really understand the value that can be delivered when we bring BIM and GIS together.

      - This is really exciting because we're kind of at the fruition of all the years of work we've been doing as a partnership with Esri. Partnerships like this, which are really deep, high-trust partnerships that go into exchanging technology in really significant ways, are really important to helping everybody elevate the quality and ability of the ecosystems we serve. The world of design and making things and the concept of bringing GIS and BIM together are actually going to be transformational to how this ecosystem works.

      - They're able to look at problem solving in a more holistic way. This kind of integration and collaboration is enabling a new approach to bring into the workflows of engineers a more sustainable future.

      - It's time to start bringing GIS and BIM together and changing how our customers build, design, and actually construct things, so I'm pretty excited about this.

      [END PLAYBACK]

      KEN PANITZ: Good afternoon. My name is Ken Pantiz, and I lead the virtual construction team at IDD Tech, a subsidiary of the Cimic Group in Australia. It's my pleasure to introduce you today the [? star ?] [? chambers ?] of speakers.

      Jovan Harrod, my partner in crime and guru of all things extended reality at IDD Tech; our special guest, Rex Hansen, Esri's product manager for a range of ArcGIS SDKs, and our GIS Santa Claus, who three times a year delivers a whole box of new goodies for us to leverage in our apps; and finally, last but not least, Michael Beale, an Autodesk developer advocate and our phone-a-friend APS Yoda who has been with us side by side over the last six years.

      Today, our session will be delivered in five parts, as you can see on the screen, each building on the previous to tell our story of delivering a connected, scalable, 4D collaboration environment for our business atop Esri and Autodesk platforms.

      Jovan and I join you today from Brisbane, Australia. IDD Tech is a small part of the Cimic Group, which in itself represents around 30% of the global ICS group. Our sister companies in the US, FlatIron and Turner Construction, and in Europe, Hochtief and Dragados, make us part of a group of construction, mining, and services companies with more than 130,000 employees globally.

      Our projects are enormous, $5 to $10 billion mega infrastructure, tunnels, stations, bridges, hospitals, airports, stadiums, giant structures created by giant teams, one piece at a time. But our scale comes with its own unique challenges. We're so big that the answer to the question, Hey, what software do you use? is almost always all of them. Our business is so diverse and driven by so many sectors and so many jurisdictions that taken in aggregate, we have to make sense of designs from varied clients and design partners and wrangle all of that into a cohesive and repeatable process at scale.

      IDD Tech is the commercial software business formed to commercialize and offer to the wider market tools developed across our group. Today's talk will focus on how we've worked with both Autodesk and Esri over the last six years to develop a plan and execute some of the world's largest infrastructure projects and the unique challenges of managing delivery of mega projects.

      IDD stands for Integrated Digital Delivery, Cimic's religion for digital transformation and our roadmap for how we will move our business into a connected, digital, and delivery-focused organization.

      Over the last five years, we have brought together GIS, digital engineering, planning, project delivery to create Tobe Builder, an interactive environment built by builders for builders. Let me explain the what and the why of Tobe.

      Firstly, as builders, we must understand the real-world context of every decision. We don't build projects in a pristine environment. Real projects are messy. They're built in and around existing infrastructure in communities that maybe don't appreciate the inconvenience of the process.

      We've leveraged ArcGIS Maps SDK for Unity to bring our own GIS maps into Unity. This means that we don't need to rehost or convert large GIS data sets. This Aerometrix city mesh of Melbourne, for example, is more than 300 gigabytes in size, but the ArcGIS scene service allows us to stream in this gigantic data set as well as traditional 2D raster or vector tiles for things like road networks, utilities, or environmental overlays.

      This sets the stage upon which we plan our construction methodology. Upon this stage, we add our BIMs. Full fidelity, dimensionally accurate design models coupled with coordinated GIS services means that our teams can see their designs in context, in scale, in their full, heavy, and at times overwhelmingly high levels of detail.

      Models are simply drag and dropped from ACC, meaning that the design-- as the design evolves week to week, we're always working with the most recent version. We support the full model hierarchy, BIM properties, and we can on the fly rebuild this model hierarchy using any combination of BIM properties. This allows our delivery team to rebuild the model how they're going to build it, rather than how it was packaged for design.

      You can see here a fabrication model for a single bridge on Westgate tunnel project. It ran to more than 100 million polygons over 256 separate models. This is the actual Tekla fabrication model, with the colors you can see representing each individual piece of plate work as it was fabricated in China and then shipped and installed in Melbourne, Australia.

      Once the context and the scope are represented, the next pillar is the introduction of time. While design is great at representing how infrastructure will appear when complete, as an industry, we're still learning how to manage and represent the thousands of temporary states that an asset goes through as it is constructed.

      Our tool can import a 2D schedule format, such as Primavera XER or Microsoft Project or 4D schedule formats, such as Asta Powerproject. We can also import from every engineer's first love, Excel, or use our own task creation tools to flesh out and create simple sequences right inside Tobe Builder. This allows the delivery teams to understand that critical sequence of how an asset must be constructed, and it helps ensure that our planning is realistic and deliverable at all times.

      We, however, take this a step further. We've invested over the last four years in building out a dimensionally accurate, rigged digital library of real-world vendor equipment, cranes, trains, trucks, traffic lights. All of them represent a rich library of props that we can use to explain in detail how that beam just magicked into place.

      Our rigged resources are keyframed at points in time. And then Tobe interpolates these poses from keyframe to keyframe to create animated sequences. There's so much value to contractors and subcontractors having clear, concise, and unmistakably understood shared understanding of exactly how the project methodology is to unfold. This ensures that we can have the discussions and the conflict early in the digital phase, and we can rehearse and plan and replan so when it comes to do it for real, in the real world, there's just no surprises left. We know exactly what we're doing and exactly when we're going to do it.

      Our final pillar is an acknowledgment of the common excuse for not doing construction visual planning. We've integrated Rhino Grasshopper into the environment so we can build simple, representative geometry for our temporary works and temporary states that are rarely, if ever, modeled by the project.

      While they might model, say, a pipe or a run of services, they'll rarely model the trench the pipe goes in or the film work or the scaffold that we need to build it. Our automation tools allow these creation of temporary works, representative geometry, as a coordinated IFC file that can then be taken out of Tobe, back upstream, to real design packages to be further elaborated on.

      Users can simply click out a simple line or some point inputs and fill out some simple parameters. And then Rhino Grasshopper creates an IFC model and publishes that model to ACC for ingestion into our wider scene.

      These five pillars together create a rich graph of information, an interconnected digital asset that represents how our projects teams have a best shared understanding of how the project is going to be delivered. Once this environment is set up, we then use a variety of platforms and technologies to communicate to a broader range of stakeholders.

      Immersive, big-room environments allow us to interact with the model in a large team setting, or virtual reality in both tethered and standalone formats allows us to gain a full-scale, unique perspective of this proposed methodology. We can mix and match these experiences at will, so a team of people could be using VR, a large touchscreen, and desktop computers to work together to rapidly iterate on solutions.

      Finally, by publishing a construction sequence to our companion application, Tobe Maps, this allows our team to take rich, connected plans out into the field. Our desktop tool configures and publishes AR scenes that take a subset of the BIM, the resources and the schedule related to it, and delivers it out to iOS and Android devices.

      We can use a two-point calibration or preconfigured markers to align the virtual and the real world. And we have full access to the model hierarchy and all the BIM properties out in the field. With modern devices providing excellent tracking, we can move through the real world augmented with ease.

      Our AR tools work happily offline. Here, we can see, far away from a 4G signal, a superintendent has scanned a QR code, and he's free to move about the space and interact with the digital model and its properties while seeing firsthand the real-world progress as compared to what was planned.

      Together, these tools empower the whole project team to create, refine the best possible plan before work even commences. Having these kinds of detailed discussions 6, 12 months ahead of the real-world delivery is priceless to our teams. And with that, I'd like to hand over to Jovan Harrod to explain the how of delivering this capability.

      JOVAN HARROD: Thanks, Ken. Hi. I'm Jovan Harrod, a product manager at IDD Tech, looking after the Tobe suite. Today, I'm going to talk about the technology journey to get both BIM and GIS into Unity to create the Tobe suites of products. I'll also touch on the services and technology provided by both Esri and Autodesk to help us achieve our product goals.

      So let's go back in time to 2018, when I joined EIC Activities, one of the group companies in the Cimic Group looking after augmented and virtual reality. I was doing rapid prototyping of AR and VR apps in Unity. And basically, the workflow I was using was to import Navisworks data into Navisworks or InfraWorks, export an FBX, import that FBX into Unity, and then build an application around that and run it.

      Now, this allowed for baked occlusion culling in Unity, so Unity people, basically making that game object static and hitting Bake. And it was usable performance, but not really a scalable process, if you looked at it.

      So this highlighted the need for runtime loading of BIM with metadata from somewhere into Unity. Now, BIM 360 adoption was growing in the business at the time, so it seemed like the right place to start. And I'd met with Michael and Cyrille Fauvel at Autodesk University in 2019 in Vegas. And they said that Forgetoolkit was the way.

      So I engaged our lead dev, now Cameron Gibbs, as a casual developer at the time, and he built the-- what we call the Unity Forge API. This allowed us to select a model in BIM 360 and stream an AR kit scene into Unity at runtime with access to your metadata and your properties.

      Now, under the hood, this was basically using the data management API to access the BIM 360 Cimic Hub and using Forgetoolkit to then create and then load an AR kit scene for the selected SVF.

      We tested this on a few platforms, including desktop, Android, and the Oculus Quest, which is essentially Android. And it worked. However, it was, unfortunately, quite slow. And the future of the service was a bit uncertain, so there was some reliability issues.

      So we moved on to 2020, the start of COVID. Basically, met with Michael again at the Forge Accelerator in Sydney. And we all quickly rushed away home because lockdown was about to happen, so we did a virtual accelerator.

      And at this point, Michael sent me in the direction of a repository created by a guy named Peter Bross. The repo was called forge-convert-utils, and it would produce a glTF from a selected SVF and allow us to load that into Unity using, in our case, glTF files.

      So this is a comparison video that I put together at the time to show that loading performance difference. So we have the simple sample Revit model being loaded as an AR kit scene using Forge toolkit. And then on top of that, I have the advanced sample Revit model as a GLV that was converted using forge-convert-utils being loaded from an OSS bucket via a signed URL.

      Now, Peter was also writing the object ID of each element into the mesh name, so in theory, we could use this to get properties.

      Now, at this point in time, it was really just me playing with MPM packages, forge-convert-utils, glTF pack, glt-pipeline. And this is via command line interface, manually converting models and uploading them to buckets for use in Tobe Maps POC at the time.

      Around this time, EIC Activities put together an initiative called the simulated built environments that would eventually be known as virtual builder. Our dev team joined at the end of 2020. And we identified that BIM and GIS were mission critical data sources required for true construction simulation, along with time and resources.

      Now, typically, these systems are quite separate and, really, had no way of coming together at the point in time that we tried to tackle this problem. Our philosophy was to retrieve data from its host location and avoid recreating functionality if the same could be achieved through integration.

      So given that we were going to work in Unity, and the ArcGIS Maps SDK for Unity magically, at the same time, was in early access, it made sense for us to use that as our way of getting our data that was already sitting in the ArcGIS ecosystem in the broader business into this product.

      For BIMs, it just seemed opportune at the time that I had been already working with Michael and Peter to bring to fruition this use of glTF to bring that data into Unity. And given that the common data environment [INAUDIBLE] or the broader business at the time was going to be BIM 360, it just made sense.

      So looking forward, we went to early 2021, and we had a working prototype of BIM and GIS in Unity. We had ArcGIS Maps SDK for Unity giving us a nice WGS84 globe. And then we had a service that was able to convert BIM from BIM 360 into a draco-compressed GLB that we would consume in Unity. We were using glTFFast at this time as our runtime loader in Unity.

      Now, each element was a mesh with the object ID, so we could do picking. However, we had high drawcalls, and max model size really capped out at about an LOD 300 bridge, so a small one or a medium-sized LOD 300 building. This was really because of that high volume of meshes. So lots of meshes, high drawcalls, low performance.

      So the version 2 of that converter was updated to use gltfpack to mesh merges by material to reduce those draw calls overall. Cam was also producing a mapping JSON, so we knew what verts matched to what object ID so we could do picking for properties. And we were also manually building the hierarchy at the time. And there were some magic shader stuff that was happening to allow us to basically hide parts of the model, even though those meshes were merged.

      So at the time, we were able to do what we needed to do. We could hide and show parts of the model using task-linked-- tasks from a schedule that were linked to those BIM elements. And we were also testing that same pipeline in Tobe Maps pilot at the time, which was being tested in Australia and Hong Kong.

      Now, from 2022 onwards, the team really worked on optimizing the converter to be more stable in performance to really deal with the large BIM sizes that we were needing to ingest. One of the biggest performance gains came for us at the time of the West Gate Tunnel Project, Bridge 50, which really pushed us to the next level. This, as Ken described, was a huge project for us with over 200 BIMs.

      And at this time, changes were made to the converter to use MeshOpt compression, so we were doing quantization, and Cam did some magic to write the object IDs into the [? UE2 ?] channel of the verts so we could get rid of that mapping JSON.

      The real gains were made, though, on the optimizations of the loading order of BIMs and resources in Builder itself, with the reduction in loading time going from 20 minutes when we started off to about five minutes load time. Now, that doesn't sound, like, really quick, but this was a huge project at the time for us, and that was a massive gain. So greater than 200 BIMs, and probably the same amount of resources in the scene.

      At the same time, we needed to really solve an issue with long BIMs or linear models, where linear infrastructure models located in custom projections were not aligning with the WGS84 map. So thankfully, Rex, at the time, came to the rescue around the middle of 2022, giving us support for base maps with custom projections in the 1.0 release of the ArcGIS Maps SDK, which solved that for us. So our custom projection models would sit on a custom projection map, and everything was happy days.

      Looking to where we are today, V4 of the converter is pretty much the same as V3, with a bit of mesh splitting and a lot of optimization on the infrastructure side. It allows for models being imported directly from Autodesk Construction Cloud into Builder with all the BIM features you have in the ACC viewer-- that is, your hierarchy, your properties, your selection, sectioning, visibility control.

      Now, given that we're built in Unity, the Builder suite basically can ingest that data once and use it on all the platforms the game engine supports. In our case, we're targeting Windows with Tobe Builder. We've got Tobe Maps on iOS and Android. And on Quest 3, we've got our upcoming XR app called Tobe XR. So build it once, bring it into Unity, and deploy to all of those platforms, which was the original idea.

      Now, during this section, I've described the technology journey. And journeys can be boring and arduous, but Ken and I have fortunate enough to have a great team that are on this journey with us. It's truly remarkable that our team of four developers manage and maintain three products across four platforms.

      We were recently honored with a Special Achievement Award in GIS from Esri for our work on Tobe Builder. And I'd like to extend a special acknowledgment to our development team, Cam, Kailas, Josh, and Michael. These talented individuals are the driving force behind the entire Tobe suite.

      And now with that, I'd like to add-- apologies. With that, I'd like to hand over to Michael to talk about how Autodesk has been helping us achieve our dream of BIM and GIS together using open standards.

      MICHAEL BEALE: Thanks, Jovan. Good morning, everyone. My name is Michael Beale. I am a principal developer advocate at Autodesk. And today, I'm excited to walk you through a technical reveal focusing on how we've leveraged open formats to bring GIS and BIM models together.

      And this has been a collaborative effort between Autodesk, Esri, Cimic, and the open source community. And as seen in that opening video, Autodesk and Esri's partnership is centered around bringing GIS and BIM together. Some of the technical details I'll show are just a glimpse into this collaboration and the many people involved in making this happen.

      So as Jovan said, back in 2019, both of us Aussies-- we both realized that the open formats were the key to solving some of these large model challenges across both game engines and also sharing and-- sharing data across platforms. So by using open formats like Khronos's glTF and OGC, the Open Geospatial Consortium's, 3D tiles and I3S open standards, we've created a solution that I think scales fairly well. Both 3D tiles and I3S are essentially what we call HLODs or Hierarchical Level Of Detail.

      And so it turns out, though, a well-crafted HLOD combined with optimized glTF files can render massive data sets in real time with really efficient loading patterns. And this is the first of three goals-- basic viewing, filtering, and deltas. And to provide these three goals in an exchange format of large BIM models.

      To support the filtering and deltas, We just need to add the BIM element ID inside our glTF. Easy, right? And the idea is that if I click on a BIM object, I can get the BIM's element ID from the glTF. And then I can see its metadata properties by querying the API, ACC APIs.

      And also, with these IDs embedded inside the glTF, I can do visual filtering. I can hide and isolate things like the HVAC system in this ship in the middle just by discarding pixels. And lastly, if the design changes over time in ACC, I can use the API to compare two versions and take the IDs and match them with the BIM element IDs in order to colorize and see the differences in my model over time. So by using well-established open formats and keeping this implementation complexity low, we naturally get a wider adoption across these three goals.

      Now, I'm going to play a quick video. And I'll explain with the video what an HLOD is and how it enables us to manage large BIM models and render them.

      So the first thing to do is think of an HLOD as a grid of boxes. And each box is one of these small glTF files made of meshes. When the camera gets close to a box, it loads the glTF. When the camera moves away, it unloads that glTF. And this saves memory. Ultimately, your 3D engine-- it stays fast because it only loads and renders the glTFs nearby.

      So HLODs break down the model into smaller, manageable tiles and load detailed data only when needed. This technique can be tuned to sacrifice detailed to save memory and also to improve rendering performance on low-end devices and tablets.

      So now that we've got a basic understanding of what an HLOD is, let's look at the pipeline. We take a BIM model from Autodesk Construction Cloud, ACC. We process that through Autodesk's Cloud Services APS, and we convert that from there into our HLOD and glTF files. This open format, glTF, can then be consumed by any 3D tiles loader or for the I3S version, via, say, Esri's Unity SDK for that seamless integration and bringing BIM data into the GIS world.

      And as an experiment, we added this converter module into Autodesk's APS Model Derivative service. And that helps support some mixed requirements. The Model Derivative service can convert 70-plus different file formats, things like Revit, BIM models, Navisworks models, and IFC models. And it gets converted into what we call the SVF2 format. And from there, we use the APS-Convert-Utils and transform that into our HLOD and glTF tiles.

      This modular approach, which leverages APS, allows for that smooth BIM/GIS integration with customers that are already using our existing APS Platform Services.

      And now in this slide, I'm going to just briefly gloss over the technical details of how we create the HLOD, our tree structure. Basically, we're creating a bounding volume hierarchy using a surface area heuristic with binning. And we sort the meshes from largest to smallest. And when we fill up a glTF, we limit the number of triangles in that glTF to about 65K to 200K triangles.

      And the final result is that we end up getting large buildings with large walls. They tend to span the entire scene. And so those geometries sit near the top of the tree, while the tiny nuts and bolts of the door or the chair-- they get spatially divided into many different regions and small cubes, and they sit at the bottom of the tree. We have lots of parameters to play around and tweak this tree structure and test it across many different model styles.

      Next is glTF baking. We use gltfpack, an open source tool on GitHub, and we use that to consolidate our meshes based on their material shader. This reduces draw calls and really enhances that rendering speed that Jovan was showing you.

      This prebaking step also does MeshOpt compression, giving a small footprint and fast loading and ultra fast decoding. And this solves for our first key goal, basic viewing.

      The entire pipeline-- it's optimized for delivery over HTTPS and a CDN. And that gives simple, web-friendly caching mechanisms. And it ensures a fast and repeated access to all of the assets involved.

      Right. So now let's connect the visual components to the metadata. Here, I've got a building I'm looking at. And I've sectioned this building. And what you're going to see here in this visual representation is a debug mode. I'm going to turn on a special shader that colorizes the element IDs. And what's going on under the hood is you're going to see glTF's extension mesh features activated. And each color will correspond to a specific BIM element ID.

      So I click on that here. And you can see now all of the colors appearing. And this is going to directly map the geometry with its associated properties. So you can see I'm hovering over different colored sections. And when I click on one of those elements, this application will retrieve the BIM properties based on that ID from Autodesk's Cloud APIs and then display them here on the left. And this highlights that connection between the geometry, that 3D geometry, and the BIM property data.

      The next one is visual filtering. We can use that same ID to filter elements based on categories-- for example, things like the HVAC system of this building.

      So I click on the-- I click on this particular visual filter, and now I can see all of the HVAC in the scene. And so this is a simple key-- it's a key workflow that helps users isolate specific systems in the model and allows for that detailed inspection on a construction site.

      So for example, here I am in the pool room, and I can see more details. And this also relates to versioning. I can use the ID system and the APS API to colorize the changes that are happening across model versions.

      And here are some quick stats. Here, we convert a large Navisworks model. It's about 200 million triangles. And that means I can now load things instantly and render things at 60 frames per second. The conversion time took about 20 minutes to convert everything. The SVF files that are output to disk are about 27 gigabytes, while the glTF and 3D tiles and I3S version come to about 287 meg on disk without losing details. And that's thanks to glTF's compression. The glTF's tooling and wide adoption has been a key to making this solution happen.

      Now that I've revealed some of those technical details, we can see how the power of open formats, like glTF with-- and HLOD combined with the collaboration between Autodesk, Esri, and Cimic-- it enables us to connect our platforms together. Together, we're creating scalable and interoperable solutions. Now I'll hand it over to Rex, who will walk us through ESRI's SDK for Unity, the final piece of this puzzle.

      REX HANSEN: My name is Rex Hansen. I work for Esri as a product manager for the ArcGIS Maps SDK for game engines. Just a little background-- Esri is the global leader in GIS software and services. And we work closely with our partner, Autodesk, to deliver comprehensive solutions to capture, create, manage, analyze, and share real-world landscapes and built environments.

      Cimic has invested in Esri as their enterprise GIS, and Tobe Builder, built with Unity, is founded on the geospatial capabilities of the ArcGIS system. I'm going to take us on a brief tour of the ArcGIS system to get us to the ArcGIS Maps SDK for Unity, which is the developer tool that Tobe Builder is using to integrate with ArcGIS.

      First, Esri builds ArcGIS. ArcGIS is a complete 3D GIS system for managing and integrating all types of 3D content, creating a platform for living digital twins. We help customers gather, create, and manage authoritative 3D geographic data in a GIS, a Geographic Information System, a system of record.

      Customers then use that data to visualize spatial phenomena, use location-based resources, establish associations, analyze impact, determine data flows, and really, better understand spatial and temporal patterns, then communicate and share those results and solutions to make better decisions.

      3D capabilities are foundational and continue to advance across ArcGIS, from enhanced visualization to 3D editing and analysis, like flood simulation, to supporting the latest 3D formats, like 3D tiles, and finally, creating focused, immersive experiences. We have hundreds of tools that enable you to extract features and look at them in a 3D setting across organizations.

      The capabilities are extensive and far reaching for creating the context and the canvas for dynamic landscapes and living digital twins. Now, Tobe Builder is an application built with Unity, a game engine, and uses one of our game engine SDKs, so let's drill in on creating immersive experiences.

      Immersive experiences are designed to drive deeper engagement through intuitive interactions with advanced 3D capabilities and seamless integrations. ArcGIS powers 3D and XR experiences that allow users to explore and analyze spatial relationships in an intuitive way, designed to reduce the abstraction between the digital and the real world across a variety of devices and focused apps. Now, let's refine our focus on game engine integration.

      To streamline game engine integration, Esri delivers ArcGIS Maps SDK for game engines as premium developer products that integrate ArcGIS with the two market-leading game engines, Unity and Epic Games Unreal Engine. ArcGIS Maps SDK for Unity and Unreal Engine provide a real-world global or local canvas and combine real-world geospatial data and analytics from the ArcGIS system with high performance rendering and interactive capabilities of a game engine. This includes leveraging physics engines, particle systems, and animations, which are standard functionality in a game engine. Now, Tobe Builder was built with the Unity game engine, so we'll focus in on the ArcGIS Maps SDK for Unity.

      Now, Tobe Builder is a great showcase of a world-class immersive application that combines the advanced capabilities of ArcGIS, Autodesk, and Unity to deliver an experience that models the real world and brings their 3D geospatial data-- really brings their scenes to life to be incredibly useful and productive for their projects and their customers.

      The ArcGIS Maps SDKs for game engines, including Unity, supports a wide variety of data sources today, such as base maps and terrain as well as mesh and 3D structures that represent BIM data. In addition, the plugin includes tools to manipulate geospatial data and place assets in game objects within a real-world context.

      Now, the road ahead for the game engine SDKs includes support for additional data sources, such as 3D tiles, point clouds, feature layers, the ability to query attributes and intelligence in your data, and better support for additional platforms, such as visionOS and Linux. We're excited to keep advancing the ArcGIS Maps SDK for Unity and the ArcGIS system as a whole, increasing integration opportunities between Esri and Autodesk to enable greater immersive experiences and improve productive workflows for Cimic and, of course, our customers at large.

      JOVAN HARROD: Thanks, Rex. As mentioned by Michael, we've been looking at what's next for loading even larger BIMs or insanely large BIMs into Unity for our products. The POC we've been working on has been focused on using HLOD or 3D tiles to load BIMs from ACC into Unity. And I'm pleased to share an update on that POC and a bit of that progress that we've made.

      Here, you can see a model in ACC. It's about roughly a 400-meg Navisworks model. And you can see the usual basic filtering-- sorry, basic viewing and filtering that we can do in the viewer. Now, in our current V4 pipeline that we bring data from ACC into Tobe Builder using-- we cannot consume this as a single model, and it needs to be broken up into smaller chunks.

      When it is imported, the frame rate is unusable, but thanks to an early private beta, we can bring that model in using a 3D tileset. Bringing this to Unity, we can do things like basic viewing and filtering using the technology that Michael has described earlier.

      What you're seeing in the video at the moment is basically loading in real time from disk, where we're using the 3D tile specification, and specifically, the Xmesh Features extension, to grab the feature ID from the actual verts of the mesh.

      Now, this is just a POC, and this is what it would look like when it works. But what we're showing is basically picking-- using that Xmesh Features to get that feature ID. And then using that, we can then get the properties for that mesh.

      Now, overall, we're seeing huge gains in loading time and frame rates, which also holds the promise of allowing filtering as what was shown by Michael in the web viewer. We're hoping this will become a part of our BIM ingestion pipeline. And that will allow us to load insanely large BIMs using the current Tobe Builder feature suite, which, in future, should allow us to basically have our five pillars-- that is our GIS; our full-fidelity, insanely large BIM; our temporary state that is our resources; and our temporary works; as well as time to bring together that project.

      Now, because we're in Unity, we should be able to deploy this to all the platforms it supports, such as enabling XR experiences that would usually require massive optimization of the BIM to be usable. This is an example of that same tile set that was shown in desktop Tobe Builder, used here in a HoloLens with the user easily able to interact with this BIM at a usable frame rate.

      I'll now hand over to Ken to talk about how this technology will be used to facilitate city-scale interaction with insanely large BIM and GIS in the future.

      KEN PANITZ: Thanks, Jovan. Well, Autodesk and Esri have been sharing with us how they're going to support the delivery of the LA '28 Olympics, our hometown of Brisbane, Australia is hosting the next games in 2032. And IDD Tech, we're imagining a future where multiple contractors can work together in a city-scale interactive environment to efficiently and effectively deliver all the required venues for Brisbane '32.

      Shown here is a POC of just that, 3 gigabytes of federated Navisworks models coordinated in an accurate coordinate reference system on real maps synced to a multi-year delivery timetable. This is our Holy Grail, a future where logistics and delivery can be coordinated across multiple sites and multiple contractors, where councils, utilities, transport agencies are all able to see well in advance how the delivery of the Olympic venues will impact their operations and the flow of their city. We'll work proactively to minimize disruption across Brisbane.

      If you share our hope for a better way of using integrated workflows and digital information to better support delivery, please reach out to us, because we'd love to talk. I'd like to take this opportunity to thank my cospeakers, Michael from Autodesk, Rex Hansen from Esri, and Jovan, and also a special thank you to Autodesk and Esri for being our partners on this journey over the last six years. Thank you.