Game Engine Performance for AEC
Project Soane in the VIM Desktop Viewer

Game Engine Performance for AEC

Are Traditional Game Engine Architectures adequate for AEC Use Cases?

My old colleague Peng DU asked me recently on a separate post whether I thought the Unity game engine had sufficient performance for AEC use cases. It’s a nuanced answer, which I felt merited its own post.

Unity, like Unreal and other game engines in their generation (those designed between 15 and 25 years ago) do have more than adequate performance for many AEC use cases, when scenes and assets are prepared correctly (e.g., LODs, GPU instancing, segmentation of levels, splitting/combining meshes, etc.). However, it is a lot of time and work to achieve the desired level of performance for non-trivial models. Game engines are architected with the assumption that models are created for games by artists.

CAD models tend to be very large with lots of instanced meshes and objects. If we naively convert the elements of the CAD model (e.g., Revit elements) into game objects (actors) we will bring any game engine (or modeling tool) to its knees.

To work around this problem, we have three solutions:

  1. Hire an army of artists to remodel everything from scratch.
  2. Use an automated data preparation pipeline that optimizes meshes and materials, assigns game objects, and creates LODs.
  3. Used a specially designed rendering engine.

There isn’t much to be said about using an army of artists other than it is slow and expensive, but still a viable option in some cases. So I will focus on the two other alternatives.

Using Data Preparation Tools

Data preparation tools are a traditional approach to the problem. I spent some time at Autodesk working on their data preparation pipeline for bringing Revit models into the Stingray game engine, which powered the (now discontinued) Autodesk Live offering. It was interesting in that it was built on 3ds Max as a service, or what Autodesk calls the Design Automation API.

It was a clever approach in that 3ds Max offers many interesting geometry processing operations, has a great scripting engine, and supports many import formats. Unfortunately it was very slow. Like many game engines, 3ds Max also struggled with large and complex scenes with many objects. That said, if someone wanted to use this approach it wouldn't be that hard to recreate using Autodesk Platform Services (previously known as Forge). Recent versions of 3ds Max are better than ever at importing Revit models.

A similar approach is offered by both Unity and Unreal. They each offer their own of the box data preparation solutions: ?https://unity.com/products/pixyz and https://www.unrealengine.com/en-US/datasmith. If they work well for you, then that is great. However, if they are too expensive, complex, or slow, or they can't handle your larger projects, you need an alternative. ?

Custom Rendering Engines

What we learned at VIM, when we started transitioning away from Unity about three years ago, is that it turns out to be possible to design a rendering engine around AEC data that “just works” even with millions of instances, and tens of thousands individual meshes. In a nutshell we did this by placing all data in the GPU and managing picking, instancing, visibility, and occlusions there. When your geometry and instancing data is in a render-ready format (like the VIM format) then loading massive projects with GB of data can becomes almost instant. Rather than waiting for hours to pre-process data and recompile the engine. ?

Using a Vulkan based solution allowed us to side-step a slow and inefficient data processing pipeline, and worry about complexities in the engine like draw call batching. All the work is done in the GPU asynchronously, freeing up the CPU for interesting things like BIM data queries.

We further optimized the renderer by using a simplified shading model (e.g., no skinned animations, omitting textures, using ambient occlusion instead of shadows, etc.). The fact that this allowed us to handle geometry and scale of an unprecedented magnitude was worth it for our customers and use cases. In fact, the performance is so good, that we were accused by industry professionals of faking the results. ?

Final Words

So in summary, virtually any game engine can provide adequate performance, if you are willing to make the trade-offs and write the code for it, but sometimes it is just so much work, it is easier to rebuild from scratch when you know your specific use case.

David Thomson

Product Director with Digital Marine & Platform Focus | AI IoT, XR and PLM | AVEVA, IBM, Gravity Sketch Alumni

1 年

When at Aveva we had a very novel approach of directly rendering our CAD Geometry in unity 's g buffer via a hack of sorts. It meant no colliders etc but super fast performance and up to 6 months tike saving it data prep. Shame the project was dropped.

"If we naively convert the elements of the CAD model (e.g., Revit elements) into game objects (actors) we will bring any game engine (or modeling tool) to its knees." Actors: sounds very much like the old 'Building Object Behaviours' that BIM was supposed to give us. A solid needs to behave like a beam for it to function as a BIM object. A solid subtraction needs to behave in a certain way to function as a window. What is the state of the art today? Surely we dont want to end up with dumb models in the game engine that is just used for rendering, quantification and clash detection?

要查看或添加评论,请登录

Christopher Diggins的更多文章

  • Geometry Computation in the Browser

    Geometry Computation in the Browser

    This article explores the motivations for developing a low-level geometry library / kernel that can run in the browser…

    1 条评论
  • How Pixar’s USD Sparked a Debate in AEC: What Can We Learn from Hollywood?

    How Pixar’s USD Sparked a Debate in AEC: What Can We Learn from Hollywood?

    What is USD? USD stands for “Universal Scene Description.” It is a set of libraries and tools developed at Pixar over…

    20 条评论
  • Using AI to Help Design a Language

    Using AI to Help Design a Language

    Reading this back to myself, it sounds like science fiction, but over the last couple of weeks I have been using the…

    2 条评论
  • IFC Property Databases

    IFC Property Databases

    Towards Efficient Storage and Querying of IFC Properties Abstract We explore the advantages of using a relational…

    6 条评论
  • The World’s Fastest IFC Loader/Parser?

    The World’s Fastest IFC Loader/Parser?

    ..

    22 条评论
  • 10x Faster IFC File Parsing

    10x Faster IFC File Parsing

    In this article I share some early results while trying to write the fastest IFC parser that I can. Background on IFC…

    26 条评论
  • Effective Developer Documentation

    Effective Developer Documentation

    This article was inspired by a call-to-action by Jonathon Broughton from Speckle to provide feedback on how they can…

    1 条评论
  • The Entity Component System Software Pattern for AEC

    The Entity Component System Software Pattern for AEC

    Introduction to Entity-Component-System for BIM Developers The NXT BLD conference is today and regrettably I wasn’t in…

    7 条评论
  • Speckle Desktop: My Speckle Hackathon Experience

    Speckle Desktop: My Speckle Hackathon Experience

    Towards a Desktop BIM Design Tool For the Speckle hackathon on June 7th to June 9th, 2024 I wanted to create a desktop…

    2 条评论
  • AECTech Hackathon Ideas

    AECTech Hackathon Ideas

    I'm really looking forward to attending the AECTech hackathon at BIG - Bjarke Ingels Group in Barcelona this weekend…

    2 条评论

社区洞察

其他会员也浏览了