This newsletter continues to cover what has changed in Unreal Engine, in transition from UE4 to UE5. Previous newsletter covered platform changes, rendering, and shader debuging, and now I continue with Chaos Physics.
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 behavior) 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 disappered, 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 depracated, 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 depracated. 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 depracated 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.
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.
UE5 Compared to UE4, part 2
100% agree. 5.0 is so unstable and barely working. I don't even consider 5.1 a stable version. IMO It will be in pretty much broken state after it is released. 5.2 maybe the first "go or no" version (hopefully!)