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

[DavidGraham]

Well to be fair, Lego Horizon isn't really especial in the regard, it's a simplistic game, it's not really open world, and the environments are broken up into small chunks separated by brief fade to black loading screens that last for 1 second (on my Samsung 990 Pro SSD/Ryzen 7800X3D). So any traversal stutters or shader stutters are constantly being eliminated in these loading screens.

I played Hellblade 2 yesterday, I encountered 3 traversal stutters in one large area, it appears these stutters occur more frequently in areas with many intractable objects, perhaps confirming the many actors theory, those traversal stutters were certainly lower than other UE4 games, but they still happened none the less. I also encountered several shader compilation hitches in a large fight scene, they were instantly gone the second I replayed the scene (confirming they are shader stutters), they happened even though the game did it's usual warm up shader compilation.

While I didn't try Empire Of The Ants myself, I discovered it is full of traversal stutters whenever the ant jumps from one area to the next, it's visible on several YouTube runs (like this one here).

I don't necessarily believe traversal stutters happen more on PC than PlayStation/Xbox, two fresh examples that come to my mind are Jedi Survivor and Dead Space Remake (on Frostbite engine), both suffered greatly from traversal stutters on consoles. I am sure there are examples but I can't remember them right now.

I really wish Epic would backport some of the shader stutter mitigations from UE5.3 to UE4, I reiterate it would be a huge PR win for Epic and a huge win for PC gamers. Since 2023, we had Hogwarts Legacy, Stellar Blade, Jedi Survivor, HomeWorld 3, Alone In The Dark Reboot, Ghostrunners 2, Lies of P and others, all using UE4, not to mention the tons of small indie games. I am sure there are still other games that will continue to be made in UE4 for years to come, it would be a great help if the developers community had access to better shader compilation tools in UE4 to make the experience much smoother and enjoyable for PC gamers.

 

[Liandry]

What is this title above, battle royal game?

 

[GhostofWar]

What is this title above, battle royal game?

I think this is the game you were asking about, assuming it was referencing the post with pictures but not alot else.

Off The Grid | Early Access | Gunzilla Games

In Off The Grid, your mission is simple: Survive. Loot. Dominate. Jump into Early Access and experience the mayhem first-hand as we unleash new locations, weapons, and cybernetic limbs to build your ultimate warrior. Whether you’re battling it out in the heart of a high-stakes Battle Royale or...

gameoffthegrid.com

 

[trinibwoy]

Welp STALKER 2 isn’t doing any favors for UE5’s reputation. Performance seems very broken based on early reviews.

 

[GhostofWar]

Here's a video with a bit more info, Towns & built up areas seem to hit cpu pretty hard. Going to get this and try it for myself either way once I get some free time to kill.

 

[raytracingfan]

I really wish Epic would backport some of the shader stutter mitigations from UE5.3 to UE4, I reiterate it would be a huge PR win for Epic and a huge win for PC gamers. Since 2023, we had Hogwarts Legacy, Stellar Blade, Jedi Survivor, HomeWorld 3, Alone In The Dark Reboot, Ghostrunners 2, Lies of P and others, all using UE4, not to mention the tons of small indie games. I am sure there are still other games that will continue to be made in UE4 for years to come, it would be a great help if the developers community had access to better shader compilation tools in UE4 to make the experience much smoother and enjoyable for PC gamers.

Do we have any data on this? Are there still developers that are starting new projects with out-of-the-box Unreal Engine 4 even today, or is it just games that began development years ago finally coming to market or studios remaining on their forked and customized versions of UE4?

 

[IQandHDR]

I am seeing some..."fizzle" when raytracing are being used in UE5, espceially with fog present.



It is actually really distracting and I do not see the same kinda of "fizzle" in eg. CyberPunk 2077 with REDengine
The only other place I have seen this is in "halfLife 1" with a RayTracing MOD installed (https://github.com/sultim-t/xash-rt/releases) in the intro where "god rays" are really low resolution in the intro.

I could try and record some video, but I need to install the NVIDIA App then first I presume.

Since this is my first EU5 game, I hope this is a one off (due to the dev) and not a game engine issue?

 

[raytracingfan]

That just looks like ray tracing noise that wasn't cleaned up by the denoiser. It's inevitable if the sample count is too low to be cleaned up or the denoiser was ineffective.

 

[milk]

I am seeing some..."fizzle" when raytracing are being used in UE5, espceially with fog present.
View attachment 12400
View attachment 12401

It is actually really distracting and I do not see the same kinda of "fizzle" in eg. CyberPunk 2077 with REDengine
The only other place I have seen this is in "halfLife 1" with a RayTracing MOD installed (https://github.com/sultim-t/xash-rt/releases) in the intro where "god rays" are really low resolution in the intro.

I could try and record some video, but I need to install the NVIDIA App then first I presume.

Since this is my first EU5 game, I hope this is a one off (due to the dev) and not a game engine issue?

Ray-marching heterogenious volumes is very costly. No game does it at full resolution nor without relying heavily in stochastic dithering and temporal acumulation/reconstruction. This kind of smoke, dust, fog, is fuzzy in every game that sports it, but some hide it better than others.

A highly dynamic object intesecting the bussier areas of the volume such as here is the absolute most pathological scenario.

 

[IQandHDR]

Ray-marching heterogenious volumes is very costly. No game does it at full resolution nor without relying heavily in stochastic dithering and temporal acumulation/reconstruction. This kind of smoke, dust, fog, is fuzzy in every game that sports it, but some hide it better than others.

A highly dynamic object intesecting the bussier areas of the volume such as here is the absolute most pathological scenario.

That makes sense, thanks for the explanation.
It just a slight annoyance (for me) that is breaks immersion right in the intro of the game.
That and shadow LOD on the flight to the mountain are my biggest "ticks" in this game.


And it is even using RR per the .dll's, so the issue is not a "bad" denoiser:

 

[chris1515]

https://twitter.com/x/status/1861446070858846571

The Witcher 4 enter full production

 

[Karamazov]

https://twitter.com/x/status/1861446070858846571

The Witcher 4 enter full production

Hmm...

 

[IQandHDR]

Will be interesting to to compare the raytracing to RedEngine (CyberPunk 2077) as they set the bench pretty high with that one.

 

[Karamazov]

 

[Shifty Geezer]

This doesn't use Nanite, right?

 

[Karamazov]

not for everything, but some elements do. (trees, statues etc...)

 

[Shifty Geezer]

Why's that then? There's some pretty egregious pop-in (very visible at 4:17 and 8:07) pop it's isolated to random elements where other similar elements, like other rocks, have no similar LOD.

 

[Dominik D]

A common one that has been discussed in quite a few UE talks is relying on blueprints too much, but I'd extend that to the entire actor/component infrastructure. (...) This of course has always been an issue even in UE3 and 4, but with people creating larger and more complex worlds it becomes even more important to address. This is of course what MASS and PCG and similar systems (demo'd in CitySample and ElectricDreams among others) tackle in various ways (...)

Blueprints are fine. You can write most of your game in BP and get the performance you want. The issue is not what (BP) is used but how. It's very easy to pull too much into your BP, it's too easy to rely on tick and it's much easier to recalculate things than it is to cash them. It's not that BPs can't be used extensively it's that ergonomics are not there and the path of least resistance is often suboptimal. This is compounded by two banes of game development: waiting with performance monitoring for too long and lack of investment in automated testing. By the time you start looking at performance issues you're typically down to only one option: rewriting parts of your BPs in C++. Not because logic couldn't be in BPs but because untangling wacky dependencies in BP would be riskier than doing some massaging in C++. MASS and PCG aren't solving these issues as they either exist for different use cases than BP are used (MASS) or require designing entire parts of the game around them from ground up (PCG) and can't be used during development as a crutch.

HLOD is another area of the engine where I suspect people get tripped up on because it is both very necessary once you have worlds of certain sizes, but also a bit of a bespoke workflow. Obviously engine improvements can help here and they do continually come, but I suspect some folks effectively get a bit over their heads with respect to their ambitions.

In UE5 (BTW, HLOD can mean many different things in UE) when you're using world partition, HLOD is a massive, complex system that interacts with multiple pieces of engine in non-obvious ways. It's under-documented and really hard to use. Undocumented and non-obvious is Unreal's unifying thread.

So if you're a developer working in UE5, you should probably make sure the engine can handle what you're trying to do. If it doesn't you can alter your game or alter the engine.

It sounds simple in principle but like I said above: Unreal is massive, complex, and very few people understand how different things interact. And more often than not you don't need to modify the engine. What you need is understanding of a subsystem that's poorly documented or even hard to discover (there are tons of things UE can do but very few people know exist). Undocumented and non-obvious.

Yes, typically the developers of Unreal Engine games. But I'll leave it at that. I get it.

Your blind spot seems to be that the same issues pop up in non-UE games. It's just (like many pointed before) that there are fewer non-UE games on the market. You're ignoring your priors. It's tempting to claim that games wouldn't have similar issues if only developers used different tech. But that assumes that UE is used despite its clear problems for seemingly no gain. Surely you don't think that developers are blind to solution this obvious.

From my experience with the engine a lot of traversal stutter comes from expensive actor initialization.

Yup. Streaming the content in and performing gameplay-related logic (which is typically single-threaded) is what chokes most games.

What Epic can do is educate people better. Another thing is improving their profiling tools, something they are actually doing late in to UE4 and are continuing with UE5.

Before you profile anything you need to know what is there for you to use. There are so many things UE delivers out of the box that are hidden. A lot depends on tribal knowledge. If you work with sufficiently many UE experts you will absorb knowledge through osmosis over time. But boy, is Epic really bad at educating about their engine. Most videos and articles are extremely surface level and fall apart the moment you start working on a semi-complex project. It looks great when you deliver new feature and have a flashy hour long presentation. But it all falls apart when you start using it. Suddenly you're on your own and have to build a game while trying to catch up with development Epic did on a feature. So read that code like a champ because that's the only way to learn how things work. :|

The problem is just educating people on how to do it better.

"Just" is doing a lot of heavy lifting here. Epic is, in my view, pretty terrible with educational material. What they do feels sufficient if you don't use their engine. But isn't as soon as you do.

Folks have to realize that there's not some smooth division between "engine" and "game" code in Unreal.

I intended to quote this in disagreement but this really depends if we're talking about making game (then I disagree) or learning UE (in which case I agree). Diving into engine is often the only valid way to build expertise. Good luck finding the time for that while you're also building a game.

I think it is more that developers simple don't know and don't care enough to become more knowledgeable.

Yes, developers are lazy and don't care about anything.

If I make a thread on Steam forums, or a support ticket and say something like "you're spawning too many actors.... yadda yadda.." they're just mostly going to ignore me.

If you can't back your claim with data, why would they? I mean, this is as helpful as "could you please write fewer bugs? kthxbye".

 

[Karamazov]

Why's that then? There's some pretty egregious pop-in (very visible at 4:17 and 8:07) pop it's isolated to random elements where other similar elements, like other rocks, have no similar LOD.

maybe because it still has to run on last gen hardware and you can't make a whole different looking game for gameplay purposes, plus the still available 120fps mode which uses the standard rendering.

 

[Remij]

Your blind spot seems to be that the same issues pop up in non-UE games. It's just (like many pointed before) that there are fewer non-UE games on the market. You're ignoring your priors. It's tempting to claim that games wouldn't have similar issues if only developers used different tech. But that assumes that UE is used despite its clear problems for seemingly no gain. Surely you don't think that developers are blind to solution this obvious.

No, I'm not blind to it... I call out issues in every game I see.. ESPECIALLY regarding hitching and stuttering. Obviously I'm putting more emphasis on Unreal Engine for precisely the reason you mentioned... it's used in more games, it's more prolific, and it's an issue game after game after game. And it's not some assumption to believe that developers who code and built their own engine for their own specific purpose will have more of an understanding as to why issues are happening in the engine and are more likely to avoid them or at the very least address them.

If you can't back your claim with data, why would they? I mean, this is as helpful as "could you please write fewer bugs? kthxbye".

So you're saying unless I can tell them specifically what is wrong with their code and show them the errors in their code, I shouldn't mention it? If I explain the symptoms with proof and suggest the cause it is still ignored much of the time. Why even make this comment in the first place when the entire post that you edited out explains exactly why I said they wouldn't take said comment seriously?