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.
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.
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.
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.
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.
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!
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.
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.
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
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.
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
@@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.
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.
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
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
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
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!
After seeing that grey graph, I have a lot of respect for people that make games
😂The turbo implementation part made me crack up. "We implemented something called turbo to the engine"
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.
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! :)
Thrilled to see CDPR at Unreal Engine!
Hey, great talk looks promising! Is this already available in 5.5?
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 😂
Brilliant! Thank you so much!
We will get this in engine or this just to show us how great they are and clever?
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.
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.
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!
This is awesome, thank you so much for sharing! I dream of massive uncompromising worlds :D
Please release the plugins to the EPic marketplace
would be wild. CDPR plugins, for % of revenue kekw
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.
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
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
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
How about something like Unity DOTS as the universal solution to all of that?
I want it
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.
FINALLY!
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
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?
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.
What a mess of an engine lmao
Do you think CDPR would be switching engines at all if it was so bad?
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
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
Никто не узнает что я знаю только HTML