CD Projekt RED + Creative Assembly vs Unreal Engine
HTML-код
- Опубликовано: 17 окт 2024
- ► Watch the FULL Video Here: • DF Direct Weekly #172:...
► Support us on Patreon! bit.ly/3jEGjvx
► Digital Foundry RUclips: / digitalfoundry
► Digital Foundry Merch: store.digitalf...
► Digital Foundry at Eurogamer: eurogamer.net/...
► Follow on Twitter: / digitalfoundry
As a UE5 dev, I REALLY hope we get some of these changes to base UE5. It's a problem practically every game suffers from and many developers don't have the resources to properly fix this on their own. We can already see that in CDPR's case it's a huge engineering effort.
I was at the CDPR talk and they are ignoring the new UE5 streaming (world partition) and rolled their own, only supporting static parts of the environment (gameplay still uses the vanilla UE5 code) which still helps an enormous amount when most of your environment is a city. The Creative Assembly seems to do something similar, their approach *seems* simpler (although they did a LOT of stuff overall since it was still UE4 without nanite etc.) but still very effective and overcoming the UE5 shortcomings.
Hey its TOM!
So is CDPR modifying parts of the engine?
@@aquaneon8012 to avoid issues upgrading to new versions they try to stay away from modifying the existing systems like World Partition (grid based level streaming) and instead make their own systems. I bet this has required some smaller engine mods elsewhere, but the larger systems remain the same.
I was at CDPR presentation too, but how did you miss the part where they said that some of their improvements are already implemented by Unreal team?
What I got from that presentation was that different companies want assets to be loaded/unloaded differently. CDPR is fine with pop-in, but doesn't want framedrops, Epic is fine with framedrops, but doesn't want pop-in.
@@SmellsLikeRacing Yes I'm aware that some of their changed made it into the engine, but that doesn't include any of the streaming solutions. The bottom line is that traversal stutter isn't solved, and that's what I'm hoping we'll still see major changes for
This is the result of engineering an engine for everyone. Unreal needs to make it easier to disable modules of the engine so larger products can reduce their overhead
This is true! Also, the core gameplay architecture has a strong smell of match--based multiplayer shooter.
Disabling modules would be a great thing for this engine. If you wanted to use UE5 for its many improvements to world creation and general scripting over UE4 but you don't want Nanite or Lumen it's not as easy as you'd hope to get rid of them. There's so many pieces of third party documentation online on how to do it and most of it really isn't truly disabling all of it, it takes quite a bit more than you think to truly excise those features from a project.
Unreal has a lot of shitty code written over 10 years ago with bad programming practices. This is the result of trying to maintain same codebase across engine iterations over 2 decades.
A modern engine that focuses around ECS, Scene Graph, multithreading, batched updates and async streaming would get rid of all Unreals problems while still allowing for development of all sorts of games/3d projects
i disagree. 90-95% of the game optimization what most of the programmes ignore (materials shader,... so on)
@@Lamatetatonka well when unreal claim to fame is it handles all that stuff for you, I think criticism should be shared
The old Source engine powers Titanfall 2 and it plays much better than any UE fps game I have played.
its also far simpler and doesn't have raytracing, nanite or the other optional bells and whistles that makes unreal more expensive
It's not source engine, they modified it🤬
They modified it heavily ;-)
Although source is a great/efficient engine, it's performance drops to a crawl if you try to use it for any sort of open-world experience. It was designed with HL2 in mind, in that it loads small, individual levels and lacks any sort of open world streaming capabilities. All you need to do is load up an old HL2 mod that pushes the level size too large, and you'll see massive performance dips below 60FPS even on a 7800x3d.
@@rustyshackleford4117 that's the cruel truth some Source praisers can't accept.
This is often how it is in any kind of software engineering. Public, general purpose functionalities & libraries are great, and even I use them all the time. But when you use those public functionalities too much without considering the potential benefits of designing your own specialized system, you can easily end up with problems, usually in accuracy and/or performance.
I think this is especially true for modern software development, where package managers and build tools make integrating dependencies a breeze (looking at the average webdev project that has 1000+ dependencies and nobody really knows any of them). It has taken away the deliberate time to consider if and how you integrate other peoples code and how you intend to use it, looking at the implementation to understand the overarching functionality and adjusting for your use case.
TBH main problem with Unreal's design is that it tries to automatize everything instead of giving devs good API's to work with on top of an efficient base.
For example, you have really advanced character movement system but it is a performance hog that butchers FPS if more than 20 character is present. You have automated movement replication on actors but it will eat network bandwidth inefficiently. Most gameplay code resides on objects themselves which makes programming straightforward, but results in single-threaded, cache unfriendly gameplay design that doesn't scale well with modern processors. We have Chaos physics that has a lot of features but with far worse performance vs traditional physics engines. Automated replication system that requires constant object state checks that will continuously eat performance even if nothing changes. And these are just to name a few
All of these problems can be fixed while still keeping the engine as general-purpose as it is. Matter of fact they are actively working on fixing these problems one by one (mover system, scene graph, iris replication and push-based replication etc)
@@NavhkrinHonestly those things sound quite basic. And UE5 has been in the oven for years now. How much more time do you need? Meanwhile other devs could have made their own engine satisfying their custom needs with better performance.
@@aladdin8623 Main problem is making sure all these changes play nicely with already existing engine code. UE5 is just UE4 with Lumen + Nanite and typical software updates. And this approach is what essentially makes it hard for Epic devs to fix problems. They need to smoothly integrate these changes over course of many updates while making sure everything transitions smoothly. What are few weeks' worth of work on a fresh project turns into an update that needs to be carefully administered over course of a year.
@@Navhkrin Yes, the needed time for merging patches increases, the more dependencies in several versions you have for which you have to adapt the code.
What also adds to the patching time of a general purpose graphics engine are so many bloated features, which have to be taken care of and have to be dragged along. This gets very complex very fast while many of them aren't even going to be used every time.
A custom graphics engine is more flexible and doesn't necessarily need to uphold compatibilities to its previous versions.
I love how you guys put a shine on Alien Isolation at the end there. I will sing that game's praises till the end of days. Alien Isolation 2 needs to happen. I think a well done sequel will be received very enthusiastically since the OG's reputation has only grown over the years.
I work on a small indie game (Soulstone Survivors) and we use Unity. Even for our game we have to do all sorts of tricks to try to get the game to run fast, like using the low-level features of C# (pointers, manual memory management), manually instance render things, etc. I think as an engine supplier Unity & Epic can't be expected to deliver top performance on all cases; I think it is much more productive if they give you a very solid foundation -- specially for content creation (i.e.: scene editing, animation, etc.), a flexible editor so that we can create bespoke tools and a flexible engine core, with all the facilities to allow us developers to fine-tune the render and logic for our games. A flexible general purpose engine is better than a great niche engine. If your game is ambitious, you hire people with engine/graphics experience to make your game go brrr. All we need is a bridge between "write our own engine" and "get the perfect engine off the shelf" as neither option is realistic.
Unity user, opinion discarded. xDDD
It's the promise vs the reality.
You guys say UE is improving, but I've been using UE since 5.0, and roughly since 5.3 the performance got worst, and 5.4 performance is even lower.
But the Matrix Awakens City Sample did get better performance somewhere between 5.0 and 5.4... Alex tested it.
@@cube2fox 5.4 introduced multithreaded renderer. However, after 5.2 the editor performance went down, twice.
Show us your profiled example then. Otherwise you just seem to be here to badmouth the tech.
Yha unreal engine 5 runs much slower than 4 all due to you being forced to use new render pipeline.
For anyone interested or curious, the Unreal Engine youtube channel posted Creative Assembly's talk regarding their "chocolate" renderer and how they dealt with stutter issues ruclips.net/video/WGv_BjxvJ8M/видео.html
Thanks!
Thanks, the CDRed Talk is not published, right?
@@patho97 ruclips.net/video/JaCf2Qmvy18/видео.html - Published today
@@patho97 ruclips.net/video/JaCf2Qmvy18/видео.html
@@patho97 A little delayed but does look like cd projekt red's video was posted ruclips.net/video/JaCf2Qmvy18/видео.html
I'm from Warsaw. My mate was working at cdpr when they decided to move to UE. All I can say is that the lead programmer was very, very unhappy about it.
But yeah, it was already decided back then they will rewrite most of UE.
Part of me thinks then that the decision to switch was very high up (Shareholders), if the top developer was against it. Shareholders probably like the idea of cutting down training times on engine introductions to new staff, whilst also eliminating the need to make new iterations of the engine since Epic would be handeling all that.
Honestly when I look at Cyberpunk and the amazing tech it introduced, I feel like I'm still waiting for any other AAA company to come close to it with Unreal.
The lipsyncing tech based on the language you have changing characters lip motions, the amazing and probably most immersive dialogue system I've ever seen in the game, the lack of loading screens... I mean there is something there that's just magic.
@@HoveBroker Yes, didn't want to say it, but after issues with cyberpunk launch they wanted to change the branding, but they are rewriting it so that it is similar to their engine.
No doubt, lighting in Witcher 3 is still superior to every game that released recently. Its a shame how CDPR degraded in a last years pandering to DEI and shareholders. Now Im not going to preorder, buy for full price or even buy at all(Witcher 1 remake) their games anymore.
"You were the chosen one! It was said that you would destroy the EA/Ubisoft/Activision, not join them! Bring balance to the Gaming, not leave it in darkness!."
RIP CDPR😢
@@anthonynehoda2064 They were forced to do it i think. And by that I mean the fiasco with that q&a team they hired for cyberpunk costed them a lot of money.
@@HoveBroker Incredible tech yeah that it was so broken in release that you needed another 2.5 years to play it while the game has been in development for so long. Also the promised features are still missing.
What's the point of switching away from in-house tech if you have to heavily modify this engine in order for it to actually perform decently? Unreal and its "jack of all trades, master of none" approach has been fucking up the games industry since UE3.
What I understood from the CDPR side is that they prefer to focus their strengths on developing their own tools for a steadily modernized engine like unreal rather than developing their tools AND an entire new engine for every time they want to make a new game
Reducing training time when you've got too much employee turnover.
the death of in house engines is pretty much coming up to the people that created these tools have either moved on or are retired. harder to teach new devs on an engine that they may only use once in their career rather than UE and other widespread engines. also lack of documentation, contractors, etc are all problems with in-house.
Because you can hire way more people from all over the world that knows UE, in stead of teaching them to use their internal engine. Less costs, more Labour, less waste of time. Especially for temporary contracts
@@marcinkrzeczunowicz8571- CDPR openly stated recently they will use Unreal engine from now on. That shows how expensive it was to develop RED engine and get it to the point it was in Cyberpunk 2077.
Proprietary Engine does not guarantee better optimization. Dragon's Dogma 2 made on RE engine has shader compilation and traversal stutter as well.
Yeah because thats the first open world on that engine and was done by a really small team and pretty low budget compare to other capcom titles but im sure it would be other story on monster hunter wilds
@@allansolano5587 If you have a small team you should stick to an existing engine instead of making your own.
But the engine they used in cyberpunk does not stutter and is a great open world engine.
But a bespoke engine does guarantee the *opportunity* to optimize more than you could with a general purpose engine.
It’s why they are making a successor to the RE Engine to handle open world.
Long story short: if you want a game to be complex but run fast, you can't rely on a stock engine (despite the engine) and it sounds very radical for small teams who want to grow into any complex ideas.
Building up your own render or own entities management system is very hard. And eventually the most common issues should be fixed by engine providers. But it will not completely eliminate performance issues.
Not entirely - you can't rely on monolithic general purposes engines like Unreal. A lot of other engines are more focused on entirely game development (CryEngine) or are designed to be modular (Unity).
Unreal needs to be broken up into components, right now it is far too bloated and unspecific.
Nope, the correct message should be: know your engine limits and build the game around those limits.
Not everyone has the same needs, so you should pick the engine that fills most of your needs because then you can put more time into developing the game, not the engine.
I used UE outside the game industry and for a limited scope, but one big problem I think it has, is the actors instancing, it blocks the entire pipeline and to my knowledge, they never fixed it. Even in the matrix demo, when you hit something and they swap the instance of the cars, it always stutter. I hope they will fix it in the reworking of the rendering pipeline, other than that and the chaos physics engine, UE is pretty great
@@MaxIronsThird I don't think Nanite has anything to do with it
You gotta have faith if you're developing in unreal right now. Its impossible to not notice the stutters when assets are loading into even AAA games, like callisto protocol, but contrary to the damning past evidence, theres also evidence of improvement with each iteration. Consider how the matrix demo has a 50% fps boost between 5.0 and 5.4 on the same pc.
Matrix demo is just a tech demo. It doesn't need to be super-optimized because it's a demo and also a benchmark for future releases.
Now it's used even in marketing: "5.4 runs City Sample 50% faster than 5.0".
@@SmellsLikeRacing they said it them self in an interview explaining why that was happening and it's a known issue that UE has. The 50% improvement in 5.4, again, something they said, not sure what your point is.
What's the link to the CD Projekt Red presentation?
People who post the link probably get shadow banned by RUclips.
Were you able to find it?
@@SneakyKittyGameDev no not yet, was hoping that one of the DF guys would post the link that they had.
@@muz1903 It is available on presenters Linkedln
ruclips.net/video/JaCf2Qmvy18/видео.html
for Dachsjaeger
Quick guide to read Polish names:
Jarosław -> Yaroswav (our J is almost always read like Y in english, same with Ł as W and W as V, since we don't have V nor X in our Alphabet then there are some differences)
Tomasz (you did a splendid job there)
Rudzki (same, awsome job)
Dżaroslą jest najśmieszniejsze tho
Who cares lmfao
So im not crazy, Unreal stutter is a thing!
Um, it’s not exactly a secret. It’s one of the biggest game tech conversations about Unreal Engine for years now.
its a stutter for devs that don't understand shader linking or async level streaming or other factors that can cause stutter. For devs who know what they are doing, its fine
Hey DF, when talking about external documents like talks from conventions, articles or papers, it would be prudent to include links to those documents in the description.
Also re: Responsibility - this is both on Epic (or Unity) to make their stuff reasonably straight forward to use and on the game devs. While engine devs provide tools for many use cases, it's the game devs job to make sure they're using the tools "correctly" as in "fitting their use case". Perf problems are often cases where the usage does not fit the use case and no engine can really prevent that.
i wonder what unreal monopoly means for games.. i like the redengine
I miss it already. It still looks better than any game made with UE5
Because you can hire way more people from all over the world that knows UE, in stead of teaching them to use their internal engine. Less costs, more Labour, less waste of time. Especially for temporary contracts
@@poltergeist7621 On top of that, RedEngine was expensive and terrible to maintain. - main reason for CyberPunk issues, removed features, lack of multiplayer etc. They spent 3 years ironing it out. Some developers said RE code is a spaghetti mess and touching some features meant big issues with other features and so on. Other developer said making cyberpunk was like placing rails ahead of a moving train. In the end it's stitched together, but they don't want to go through this anymore and want something that works. And it doesn't mean everything Witcher and so on will look like other games on UE, as CDPR coders from RedEngine joined forces with EPIC Games so CDPR can create games with their identity on UE, buildup on both sides skills and experience.
@@poltergeist7621 👍 The only reason for CD, as they have had a really thing going but abandoned it.
i'm all for major players moving to Unreal but it's still has a long way to go in terms of optimization
@@Jereb343u must be a blind ape to remotely think red engine is even 1% of that of unreal.Just play the game stray with the ultimate cat mod n u will see how insane it looks on ue4 n how much better it captured the world of cyberpunk than cdpr n also nobody wants to die is the best looking cyberpunk game ever made no way in this world do u think red engine looks that good maybe go play some games then talk u bot
good talk, any chance to get the CD Projekt RED presentetion link?
Because you can hire way more people from all over the world that knows UE, in stead of teaching them to use their internal engine. Less costs, more Labour, less waste of time. Especially for temporary contracts
At least that's the theory. The problem is when you waste a bunch of time trying to diagnose why UE is not doing the thing you want it to do.
@@SMorales851 You would have the same problem with a proprietary engine. Probably more.
It's honestly great for us devs and artists. You can quit whenever you want without having to worry your knowledge of that proprietary engine won't be useless elsewhere. I'm not saying that if you learn an engine you can't work on another one, many elements are the same, but you won't be as fast as someone who's been using it daily for years.
@@OverJumpRallyunfortunately that also begins the rat race. If skills are too transferable, what happens is companies start to delegate all training to employees, forcing us to pay and maintain our own certification since “everybody is using the same thing”. It also creates a situation like in accounting in which concentration of market share make those firms feel comfortable underpay and overwork their staffs, high turnover at entry level is a desirable outcome rather than something to avoid. Not only that, it’s also why firms feel comfortable asking for 3 years of experience for entry level position since the technical skills are “transferable”.
Was going to write the same thing. What tools devs are comfortable with matters a lot, and you can't stare blindly at the technical or economic aspects of choosing a game engine. For business purposes UE is very attractive because of the multi platform capability as well...
I think the commercial underperformance of CryEngine has caused it to be underutilized unfortunately, but I feel like a lot of developers that are using Unreal would be better off with something like CryEngine. Especially larger games. Especially when thinking about games like Halo. There's the news of 343 switching to Unreal for future projects, but when you look at the feature sets and what each engine is geared towards, I imagine CryEngine fits the concept of Halo a lot better than Unreal.
While that might be true, one of the core reasons 343 is switching to Unreal is the fact that quite a lot of other Xbox studios are/will be using it, so there is this internal knowledge/experience that can be shared to make their work easier.
Cloud Imperium Games trade marked, branded and is doing showcases for their fork of CryEngine, the "StarEngine". I think as soon as they release SQ42 and Star Citizen 1.0 they will license this thing (why else bother to trade mark and brand it? If they don't intend to sell it). If they do that is should be a interesting competitor to Unreal. It seems to maintain the efficiency of CryEngine but blowing up the scale. For large or complex open worlds if Epic don't get their shit together, it will be a better option. That and for online game, other games are already starting their own version of server meshing with a far smaller budget and development time (probably looking at the high level presentation of CIG about it they could implement the same concepts avoiding the roadblock that CIG found along the way), so now I don't think it make sense for them to let it be a proprietary. That will be game changing for online games. Specially MMO's.
The Unreal Engine is versatile and general purpose.
CDPR & CA have done deep dives and EPIC need to take note.
Collaboration is key and forcing gamers to buy the latest and greatest is no justification for poor optimization.
Epic didn't fix Unreal engine 4 and won't fix 5, the engine is solid but the prebuilt included tools are not good for certain things. Think of it like this.... you can build the Venus De Milo with Lego bricks but it will never be smooth, to get something smooth and polished from the engine it needs to be sculpted by hand to a certain extent and even after you put in all that work...... the arm might fall off if something unexpected hits it!
I thought unreals goal was to make an engine that can handle big open worlds?
Epic provides the engine, they should be the ones making sure it works.
Developer job using an off shelf engine should be focused on making said game, not fixing issues.
Knowing only how to make a game and knowing nothing about the engine is like building a house and knowing nothing about the foundation. Developer should know what they're doing and at least have a few people around who can tune and tweak the engine. Anything less is irresponsible.
Well, the fact is that not every unreal engine game has stuttering issues.
And some games not running on unreal do have the same issues (elden ring the most infamous).
It's not a simple engine issue, it's a relation between engine, API and developing team.
@@mondodimotori The OP isn't wrong, but you're exactly right.
it does work. But developers need to learn how to optimize first. Turning on all the bells and whistles of unreal like raytraced lumen, nanite etc and expecting amazing performance is not going to play out very well.
It can also depend on the game with how important response time has to be as well. So they can increase the frames for less stutter, but they are false frames generated and not reflected 100% for response time which would be a problem for fps trying to hit small targets. But even for an fps trying to hit a large enough target increasing frame generation should fix that issue.
Of course thats still an issue at the engine level that needs to be addressed. Since bad performance means that the developer can not have proper basic requirements when selling their game to the average consumer and will require higher requirements on the PC itself.
But at least with frame generation it will help with stutter.
Epic is not helping the gaming community if they are setting up game developers up to fail with such a huge technical issue for them to deal with. The whole point of the unreal engine is allow developers to be more independent to make games. So basically to get more indy game in the industry when outsourcing the unreal engine, its going to look like an 'indy' (lack of density and lack of content) game when using unreal engine, because the unreal engine has technical issues. Almost seems intentional and do not want more BG3 game developers setting the bar higher for game devs making AAA games on a indy developer budget.
The main solution for allocation and de-allocation stutter as well as for shader compilation stutter is to perform those asynchronously, and only mark the assets that are depending on those as available for rendering in the current frame if all dependencies are completed.
You simply can’t allocate and deallocate large amounts of resources in Windows on the fly “just-in-time”.
This means you’ll need to have a time buffer/allowance between when you begin to load the asset and when you expect to be able to use it. For example, as you move through the world, there’s the “start to load this top LOD” radius that is going to be further out than the “start to render with the top LOD” radius
It’s quite simple, if your game doesn’t run well, has bad frame pacing and other performance issues as well as needing a 4080 and upwards to somehow run acceptably without looking like trash, I won’t buy your game.🤷🏻♂️
And others should do so as well. As long as people buy these games companies will put them out in this status.
@lock2002ful so what GPU do you run
Pikmin 4 was made in Unreal Engine and runs on Switch, so this shouldnt be an issue
@@Chunnibyoubaka
3080 12 GB, not that it should matter.
I'd like to see Alex revisit and make a new video on the PC version of Days Gone. To me it's the best UE4 game I've seen, in terms of visual quality, performance, and general smoothness of the experience, and it's open world. Without knowing, I'd never assume that game was on UE4. It seems almost on par with RDR2 in most aspects, which is hard to imagine UE4 doing. I think it can be used as a showcase of how large talented teams can utilize UE in ways that smaller devs can't. And I assume CDPR will be able to do similar things with UE5 as what was done with Days Gone on UE4, where the engine might not even be recognizable.
But i feel the type of game that days gone is like the world is not really that open and it doesnt have that big amount of npcs or systems in place it does run amazing but its a simple game compare to games like cyberpunk 2077 or even the witcher 3
@@allansolano5587 While it is a different type of open world compared to W3 and CP2077, it can still be compared to Jedi Survivor with all of it's infamous issues. But Days Gone does have the hoard system that has perhaps hundreds of zombies all on screen at once.
@@mrmunkee oh yeah thats true it all depends on the devs of course, sadly anything from EA its gonna be half baked in any engine hahaha
@@allansolano5587feels the opposite to me. Hordes are quite more dynamic than bunch of npcs walking in lines
I would say that the simple fact that Epic demands a bracketed payment system based on the scale of game and the profits it eventually ends up making should also mean that they cater to developers and/or tailor make the engine to suit all possible outcomes. If I'm a big publisher and I'm expected to give royalties from everything I make up to a certain percentage, simply because I'm making a LOT more than anyone else using this same engine, then I would expect this engine to function well for my needs without much in the way of modifying it. This is supposed to be a way out from having to spend the time developing your own "in house" engine. It's supposed to be industry standard.
CD Projekt should have stuck with Red Engine. To this day, Cyberpunk looks amazing and performance has come a long way with PathTracing and RayTracing intact.
Yeah 4 years after release XD
They said themselves that updating the engine is massive work and you need to work on it constantly. If they stayed with Red Engine we would get 1 game every 5 yrs like it used to be. It is a huge valuation company but still quite small compared to industry titans.
Unreal engine makes hiring super easy though since its a standardized engine which most new devs would already know. Training time is significantly cut because of that.
@@JS-bh3pz I'd hope what they learned with Cyberpunk could be applied rather quickly to newer games, the wheel had been invented already. But I dont pretend to know how it all works so maybe they did make the right decision, time will tell. I love the UE5 engine game Banishers, it is jaw dropping at times.
But the rendering is quite annoying when shit just pop up infront of you and a rendering distance which is so short.
I think the fact that unreal engine takes a bigger cut in the long term for the games developed on it, it really is up to the Epic team to make unreal better. Yes it's the devs decision to use it, but, unreal is also promising a looooot of things that fall apart once you get to scale.
Unreal needs to make a FRAMEWORK instead of an engine for those who want the speed.
A game engine is already a framework for developing games.
I have never heard Alex say “uh” that much before 😂
Unless a studio doesn’t know what it’s doing, having your own bespoke engine is always better. Some of the greatest games have this in common.
As for SEGA: Alien Isolation 2. How hard can it be?! Instead they waste time on shitty RTS games and chasing MP game modes. AI ran well, looked good, still looks good. The only visual criticism is the lack of a proper AA method, but there is a great TAA mod available that injects TAA via modified shaders. The game has never looked better.
The engine devs have been pretty transparent that Lumen, Nanite etc have performance costs and they are completely optional, and not required to make a beautiful looking game.
Too general what was discussed. Its trivial in any engine to bring it to its breaking point, eating up frametime or generating stutter with really unoptimized content. There is only so much a game engine can do here. Mostly being as transparent and understandable as possible what causes those slowdowns.
Idk if this was covered but a lot of the points brought up at UEFest, either had solutions or solutions being worked on, engine development for Unreal is a two way street with the bigger studios in this industry and it was even mentioned a lot of CDPR's optimizations were shipped with the release of 5.4.x
5.4 made the performance worse
@@raskolnikov6443 Elaborate, like what game are you working on, scale, platform, features, bp or c++, WHAT part of the performance got worse
I work with unreal (I use it, don’t make it) and I very much enjoy these discussions.
I would really like some interviews from unreal developers on the subjects.
I'm sure the Developers at CDPR are thrilled that upper management forced them to throw their highly modifiable proprietary engine in the garbage for the sake of using this notoriously strict engine, only to have to completely rebuild and work around parts of that engine anyway.
On one hand i like different engines like the red engine, cry engine, creation engine, and more. It gives games a unique feel which is intrinsic to the design ethos and feel of the games. On the other hand if switching to unreal meant a new elder scrolls and fallout in a few years im down. I wouldn't want them to feel less bethesda like though. I worry the next witcher will have this issue as well. I guess time will tell.
People deny this all the time and maybe I’m just imagining things but UE games do have a certain feel/ look to them IMO. Just like cry engine has a certain feeling/ look. I wouldn’t want all these games to use the same engine.
Is there a link for the Hyenas presentation at Unreal Fest?
the fact that Unreal specifically states that they will gladly accept pull requests on github says a lot about their policy about this
I really hope The Coalition does an UE5 presentation next year, to hype E-Day.
Not sure why they would not use the cyberpunk 2077 engine. It supports full path tracing and runs amazing and looks awesome AND NO STUTTER!
"runs amazing"
Well well now, old onto your horses. It runs amazing now, 4 years after launch on modern hardware. But it was pretty heavy on hardware available at launch.
@@mondodimotoriUE5 has not a great track record either when it comes to performance.
I imagine its cause the engine was a mess to work with according the reports while also making the game as more projects are being made it constantly requires going back to the engine to rebuild and rewrite parts of it that they probably aren’t able to keep up. They just wanna focus on making the game without having to make all these major rewrites that could create roadblocks.
CD Project red went all in on UE and now they are already hitting big hurdles of moving from there own tech
Nope, now they are giving talks how they overcame the issues. Some stuff they contributed back to Unreal, some stuff they keep as copy of their own.
The idea of using UE and being like "We can't use actors, or the rendering system" is funny to me because it's like... so what ARE you using from the engine? In any case I'm really interested in what sort of changes from these endeavors get implemented, like some sort of lightweight "actor" or "skeletal mesh" class that does basically nothing behind the scenes except render on screen, of course that will limit what other engine features they can interact with but that's always the case with highly optimized stuff anyway.
Alex pulling out the dialectics ✊
They have mentioned in a presentation that they are working on something like Unity's ECS.
it's like dedicated engine is better fit for a game than a universal one... Who would have thought.
Depends, like how far off of the general purpose path you go, if you are attempting to do something unqiue and interesting in an engine then limitations or issues will occur, reason why a lot of game engines were made specifcally for games in the 90s, they wanted to make the game a certain way, no engine could do what they wanted to to hence made their own engine that does what you need it to do.
Though I would hope that developers would work with Unreal/Epic Games to address any bespoke requirements or improvements that could benefit the wider development community but depends how much they want to keep ownership of improvements/work for a competitive edge.
I liked Hyenas, but yeah, playing the closed alpha, while performance is of course not the main focus, I struggled to hit a consistent 60 with a high end system, being severely cpu-limited.
the baseline engine blueprints ***should*** work flawlessly out of the box, if you ask me
I despise Epic though
I reckon the devs have been forced to use ue5 by management, for some sort of ill informed marketability reason, and are now trying to circumvent its shortcomings to get back to what they had with their custom engines
Shame CDPR isn’t just sticking with their RED engine. It’s amazing in CP2077
yeah it really did them well on launch day with cyberpunk 2077, flawless from start to finish
It's not. They did amazing work with it, but getting the game to where they wanted with the Engine was a struggle.
@@Leomerya12worth it. To throw all that away is a shame.
There's more to an engine than how it looks and performs. Within studios, the build-process and asset work flows and processing are just as important.
The problem with Bungies Destiny allegedly is that their techs build process is so slow and tedious that it discourages experimentation.
Another point is that it's easier to get employees with experience if you use UE.
Odd, I got totally different message from the talks. Unreal Engine does synchronized loading/unloading by default, but CDPR prefers asynchronous loading/unloading, which might have a pop-in.
Basically, Epic prefers to that games with their engine rather have stutter over pop-in because stutter is a feel thing, but pop-in is a visual thing.
UE either 4 or 5 just shouldn't be used by all these massive companies they should be using their own engine
Alien isolation sold 2.1m copies yet Sega said it didn't perform good enough! Yeah that's what happens when you make a 18 hour horror game with AAA budget.
I don't know what more could be done with Alien Isolation to have a sequel that isn't a rehash of the first.
Unless they went more action oriented like in Aliens... but that would be a different game.
In order to remove stutter and increase fps, they should simplify the games, dumb them down, and make all of them linear corridor shooter. Fps are important you know, and who cares for the rest.
I am a developer, and i think it should always come down to the developer to make sure what they ship is fit for purpose. UE make an engine, but they dont force the developer to use certain features.
engine makers should ensure the baseline/blueprints work flawlessly out of the box, especially if they expect smaller teams/less experienced folks to use it for their games
Let us hope that CDPR hires an actual reputable Q&A contractor company this time around instead of scam artists cause they stand to lose a lot more, if the next Witcher's launch turns out as disastrous as CP2077's.
Cdpr moving to unreal is depressing. Everything is going to be on this engine x_x.
Heard it got a lot better in UE5.4 when you use that with the Matrix demo which I believe was launched with UE5 or 5.1 originally? Maybe 5.5 will be the true fix.
This is why I like the idea of Godot, solutions can be rolled into the base engine more readily.
Love RedEngine2, amazing tech.
Interested to see how codemasters is doing with wrc after all the updates. Might be worth it to reach out to them and see what they have discovered while dealing with #stutterstruggle
This is what killed EA WRC. Unreal engine is just not it right now
Unreal Engine and its consequences have been a disaster for the human race
feel like responsibility isn't the correct way to put it? People can only work so fast on so many things, why put a lot of effort into something only a couple of games will benefit from when you could make things that everyone could benefit from. This is why UE5 being open source is really nice though, yes a lot of smaller teams kinda get screwed over, but those bigger teams can really focus on adapting the engine to their specific needs.
Unreal engine isn't open source. It was free to use but it is not open source and any license.
Alex's expression in the thumbnail - 🤔🤔
😅
🤔
Such an overhyped engine. It's always been. Even when UE4 was being hyped and making mainstream news, I always felt the best engines were Crytek and Frostbite, with the Battlefield games continually being the best looking open map games I've seen...and in some cases? Even the old Source engine which was being used on Titanfall was more impressive. I never understood why CD was up and leaving their own engine when they had just gotten it to such a polished state, over such a controversial engine that did Immortal Of Aveum no favors at launch lol. This is indeed the most controversial engine to ever make headlines. We even seen the forewarnings, with articles like, "UE5, poised to melt your GPU..." entitled articles.
This is why AAA devs keep their proprietary engines. CDPR takes a huge risk with this. Soon they will lose their capability to make an engine and then they will be at the mercy of epic. Most of us AAA do not want to take this risk…
"Shader compilation stutter" is so funny to hear bcs it literally shouldn't exist. In another Talk at Unreal Fest by the guys who made The Talos Principle talked about their experience using 3rd party asset packs and how they had at some point over 2 thousand unique master materials in their release builds... which is just insanity.
If you don't know unreal, a master material represents a unique shader to be compiled.
So yeah that's gonna stutter 😂
But even then you could still precompile shaders, so no stutter?
Well not so fast, you explained quite well that it has multiple sources and if you know what you're doing shader compilation as a reason is not even worth talking about it. But failed so mention why its not worth talking about.
That it's literally just skill issue.
Everything else is improperly using worl partitions and hlods
The frame timing in The Witcher 3, both the DX11 and 12 versions were terrible. I don't think CD Projekt has any sort of special advantage in this situation. If they cannot get it right with their own engine, what makes them capable of doing it with one they didn't create?
I never had problems of frame timing in The Witcher, both before and after the patch. If I lock at 60, it's a perfectly flat line. (but I don't use ray tracing)
Maybe they get help from epic or Other Developer.
At that point they should just contribute to Godot.
They tried level streaming tho right
Um. What this video was about? Unreal is universal for every project and it's bad?
Can I have a link to those studies?
So epic should be working on it right? To fix it.
We need Carmack back for engine coding.
That makes no sense, that's like saying that we need Sweeney back for engine coding.
@@SmellsLikeRacing not really, Sweeney is already in Epic and does nothing I guess except marketing and shit. His engine is pretty f-ed up.
@@JohnnyBg2905 you missed the point entirely, both of them were great engine programmers of their time. Both distanced themselves from engine programming when they hired better programmers to do it.
The engine is open source. Could the developers offer to improve?
Epic is to blame. Unreal Engine is a tool and when your tool is broken It's your job to fix it.
Unreal engine is pretty much why I don’t play games anymore. Between them being blurry, smudgy messes, the texture loading mess, or the completely unacceptable stutter
yea i know coders hate blueprints and they wana invent the weel every time evry project.
UE6 should focus completely on optimization of current technology focusing on tweaking the engine to work well with large scale projects.
This is NOT a developer issue if a lot of top-tier developers are dealing with similar headaches.
Unreal needs to fix it and stop adding “features” until it’s addressed.
who don't steam, ps and xbox get invovled on this?
Alex it's called data throughput. If you move rapidly through a world that is using lots of tech and high res assets, you have to swap out RAM content rapidly. UE5 is designed to run on systems with a very fast data throughput for real time asset streaming. That is why PS5 was used for the demo. PC would just stutter its way through the demo and you would be calling it frame compilation stutter. Yes you could just reduce the workload and dump stuff so less RAM swapping is required, but as Richard indicated, that just throws the baby out with the bath water. Using instances of the same object also reduces storage requirements in RAM.
Notice we are not linking frame rate to a CPU bound situation. Frame rates mostly suffer from data throughput issues, not shader compilation or a CPU bound situation. We will have to wait and see how PS5 Pro handles GTA6. 60fps will be possible on PS5 Pro if the game is fully optimised and does not spam the CPU unnecessarily like Dragons Dogma 2.
Mmmm nah. My PC’s got a 5.0 NVME and direct storage works the same on PC that it does on Xbox. UE5 titles still stutter. The difference is shaders are precompiled and bundled with consoles so all that stuff can be worked out beforehand due to the hardware being identical between copies.
Almost all the unreal engines games are a stuttery mess or they do the annoying weird DXGI_ERROR_DEVICE_HUNG crashes on AMD cards.. when I directly asked devs about it they would tell me it's a problem with unreal engine and on epic games to fix.
In house engines, the best by far.
The stuttering problems have to do more with shader caching than anything else. Some developers force pre-caching during load, other do it dynamically, and others have a blend. I believe Fortnite currently has a blended model and they are trying to make the dynamic shader caching operate better asynchronously without impacting frame times as much. It's why in Fortnite the first time you run through an area and see certain player skins there is hitching, but subsequent run throughs do not get the hitching, because the shader cache has already been built. The work they are hoping to get in for the next release is on their roadmap under the card titled "RHI - Renderer Parallelization"
The type of stutter talked about in this video has nothing to do with shader compilation stutters. It's about a different, way harder type of stutter to fix... I think you should watch the video, they talk about it.
good
Old news. Lots of improvements have been made with UE 5.4 in terms of pacing.
Hyenas was shut down over a year ago and, as you stated, was running on UE4.
Having a hard time believing that Creative Assembly will do anything right at this point - they will most likely add UE5 as a DLC purchase option.
Cdproject isnt gonna fix stutter, they didnt even fix it in their own engines. Their games are good, its not a knock on their games, but they always have and had technical issues, no better than unreal. Also i think its on both epic and thr developers, to fix the issues, but its more on epic, its their engine and they market it to these devs for their projects and it should be solid, its not like epic hasnt been aware of this since the begining of their engines.
CDPR is taking on a challenge that is going to cost them more in the long run. CDPR are not only fooling themselves, but they are going to go for Round 2 of over hype. Their own engine was barely able to pull off Witcher, and janked Cyberpunk. Who is going to cover them when their experiment fails? Epic? Epic will be broken up and parts of it sold in the next 10 years. This company is playing short, if they cared about the long game they would have started the fix from Unreal Engine 3.
I knew this was going to happen when they ditched the phenomenal Red Engine! They ditched their semi-perfect diamond for a polished silver in order to not deal with bugs but little did they know that Unreal Engine has fundamental issues that are way more severe than some clipping bugs, mission bugs, animation bugs, performance bugs. At the end they not only solved 100% of the issues of Red Engine but they made CP2077 one of the most optimized game ever but the problems with UE is so fundamental that you need to use other engines to circumvent them! I actually had no idea they were this severe. I thought Epic could gradually improve it. Serves them right for ditching their baby Red Engine lol!
They switched to UE5 because it’s much cheaper. Turnover is much less of an issue. Many devs are experienced with UE unlike red engine. That’s the unfortunate reason.
everything is made for fortnite
Yes Alex we get it, you are multi-lingual
Ey! Ich auch !