I'm most impressed by those 1600 skeletal meshes. Every other solution I've seen for a large amount of SM's have been messy vertex animation and instanced skeletal meshes. This seems to be a method to get a good number of SM's in a scene without going down a completely different and messy workpath I'm extremely happy to see CDPR pick up UE, lots of the changes they've made have already made their way into the engine and it seems like more great improvements are coming
With the sacrifice being that these skeletal meshes almost certainly have the bare minimum in terms of interactivity, even less so than vertex animated static meshes and/or instanced skeletal meshes. And it's not likely they work with editor tools like sequencer at all. Still, potentially huge for something like crowds.
I love Unreal Fest time. I was always a fan of being blown away by SIGGRAPH talks, and now we have our own Unreal dedicated version. I just hope I can afford to visit sometime. Perhaps even do a talk when my imposted syndrome is on holiday :)
I hope that Unreal Engine 5.5 and beyond will bring significant native improvements to eliminate the micro-stutters that occur whenever a section of the level is loaded or unloaded in real-time. While Unreal's advancements in rendering are impressive, frequent stuttering quickly diminishes the experience, making it less enjoyable to play a game built with Unreal.
@@jcdentonunatco Yes, and it's even enabled by default in Unreal's streaming options. Loading/unloading a cell, even with async enabled, doesn't prevent major spikes on the game thread, causing the game to freeze for 1 to 2 frames. Even tweaking the streaming values to slow it down doesn’t make a difference.
@@jcdentonunatco I'm using 5.4, and it's exactly the issue described by CDPR in their talk. The traversal stutter problem isn't new, as soon as a game needs to stream in/out parts of a level that are somewhat rich in assets, the engine causes stuttering issues.
Kinda bizzare to me that after literal decades of multicore CPUs and Unreal Engine existing, only now is something finally being done about UE actually using CPUs effectively...and I wonder if that would even happen without CDPR deciding on the UE switch. On one hand it is good since UE will benefit and thus all games using it, on the other I am still sad the Red Engine is dead.
They didnt go... they were warmly invited, as in... "please come in and bring whatever works from the Red Engine into UE cos we forgot how to make games, all we know are movies"
Interesting talk, I really like how it doesn't seem to require much extra work setting up levels to take advantage of it, sounds like they can just take a typical unreal project, run a process through their tools and boom, they get better performance, and even a few extra options for things like fine grained streaming control. Really impressive how they can handle 1600 skeletal meshes as well. I'd love to get my hands on their tools, has there been any word on if their "turbo tech" will be sold or opened up to the public?
How is your Jobs system different from Epic's MassEntity (they made it multi-threaded in recent updates)? Is this only your proprietary solution or will it be added to the main? If it's added - will UE5 have two different ECS solutions or will they merge?
I do not track Mass framework evolution closely enough to answer what is the current state of it. But the main difference I would say is that the concept of Resources is a much broader concept than Processors in Mass - With JRE you can use any arbitrary single-threaded system and treat it as a Resource to write a Job in which it can be used in read/write way interact with other "Resources" no need for critical section. JRE will ensure thread safety based on resource usage and run simultaneously other jobs if there is no conflict in the access pattern. The second difference is that Entities can be created and initialized while existing entities are being processed. Third, it supports coroutines - for me personally it is super useful tool to split jobs into subtasks - and hide complexity from the third party. Lastly, It supports Resources and job scheduling based on it but you can still use locks and just use it as general purpose job system.
I am tried to solve same problems described here. I have own ECS implementation and I am interesting how to use IPrimitiveComponent and IStaticMeshComponent interfaces? So should i write something like that MyStaticMesh : public IStaticMeshComponent (and ofc implement realizations) and this will be enough to use this lightweight Component. So i can operate with it inside background thread? It will be very useful if you will give more clarification or even example
No it is not. Only the primitives like iprimitivecomponent, there is FPrimitiveSceneProxyDesc::InitializeFromPrimitiveComponent but no FPrimitiveSceneProxyDesc::InitializeFrom (could be a more descriptive name change). None of the Turbo elements or jobs are present.
@@RomanTimm If they wanted us to use similar techniques then they would publish a whitepaper with a more in depth description of the method or implement it in the engine for everyone. I'm guessing It's mosty publicity for their shareholders :(. Edit: After some looking into the source code I think I understand what they are doing. They seem to be hijacking Unreal's proxy system that syncs up the render thread and the game thread. Each mesh in the game thread normally has it's parallel representation in the form of a proxy mesh that lives on the render thread. They are probably just instantiating the pure proxy without the game thread representation. Hence why the quick loaded assets behave like ghosts as you can't really interact with them as they probably don't have a direct representation in the game thread hence the limited interactivity.
So its a bit back to layered activity in a scene or load adjustments between "gaming space" and "detail space"? Also what the max content needed in most player's gaming spaces, short to long distance and how one deal with the inbetween phase is quite curious about. (Dont mind this)Whatever that binds the two together, like using raytracing's boxes as an extra check for collision into game space? Nvm.
it depends and it based on your needs. specially if your team or group is consist of 1200 developers in a project then things will get more complex and you need more modifications
@@aviatedviewssound4798When they will add more features the situation will get more complex and the codebase will derail, We can’t build a “Theory of Everything” simulation engine, Also hardware manufacturers on purpose make it hard to access their GPUs by making multiple competing languages and technologies (CUDA, DirectX, Metal, Kotlin, Swift) in purpose of locking the developer into their system what makes making a multi-platform game/engine an extremely daunting and error prone task because of all of this unnecessary technical complexity nonsense
So what I didn't fully understand yet from this, is this now build into the engine since UE5.3? The description talks about a "small feature implemented" I take it they talk about the JRE system? Is there a way for me as a single indie dev to benefit from these optimizations? Or am I already enjoying the benefits ':D ? From a game development perspective, managing utilization seems a key performance factor.
In UE you gonna find just the decoupling. Everything shown after the 19:00 mark is about what we did with it, just to showcase how powerful it is and inspire experimentation.
Always love seeing ECS! It is so efficient but so rarely used. Ive had a hard time figuring out how to code navigation and perception using mass entity which would allow for thousands of agents but im not a great programmer, though i bet many people could. Right now mass is good for crowds but requires more work for more functional AI which is what i want. We are getting closer!
31:33 I'm still noticing microstutter and judder while this "cooked game" demo is going. Unreal Engine is just universally known as the Stutter Engine at this point.
Not exacly, LWI allows you to just "Pack" SM into ISM but the ISM lifetime is still connected to GameThread - here we have built an "alternative" primitive form SM and ISM - much lighter and to be multithreaded - needed for large-scale and good CPU processing. With that, you can implement similar to the LWI system.
If Epic really wants to make game development accessible to anyone, they really do need to streamline and simplify things like multithreading, and Task management.
UE5 out of the box is bloated and unfriendly. Ive been using the engine for 5 years now. Their best achievement has been nanite recently. Most of their advancements are "okay" because their cost are so extremely high. Well of course its an "amazing feature!" But good luck using it for any feasible real time game
@@silfrido1768 Nanite is fabulous. But for example metahumans or their new motion matching. There are some serious expert level hoops to jump through to make it feasible for the average indie dev
@@silfrido1768Nanite is very expensive, but good luck making a normal poly game without it. Notice most ue5 games that run ok are small levels and only 2 characters in it. To run at 60fps and have a normal looking game, forget about lumen and volumetric anything; megascan foliage is ultra optimized, but any other forget about it, it will destroy your performance.
@@bam_bino__ A yes I'm guessing it's Threat Interactive ;) The discussion on the official Unreal forum goes more in depth and shows the other sides of the discussion.
Doubt we will get this tech. Epic has implemented the hooks for their systems but their tech does not use any of Epics in house UI (it looks to be IMGUI). So a lot of custom dependencies that probably load in files "around the engine" and then just hook up assets to a generated GUID pool.
Such a god awful engine and epic still wants millions of users to use their shitty storefront buggy launcher too and entrapping devs into a monopoly wall garden. Fucking hate how modern AAA games are going to be in UE for decades
Epic better help CDPR to make the next Witcher game properly. I’m gonna go nuts on Unreal Engine if the next Witcher ain’t great. Help the developers achieve something great.
@OverJumpRally you are not correct. Your game is not proof. I was talking about VR. Also you can't really compare your game with the likes of Assertol Corsa competitions or EA Sports WRC
I don't understand how CDPR went from building an amazing purpose-build proven engine with inhouse knowledge to... Hacking an off the shelf engine to contort it to their usecase. I hope it goes well for them, but they're really not making it easy for themselves.
Because UE has a lot of features for example Meta Human - it's impossible to make the same tool by only game studio (that's why CP2077 uses JALI), so there are two solutions and both require a lot of money. Meta Human is for free and is impressive - see W4 cinematic trailer, humans are created with Meta Human. Yes I'm writing about one tool, there are others.
They're importing some of their tools from REDengine to unreal (Mainly the quest designer graph system and the cinematic designer) so they're not abandoning it entirely. But I agree. I'll miss the REDengine and REDkit.
For each of their games, they would have to rewrite the redengine all over again if they continued using it. So just because cyberpunk is now optimized doesn't mean their next game using the same engine will be optimized. This is why it's better to use ue5 since cdpr would only have to update certain parts of the engine.
It's completely normal, why are you guys so concerned about it? Those questions are funny, because they are from gamers, not devs. You don't even know what are you talking about, man.
@@thev01d12 Probably someone who doesn't like having to listen to a thick indian accent. You see, sometimes people like things and sometimes they don't.
@@RenatoC.g They are spending millions of dollars translating their tech to a new engine, they aren't doing it because the engine is so bad as to be virtually unusable, that would be absurd
@@RenatoC.g you dont even know what are you talking about, they were introducing a new streaming system optimized for open world games, ue is not only for open world games, WTF? You need to create streaming logic by yourself, nothing wrong with it. When gamers talks about development xD
Lords of the fallen , hellblade 2 and blavk myth were all a stuttering mess on a 4090 pc . Forget lumen and all that crap . Concentrate on makong it run properly. Unreal is a joke
it was smooth on my 4060 xD wth are you talking about, there are also other games on ue you don't even know, like borderlands, mortal kombat 1, rocket league, marvel rivals, stalker2 (it's still unoptimized), and many more.
I'm most impressed by those 1600 skeletal meshes. Every other solution I've seen for a large amount of SM's have been messy vertex animation and instanced skeletal meshes. This seems to be a method to get a good number of SM's in a scene without going down a completely different and messy workpath
I'm extremely happy to see CDPR pick up UE, lots of the changes they've made have already made their way into the engine and it seems like more great improvements are coming
Well too bad this will not be released, at least there are some clues what it takes.
These changes only affect CD Project Red, the Unreal branch doesn't receive these updates
@@jcdentonunatco During the talk he states that some of the improvements are indeed making their way into the engine
@@twkarp Too bad not all of them
With the sacrifice being that these skeletal meshes almost certainly have the bare minimum in terms of interactivity, even less so than vertex animated static meshes and/or instanced skeletal meshes. And it's not likely they work with editor tools like sequencer at all. Still, potentially huge for something like crowds.
I love Unreal Fest time. I was always a fan of being blown away by SIGGRAPH talks, and now we have our own Unreal dedicated version. I just hope I can afford to visit sometime. Perhaps even do a talk when my imposted syndrome is on holiday :)
I hope that Unreal Engine 5.5 and beyond will bring significant native improvements to eliminate the micro-stutters that occur whenever a section of the level is loaded or unloaded in real-time. While Unreal's advancements in rendering are impressive, frequent stuttering quickly diminishes the experience, making it less enjoyable to play a game built with Unreal.
To fix that you want to load levels asynchronously. Once they are fully loaded, then you can transition to them and unload your old level if needed
@@jcdentonunatco Yes, and it's even enabled by default in Unreal's streaming options. Loading/unloading a cell, even with async enabled, doesn't prevent major spikes on the game thread, causing the game to freeze for 1 to 2 frames. Even tweaking the streaming values to slow it down doesn’t make a difference.
@@Shunkan26 hmm have not experienced this issue and we use async level streaming quite a lot. What unreal version are you on?
@@jcdentonunatco I'm using 5.4, and it's exactly the issue described by CDPR in their talk. The traversal stutter problem isn't new, as soon as a game needs to stream in/out parts of a level that are somewhat rich in assets, the engine causes stuttering issues.
temporal blurry mess is meant to be an advance in rendering, I suppose
After seeing that grey graph, I have a lot of respect for people that make games
I'm so happy that his just came up. I was wondering what's up with the CDPR & EPIC collab / tech transfer.
It's just amazing. I hope that CDR works will push Epic even further to improve their engine for huge open worlds!
😂The turbo implementation part made me crack up. "We implemented something called turbo to the engine"
Thrilled to see CDPR at Unreal Engine!
Kinda bizzare to me that after literal decades of multicore CPUs and Unreal Engine existing, only now is something finally being done about UE actually using CPUs effectively...and I wonder if that would even happen without CDPR deciding on the UE switch. On one hand it is good since UE will benefit and thus all games using it, on the other I am still sad the Red Engine is dead.
multicore was in unreal for years but its up to developer to utilize it
@@redtroll80 Not effectively, the whole talk is about how UE relies way too much on a single main thread
@@8Paul7 well you can do alot by yourself with c++ and multicore. But i would love those skeletal meshes integrated in UE🫸🫷
They didnt go... they were warmly invited, as in... "please come in and bring whatever works from the Red Engine into UE cos we forgot how to make games, all we know are movies"
Interesting talk, I really like how it doesn't seem to require much extra work setting up levels to take advantage of it, sounds like they can just take a typical unreal project, run a process through their tools and boom, they get better performance, and even a few extra options for things like fine grained streaming control. Really impressive how they can handle 1600 skeletal meshes as well. I'd love to get my hands on their tools, has there been any word on if their "turbo tech" will be sold or opened up to the public?
How is your Jobs system different from Epic's MassEntity (they made it multi-threaded in recent updates)? Is this only your proprietary solution or will it be added to the main? If it's added - will UE5 have two different ECS solutions or will they merge?
I do not track Mass framework evolution closely enough to answer what is the current state of it. But the main difference I would say is that the concept of Resources is a much broader concept than Processors in Mass - With JRE you can use any arbitrary single-threaded system and treat it as a Resource to write a Job in which it can be used in read/write way interact with other "Resources" no need for critical section. JRE will ensure thread safety based on resource usage and run simultaneously other jobs if there is no conflict in the access pattern. The second difference is that Entities can be created and initialized while existing entities are being processed. Third, it supports coroutines - for me personally it is super useful tool to split jobs into subtasks - and hide complexity from the third party. Lastly, It supports Resources and job scheduling based on it but you can still use locks and just use it as general purpose job system.
Brilliant! Thank you so much!
I am tried to solve same problems described here. I have own ECS implementation and I am interesting how to use IPrimitiveComponent and IStaticMeshComponent interfaces? So should i write something like that MyStaticMesh : public IStaticMeshComponent (and ofc implement realizations) and this will be enough to use this lightweight Component. So i can operate with it inside background thread? It will be very useful if you will give more clarification or even example
Those 6 key things for a great open world game are so much harder to do well than most know. HLOD, HISM, ISM, and pray 😂
This is awesome, thank you so much for sharing! I dream of massive uncompromising worlds :D
How do you serialize/deserialize the proxydescription? Any example code on github?
Hey, great talk looks promising! Is this already available in 5.5?
No it is not. Only the primitives like iprimitivecomponent, there is FPrimitiveSceneProxyDesc::InitializeFromPrimitiveComponent but no FPrimitiveSceneProxyDesc::InitializeFrom (could be a more descriptive name change). None of the Turbo elements or jobs are present.
@@3draven Did we get a hint if ever we will also see these features in the engine, or is it will forover stay as a tease?
@@RomanTimm If they wanted us to use similar techniques then they would publish a whitepaper with a more in depth description of the method or implement it in the engine for everyone.
I'm guessing It's mosty publicity for their shareholders :(.
Edit: After some looking into the source code I think I understand what they are doing.
They seem to be hijacking Unreal's proxy system that syncs up the render thread and the game thread. Each mesh in the game thread normally has it's parallel representation in the form of a proxy mesh that lives on the render thread.
They are probably just instantiating the pure proxy without the game thread representation. Hence why the quick loaded assets behave like ghosts as you can't really interact with them as they probably don't have a direct representation in the game thread hence the limited interactivity.
So its a bit back to layered activity in a scene or load adjustments between "gaming space" and "detail space"? Also what the max content needed in most player's gaming spaces, short to long distance and how one deal with the inbetween phase is quite curious about.
(Dont mind this)Whatever that binds the two together, like using raytracing's boxes as an extra check for collision into game space? Nvm.
Please release the plugins to the EPic marketplace
would be wild. CDPR plugins, for % of revenue kekw
what's wrong the the ECS?
So in order for UE to work properly, it has to be rewritten...
it depends and it based on your needs. specially if your team or group is consist of 1200 developers in a project then things will get more complex and you need more modifications
In order to live under a bridge, one must troll.
Godot has a better foundation then UE5 so why don't you support it and it's fully open source.
It's been rewritten for 20 years. Anyone can suggest changes.
@@aviatedviewssound4798When they will add more features the situation will get more complex and the codebase will derail, We can’t build a “Theory of Everything” simulation engine, Also hardware manufacturers on purpose make it hard to access their GPUs by making multiple competing languages and technologies (CUDA, DirectX, Metal, Kotlin, Swift) in purpose of locking the developer into their system what makes making a multi-platform game/engine an extremely daunting and error prone task because of all of this unnecessary technical complexity nonsense
So what I didn't fully understand yet from this, is this now build into the engine since UE5.3? The description talks about a "small feature implemented" I take it they talk about the JRE system? Is there a way for me as a single indie dev to benefit from these optimizations? Or am I already enjoying the benefits ':D ? From a game development perspective, managing utilization seems a key performance factor.
No. It's CDPR's features they built for themselves.
@@piotrmazek540 yeah, but they mentioned "maybe pushing it to UE"
In UE you gonna find just the decoupling. Everything shown after the 19:00 mark is about what we did with it, just to showcase how powerful it is and inspire experimentation.
@@jarosawrudzki7380 thanks for the information
Always love seeing ECS! It is so efficient but so rarely used. Ive had a hard time figuring out how to code navigation and perception using mass entity which would allow for thousands of agents but im not a great programmer, though i bet many people could. Right now mass is good for crowds but requires more work for more functional AI which is what i want. We are getting closer!
31:33 I'm still noticing microstutter and judder while this "cooked game" demo is going. Unreal Engine is just universally known as the Stutter Engine at this point.
Yeah, CDPR are making a huge mistake switching from their own engine to Unreal.
@@itzan7513 Agreed.
thats probably just from the video playback, if you look at the graphs the highest turbo streaming peak is around 6ms, which is still over 140fps
@@Erxv1 If this is console performance, they're going to cap the framerates at 60fps or 30fps which I guess means we shouldn't see any stutter.
@@aquaneon8012 exactly! :)
How about something like Unity DOTS as the universal solution to all of that?
This seems very similar to the LightWeightInstances introduced in UE5
Not exacly, LWI allows you to just "Pack" SM into ISM but the ISM lifetime is still connected to GameThread - here we have built an "alternative" primitive form SM and ISM - much lighter and to be multithreaded - needed for large-scale and good CPU processing. With that, you can implement similar to the LWI system.
@@jarosawrudzki7380 Really interesting. Thanks for the explanation, it clicked near the end of the presentation.
If Epic really wants to make game development accessible to anyone, they really do need to streamline and simplify things like multithreading, and Task management.
I want it
UE5 out of the box is bloated and unfriendly. Ive been using the engine for 5 years now. Their best achievement has been nanite recently. Most of their advancements are "okay" because their cost are so extremely high. Well of course its an "amazing feature!" But good luck using it for any feasible real time game
There was some guy that made a video explaining how nanite is not good, but tbh I don’t know I’m still learning
@@silfrido1768 Nanite is fabulous. But for example metahumans or their new motion matching. There are some serious expert level hoops to jump through to make it feasible for the average indie dev
@@silfrido1768Nanite is very expensive, but good luck making a normal poly game without it. Notice most ue5 games that run ok are small levels and only 2 characters in it.
To run at 60fps and have a normal looking game, forget about lumen and volumetric anything; megascan foliage is ultra optimized, but any other forget about it, it will destroy your performance.
@@silfrido1768 that guy is deleting comments that disagree with him, i wouldn't take that guy seriously
@@bam_bino__ A yes I'm guessing it's Threat Interactive ;) The discussion on the official Unreal forum goes more in depth and shows the other sides of the discussion.
FINALLY!
We will get this in engine or this just to show us how great they are and clever?
Doubt we will get this tech. Epic has implemented the hooks for their systems but their tech does not use any of Epics in house UI (it looks to be IMGUI). So a lot of custom dependencies that probably load in files "around the engine" and then just hook up assets to a generated GUID pool.
Hopefully these efforts fix the stutter for everyone. It’s the worst part of UE5, traversal stutter
Such a god awful engine and epic still wants millions of users to use their shitty storefront buggy launcher too and entrapping devs into a monopoly wall garden. Fucking hate how modern AAA games are going to be in UE for decades
We got a meltdown over here, you guys don't even know what games are on unreal engine, pretty much every genre. You are ridiculous xD.
@@quadro1337 nah sorry but i think there are better engines to use for games that isn't designed for movie rendering now
@@banguseater yeah, a lot of movies were made on unreal, almost as many as games. You seem to have no idea what are you talking about xD
@@quadro1337 i dont know what youre talking about. youre saying i can't tell what games are on unreal? like what? lol
Fix stutters and poor optimization. Doom eternal is putting every game dev to shame… older games also putting you devs to shame
Epic better help CDPR to make the next Witcher game properly. I’m gonna go nuts on Unreal Engine if the next Witcher ain’t great. Help the developers achieve something great.
Unreal Engine is really bad for racing and specifically racing within virtual reality. It desperately needs improvements if possible
That's not right, and my game is proof.
@OverJumpRally you are not correct. Your game is not proof. I was talking about VR.
Also you can't really compare your game with the likes of Assertol Corsa competitions or EA Sports WRC
I don't understand how CDPR went from building an amazing purpose-build proven engine with inhouse knowledge to... Hacking an off the shelf engine to contort it to their usecase. I hope it goes well for them, but they're really not making it easy for themselves.
Because UE has a lot of features for example Meta Human - it's impossible to make the same tool by only game studio (that's why CP2077 uses JALI), so there are two solutions and both require a lot of money. Meta Human is for free and is impressive - see W4 cinematic trailer, humans are created with Meta Human. Yes I'm writing about one tool, there are others.
they made them switch engines and now they have the worst of both worlds by having to switch and also make up their own solution by rewriting unreal
They had to move on to something though.
Staying with the outdated undocumented mess that is the RedEngine was not a viable option.
They're importing some of their tools from REDengine to unreal (Mainly the quest designer graph system and the cinematic designer) so they're not abandoning it entirely.
But I agree. I'll miss the REDengine and REDkit.
For each of their games, they would have to rewrite the redengine all over again if they continued using it. So just because cyberpunk is now optimized doesn't mean their next game using the same engine will be optimized. This is why it's better to use ue5 since cdpr would only have to update certain parts of the engine.
It's completely normal, why are you guys so concerned about it? Those questions are funny, because they are from gamers, not devs. You don't even know what are you talking about, man.
Know what's great about this vid? The speaker isn't wearing demon eye contact's !! helps me take what is being presented to me seriously.
Ikr
as long as they don't have a thick indian accent, i don't care
@@toddhowardfrred neck?
@@thev01d12 Probably someone who doesn't like having to listen to a thick indian accent. You see, sometimes people like things and sometimes they don't.
@@thev01d12 bigot?
What a mess of an engine lmao
Do you think CDPR would be switching engines at all if it was so bad?
@@GlassesAndCoffeeMugs Yes, stutter engine
@@RenatoC.g They are spending millions of dollars translating their tech to a new engine, they aren't doing it because the engine is so bad as to be virtually unusable, that would be absurd
@@RenatoC.g you dont even know what are you talking about, they were introducing a new streaming system optimized for open world games, ue is not only for open world games, WTF? You need to create streaming logic by yourself, nothing wrong with it. When gamers talks about development xD
USkeletalMeshComponent needs to be fixed.
Lords of the fallen , hellblade 2 and blavk myth were all a stuttering mess on a 4090 pc . Forget lumen and all that crap . Concentrate on makong it run properly. Unreal is a joke
it was smooth on my 4060 xD wth are you talking about, there are also other games on ue you don't even know, like borderlands, mortal kombat 1, rocket league, marvel rivals, stalker2 (it's still unoptimized), and many more.
Никто не узнает что я знаю только HTML
Unreal Engine = Stutter Engine
fortnite player, not dev