What’s on the Horizon for High-End Engineering Visualization

The last 30 years has seen incredible advancements in the 3D capabilities that are available on a PC. Without them we would not have a thriving multi-billion-dollar gaming industry. Despite these advancements the engineering community has been at a relative stand-still from a visualization perspective. The renderings you see in SOLIDWORKS today are not too different from what from where it was nearly 30 years ago.

PBR textures are widely available from various sources like these from Poliigon. (Picture courtesy of SOLIDWORKS)

Despite this there are several important trends taking shape around visualization that will impact visualization in the engineering world in the near- and mid-term. These are developments that any engineering software vendor should have on their radar – and they promise to push graphics in interesting and innovative new directions.

Realtime Photorealistic Rendering of Models

When it comes to graphics, the gaming industry has been long offered real-time, high-quality rendering. The desire for this within the engineering world has been limited mainly to the marketing departments. We believe this is going to change as simulation gets more integrated into the design process. Let me explain by first talking about how things have advanced in the gaming industry.

The gaming industry has been able to achieve high-quality renderings in real-time by having artists add sophisticated materials to the model and then leveraging the power of the GPU to render them real-time. A by-product of this is a new way of representing materials called PBR (physically based rendering). PBR represents materials as a series of equations which model how light reflects off the surface which can be implemented very efficiently by shader code running on the GPU. This allows for high-quality rendering of a model in real-time. The widely used GLTF and FBX formats both support PBR as a way of representing materials and so 3D users can easily share models with rich material definitions. This is helping significantly with the adoption of PBR.

So why has the engineering community not adopted PBR and how could that change? The main reason is that engineers are concerned with their design working optimally and photorealistic rendering is not needed for this. So while CAD systems have provided the ability to make their models look more realistic, few users take advantage of it. As simulation moves upstream and becomes part of the design process this is going to change. To do simulation, designers are often required to include material definitions with the model (be it a tile type for a roof or a metal specification for a part). In many cases once the material has been set the CAD system can have a shader which represents this and consequently provide a high-quality rendering at no additional cost. SOLIDWORKS has been a leader in providing high-quality shaders for materials with its realview capabilities and we expect their use to become more widespread as designers set materials for simulation purposes and then start seeing the additional value of realism.

Engineering Data Making it Out of Engineering Departments

There are a number of benefits to having engineering models look more realistic. A major one is helping with use of designs outside of the engineering department where there is a much stronger desire to have the models look more realistic. IoT and augmented reality (AR) represent a huge opportunity to leverage the use of engineering data. To attach sensors to the 3D design, IoT often requires the full model definition which is available in the original CAD file. At its heart, AR involves putting a digital object into the physical world – and if you're going to put it into the physical world, it needs to look like a physical object. This is why the investment in PBR is important. Same goes for virtual reality (VR). If AR is about putting something digital into the real world, VR is about being immersed in a 3D environment. Both of these immersive experiences have turned photorealism from a “nice-to-have” to a “need-to-have”.

IoT and AR/VR/XR both represent exciting new markets with significant opportunities and we’re expecting the CAD vendors to make sure their applications are going to be in a position to maximize their opportunity here which we believe will result in efforts being put into more photorealistic models through advancements like PBR.

Handling the “Density” of Engineering Data

Another trend impacting engineering graphics is the sheer density of data that needs to be visualized. More and more of the physical world is being captured by cameras and scanners, and that data – including its millions of triangles – needs to be dealt with effectively.

The density issue isn’t just related to 3D cameras and scanners – it's part and parcel of CAD data in general. For instance, a car that’s been modeled down to every last nut and bolt will constitute a huge number of surfaces coming from the CAD data alone. Furthermore, more sophisticated management of the data is resulting in significant amounts of additional information being attached to the model (e.g. manufacturer, cost, material etc.) which adds further weight to the data.

Many systems wind up choking on this design data because there is too much of it. As a result, customers wind up going in and removing various internal parts of the design manually, whittling the CAD data down to a more manageable size – not exactly a good use of engineering time.

More than being a hassle, it’s also counterproductive for analysis. While design, analysis, and simulation used to be somewhat “siloed”, engineering software has matured to the point that simulation and design are very much together now – and effective analysis requires the design data to be even more dense, not less. Accordingly, rendering systems need to be able handle the kind of visualizations associated with simulation, such as flow paths, vector fields, and highly tessellated meshes.

For all of the above reasons, the ability to handle increasingly dense data is something that engineering software cannot ignore to effectively meet the needs of its customer base.

The Merging of the Mechanical and Building Worlds

A closely related development to the above trend around data density centers on the aggregation of mechanical and building and construction data.

With many buildings today, it’s not uncommon for a major component like the HVAC system to be designed in a mechanical design application while the building itself is designed in a building information modeling product – and those mechanical design components need to be brought in and merged with the BIM model.

Again, the challenge with real engineering data is that if every last nut and bolt is modeled, you wind up with a massive amount of data that needs to be rendered. This problem is heightened by the fact that “designing from scratch” is, to a certain degree, being replaced in favor of importing pre-constructed parts from content libraries. This only guarantees that each and every component – whether it’s a ball screw, a flange, or an air cylinder – is going to be fully modeled.

As these building & construction and mechanical worlds increasingly come together, systems need to ensure they can effectively visualize the massive amounts of data that – far from being separate – are now regularly intermingling.

Continual Evolution

The engineering software space is continually evolving, and graphics and visualization capabilities need to evolve right alongside in order for customers to successfully tackle new challenges and capitalize on new opportunities.

Staying on top of some of the key developments in the space around the shift to PBR, the increasing density of data, and the coming together of mechanical and building data will enable engineering software vendors to best meet their customers’ rendering and visualization needs moving forward. In doing so, they will be able to push users’ productivity and capability ever further, while the landscape continues to shift and evolve around them.

This article was originally published in Engineering.com