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

I feel like, as a consumer, it's often very difficult to get a lot of developers on board to fixing these issues, precisely because we don't have much or any insight into what's causing them.. and that's where ultimately I think I come back to the engine providers. I think it's fair to say that the only people who programmers take seriously is the opinions of other programmers. On game forums or support forums it's extremely annoying when half the battle is arguing with people who claim they don't have any issue. Specifically coming into threads to deny that your issue exists among others who, while often having good intentions.. post stupid placebo fixes. 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.

In my eyes, there's a systemic issue in the industry where we've gone on accepting this stuff for far too long, and not enough of the right people are calling it out to where things systemically change. In my mind that's where the engine providers come in. I know they can only do so much.. but when there's as prevalent of an issue as this, is it not prudent to bring more awareness of how to do these things properly to the studios who use the engine? I thought the same thing about the shader compilation thing. How on earth was Epic not reaching out to more developers sooner and being like "hey you should do this and this to pre-compile and prevent these issues from happening."

I ultimately don't know what the developer/engine provider relationship is like.. but I feel like if I was the engine provider, I'd be reaching out far and wide and ensuring people were in the best position to see their games succeed on my engine.
 
South of Midnight runs on UE4, I was surprised by that. I think it's among the best in terms of graphics and they targeted 60 FPS with it on Series X, so presumably in high resolution.

It will be a nice slap in the face to low-res console ports of UE5 games.
I highly doubt there's any correlation between UE4 and high resolution and frame rate. Jedi Survivor was also UE4, for example.

nay, it's less engine and more "here are the targets we want to hit, and we are prepared to make cuts to hit them"
 
Satisfactory is also a game that has very high frame rate and uses UE. When it came out in early access they used UE4 but migrated to UE5 (they don't use nanite but have an option to use lumen which is off by default and the quality is scaled back a lot since early access) After migrating they had some minor performance problems but those were fixed at the end. So yeah you can it does not matter if you use UE4 or 5 it is all about the features you use. If you use lumen or volumetrics your frame rate will be hit hard. This is something a lot of modern UE games opt in for because it's the easiest way to get a consistent image and good lighting.
Btw: Satisfactory also let you build insanely large factories and has a large open world with very high speed travel options. So you would expect lost of stutter but haven't experience much which is pretty good of them. It does have a lot LOD pop in though, especially when traveling very high in the air as the LOD's aren't tweaked for that view angle. I would love to see DF cover that game.
 
Consumers are the ultimate enabler of the continuance of poorly made games. I don’t know what the refund policy is for consoles, but on PC there is no excuse given Steam’s extremely generous policy. Money is the only feedback that matters to companies.
 
Consumers are the ultimate enabler of the continuance of poorly made games. I don’t know what the refund policy is for consoles, but on PC there is no excuse given Steam’s extremely generous policy. Money is the only feedback that matters to companies.

I played this game for 1000 hours and it’s unacceptable!
 
Satisfactory is also a game that has very high frame rate and uses UE. When it came out in early access they used UE4 but migrated to UE5 (they don't use nanite but have an option to use lumen which is off by default and the quality is scaled back a lot since early access)

They do use nanite for cliffs. They don't use them for for the impressive factory bits, which is all just conventional LOD.
 
This makes them even more motivated to create beauty due to UE4's more limited toolset. And apparently they're doing well, South of Midnight looks pretty good. For example, seeing those detailed opponents/characters, I would simply point out that it uses Nanite, but no, it doesn't. And that's why it will probably be in high resolution with 60 FPS on console. Moreover, based on the presentation I saw, I am convinced that 10 out of 10 random gamers would easily believe that this game is using UE5.

The essence of what I am saying is that it is welcome to see high image quality on the console with 60FPS together with great graphics.
 
They do use nanite for cliffs. They don't use them for for the impressive factory bits, which is all just conventional LOD.
Oh you are right. Pretty cool, didn't catch that. I did a search and here they show it here:
Pretty cool that they only use nanite for some selected assets. Means they really did some investigation of where they would be getting a win and where not. This is something a good dev should do.
 
I feel like, as a consumer, it's often very difficult to get a lot of developers on board to fixing these issues, precisely because we don't have much or any insight into what's causing them.. and that's where ultimately I think I come back to the engine providers. I think it's fair to say that the only people who programmers take seriously is the opinions of other programmers. On game forums or support forums it's extremely annoying when half the battle is arguing with people who claim they don't have any issue. Specifically coming into threads to deny that your issue exists among others who, while often having good intentions.. post stupid placebo fixes. 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.

The number of actors* is not something that should be visible to user/gamers. A better support ticket would be something like "when there are more than X NPCs the frame rate goes down". Even better if you have a video and frame graphs.

*The technical term usually used for NPC etc.
 
The number of actors* is not something that should be visible to user/gamers. A better support ticket would be something like "when there are more than X NPCs the frame rate goes down". Even better if you have a video and frame graphs.

*The technical term usually used for NPC etc.
Obviously the more objects you're loading and rendering the more stress will be put on the system. My point is you're not going to be having a dialogue with programmers specifically, and if you try to be that specific with the reason for an issue.. it feels like it will just be ignored. They're going to insist you install the latest drivers... close any programs which may be interfering with the game and so on..

Traversal stuttering is more prevalent on PC than it is on console. Is it fundamental issues with the PC architecture? Sure.. but why can't the default engine behavior be better adapted to deal with it on PC then? The main presumption is that devs develop games around console hardware... and since the game "works well enough" on PC from that point, they don't optimize further. Bigger developers with large teams will put in work a lot of the time.. but you get all these other cases where they wont bother. I get that it's more of a dev issue first and foremost.. but when something becomes so prevalent.. it needs to be looked into by the engine developer, and from there make bigger pushes for more education, better tools, better APIs, and quite frankly better QA from publishers.

I wish there was a very visible gaming tech focused website where programmers and engineers could submit public tech reviews and critiques of game releases and submit suggestions to improve which would directly be accessible. I don't think anything could evoke change and improvement much like having your peers grade your work and for it to be publicly visible by the gamers who play them.
 
In my eyes, there's a systemic issue in the industry where we've gone on accepting this stuff for far too long,
I think plenty agree with you.
and not enough of the right people are calling it out to where things systemically change. In my mind that's where the engine providers come in.
But there are best practices and guidance. Devs are choosing to ignore it for whatever reasons. Likely cost/benefit analysis. Even not looking at the guidance is a cost/benefit consideration as you have other things you need to be working on right now.
I ultimately don't know what the developer/engine provider relationship is like.. but I feel like if I was the engine provider, I'd be reaching out far and wide and ensuring people were in the best position to see their games succeed on my engine.
Epic can't insult devs and tell them they suck. ;) You can't make them do better. They can only provide tools and best-practices. There might be something Epic can do to present a FAQ on optimisations and guidance on which features have which costs, and how to use the profiling, and to improve profiling tools. I dare say plenty of this already exists though and devs just aren't digging deep enough. So Epic can make it easier, but they can't make anyone use the tool to its best.

That becomes a market and economics problem. If consumers demand better quality, developers will supply. If consumers are happy with good enough, they won't. This is how the free market works and ensures everyone gets what they want based on what they are willing to trade for.

I wish there was a very visible gaming tech focused website where programmers and engineers could submit public tech reviews and critiques of game releases and submit suggestions to improve which would directly be accessible. I don't think anything could evoke change and improvement much like having your peers grade your work and for it to be publicly visible by the gamers who play them.
They do. They just aren't particularly public facing because the consumer has no idea what's being said. Every talk at GDC etc. is all about furthering the general understanding of the people who make these games. Although suggestions to improve are few and far between because everyone involved with making these games understands the complexities and wouldn't presume to tell other people what they are doing wrong, knowing full well the reasons aren't just 'they missed it'.
 
That becomes a market and economics problem. If consumers demand better quality, developers will supply. If consumers are happy with good enough, they won't. This is how the free market works and ensures everyone gets what they want based on what they are willing to trade for.

Ideally yes. I can’t think of too many games that sold poorly due to technical issues though. Assassins creed unity and Cyberpunk come to mind but the average gamer doesn’t seem to care that much about technical flaws (aside from gameplay bugs).
 
  • Like
Reactions: JPT
Obviously the more objects you're loading and rendering the more stress will be put on the system. My point is you're not going to be having a dialogue with programmers specifically, and if you try to be that specific with the reason for an issue.. it feels like it will just be ignored. They're going to insist you install the latest drivers... close any programs which may be interfering with the game and so on..

You really can't know the reason* unless you are one of the devs. You can only look at the symptoms like the DF team does. However, those analyses are really useful for devs.

Unless you do one of those crazy decompiles.
 
They do use nanite for cliffs. They don't use them for for the impressive factory bits, which is all just conventional LOD.
I believe it may also be used on some of the conveyor belt items as well, but I don't remember 100% where that ended up. The machines themselves don't use it mainly because of how they are animated if I recall. [Edit] Just quickly checked this and it does seem to be mostly scenery that uses Nanite in 1.0.

Traversal stuttering is more prevalent on PC than it is on console.
I don't know that I would say that is routinely true. It's probably true that folks targeting consoles tend to need to polish things somewhat more (for cert and otherwise), but most of the issues around the broad box that people call "traversal stutter" aren't really very platform specific, unlike shader compilation.

Regarding developer education... obviously more can always be done. On the other hand I would not over-estimate how much interaction there is between engine providers and users (game devs). Certainly in some of the AAA cases there's sometimes more direct conversations but I think people would perhaps be surprised how many games - even high profile ones - basically take engine releases and never talk to Epic/Unity/whoever at all. For my part most games I see coming out using Unreal I learn about at the same time as the public does, if not later 😆 Folks can ask specific questions on the various support channels, but engine vendors getting to see or provide feedback on builds of games in advance is a very rare case.

And in terms of consumers providing feedback - you don't need to debug what is going on. Just give the symptoms. Speculating on root causes is a fun exercise for us at B3D but it's certainly not necessary or even helpful in bug reports/feedback to game devs. Good repro cases are what matters.

In other UE game news though, played a bit of Empire of Ants (PC) recently and watched the kids play some Lego Horizon Adventures (PS5) today and both run great and look great. Haven't noticed any stutters in either so far.
 
Last edited:
I believe it may also be used on some of the conveyor belt items as well, but I don't remember 100% where that ended up. The machines themselves don't use it mainly because of how they are animated if I recall. [Edit] Just quickly checked this and it does seem to be mostly scenery that uses Nanite in 1.0.


I don't know that I would say that is routinely true. It's probably true that folks targeting consoles tend to need to polish things somewhat more (for cert and otherwise), but most of the issues around the broad box that people call "traversal stutter" aren't really very platform specific, unlike shader compilation.

Regarding developer education... obviously more can always be done. On the other hand I would not over-estimate how much interaction there is between engine providers and users (game devs). Certainly in some of the AAA cases there's sometimes more direct conversations but I think people would perhaps be surprised how many games - even high profile ones - basically take engine releases and never talk to Epic/Unity/whoever at all. For my part most games I see coming out using Unreal I learn about at the same time as the public does, if not later 😆 Folks can ask specific questions on the various support channels, but engine vendors getting to see or provide feedback on builds of games in advance is a very rare case.

And in terms of consumers providing feedback - you don't need to debug what is going on. Just give the symptoms. Speculating on root causes is a fun exercise for us at B3D but it's certainly not necessary or even helpful in bug reports/feedback to game devs. Good repro cases are what matters.

In other UE game news though, played a bit of Empire of Ants (PC) recently and watched the kids play some Lego Horizon Adventures (PS5) today and both run great and look great. Haven't noticed any stutters in either so far.
Thanks for clarifying some things for me. I kind of suspected my idea of the level of interaction between the engine providers and the devs themselves was far off. Do you think the support channels are adequate as they are?

Good to hear about both Empire of Ants and LEGO Horizon! Both games look really great graphically.

I actually came back to this post because I was on Twitter and came across Tom Looman's post about UE5.5 changes and improvements, and he made a blog detailing some of them, and instantly thought about what you said regarding Actors here.

Instanced Actors​

“Instanced Actors is a new feature designed to reduce the overhead of having too many actors in your game world. It does so by replacing actors with Mass entities and converts on-the-fly between actors and entities (called hydration/dehydration), providing a lot more performance out of densely populated open world environments. The conversion is controlled by the Mass LOD system using distance to viewer logic, and physics traces can be used to trigger hydration as well.”

“This works best when you have many actors using the same mesh, for example rocks and trees in large environments.”


Instanced Actors feature is potentially huge for many as high Actor counts in your level has all sorts of bad side effects (including the infamous traversal stutters during level streaming – I *hope* this can help reduce those but have yet to try this in production).

In my understanding, this will (eventually) replace the LightWeightActor which never got much attention since it was introduced in 5.0.


Hopefully these kinds of changes can help improve things.. and Tom is a hero for educating devs about the latest UE features. Clearly the engine teams are working on things and trying to address it! :)
 
Back
Top