Unreal Engine 5, [UE5 Developer Availability 2022-04-05]

Low clocks on a wide CPU is even more reason to improve threading support.

They did as games would have run like dog shit on PS4/Xbone if they didn't.

There was just no need to on PC as any half decent quad core could easily deliver more CPU performance.

We're now feeling it this generation as a result, and even now, the current console CPU's are falling considerably behind.

20240511_141642.jpg
 
Let's remember it's not just "multithreading in general" - which is a nebulous concept that is more about the details than the consumer view of it - but also that the content itself has shifted drastically in the past 5 years or so. As new technologies come online that remove previous barriers, content starts to push it hard in ways that it was never pushed before. A dynamically lit open world stresses completely different parts of the engine than a game with baked lighting and level loads.

CitySample was a step towards Unreal doing a better job of the former, but nothing is ever really finished in game/engine development. While Nanite and Lumen did a pretty good job on the GPU rendering side of things, much of the engine has never had to deal with 2+ million instances of things moving around. Even compared to other open world games CitySample is a bit of an outlier in complexity of course, so some of the best practices are still being worked out.

And that's worth remembering in all of these discussions: CitySample is an interesting workload, but it doesn't necessarily represent the end state of how to produce content. Both Epic and the whole industry are constantly learning and relearning how to use these tools best to do new and exciting stuff. While it's easy for a bystander to say "why didn't they anticipate this problem", in reality it's much more that many pieces of the puzzle are moving at once and new bottlenecks are being revealed and addressed constantly. UE 5.4 hits a bunch more that impacted CitySample heavily, but you don't have to go too far to also find a list of folks complaining that Epic claimed X% better performance and my game didn't get faster at all. There's just a huge array of very different types of content that get thrown at a modern engine like Unreal, each of which will have their own priorities and issues.
 
So there is still no modern AAA engine built from the ground up on SSD and full multithreading? Nice...
Multithreading is really difficult (and in some cases impossible). Rewriting certain parts in Rust would make it easier, but that is a really big engineering decision.
 
Both Epic and the whole industry are constantly learning and relearning how to use these tools best to do new and exciting stuff. While it's easy for a bystander to say "why didn't they anticipate this problem", in reality it's much more that many pieces of the puzzle are moving at once and new bottlenecks are being revealed and addressed constantly.

That’s fair but software design isn’t all reactive. There is some forethought and planning expected in tackling existing and new problems. So I think it’s also fair to be curious about how effectively these engines are being adapted to leverage modern hardware and tackle new problems.
 
That’s fair but software design isn’t all reactive. There is some forethought and planning expected in tackling existing and new problems. So I think it’s also fair to be curious about how effectively these engines are being adapted to leverage modern hardware and tackle new problems.

UE avoided tackling good multithreading and GPU resource usage for quite a bit, third party devs have been complaining about it since last console generation. Internal politics are going to be politics, and that giant mountain of code debt couldn't have been fun to tackle.
 
UE avoided tackling good multithreading and GPU resource usage for quite a bit, third party devs have been complaining about it since last console generation. Internal politics are going to be politics, and that giant mountain of code debt couldn't have been fun to tackle.
Right but again it's a bit more nuanced than that. Many parts of the engine have had excellent multithreading for a long time (hence why they rarely show up in complaints). Render thread parallelization is just one recent part of the work, but honestly game thread stuff is another level of difficulty too because it's not something that can generally just be done at the engine level, but needs content to adapt. Like PSOs we're all eventually going to come back to "the power of the tools exposed to content creators lets them do things that are very hard to fix/improve at an engine level later", and game thread is another great example.

As an engineer this is often frustrating, but I continue to remind myself that the flexibility and power of the tools is also a big part of the popularity of the engine itself. It's easy for me to say "hey we should have restricted some of the stuff in the material editor and blueprints to allow us to much better optimize and parallelize on the backend", and indeed many game engines fall in different places along that curve. But could I say with confidence that if Unreal had more restrictive content tools and thus Fortnite (or whatever example) had less stuttering but also potentially less variety of content it would be more or less popular than it is? Or the engine itself would be more or less popular? I don't think anyone can answer those questions with confidence, so in the end it's more just a question of continuing to iterate and do the best we can with the content that already exists, while slowly adapting it over time to become more efficient.
 
Last edited:
If the choice is UE 5.0 with no lumen and nanite, but you get them in 5.4 when the backends for those systems are better multi-threaded,
OR
we get what we got, which choice you making?
Even as consumer i think the option of getting access to these tools earlier is better.

Let alone the work that goes in the art and content pipelines, and plugins to best support and enable lumen and nanite content in actual games.
getting those technologies into UE earlier allows for a greater ecosystem to build around them, even when they are in imperfect state.
 
@vjPiedPiper people like to think there’s a perfect time to release tech, but usually getting it into more hands early is better. Holding onto nanite, lumen, vsms probably pushes the current quality and performance further out. Ultimately they’re just options. The trajectory for UE5 has been nothing but positive. Looking forward to see what comes in UE 5.5 or even the next season of fortnite which is soon. Fortnite received motion matching well before he 5.4 was released.
 
If the choice is UE 5.0 with no lumen and nanite, but you get them in 5.4 when the backends for those systems are better multi-threaded,
OR
we get what we got, which choice you making?
Even as consumer i think the option of getting access to these tools earlier is better.

Let alone the work that goes in the art and content pipelines, and plugins to best support and enable lumen and nanite content in actual games.
getting those technologies into UE earlier allows for a greater ecosystem to build around them, even when they are in imperfect state.

Earlier is better of course. Were the multi-threading improvements specific to the new Nanite renderer though?
 
UE5 has loads of legacy codebase as it's not really a clean slate modern engine but a continuous upgrade project all the way back from UE1 (probably).
How many "clean slate modern engines" are there? There are countless engines still in use today that trace their roots to some version of id Tech. CryEngine has spawned its own successors. Creation 2 has its roots in Gamebryo. Iteratively upgrading engines as necessary seems to be the norm. At a certain point an engine probably becomes a Ship of Theseus, but I doubt many devs are interesting in starting engine development from scratch just so that they can claim to have a "clean slate".
 
How many "clean slate modern engines" are there?
There are some but a complex engine is rarely "clean slate" as it's just infeasible to write one from scratch in parallel to a game being developed on it.
The point however is that UE's legacy part is a lot bigger than in some engines which were created much later than UE1.
 
I'm not sure if there's a way to control time of day on replays, but it doesn't seem like I can just roam the map in creative. You used to be able to make an empty full island, but now it just seems like these small template maps unless I'm missing something.
 
I'm not sure if there's a way to control time of day on replays, but it doesn't seem like I can just roam the map in creative. You used to be able to make an empty full island, but now it just seems like these small template maps unless I'm missing something.
Best way is to play a game then survive long enough for a full day night cycle to happen, then use the time bending in replay mode.
 
Best way is to play a game then survive long enough for a full day night cycle to happen, then use the time bending in replay mode.

Yah, I had a long game but I didn't see the right day night. I'll check some of my wins again. The other things that's annoying is if I change graphics settings while viewing a replay the game crashes to desktop. I can change settings during gameplay just fine.
 
Back
Top