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

[Remij]

Obviously not something you should forgive but the drive-bys on Unreal are getting tiresome. You literally just used the opposite logic in the DF thread regarding DLSS and PSSR (it must be the game's fault, despite the fact that those techniques are way more black box and have way smaller API surfaces than something like a game engine).

There's obviously plenty of games at this point that run well without issues on UE5 that are way more complicated that DQ3. There's also plenty of games that run like shit that don't use Unreal. You're not considering the prior probability (i.e. that a large number of games use Unreal these days), and letting your emotional response just pick a target that can consistently blame rather than the reality of lots of games have lots of different issues.

... and of course so am I. As I like to remind myself and everyone, it's obviously fine to call out issues in games. Pattern matching can be useful although it's worth reminding ourselves that it's a better debugging tool than root cause tool. The place where people tend to overstep their bounds is when they confidently claim a root cause for issues they don't really understand.

Ultimately consumers are not the customers of Unreal Engine (outside some stuff like UEFN, which blurs the line a bit but also comes with significant guardrails). Game developers are the customers of UE, and consumers are customers of the game developers. At B3D we like to break things down into the tech which is fantastic, but when it starts to stray into misdirected internet rage it just distracts from that discussion. I realize this is what gets clicks for the tech reviewers, but we don't really need to bring it here as well.

IMO the more interesting discussion (if people even want to have it) is what sorts of pitfalls do folks potentially run into that causes these kinds of issues that other people (ex. The Finals, Satisfactory, Hellblade, ...) are able to avoid. In reality it's gonna be a ton of different things, but naively I'd guess that the ease of use of the engine from the gameplay side is potentially a bit too enticing and can lead people down some bad paths. 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. The naive way to do things (treating actors as self-contained blueprints/prototypes and then creating large amounts of them to fill out a world) can lead to significant overhead. 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, but really the expectation is that if you are going to create a large scene with tons of objects you're going to need to make appropriate infrastructure in the game itself, based on these frameworks or otherwise. Satisfactory is a great example of handling tons of objects, but they certainly don't have a blueprint ticking for every item on a conveyor belt...

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.

I don't feel like I'm applying different logic regarding PSSR in the other thread. If PSSR consistently had the same issues for the next 3 years game after game, you bet your butt I'd be making a similar post about it. PSSR is brand new, I can still give it the benefit of the doubt because one bad implementation doesn't mean the entire thing is bad. Look at FSR... everybody shits on FSR consistently. At this point we don't even need to see a game to make an educated guess of which issues FSR is going to have, because it's the same thing time after time. There's like a couple of decent FSR implementations you can count on one hand... and thus it's rightly built up a well deserved negative reputation. There's always exceptions to the rule. I didn't just wake up and decide to hate on Unreal Engine.. I think (or at least hope) you know that I appreciate how incredible aspects of it are.

I'm going to assume the studios of games like The Finals, Hellblade, Satisfactory and so on don't have these predicable issues because they have people that rewrote rather large parts of the engine to perform how they need it to perform? I know Embark Studios have some very highly regarded programmers and engineers from the Frostbite days.

PSSR and DLSS might be black boxes, but there's nothing stopping developers from doing their own reconstruction tech for what works best for their game, right? And yet they will do the typical thing and implement one of the existing ones almost guaranteed. I mean why not, it's right there. I'm not saying its easy or even feasible for them to do it better on their own.. and so the same thing happens when it comes to engines. My way of thinking is that as a baseline it shouldn't have these obvious repeatable issues, especially in games like DQ3 which looks like a PS3 gen game. I'm not asking for much here. It's extremely frustrating. If guy A sells a car to guy B and it's a lemon, and so then he slaps on a fresh coat a paint and sells it to me.. it doesn't make it ok for guy A to have sold the car to guy B in such a way in the first place. Obviously guy A isn't going to give a damn because he already made his sale.. but in the case of Unreal Engine and how it's monetized your customer's success is ultimately what decides how successful you are as an engine, and bad implementations reflects back on the engine as well, unfortunately.

I definitely agree that discussing why these things might be happening is far more interesting than just having someone complain that they are over and over again. I definitely appreciate any insight you or others can give.. I'm always trying to understand it better.

 

[Scott_Arm]

...

I'm going to assume the studios of games like The Finals, Hellblade, Satisfactory and so on don't have these predicable issues because they have people that rewrote rather large parts of the engine to perform how they need it to perform? I know Embark Studios have some very highly regarded programmers and engineers from the Frostbite days.

...

But isn't this every engine? You work within its limitations, or you alter the parts of the engine to support what you're trying to do? When Horizon Forbidden West comes out, that includes upgrades to Decima that are tailored to the game they're trying to make.

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.

 

[Remij]

But isn't this every engine? You work within its limitations, or you alter the parts of the engine to support what you're trying to do? When Horizon Forbidden West comes out, that includes upgrades to Decima that are tailored to the game they're trying to make.

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.

Sure, but how many times must I stress that the game I referenced is not ambitious in the slightest. This should not be a game that is taxing the engine so much that we're having issues like this. This is not a UE5 game with the latest tech..

 

[trinibwoy]

Sure, but how many times must I stress that the game I referenced is not ambitious in the slightest. This should not be a game that is taxing the engine so much that we're having issues like this. This is not a UE5 game with the latest tech..

It may not look ambitious on the surface but we don’t know if the developers are misusing the engine in non-obvious ways to the end user. I think there’s enough evidence of consistent issues to support criticism of UE5 but we can’t know for sure that it’s the engine’s fault every time. I think that’s what Andrew is getting at.

 

[Remij]

It may not look ambitious on the surface but we don’t know if the developers are misusing the engine in non-obvious ways to the end user. I think there’s enough evidence of consistent issues to support criticism of UE5 but we can’t know for sure that it’s the engine’s fault every time. I think that’s what Andrew is getting at.

Well really then what CAN consumers complain about? I simply said I'm starting to hate the engine.. whether that's because developers are failing to utilize it properly or whether it's an engine issue itself.. it's a common thread that is happening over and over again.

 

[Scott_Arm]

Well really then what CAN consumers complain about? I simply said I'm starting to hate the engine.. whether that's because developers are failing to utilize it properly or whether it's an engine issue itself.. it's a common thread that is happening over and over again.

Ultimately it's the developer that's selling you the game.

 

[Remij]

Ultimately it's the developer that's selling you the game.

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

 

[DavidGraham]

There's obviously plenty of games at this point that run well without issues on UE5

Not that plenty though, let's be real here. It's the exception to the rule, not the norm. The norm has been that since UE4, any UE4 or UE5 title is subject to suffer from major stuttering issues, Epic bears the responsibility of that reputation, they let UE4 in that sorry state for the entirety of it's lifetime, hell UE4 continues to be bad to this day despite many new titles still using it, Epic never cared to retroactively fix UE4. Just like they never cared to fix the traversal stutters of UE3, with the end result of UE4 getting released with both types of stutters (traversal and shader).

In UE5, the problems continued because Epic delayed dealing with them in a proper manner until 5.3 or so, and thus most games using UE5 still suffer from them because most are using versions that preceded 5.3. Sadly, UE5.3 and later versions still suffer from the old traversal stutters to this day. Thus, attention needs to be given to fix this one or mitigate it to the largest extent possible.

If we want to learn something from that is that Epic should have acted sooner, should have discovered that most of their titles are suffering these stutters and offered a fix or a way for non experienced developers (which is the majority of their customers) to mitigate them. If it wasn't for the efforts of normal people complaining loudly and organizing their complains in the famous "StutterStrugle" campaign, especially the one organized by DigitalFoundry, none of these stutter issues would have been properly identified, and we would be still blaming our drivers or our hardware for these stutters.

Thankfully, Shader compilation stutter appears to be a mostly solved issue in the latest versions of UE5, but traversal stutter is not, more effort is needed from the community to call them out more, and more effort is needed from Epic to fix or mitigate them sooner than later, so as not to repeat the mistakes of the past. Epic should also consider adding shader compilation mitigations and fixes retroactively to UE4 considering many new games are still using it. That would be a great and responsible move from Epic indeed, and would help turn the bad reputation of UE4 around.

It's as you said, we need to move forward from this, scars and all, learn from the past mistakes and move forward to a brighter future.

relying on blueprints too much .. entire actor/component infrastructure .. HLOD is another area of the engine

Are these issues directly responsible for traversal stutter? I am asking because we appear to not have discovered the specific cause of the issue just yet.