Unreal Engine 5 Compared to Unreal Engine 4

#unrealengine #gamedevelopment #gamedev #gameengine

People seem to have all kinds of views on what Unreal Engine 5 is, which mostly depends on how long you have used Unreal Engine previously, what kind of projects you have made, or whether you are interested in technical details of development at all. I will look at this from experienced Unreal Engine 4 developers point of view, going through many features and details which have changed in UE 5. Before I go to details, I like to tell about my views during this transition process.

Long Journey of UE 4

In order to get some perspective for all of this, I like to point out that even the development of Unreal Engine 4 has been a huge project, starting from early 2014. I have made this condensed video presenting how UE 4 has evolved, year by year, version by version. It is very easy to take all this for granted, although there is a tremendous amount of planning and work behind all this.

I want to make it clear that even when I criticize strongly some new development lines in Unreal Engine, I do it because I care about UE in general, and I still have lots of respect for all developers involved in making this engine, editor and development tools. Those developers have done a magnificent job, but like all developers, even they are human, and humans make mistakes sometimes, or make incomplete plans, or do not have enough time to implement what was planned. Development of game engine and editor is a very, very complex project.

When UE 4 was started, the game development was quite different than now. Most games used much simpler graphics, for example. Physically Based Rendering was just starting to get more common, but still many games were developed with those graphics pipelines that studios had used for years. Things like Subsurface Scattering came even later.

Virtual Reality was still an infant, and only a few developed something with experimental and clumsy Oculus Dev Kits. Year later there was HTC Vive and Steam VR, but everything was very experimental in VR until the end of 2017, when VR got more momentum. Years 2016 and 2017 were interesting for a VR developer, because you had to develop everything yourself. We even won couple of competitions and got Epic MegaGrant. Unfortunately it also showed how toxic and abusive the VR gamer scene can be.

By the year 2020, Unreal Engine was full of interesting features, added in numerous iterations of the engine and editor, and it had been free for 5 years. In my honest opinion, Unreal Engine was more than adequate as UE 4.25. It had all the features I think were necessary to general purpose game engine, and even some which were not-so-necessary. My point is, that there are so many different types of games and different needs, so it is not wise to cram everything (and kitchen sink) into one engine. By this time the planning and development of next generation UE was revealed, although only as a video presentation. It took another year, before Unreal Engine 5 Early Access version was released to general public.

Transition from UE 4 to UE 5

I guess the whole world knows about Unreal Engine 5 by now, at least the gaming and game development world, but it gained immediately lots of fuss in digital media production and among Metaverse enthusiasts. Main attraction of UE 5 - used heavily in all marketing - was its next level visual features, ultrarealistic real-time graphics which could be used in film and tv virtual productions, architectural visualisations, product presentation, simulations and games.

As a game developer I was disappointed. Realistic graphics are fine, but… graphics alone do not make any games better. There are lots of games with stylized, blocky or pixelized graphics, and yet those games have hooked players for years. I was disappointed because the announcement focused mostly on features which seem to be important for other media production, not games development. I can understand that non-developers wet their pants, when they see gorgeous graphics, and how you can blend them with the material you shoot with real cameras. They think about big productions and money. Developer looks at tools, stability, performance and mechanics under the hood.

When UE 5 was announced, there were 3 key points in the announcement - new lighting system called Lumen, new mesh system called Nanite, and finally the promise of UE 4 compatibility, which claimed that UE 4 projects could be continued immediately in UE 5, just open your old UE 4 project in UE 5 and everything works. There was of course Chaos Physics too, but that was nothing new. Chaos physics had been already introduced in UE 4… rather unsuccessfully. Chaos Physics was planned to work in UE 4.25, but Epic Games had to pull back couple of times, and keep it it as optional feature (which you had to compile yourself) while PhysX was used as default physics engine until the end of UE 4.27.

Both Lumen and Nanite sound wonderful, of course, although I was a bit sceptical. But the third point - UE 4 and UE 5 compatibility - that made me wonder. In order to work out that kind of stunt, either UE 5 is mostly similar to UE 4, or there are some really clever automatic conversion tools integrated to UE Editor. But… neither of these sounded convincing. Quite soon Epic realeased Unreal Engine 5 Early Access edition, and after that the final UE 4.27, both of them only increasing my scepticism. UE 5 EA was in some ways impressive, and in some other ways quite shoddy. Again, Chaos physics had caused problems, and it remained optional.

Based on my long experience with Unreal Engine, and based on my tests with UE 5 Early Access, UE 4.27, and source compiled versions of UE 5.X, I got a strong feeling, that UE 5 cannot be truly production ready soon… at least not during early 2022. With "ready" I mean something where all features work, and they are thoroughly tested, optimized and documented.

Tim has a Shiny New Engine for You

But as it happened, UE 5 was launched, and certain things that I feared materialized. Clearly UE 5.0 was not as ready as Epic claimed, and that disappoints me most. I am very tired on all these cheesy and glossy marketing promises. There was clearly a rush to get UE 5 out, since several mechanics lacked some features. This is not a problem if you are developing something that needs basic features and mostly used mechanics. If you make those asset flip dioramas for social media endorsement you will have no trouble at all.

But if you are developing something complex and extensively use very advanced features of UE, you probably find several things in UE 5 that "do not work", "are buggy", "are not ready yet", or they have changed so much, that your old UE 4 code isn't compatible. Basically the UE 4 compatibility is not just sunshine and rainbows, like it was promised. As you will see later, there are many fundamental changes in UE. You can open UE 4 project in UE 5, but you should be prepared for lots of manual work to get everything working like they worked in UE 4.

On the other hand UE 5 is an improvement in many ways, so… I have very mixed feelings about UE 5. I just hope that Epic Games put more focus on those features they start, and really finalize them, until starting yet another feature that will linger on with "experimental" status for several years. I am hopeful, but also sceptical. So, if someone thinks that after all that criticism above I hate Unreal Engine, I have to say that it is a totally wrong impression. On the contrary, I love using Unreal Engine - why else would I bother writing all these notes below. But I think that any user who really delves into the internals of some specific software is entitled to criticise things that do not seem to work. There is a big difference between brainless shouting and bashing compared to analytical criticism.

Differences, Differences!

However, this upgrade is not just new graphics - there are lots of changes in the engine features under the hood. Also, many thinks are not like people assumed based on those early marketing presentations. Yes, we got Lumen and Nanite, but they do not work everywhere. Now we have Chaos Physics, which works in its own way… except when it does not work. There are lots things that are new, that have changed or that substitute something that has been deprecated. I do not claim that following list is an exhaustive survey, but I have tried to list important differences between UE 4 and UE 5.

Development and Platforms

You have to switch to Visual Studio 2019, since UE 5 does not support previous editions of Visual Studio. I noticed in my own tests before official launch that Visual Studio 2022 worked better when compiling from source. Another important not is that UE 5 does not support 32-bit platforms, and never will.

You have to update build scripts and DeviceProfiles.ini (unless you use UAT), because all Target Platform Names have changed. They are now as follows:

One noticeable thing about UE 5 is that you need high-end hardware to utilize all those new features properly. CPU has to be quite powerful, backed with at least 32 GB of RAM, and GPU should be quite new. It is advisable to use fast SSD disks instead of old HDDs.

Rendering

Lumen and Nanites have been advertised so heavily, that clearly many have acquired utter misconceptions how they work. First of all they are not some kind of miracle technology which somehow circumvent laws of physics and algorithmic complexity. Second, they are not fully ready yet, and they do not work in all cases. And third, they are not a turnkey solution, which "just works" without any tuning. Lumen and Nanite do not work automatically, you have to tune all appropriate engine settings, prepare other components in specific way to use those settings etc.

Screen Space Global Illumination setting and console variable r.SSGI.Enable have been removed, and its status is not imported to UE 5. If you use it, then you have to re-enable SSGI as the default GI method, you have to set it in Project Settings, Engine - Rendering section, and change Dynamic Global Illumination Method to Screen Space (Beta).

It is important to notice, that if you use SSGI, and have Post-Process Volumes, then you have to make appropriate settings in the volume's properties, too. Volume's Global Illumination category has Method field, and it should be set to Screen Space (Beta).

Old Standalone Ray Tracing feature of UE 4 is deprecated in UE 5. Ray Tracing lighting effect is still in the engine, but it is now handled by Lumen. In UE 4 Ray Tracing was isolated feature from other lighting and end result was not always consistent. With Lumen things are different, and it implements ray tracing features for reflections and global illumination, but it is important to understand, that Lumen is still work-in-progress, and it continues to improve in the future.

Ray Tracing Reflections, Global Illumination and Shadows (not those Babylon 5 Shadows) are now separate features, and you can enable or disable them independently. They are handled in Project Settings category Rendering. If you want to use them, you must enable Support Hardware Ray Tracing in settings, too. Global Illumination and Reflections can also be set in Post Process Volume, where there are setting for these methods.

Lumen has a Software Ray Tracing feature too, and it uses Signed Distance Fields for mesh representation. You have to make proper adjustments in Project Settings, Engine - Rendering section in category Software Ray Tracing, and enable Generate Mesh Distance Fields. You can also adjust the Distance Field Voxel Density. Notice that default voxel density for all Distance Fields has increased from 0.1 to 0.2, so that Lumen will produce good software tracing quality. The obvious drawback is the increased Distance Field memory usage.

Hardware Tesselation has been removed entirely, because Nanite makes it obsolete according to Epic Games, although Nanite does not support all user cases… at least yet. Obvious remedy for this is to increase the resolution of assets. Likewise Legacy Tonemapper is not available in UE 5.

Light Propagation Volumes and Distance-Field Global Illumination (DFGI) have been removed, and Lumen handles these use cases. DFGI was experimental feature anyway, and neither of those features were developed any more. Lumen is under heavy development, and should eventually produce better quality results, although Lumen may have higher baseline performance cost.

Cascade is deprecated in UE 5.0, and it will be removed entirely in the future. So every developer should start using Niagara, and convert old Cascade effects to Niagara. There is an automated converter, but its results are sometimes unpredictable.

Shader Debugging

Numerous console variables for debugging shaders were renamed, and you have to update them manually. New names are more consistent and condense. Presumably many of these changes in setting and variable names aim to make things more clear, but there are changes which seem a bit odd, like why Duplicate shortcut has changed from CTRL+W to CTRL+D. Of course you can customize these keyboard shortcuts any way you like.

Chaos Physics

Chaos Physics is one of the biggest changes in Unreal Engine 5. PhysX is not an available, unless you compile the engine yourself, and in the forthcoming versions it will be removed totally. Although this is understandable for consistency and making engine upkeep easier, I would have preferred similar approach as in Open 3D Engine, where you can choose which physics engine you use. But modular engine is more complex to update. Although PhysX was old, had many quirks, and lacked many features that Chaos Physics has, PhysX was extensively tested throughout the years.

When it comes to Chaos Physics, it works very differently than PhysX, and is not thoroughly tested, and is clearly under heavy development and buggy. I do not buy those claims that Chaos Physics is extensively battle tested just because it is used in Fortnite. One game does not prove anything, because Fortnite is based in-house version of UE, it is developed by in-house developers who know engine inside out, and can fix things, that do not work in UE stock version.

Chaos Physics works so differently, that if your game uses lots of physics - especially if its primary game mechanics are physics based - then be prepared to go through all game mechanics, test their new (and probably weird behaviour) and make appropriate adjustments. Main reason for all this is that it is possible to simulate Physics on its own thread, instead of on the Game Thread as before. This is set as Tick Async Physics within Project Settings. However this is still considered experimental, and things may not work correctly.

Good thing is that this asynchronous Physics improves determinism of physical simulations, since it has a fixed rate, which is independent of game thread. This is important especially in networked games, where it is easier to keep physics events synchronized, because server and clients run at same pace when it comes to physics ticks.

But there are bad things, too. Since Physics thread and Game thread are now independent, there can be some delay between physics and game mechanics. If you receive and handle some input in game mechanics to trigger something in physics system, there could be an unpredictable delay. This can also happen other way from physics to game mechanics, e.g. when collision events trigger game mechanics events. So you should adjust your code to handle this kind of delays, especially in Blueprints. One solution is to run important physics dependent game mechanics in C++ callbacks, and execute them on Physics thread.

Physical Material has changed, and whole Friction handling has changed considerably, and I recommend going through all physical materials and all their individual settings and project settings. There is a new parameter value Static Friction in addition to old Friction value. Additionally, there are three new parameters - Sleep Linear Velocity Threshold, Sleep Angular Velocity Threshold and Sleep Counter Threshold - which control when and why a physics object is put to sleep.

Collision has couple of new settings, too, like Smooth Edge Collisions and Consider for Actor Placement when Hidden. First it may seem, that all these settings are new, but they are just reordered. But even if some of them are old settings it does not mean that they work exactly like they did in UE 4. I have to remind myself constantly, that there have been all kinds of bugs in UE 4, and now in UE 5 the physics engine has changed, and it is clearly a work-in-progress. Any engine update can change how things work. Based on my own observations it seems that only the most common features are tested properly, while rarely used features can have bugs which have not been reported, because no one really tests them. Considering how large piece of software Unreal Engine is, it would be unrealistic to assume, that all combinations of every setting in every feature could be tested in a limited amount of time.

When I imported some projects from UE 4 to UE 5 I noticed that Physics simulations did not behave in UE 5 like they had behaved in UE 4. This was a serious problem when movement was intiated by physical forces based on torque and rolling movement. That kind of movement depends on collisions, physical material settings like friction and restitution, gravity and mass. After considerable experimenting it seems that mass is handled differently. For some reason I had to increase objects mass considerably, and then increase torque forces too. Otherwise the friction did not work properly, and there was constant sliding that did not happen in UE 4. But… this could be a bug in engine, too.

There are even more new settings for Chaos Physics. Each physics object has a new setting Update Mass when Scale Changes and Auto Weld, which may bring surprising behavior depending how they are set. It is important to notice that most of the settings are reordered in editor panels, compared to how they were in UE 4, which is quite confusing at first. So, it may seem that some settings have disappeared, but they are just at a different place.

Collisions are sometimes quirky in Chaos Physics. Meshes may drop through landscape or other objects. There are clearly numerous bugs in collision handling. Similarly it seems that some old bugs have resurfaced, and you may not get Surface type data in collisions, instead getting only Default value.

All these physics settings are very important, and setting them right may give a tremendous boost when optimizing a game. Many developers do not understand, that game engines have to perform astounding number of calculations to control physics simulation, movement, collisions and overlaps in 3D geometry. Some calculations are trivial, but some of them are not. Very complex concave moving shapes demand numerous checks for complex collisions, and they have to be calculated several times in a second. So, putting things into sleep and using simple forms and approximations reduces the number of calculations and optimizes the simulation ensuring good performance. Don't be a fool, and think that UE can handle anything because it has Nanite etc. UE is still bound by the rules of physics.

Audio

Legacy Audio Backends are replaced by Unreal Audio Mixer, but this happens automatically. However, there are changes that user should be aware, since some components are deprecated, and they will be removed in the future and replaced with new systems, as shown in the table. I advise to start using new systems as soon as possible.

Control Rig

Most of the changes in Control Rig seem to be naming changes and structural reorganization.

You cannot use ControlRigHierarchyModifier in Python. Instead you should use RigHieararchy for querying rig elements and RigHierarchyController to author rig elements. ControlRigBlueprint no longer has a property named controller. To access the main RigVMController, use the function ControlRigBlueprint.get_controller(). Mapping is not handled in Construction Script, but on Pre-Initialize of Control Rig Component.

World Building

World Composition system used in UE 4 is now deprecated. It exists in UE 5.0, but it does not receive any updates or fixes, and will be removed in the future. It is replaced with World Partition to handle large, streamed worlds.

If you are using World Composition, there is a tool available to convert your existing maps for World Partition. WorldPartitionConvertCommandlet works from command-line, and you have to convert each map separately, one map at a time. Assuming that we have a packaged project ExampleGame, with a map /Game/Maps/Tools/Landscape/TM_Example, then it can be converted with a command

ExampleGame -run=WorldPartitionConvertCommandlet TM_Example -ConversionSuffix -SCCProvider=None

You have to substitute names as they are in your own project. When it runs, it will generate and save World Partition maps, builds runtime grids, and assigns map's Actors to the appropriate grids. If you know C++ and are interested, then you can examine UWorldPartitionRuntimeSpatialHash::ImportFromWorldComposition and UWorldPartitionRuntimeSpatialHash::GetActorRuntimeGrid to see how this process works and even modify it.

Various Tools

Old experimental Editable Mesh Plugin is replaced with new geometry editing tools. Interestingly, VR Level Editing is stripped down to only support VR Preview. VR Level editing was introduced several years ago, but I am not sure how widely it was used. I experimented with it, but in my honest opinion it was not very useful, but clumsy and tedious to use, at least when designing or editing large scenery. I can edit a scene much faster with mouse and keyboard shortcuts, and precision is better. I cannot see any advantage in it for a professional. It was more like a toy or a gimmick (and for truth's sake… VR scene was full of all kind hyped gimmicks, then).

Take Recorder replaces Sequence Recorder, and Camera Animation Sequences replaces Camera Anims. Matinee has been deprecated already in UE 4 for a long time, and in UE 5 it is fully replaced with Sequencer.

Old Stats System is replaced with Unreal Insights, although it exists in 5.0, but it will be removed eventually.

One really interesting change is the removal of Blueprint Nativization. This tool had lots of expectations and hype when it was introduced, since it transformed Blueprints into more native code, close to C++ … well, sort of. Of course, many users misinterpreted it and had false hopes, but in reality it was bit different than what they expected. Properly used it provided some performance boost, but on the other hand, Epic has optimized UE after that, and Nativization made development more complicated. My guess is that it had so few users, that it could be removed. If you happen to use this feature heavily in your project, then you should be cautious to import it from UE 4 to UE 5.

C++ Object Pointers

It may not sound much, but this is quite big change. Essentially this will replace raw object pointers in editor builds with new TObjectPtr, which is a template-based, 64-bit pointer system. It is intended to provide dynamic resolution and access tracking in editor build, but it will perform identically to raw pointers in non-editor builds. However, this is optional, you may continue to use raw pointers.

It is advisable to use TObjectPtr<T> instead of T* for UObject pointer properties and container classes found in UCLASS and USTRUCT types. There is no performance gain, neither does it decrease performance, but it may provide benefits when developing in editor builds.

If you start using this new pointer system, then there are some convention that are good to use. When you call Find family or container functions, you should use TObjectPtr<T>* instead of T** to capture the return value. If you have used auto* as the iterator in range-based iteration through raw pointer containers, then you should change them to auto&. Usage of auto& can optimize access, since TObjectPtr can cache resolved object addresses.

In most cases TObjectPtr automatically converts to raw pointer type, like when passing parameters to functions or storing data in local variables. But there are cases where this automatic conversion does not work, like ternary operators and usage inside const_cast.

UE 5 includes an automatic conversion tool, which converts engine-visible raw pointer properties to the TObjectPtr system. You can find it in UE5/Programs/UnrealObjectPtrTool/ section of the solution hierarchy in your code IDE. Source code is in directory Engine/Source/Programs/UnrealObjectPtrTool, and the executable in /Engine/Binaries/Win64 or Engine/Binaries/OS directory, depending on you operating system.

Conclusions

It is clear that you can continue to develop your UE4 project in UE5, but depending on your project there may be lots of work to get things working as they worked in UE4. Big question is if it is worth it? Do you really need those glossy new features? That is something everyone has to decide for themselves, it depends on what kind of project you are developing.

But the real question is not should you move to UE5, because eventually you have to do it anyway. UE4 won’t be supported for long, I assume. There is no point for that, and Epic Games will use all available resources for UE5. So, the the real question is when you should continue your projects in UE5. My own view is that UE5 is not really ready yet as UE5.0. Forthcoming UE5.1 will show how everything has improved, but my eyes are more on UE5.2 as a transition point. Right now there are many features that are clearly work-in-progress, and many things can change with each update, making game development bit like walking on thin ice.

If I find something important that I did not cover, I will try to tell about it in another newsletter. I plan to cover at least new World Building and Audio systems later, in more detail.