Article 6 of 7 in our Content Series: Dennis Marcus from Cruden discusses the reasons behind the company’s switch to the Unity engine for its driving simulators
Image from Unity Asset Store by ALP8310
The ability to render 3D content as realistically as possible is crucial to the success of a driving simulator. After many years developing its own rendering engine for driving simulators, about 18 months ago Cruden switched to the well-known Unity engine. A number of other engineering simulation tools that require visualization have switched to commercially available rendering engines or are in the process of doing so.
Unity began as a tool used in the gaming industry to convert a 3D model into a high-quality, 2D visualization for all sorts of games. The software is available to run on many different platforms, including PCs and mobile devices.
However, Unity is also becoming a de facto standard in the automotive industry for rendering real-time 3D content. Design departments for example, who work with engineering tools like CATIA on interior and exterior designs, often use Unity to render the digital models in 3D for use in a projection CAVE, or through a virtual reality head-mounted display (HMD). Unity enables them to visualize their designs with stunning realism, compare them with competitors and validate them with the input of management or test subjects. Unity is also used to deliver VR training tools. In car companies including the Volkswagen Group, it is the preferred tool for this type of rendering work.
Cruden had been following Unity’s progress for some time but driving simulators place additional demands on rendering engines, which is why we had continued to use our own – despite Unity’s emergence as a familiar, well understood tool among our automotive clients. But a year and half ago, we decided that the quality of their rendering engine was now suitable for our use, too. Development had reached a level where we could run it with the required resolution and frame rates, and were able to integrate it into our multichannel visual systems to make it available in a driving simulator.
We expect the speed at which Unity will develop in the future to be much higher than what we would have been able to do with our own rendering engine, so it made sense to make the shift. Cruden customers will benefit from the fact that Unity closely follows what’s happening with new GPUs and computer systems, keeping the rendering engine at the heart of our simulators right up to date and perform at the maximum ability of the available IG hardware.
Unity has immediately brought improved graphics quality to Cruden simulations. Its physics-based rendering (PBR) technology gives different materials a realistic look, based on the prevailing light conditions. Deferred Rendering is another benefit to graphical realism. It takes account not only of the sun as a single light source, but accounts for the light reflected by materials in other directions and of external sources such as car headlights when driving in poor weather conditions, or at night.
Cruden’s switch to Unity offers many more opportunities to expand and improve in this area. Instead of developing from scratch, we can dip into the large pool of plug-in features that are already available in the Unity Asset Store – a kind of App Store for the Unity engine that enables developers to share and monetize their work. We will be able to add leaves that move gently in the wind to our 3D driving sceneries, for example, or animate the roadside crane that our virtual car drives past. Much more is being developed by Unity’s worldwide development community; the sky’s the limit!
There are other advantages, too. The size of the Unity development community makes it easier for Cruden and the Cruden simulator operators to find and hire people who can build 3D content. Tools like VectorZero, which creates road scenarios from different sources for use in driving simulators such as Cruden’s, also creates 3D road models to be rendered in Unity.
More generally, the switch to Unity complements Cruden’s existing, open software architecture, making it even easier for customers to get content from sources other than ourselves. One can buy graphics only, but typically without matching LiDAR and OpenDRIVE data required for modern day automotive simulation. But 3D content still needs to be right at the source – Unity won’t compensate for the limitations of content that doesn’t strike the correct balance between graphical detail and frame rate. As described in Article 4, we believe that’s an area in which Cruden excels.
It’s also worth noting that Cruden had to tap into its driving simulator development expertise in order to deploy the Unity engine – which drives the signals to the projector – within the simulator’s Panthera control software. In integrating Unity, Cruden engineers had to change it from the typical, single-screen gaming application to a simulator-ready, multichannel visual system suitable for projectors.
Warping and blending
Warping and blending is required to create a projection system with one common screen. Projectors are typically designed for a flat projection surface, so when using multiple projectors on a cylindrical or conical projection screen, the rendered images have to be adjusted (warped) to create one continuous image optimized for the driver in the simulator. Blending refers to the process of aligning the images from two projectors to ensure the horizon is shown at the same height by each of the projectors. In the so-called blend zones, where images overlap, the brightness and color of the projectors has to be adjusted to make sure the blends are not visible to the driver in the simulator.
This work is further expanded with a module that corrects for a moving eye-position, for example when using a motion system. Cruden typically uses its own software for this warping, blending and platform tracking work, set up as a module within the Unity engine; at other times we implement solutions from other suppliers.
Right tools for the right job
As mentioned in the introduction, many other automotive simulation tools are switching to third party render engines like Unity and Unreal. When making this switch it is very tempting to try and get the best possible images from the new engine; if a tool shows high quality visuals, customers assume the simulation software is also of high quality. But as part of this process, developers soon discover that high quality visuals come at a cost, a lower frame rate for example. This is something we explored in article 4.
Another thing developers come to realize is that high-end render engines also require high-end visuals. So, depending on the applications, the integration of a third-party render engine depends on the application. For a DIL simulator, multichannel visuals and higher possible frame rate is important, but for sensor simulation using Unity or Unreal, the focus is on Physics-based Rendering (PBR) and a realistic reflection of light and radar signals on specific objects within the range of the ego vehicle. Put simply, Unity or Unreal integration in an engineering tool does not automatically make the visuals of this tool suitable for a DIL simulator.
In the final article in this Content series, we’ll talk more about projection and how advances in LED panel technology are opening up their adoption in driving simulators. Until next time!
For more information on the topics covered in this article, please contact Dennis Marcus via firstname.lastname@example.org or on +31 20 707 4646.
If you have enjoyed this article, why not sign up to receive more like this via our occasional emails.
Other articles in the series: