DeepCool LS720 (LCS) review
Fractal Design Pop Air RGB Black TG review
Palit GeForce GTX 1630 4GB Dual review
FSP Dagger Pro (850W PSU) review
Razer Leviathan V2 gaming soundbar review
Guru3D NVMe Thermal Test - the heatsink vs. performance
EnGenius ECW220S 2x2 Cloud Access Point review
Alphacool Eisbaer Aurora HPE 360 LCS cooler review
Noctua NH-D12L CPU Cooler Review
Silicon Power XPOWER XS70 1TB NVMe SSD Review
GTA 6 will have amazing graphics ahead of their time thanks to Rage Game Engine 9
According to a recent revelation from Chris Klippel, an industry insider and the creator of Rockstar Magazine and Naughty Dog, the next incarnation of the Grand Theft Auto franchise, GTA 6 might be absolutely great.
What is remarkable is Chris's remark that we are looking at an engine that is ahead of its time, which sounds fantastic. This means that GTA 6 may have better visuals than any other game this generation, which would be quite an achievement.
"The new version of the Rockstar Games graphics engine (RAGE9) that will be used for GTA 6 will be incredible," Chris Klippel begins in the tweet, adding: "I have been able to get very positive feedback, we really should not worry about this aspect" . In addition, the insider has defined this new version of the engine as a completely innovative tool: " We are talking about an engine ahead of its time."
On the other hand, if we look at Rockstar's past and bring out some Remasters, and put on Red Dead Redemption 2 or Grand Theft Auto V, we're confident it'll be quite great, to say the least. Rockstar is noted for these accomplishments, exceeding quality standards and serving as a model for the video game industry. On the other hand, consider the release of GTA 5, which was unquestionably one of the most appealing games on all platforms. Rockstar's efforts appear even better when you consider it's a large open world. In fact, over a decade after its debut, GTA 5 looks better than other newly released open world games. Furthermore, Rockstar has managed to improve the previously optimized.
BlindBison
Senior Member
Posts: 1297
Joined: 2018-02-08
Senior Member
Posts: 1297
Joined: 2018-02-08
#6015159 Posted on: 05/06/2022 06:52 PM
Shader compilation takes place pre-runtime. If this is their claim, then they are beyond stoopid for raising it as an excuse to dump on it. For every example of so-called 'stuttering' on UE4, I will find another 100 on another game engine, purely down to poor optimisation by the developer.
In other words, they have not found a problem with UE4, they have found a game that has stuttering and are blaming the game engine. Well, a bad workman blames their tools do they not?
As for testing, yeah, in case you haven't heard, when you test something, you have a comparison against it, like every review HH does. What you do not do is get the worst product you can find, just so you can dump on it for click bait purposes.
No credibility on BOTH of those counts. They are a running joke amongst software and games developers for being completely inept.
But, it does go to show that so long as you have high production values, people (for some unknown MF'ing reason) will listen to you and quote you.
My understanding is that shader compilation does not always take place pre-runtime anymore. In DX11 it used to be more common from what I understand (shaders would be compiled during loading screens and the like -- some games still do this), but many games today have real time on-demand shader compilation. DOOM Eternal for example does has very well programmed real time shader compilation in the background which does not cause stutters.
On console, shaders are always precompiled, but this is not how it goes on PC due to the differing hardware configurations. Some game like Modern Warfare 2019 or the Horizon Zero Dawn port will precompile their shaders during the game launch -- they have a dedicated shader compilation step for this (which may have to be repeated on game boot up if a new driver is installed or if a patch comes out, that sort of thing). Other games like Elden Ring or these particular UE4 titles probably "should" take this approach too, but they do not and just stutter whenever a shader needs to be used and hasn't been compiled on the fly yet. It is also pretty straight forward to test whether or not stutters are tied to shader compilation versus other sources by updating your driver or reinstalling the game and retesting for those stutters. In Battlefield V DX12 (not DX11 though) for example, that's another game with shader compilation stutter. You can test for this by replaying the exact same level under DX12 -- the first time through it stutters like mad, the second time through no stutters at all because the shaders have now been compiled.
Whether or not this is an actual issue with UE3/UE4 or solely comes down the dev, I'm not so sure about anymore. I used to think it was just a problem on the dev side, but it's become so extremely common these days with UE4 PC ports that it makes me wonder. It's not only UE4 that has this issue, Fromsoft's engine under DX12 appears to also have the same problem (though like BFV, From's engine did not appear to have shader compilation stutter when under DX11 as per Sekiro running fine without issue). Other engines like the Red Engine, the rage engine, or CryEngine I have never ever played a game under those engines that exhibited this behavior for example. Maybe it's not the engine, could just be a lot of devs use UE4 and let it slip through on PC for whatever reason, I don't know.
Shader compilation takes place pre-runtime. If this is their claim, then they are beyond stoopid for raising it as an excuse to dump on it. For every example of so-called 'stuttering' on UE4, I will find another 100 on another game engine, purely down to poor optimisation by the developer.
In other words, they have not found a problem with UE4, they have found a game that has stuttering and are blaming the game engine. Well, a bad workman blames their tools do they not?
As for testing, yeah, in case you haven't heard, when you test something, you have a comparison against it, like every review HH does. What you do not do is get the worst product you can find, just so you can dump on it for click bait purposes.
No credibility on BOTH of those counts. They are a running joke amongst software and games developers for being completely inept.
But, it does go to show that so long as you have high production values, people (for some unknown MF'ing reason) will listen to you and quote you.
My understanding is that shader compilation does not always take place pre-runtime anymore. In DX11 it used to be more common from what I understand (shaders would be compiled during loading screens and the like -- some games still do this), but many games today have real time on-demand shader compilation. DOOM Eternal for example does has very well programmed real time shader compilation in the background which does not cause stutters.
On console, shaders are always precompiled, but this is not how it goes on PC due to the differing hardware configurations. Some game like Modern Warfare 2019 or the Horizon Zero Dawn port will precompile their shaders during the game launch -- they have a dedicated shader compilation step for this (which may have to be repeated on game boot up if a new driver is installed or if a patch comes out, that sort of thing). Other games like Elden Ring or these particular UE4 titles probably "should" take this approach too, but they do not and just stutter whenever a shader needs to be used and hasn't been compiled on the fly yet. It is also pretty straight forward to test whether or not stutters are tied to shader compilation versus other sources by updating your driver or reinstalling the game and retesting for those stutters. In Battlefield V DX12 (not DX11 though) for example, that's another game with shader compilation stutter. You can test for this by replaying the exact same level under DX12 -- the first time through it stutters like mad, the second time through no stutters at all because the shaders have now been compiled.
Whether or not this is an actual issue with UE3/UE4 or solely comes down the dev, I'm not so sure about anymore. I used to think it was just a problem on the dev side, but it's become so extremely common these days with UE4 PC ports that it makes me wonder. It's not only UE4 that has this issue, Fromsoft's engine under DX12 appears to also have the same problem (though like BFV, From's engine did not appear to have shader compilation stutter when under DX11 as per Sekiro running fine without issue). Other engines like the Red Engine, the rage engine, or CryEngine I have never ever played a game under those engines that exhibited this behavior for example. Maybe it's not the engine, could just be a lot of devs use UE4 and let it slip through on PC for whatever reason, I don't know.
Loobyluggs
Senior Member
Posts: 4769
Joined: 2008-09-07
Senior Member
Posts: 4769
Joined: 2008-09-07
#6015166 Posted on: 05/06/2022 07:26 PM
It's a pre-runtime calculation, I think they are talking about something else and incorrectly calling it shader compilation.
Stuttering is the game loading and unloading assets - which is an optimisation issue, or, running a realtime/dynamic system (which might not be graphics related - it could easily be an animation non-baked system, particle system, game logic, UI/UX) and the game has a stutter whilst this is being performed.
As lightmaps/shadow maps are no longer needed with Lumen, UE5 will only stutter with the loading of an asset which demands too much from the GPU/CPU that may (or may not) be cached.
These are optimisation issues. HZD running a compilation during game load is fine, but once it is loaded, I can assure you it is not calculating shaders to then be compiled, saved into memory and then scrubbed from the cache.
They are (I am guessing from what you have said) stating that shader compilation is happening during a game being played. That is incorrect. Again, the only way to know is to run the project file through UE4 and take a look at the stats from the runtime commands and see if shader are compiling, which I can state they are not, without even looking at the game/project running.
Compile shaders pre-runtime, and bake everything you can, optimise the hell out of it and then run it.
It's a pre-runtime calculation, I think they are talking about something else and incorrectly calling it shader compilation.
Stuttering is the game loading and unloading assets - which is an optimisation issue, or, running a realtime/dynamic system (which might not be graphics related - it could easily be an animation non-baked system, particle system, game logic, UI/UX) and the game has a stutter whilst this is being performed.
As lightmaps/shadow maps are no longer needed with Lumen, UE5 will only stutter with the loading of an asset which demands too much from the GPU/CPU that may (or may not) be cached.
These are optimisation issues. HZD running a compilation during game load is fine, but once it is loaded, I can assure you it is not calculating shaders to then be compiled, saved into memory and then scrubbed from the cache.
They are (I am guessing from what you have said) stating that shader compilation is happening during a game being played. That is incorrect. Again, the only way to know is to run the project file through UE4 and take a look at the stats from the runtime commands and see if shader are compiling, which I can state they are not, without even looking at the game/project running.
Compile shaders pre-runtime, and bake everything you can, optimise the hell out of it and then run it.
BlindBison
Senior Member
Posts: 1297
Joined: 2018-02-08
Senior Member
Posts: 1297
Joined: 2018-02-08
#6015264 Posted on: 05/07/2022 01:27 AM
It's a pre-runtime calculation, I think they are talking about something else and incorrectly calling it shader compilation.
Stuttering is the game loading and unloading assets - which is an optimisation issue, or, running a realtime/dynamic system (which might not be graphics related - it could easily be an animation non-baked system, particle system, game logic, UI/UX) and the game has a stutter whilst this is being performed.
As lightmaps/shadow maps are no longer needed with Lumen, UE5 will only stutter with the loading of an asset which demands too much from the GPU/CPU that may (or may not) be cached.
These are optimisation issues. HZD running a compilation during game load is fine, but once it is loaded, I can assure you it is not calculating shaders to then be compiled, saved into memory and then scrubbed from the cache.
They are (I am guessing from what you have said) stating that shader compilation is happening during a game being played. That is incorrect. Again, the only way to know is to run the project file through UE4 and take a look at the stats from the runtime commands and see if shader are compiling, which I can state they are not, without even looking at the game/project running.
Compile shaders pre-runtime, and bake everything you can, optimise the hell out of it and then run it.
If I’m wrong I apologize, what I stated is my understanding of how it works based on what outlets like Digital Foundry have stated, but its certainly possible I could be wrong. I appreciate your aim to explain in any case. I’ll have to research this more online then.
It's a pre-runtime calculation, I think they are talking about something else and incorrectly calling it shader compilation.
Stuttering is the game loading and unloading assets - which is an optimisation issue, or, running a realtime/dynamic system (which might not be graphics related - it could easily be an animation non-baked system, particle system, game logic, UI/UX) and the game has a stutter whilst this is being performed.
As lightmaps/shadow maps are no longer needed with Lumen, UE5 will only stutter with the loading of an asset which demands too much from the GPU/CPU that may (or may not) be cached.
These are optimisation issues. HZD running a compilation during game load is fine, but once it is loaded, I can assure you it is not calculating shaders to then be compiled, saved into memory and then scrubbed from the cache.
They are (I am guessing from what you have said) stating that shader compilation is happening during a game being played. That is incorrect. Again, the only way to know is to run the project file through UE4 and take a look at the stats from the runtime commands and see if shader are compiling, which I can state they are not, without even looking at the game/project running.
Compile shaders pre-runtime, and bake everything you can, optimise the hell out of it and then run it.
If I’m wrong I apologize, what I stated is my understanding of how it works based on what outlets like Digital Foundry have stated, but its certainly possible I could be wrong. I appreciate your aim to explain in any case. I’ll have to research this more online then.
Loobyluggs
Senior Member
Posts: 4769
Joined: 2008-09-07
Senior Member
Posts: 4769
Joined: 2008-09-07
#6015333 Posted on: 05/07/2022 11:24 AM
No apps needed sir, I only would reply to you because of the respect I have
DF are just, well....it's all been said.
If I’m wrong I apologize, what I stated is my understanding of how it works based on what outlets like Digital Foundry have stated, but its certainly possible I could be wrong. I appreciate your aim to explain in any case. I’ll have to research this more online then.
No apps needed sir, I only would reply to you because of the respect I have
DF are just, well....it's all been said.
Click here to post a comment for this news story on the message forum.
Senior Member
Posts: 4769
Joined: 2008-09-07
I'm not intimately familiar with DF's testing methodology -- I wouldn't be surprised if they have made errors at times as you say (it sounds like that SSD PS video you're referring to was pretty bad), but for Chernobylite and a lot of the recent UE4 PC ports if I recall right they tested them on a beefy PC with a 10900K.
My own rig isn't cream of the crop anymore but I always see these same asset streaming and shader compilation issues on my system with a 3900X + 2080 S + NVMe drive + 3200 MHz DDR4 cl16 memory + G-Sync with or without prefer max performance on. If these issues are significantly worse with older hardware then I feel really bad for the people in that camp (as it's already bad on my rig for those games).
To me it seems like asset streaming and shader compilation are just big sore spots in Unreal Engine and devs/EPIC need to rebuild how that works seems like. I thought the problem would improve with time but it seems to me it's only gotten worse and more common. Maybe direct storage will help alleviate these problems down the line (one can only hope). I feel like a lot of devs are doing great getting their games to look amazing with these nice tools, but if the game stutters it's all for naught and their priorities are wrong imo. Stuttering is for me probably the greatest evil in gaming -- I just can't even put into words how much I hate stutter/hitching.
It definitely is possible to build very high detail open worlds style games without the stuttering problem as other games/engines have done is (Red Dead 2 / Cyberpunk work totally fine without issue on my rig for example).
Shader compilation takes place pre-runtime. If this is their claim, then they are beyond stoopid for raising it as an excuse to dump on it. For every example of so-called 'stuttering' on UE4, I will find another 100 on another game engine, purely down to poor optimisation by the developer.
In other words, they have not found a problem with UE4, they have found a game that has stuttering and are blaming the game engine. Well, a bad workman blames their tools do they not?
As for testing, yeah, in case you haven't heard, when you test something, you have a comparison against it, like every review HH does. What you do not do is get the worst product you can find, just so you can dump on it for click bait purposes.
No credibility on BOTH of those counts. They are a running joke amongst software and games developers for being completely inept.
But, it does go to show that so long as you have high production values, people (for some unknown MF'ing reason) will listen to you and quote you.