The Multi-Project Real-Time Visualization Optimization Strategy

Few things draw the ire of a video game fan more than a low frame rate. While TV and film are traditionally presented at around 24 frames per second, avid gamers prefer 60 frames per second (fps) or more.

To achieve this, video game studios often invest heavily in ensuring the game is as ‘optimized’ as possible to ensure fluid play even on slower devices. For AAA titles with multi-million dollar budgets, entire teams are dedicated to optimizing for maximum fps. Things that affect optimization include poly count, texture map size, anti-aliasing, level of detail (lod) batching, lighting and more. Each of these areas can be focused individually resulting in a net positive effect of positively improved frame rates.

While Civil FX and similar infrastructure visualization teams are cousins to our video game studio counterparts, our operations vary in several ways, perhaps most notably in budget. Because our audience is sometimes a small group or demographic and often for a limited period of time, we can’t compete in scope with video game titles that are designed for millions to play over the course of many years. In other words, the amount of time our content will be consumed is smaller than our video game counterparts not by a factor of tens or hundreds but by thousands or millions. The number of eyeballs that will see every asset in our visualization in detail isn’t even in the same ballpark as the number of eyeballs viewing each asset in even modest video game titles.

But while we don’t have the same level of budget or even justification to optimize our real-time interactive visualization (built using essentially the same technology as video games) this doesn’t mean these experiences don’t need to be optimized. Using a 3D model for a highway interchange at 10 fps is every bit as frustrating as trying to play a choppy video game.

Part of the problem is that interactive visualization is new in our industry. Our clients are often paying us for a rendered animation and we are delivering the animation using an interactive model with the deliverables both being a video file and executable file. In scenarios when the client is explicitly paying us for interactive visualization, the available budget is typically still similar to the rendered animations that have become industry standard because the end result of non-interactive and interactive is still the same- communicate the design of the project.

Because of this we often find ourselves in the situation where we need to optimize to keep our performance at an acceptable level without the budget to do so. Luckily, our clients usually are happy with a sub-60fps rate and advances in graphics cards in recent years have given us a much needed boost to push our un-optimized models to the max, but without any optimization, even the fastest graphics card will choke on millions of draw calls and polys. Our habit of using 4k displays wherever possible doesn’t help our frame rates.

Our first interactive project really struggled in most situations. This was before the GTX 10 series took things up a notch and any optimization efforts were an afterthought. Buildings were modeled in Sketchup and brought directly into Unity resulting in thousands of extra draw calls. We did spend some time on traffic and vehicle optimization so that each vehicle + axels were only one draw call with the wheels turning but we had to do heavy ‘culling’ so that cars quickly disappeared into the distance after only a few hundred feet. Using SpeedTree was helpful optimization out of the box as the LOD settings greatly enhanced our ability to show the thousands of trees on the project. Fortunately, the rendered videos were seen much more than the interactive visualization experienced so there were very few complaints about performance from the clients or other end users.

Our projects now still struggle at times with optimization but they have gotten better both in terms of performance and quality. Our traffic system continually improves to the point where we now don’t have to use any culling and can show thousands of cars at a time. Our buildings are usually baked into combined meshes and textures. We have even built an optimization slider in the settings so on the fast end less vital assets like distant buildings and parked cars are turned off and the shadow distance is shortened while on the slower render (typically used for rendering or with fast graphics cards) everything is turned on to the max.

Unlike big box titles that have significant budgets built in for optimization, we have learned that our optimization comes here a little and there a little, one project at a time. Fortunately, our clients seem to be satisfied at nearly every turn and the net result is affordable transportation visualization with (relatively) smooth interactive performance. It has taken us dozens of projects to get where we are and it will take many more to get where we need to be, but that is how progress can be made.