Let us say you are planning to make a new innovative vehicle simulator. There are currently two leading game engines that you can choose: Unity and Unreal Engine. Which one would give you the best results? Which technology allows you to effectively minimise the development time? Although there is no universal answer for all projects, we can focus on the analysis of a particular case, which will help you to capture the big picture.
In this blog article, we will try to provide a comprehensive answer to the question of why eXpanSIM is developed in Unity instead of Unreal Engine.
eXpanSIM is a universal vehicle simulator with realistic physics of cars, trucks, construction machines, and military vehicles. The simulator is designed for professional applications, which hardcore simulation fans will find interesting. It is available on the Steam Store.
The Raving Bots team is responsible for both the concept and the implementation. For this project, we developed an original vehicle physics engine (check out this webinar to learn more). Some of us began their journey with Unity 3.0 and the Unreal Development Kit (UDK) in 2010. As a team, we started working with UE4 on commercial projects two years ago (2018) – see the screenshots. Below is what we learned during that time.
Vehicle physics
Both UE4 and Unity have simplistic vehicle physics based on the standard PhysX implementation (see the documentation). Unity oversimplifies the wheel collider (check the documentation) and gives no access to important information (current lateral and longitudinal slip forces) or a way to modify it.
In UE4, you have access to the source code, including the complete PhysX engine. You can modify the vehicle update method (see the source code), but for the cost of losing sanity when you see another repeated code for each vehicle variant depending on the number of wheels (Vehicle4W, VehicleNoDrive, VehicleTank). Things can get messy if you decide not to use their standard engine and gearbox.
You should also know that UE4 does not focus on reliable physics (at least when writing this article). By default, physics simulation is framerate dependent (read more here), so a vehicle may move slower on a slower computer. For our projects, we had to modify the UE4 core because the available sub-stepping option does not solve the problem for serious applications.
For some time now, Unity allows for executing the physics step manually. Managing the physics objects is easy because the integration with the physics engine is tight, and the lifecycle of an object is simple. Just recently, Unity announced that soon it would be possible to switch between the current physics engine and Havok (read the news), which is a great plus for us.
The picture below shows two professional vehicle simulators that we made in UE4 and Unity, respectively. For simulating an aircraft tow tractor in UE4, we modified the standard vehicle physics implementation. To deliver a highly realistic tank physics in Unity, we developed a custom vehicle physics engine.
Programming and testing
The primary programming language in Unity is C#, and in UE4, it is C++. UE4 Blueprints may be useful for quick prototyping and simple UI, but an entire project written in Blueprints would be difficult to manage. On the other hand, C++ may be blazingly fast if you are a skilled programmer. However, sometimes the performance gain does not always compensate for the effort spent on old-school programming.
The thing with C# in Unity is that if you avoid memory allocation managed by the Garbage Collector, then you can achieve the same (or very close) performance as C++ thanks to IL2CPP, the Burst Compiler, and multithreaded Data-Oriented Technology Stack. As a result, we benefit from instant code compilation, ReSharper (IntelliSense and static code analysis), built-in reflection mechanism, and no brain-melting bugs. The implementation of our custom vehicle physics engine is based on the Entity-Component-System (ECS), and we can not really complain about the performance or maintainability. The only problem is that ECS is still rapidly evolving and occasionally we need to refactor our code for the new ECS versions.
On the other hand, UE4 allows you for modifying the game engine and the PhysX library itself. Now imagine you compile PhysX DLL, then UE4 binaries, and restart the editor, and the editor randomly crashes because you made some silly mistake somewhere in the code, which you can locate by attaching the Visual Studio debugger to the UE4 editor. It is indeed an unlimited source of fun!
In the early days, the source code of Unity was closed. Today many components of the engine are placed in separate packages, for which the source code is available. Also, access to internal parts of the engine is possible with the Enterprise License.
In summary, working with vehicle physics is a challenge itself. The possibility to immediately test your code and human-friendly error logging offered by Unity saves the day. It is essential for fast prototyping and developing a new vehicle physics engine. UE4 may be an option if you are looking for a base implementation of vehicle physics that you only want to modify just a little bit.
The image below demonstrates how the standard vehicle implementation in PhysX can be investigated using the Visual Studio debugger.
Optimisation and performance
UE4 is superior if it comes to rendering a large number of objects (culling, batching, LOD system). Scenes with dense foliage and detailed trees work out-of-the-box in UE4. If it comes to Unity, the standard terrain and grasses eat more CPU than they should instead of optimally utilising GPU. You need some experience and time to achieve acceptable performance in Unity.
However, the standard systems in both game engines are designed for static and relatively small maps. If we want to add a dynamic terrain system (like in Spintires) and open world (like in Microsoft Flight Simulator), then we would need to add a custom solution to a chosen game engine anyhow. Currently, both game engines allow for that (which was not always true for Unity in the past).
As you can see on the screenshots below, the visual difference between UE4 and Unity is not striking. However, achieving a good performance in UE4 is less challenging than in the case of Unity.
Graphics quality
Everyone agrees that UE4 looks better. It has a high-quality light rendering model, nice post-processing, and impressive reflections.
In the past, it was apparent when a screenshot was made in Unity because it was ugly. However, recently, it is much less obvious. You need to admit that the Unity team is pushing hard to get close to UE4 and maybe someday the quality difference will be gone.
Our simulator focuses on vehicle physics, and graphics quality is not the top priority. Yet, some devs assumed eXpanSIM is done in Unreal Engine on different occasions, which convinces us that the Unreal Engine would not give us much advantage now.
The image below presents two screenshots taken in UE4 and Unity. Unfortunately, the scenes are different environments, so it is difficult to compare the lighting models. However, the lack of real-time reflections gives away Unity.
Editor
Both engines provide powerful tools for creating immersive scenes. UE4 delivers more editor tools by default, and Unity has more to offer on the Unity Asset Store.
In the case of our simulator, we developed many custom editor tools for Unity, which would be possible for UE4 as well. Perhaps the only thing that we miss in Unity is the fracture tool, which UE4 has integrated (Chaos Destruction). However, an alternative is one of the Blender fracture modifiers.
Assets
There are much more graphical assets on the Unity Asset Store than the UE4 Marketplace at the moment. It applies to both old and new assets. The offer of the UE4 Marketplace is improving, but our project needs graphics here and now. Fortunately, often high-quality vehicle models that are published on the Unity Asset Store or the UE4 Marketplace can be downloaded from Sketchfab. Also, non-restricted Unity Asset Store packages can be used in Unreal Engine, as well as UE4 Marketplace products that have not been created by Epic Games can be used in Unity (referring to this article and UE4 Marketplace FAQ).
Our team mostly consists of programmers, so a large selection of nice and inexpensive 3D models is a definite plus.
At the beginning of 2020, many new vehicle assets were published on the UE4 Marketplace, so it looks like the situation is changing quickly.
Cost
We calculated that if our project succeeds, the UE4 licensing model (see the revenue split) would be more expensive than the Unity subscription (compare the plans). UE4 has greater potential when used together with the Epic Store, but the community on Steam is more dependable (if we can say there is any on the Epic Store).
Also, it is much easier and less expensive to hire an experienced Unity developer than someone who commercially worked with UE4. It is important to us, because our studio is modest, and we are self-funding.
Just recently, we learned that there are other license options for UE4 creators and enterprise that should be considered too.
Summary
Unity made a huge leap during recent years, which makes it probably the most practical tool for developing custom vehicle simulators. Of course, it must be said that Unity has its problems, and Unreal Engine has still a lot to offer – especially when it comes to graphics quality.
Perhaps, instead of choosing between Unity and Unreal Engine, the advantages of both game engines can be utilised at the same time. In our case, Unity allowed us to prototype our vehicle physics and achieve satisfying results rapidly. With this work done, we can now migrate to Unreal Engine. We are planning to make a plugin for Unreal Engine with eXpanSIM physics (learn more here).
We hope that the study of our case will help you with deciding which game engine would be best for your vehicle simulator. This article will be updated.
Recent Comments