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:
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.
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.
Architect
1 年"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?