To try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/ThreatInteractive . You’ll also get 20% off an annual premium subscription. PLEASE READ FOR UPDATES & RESPONSES: 1. Watch this video in 4K (as in streaming settings) as any lower compression will hide the visual details discussed. 2. We would really appreciate it if viewers could share on *giant game related subreddits. These prevent self promotion but these can really push our channel's success by the thousands.* 3. Some clarification on what was mentioned at 1:46. Sometimes when starting the game, CPU issues cause the frame rate to stay around 35-38 FPS, even though the GPU has room to perform better regardless of V-Sync. Other times, after reopening the game, the CPU issue goes away, and we can use the full GPU to reach the V-Sync limit of 60 FPS. We’ve even hit 72 FPS with full GPU usage when V-Sync is off. We have a few methods to avoid this CPU bug like making sure V-Sync is off in the save file, restarting the computer, and launching the game as the first application after booting up (other than Steam or related apps). Once the game is running in this better scenario, V-Sync can be toggled without problems, as long as it’s off before closing or saving. However, when using Intel GPA, we can’t seem to get this "good" CPU performance, even with those tricks. This could be due to the complexity of Jedi Survivor, the profiling overhead or vendor application interference. Because of the 35-38 FPS limit caused by the CPU, we use the command r.MaxFPS 30 to make performance comparisons easier, especially when comparing with NFS 2015. 4. Here are the commands both UE4 developers and gamers can use with many UE4 titles. r.TemporalAA.Algorithm 0 r.TemporalAA.HistoryScreenPercentage 200 r.TemporalAA.Upsampling 1 r.TemporalAACatmullRom 0 r.TemporalAAFilterSize 0.09 r.TemporalAASamples 2 (MSAA x2) r.TemporalAACurrentFrameWeight 0.6 5. Why is using them in UE5 a bad idea? Because r.TemporalAA.Upsampling 1 in UE5's source code forces a higher value than r.TemporalAASamples 2 which means a higher r.TemporalAACurrentFrameWeight will display lots more jitter. Now if you can V-sync around 120hz, you might be able to get away with it. You can try these commands in UE5 without r.TemporalAA.Upsampling 1 but the reason thats enabled in the first place is for higher quality pixel placement. *6. At 6:51, while the depth buffer is the only render target that didn't have a render target clear, our software still shows us that it's being written to. Please take this into consideration when referencing the performance shown. * 7. We see some people complain about shimmer in the modified TAA. But people saying this are also the ones who are okay with massive amounts of ghosting and blur in the stock TAA. This portion is not accounting for the neglected content underneath TAA. As we stated in out FIRST video, clear TAA cannot fix broken effects and shaders that rely on smear. DLAA is an absolute joke in motion and the unique footage we showed shook Nvidia so much that they released a "fact or fiction" or in other words *damage control video* in just 14 hours after we made this video to relive non-blur biased views this video will generate from consumers. *8. Some good news regarding UE5.5, you can use our TAA commands as long as the newly introduced r.TemporalAAScaleSamples is set to 0! *9. Regarding the comments on the early Z pass, we're saying it's inefficient and the suggestions we made also imply a change to how we occlude objects using depth buffers. *10. In response to Deveno linking our video out context(see our Twitter/X), we analyzed patch 9 to confirm those 8th gen optimizations did not make it to patch 9. The reason most likely is because the project for the 8th gen uses a very modified(optimized) copy of the the PC/9th gen version. Which means they would have to upload the 8th gen version on PC as a separate release or erase the current version on steam due to how unreal and steam work. This is backed up by the backwards compatibility videos showing the 8th gen version running on 9th gen consoles. All the bloated issues are still in the PC version. *11. 🚨 Official Threat Interactive Discord 🚨 discord.gg/7ZdvFxFTba *12. Stay Tuned.
I've tried r.TemporalAA.HistoryScreenPercentage 200 in Assetto Cosra Competizione and while it looked incredible, it absolutely destroyed my performance, if I understand correctly it's the equal of 200% supersampling, so you are rendering in 4K and downsampling to 1080p. Am I correct? But these are still very helpful, only r.TemporalAASamples 2 and r.TemporalAACurrentFrameWeight 0.6 alone does wonders to any UE4 TAA.
Why do you recommend using Vsync and an FPS over 50 for the tweaked TAA to work best? I almost always rely on Freesync/VRR over Vsync nowadays, usually with an FPS cap which can reduce input lag if it’s ingame/engine.
I was about to post a comment mocking whoever at Respawn said that but then I went and reminded myself of the Jedi: FO release date, and they did very well with around 3 years of development time through covid (so not even a proper 3 years) even tho the game's performance is fucked. Shades of 7th gen era but they fell short. Sure bragging is out of touch but not sure what this comment is waffling about
LMAO, reading this right after saying that the devs were probably rushed is hilarious. Who brags about making a game in record time? Brag about how happy and comfortable the devs were while making the goddamn video game, it's hard mental work.
Modern game devs are horrible and also the work flows are beyond outdated. This is literally because working at a game dev is only what unlucky bottom tier programmers do.
low level API's don't help, we've traded the security of a stable foundation made by a select group of experts for the vague promise of potentially higher performance if everything is made right everytime by an unrealistically competent dev
I would state it this way: tech influencers usually benchmark hardware, not software. They always answer the question how well a GPU runs a given piece of software, and never do it vice versa. Threatinteractive is finally someone who flips it, and benchmarks software on a given piece of hardware.
i like dijkstras view on this "when computers were small there were no problems when computers became big problems became gigantic it is indeed hard to make performant quality software nowadays
The best practices for TAA absolutely made my teeth grind when I saw that gdc .. it's like no one cares about how the game looks in motion, they only care about how it looks with a screenshot.
The problem is that these studios hire mostly cheap juniors to work on these titles. More seasoned proffesionals are too expensive to keep on and are usually fired at the end of each project to start the hire cheap cycle again. Biggest offender in this is Forza. After every release the entire technical team is fired and the wheel is literally reinvented with interns and cheap juniors dying to prove themselves. The problem isn't studio laziness, it's incompetence and cost cutting.
Cost cutting and yet they still announce the budgets of hundreds of millions... I don't like to count someone else's money, but I'm really curious about where these budgets go besides the studio's CEO's and directors' pockets. Or rather what's the percentage of the budget that actually went into making of the game.
@@Hirokuro_Asura They probably do something like your state government does. Cut corners on projects, leftover money goes to general funding, and they siphon that general funding into projects they want that will line up their pockets.
The video analyzes GPU time, not CPU time. 5ms means nothing, "poorly optimized" games from a decade will run like that on modern hardware. If you shipped a game on a console, that outputs 4k 120FPS, and it runs its frames at 5ms, you still left 3.2ms on the table that could've been used to improve the visuals or image quality. What matters is not some arbitrary frame time, it matters what the cost for the resulting visuals is, and yes, for many titles, that's underwhelming.
Game dev here. It totally depends on what type of game we're talking about and what graphical settings. A game like this couldn't possibly hope to get an entire CPU frame down to 5ms on modern hardware. Around 3-5ms CPU alone would likely have to be devoted to just rendering-related tasks such as culling, submission to the GPU, read-backs, UI updates, etc. And that's none of the gameplay itself, or any other underlying systems like scheduling, audio, etc., which you'd be looking at probably at least another 5ms+ for that. General optimization only gets you so far, especially when we're talking about something that's multi-platform and running on a bulky 3rd-party engine. Maybe, just maybe, they could've spent another year or two doing nothing but optimizing the hell out of it to get it running as perfectly as possible on all platforms, but that's rarely economically viable, and it still wouldn't hit 5ms, especially not if they're using UE Blueprints. All this is to say, yes, the game is poorly optimized, and should be better, but saying a large game like this could have ever possibly hit 5ms CPU time on modern hardware is completely unrealistic. And even if it was, it wouldn't matter, because the GPU time would still easily eclipse that. In principle, yes, there's usually a way to get it done, but it's rarely feasible.
@@Frisbie147 RE: he doesnt even realise that the game already has the rtao that he recommended It's not RTAO, it's GTAO and mentioning unreal's implementation isn't worth our viewers time because it's a slow and poor implementation.
@@Aidiakapi but the point is that it's 5ms that's almost entirely wasted/needless, in this case, a _third_ of the total render time and anyways, ideally there is some headroom so particularly intensive scenes/moments don't stutter
19:41 Holy crap, I’ve wanted something like this the moment I turned on per-pixel lighting in Dolphin. It has always bothered me how we’ve basically solved the smoothness of a model’s surface but we have nothing when it comes to the paltry few edges, as usual this issue was solved in 2008 and nobody ever heard about it because of the chaos of information.
Haha “nobody heard of tessellation” lol. Right. Tessellation is much MUCH less optimised than topology, very complex to iterate modelling wise(for saving, what, few k of poly?), and prone to tank games due to shoveling un-checked amounts of dynamic geometry in the rendering pipeline. As proven by crysis2. Oh. And since it is not topology, every detail stretches the 2d textures, rendering it useless for any real detail other than noisy stuff like sand, rocks or asphalt… It is also problematic to use in many modelling styles and level design.
I a web developer so I have little knowledge about these topics. But I research them after watching and more and more i Understand why games have been so heavy lately, especially UE games. Thank you!
Make badly optimize games. Have big corporations sponsor your AAAA games. Encourage consumers to buy the latest hardware. Profit. Money flows in a cycle, with big engine companies like Epic being in bed with many industry leaders, to gain wealth and power. You can't gain power through humble interactions and niceties.
TAA is indeed being butchered - Hell Let Loose has multiple TAA presets, but none provide good AA. The community found a good preset that produce better results than the presets provided by the developer. Fortunately, the developer listened to the feedback and included the community preset along side the other presets (unfortunately not enabled by default). For a PvP shooter where every moving pixel is important, this is extremely valuable.
I luckily found the "Community TAA" option by chance. I was using the standard TAA and it looked... odd especially when aiming near windows. Searched around and found the Community TAA tried it and it did way better.
Anti-aliasing ghosting must be garbage when you're trying to determine the exact shape to aim at in a competitive shooting game. And I'm annoyed at it without playing shooters.
This dude gives vibes of a person who does work of four people better than the ones who currently does it, and this people come to you complaining he has "bad attitude" towards them.
So most of the optimization techniques are things that already exist in many older engines, such as the legendary CryEngine tessellation? Engines and devs really are developing backwards...
First of all. The old toy is not as interesting as a new one. Second. Modern development is artist driven, so basically engineers are trying shove in ridiculous models and gorillions of autogenerated shaders and choose the most bruteforce and foolproof methods.
@@SuperXzm Pretty on point. We used to talk a lot about TECHNOLOGY, nowadays it's just needlessly high-poly models shoved into everything, and everything else took a nosedive.
It's important to also be aware of that old tech which seemed good at that point actually had many limitations and didn't actually scale well. Tessellation is one such thing. It actually worked very poorly in most cases. There is a reason that a lot of terrain solutions does their own tessellation, and why we got the mesh shaders instead. But neither tessellation nor mesh shaders work well with ray tracing and they need speciall pre processed data. There are many things left to figure out. Modern rendering can do a lot of cool things, but it's also very complex to combine and use all of it together.
They used Unreal Engine. Which is to say, they used someone else's general purpose off-the-shelf engine. Which is to say, they're not in the same league with the sorts of developers who have in-house engines. Is this an oversimplification? Yes. But it's a youtube comment, so who cares.
@@aregranhaug8617 No, Kevin Jimenez is a real human. I work with him. He works out, does not drink or do drugs. Italian, Spanish heritage & of course American. He is a VERY hard worker and he deserves so much support.
You got my sub by 15 mins, this is the content Digital Foundry is missing. I look forward to more technical deep dives, get more and more deep on the subject!
0:45 - LOL Redditors are bootlickers, they'll tell you the FOX engine looks terrible and only runs well because MGSV is a desert, while under the same breath giving Epic Games the glaze constantly. Two PS3 rhythm games (The Project DIVA F games) locked itself to 30FPS compared to the 60FPS in previous entries, and was one of the first games to be emulated on RPCS3 with high framerates, and it didn't use any of the SPU cores that the PS3 had. I don't buy the "Just because it's on consoles, that means it's magically optimized" narrative.
It’s kind of nuts that DIVA F and F 2nd didn’t use one of the PS3’s main features when it was exclusive for that platform. Now that I think about it, I think X ran at 30FPS, too… or maybe that was only on Vita… I don’t really remember since I dumped it after Arcade came out.
Need more of such content. UE5 being more widely adopted is a disaster. People are made to believe that snake oil solutions like upscaling and frame gen is the way forward and I'm glad there are at least a few of us who can see through this BS.
I remember in 2019 when 'Upscalling' is a premium feature that only the latest gpu (rtx 20 series back then) can only achieve. But nowaday games looks absolutely dogshit in performance if we disable upscalling. The latency in Frame Generation is also laughable in the current state. I don't know why nvidia & amd pushing these feature, as it is still premature in reaching the desirable graphical videlity... It even makes the whole debacle of Stagnation in current console generation.
@@nickochioneantony9288 AMD does it because nvidia did it, and people stopped buying AMD GPUs because they didn't have those features. Also upscaling is a great way to get more fps without throwing more hardware at it, the problem is that game devs now assume that it will be used so they put even less effort into optimizations hoping that upscaling will pick up the slack.
Some notes: depth prepass cannot be a different resolution use different geometry, because this woild cause black artifacts. The prepass is also used for fragment culling afaik. Gtao is on unreal, but has smearing issues and does not wprk well with dithering and depth blending - and depth blended materials would render as dark blobs. There is also a bug in ue4 that causes gtao to essentially not work, that the fix needs to be backported from ue5. Temporal aa upsampling is unnecessary for most uses and imo is too expensive to be worth it, unless you are rendering to a lower resolution (which ue5 uses by default, thanks to its superior upsampler) You can implement a technique similar to the face culling you described, it cam help with the reliability of hardware occlusion and precompited visibility, but because you cannot prioritize certain objects in the prepass over others. You could use unreal's software culling set to only use those objects, but really the cheapest solution is to use smartly llaced distance culling volumes calibrated based on the distance. For some features, the full depth prepass cannot be disabled as it is used for other things.
I like the idea of an "occlusion potential" for determining whether meshes should be included in the depth pre-pass. The volume of the mesh might be useful (assuming all meshes are "airtight" without any missing faces - or a heuristic approach could be used to guesstimate virtual faces when calculating mesh volume) which would be stored in a table on the GPU. Then the omission of the occluder from the depth pre-pass would be dependent on the mesh's volume divided by the distance from the camera (and scaled by the tangent of half the camera FOV angle, etc). However, if there are a lot of open meshes used for things like wall pieces and whatnot, that are just a bunch of front-facing triangles and not a closed airtight surface manifold, perhaps the mesh's total surface area would be better instead? Surely there's a combination of mesh size, volume, and surface area that would be a good heuristic for which meshes should actually be used for calculating the occlusion potential. Just using the AABB of a mesh, or the spherical size of a mesh (i.e. center of min/max AABB and distance to farthest vertex) doesn't account for meshes with a lot of holes/cracks/gaps and would still include them in the depth pre-pass. This is something I'll be thinking about for a while. For cylindrical object rendering it seems like some kind of "beam particle" representation could be used instead, where you're literally just passing points along the axis of the geometry to the GPU and it's generating a screenspace triangle strip that has the proper cylindrical worldspace coordinates and texture coordinates calculated for each fragment to create the illusion of a cylindrical object conformed along the polyline. This would require some maths to accommodate for perspective projection so that the illusion doesn't fall apart as the camera moves closer to such geometry, but I believe it's something worth looking at. At the end of the day though, it's really the lighting compute that is the meat of this game's frame time and it would be a lot of fine-tuning all of the other phases of rendering a frame just to squeeze out a few more fractions of a millisecond per frame. These guys didn't write UE's renderer, they just made a game with it - and likely didn't respect hardware limitations and performance as much as they should've. I also wanted to say that it's important to distinguish between frustum culling and occlusion culling. Coarse occlusion culling on the CPU can go a long way when there is a lot of individual geometry in a large scene, and it's something that a lot of modern engines completely forego - instead relying on the GPU just having thousands upon thousands of individual meshes thrown at it for it to contend with. The Godot game engine, for instance, had zero occlusion culling for a long time (after it had gained 3D rendering capability) and relied exclusively on frustum culling. Back in my day, you didn't have a game engine unless you had an occlusion culling algorithm. Heck, if all you had was an occlusion culling algorithm then you had the central core foundation of a game engine upon which the rest of its bells and whistles could be built. I couldn't believe Godot was a 3D game engine with zero occlusion culling whatsoever, and calling itself a "game engine". Anyway, I digress... I think it would've been useful for the curious newbies out there if it had been made clear that the "depth mipmap" and "HZB" are one-and-the-same. HZB = Hierarchical Z-Buffer, where a max() miptree is generated from the depth buffer by taking the largest value (i.e. the closest Z value, because depth is stored inverted, as 1/Z) out of each 2x2-pixel area of one mip level to be used as the depth value for the next higher mip level's pixels, rather than averaging them together like a regular mipmap. I don't think you need to explain all the ins-and-outs of graphics rendering, but it's my opinion that people who are still learning would get more value out of your content if you pointed out the non-obvious. Instead of saying "HZB" just say "hierarchical Z-buffer", for instance. I think that this more informative content could be made more accessible, in terms of its informational content, to the audience that existing tech tubers have. I, for one, am tired of just seeing framerates, but then again I've been a graphics coder for 25+ years :P I look forward to more videos like this :D
Thanks for a very detailed video. There are a few points I would like to add. - Depth prepass became a new standard whether with occluder meshes or actual geometries or reprojected from the previous frame (see GPU-driven rendering pipelines). It often makes things faster (but not always). It is also mutually exclusive with occlusion culling. You can use both. - Tessellation doesn't work well with reprojection algorithms (TAA, ...). The tessellation makes it very difficult and expensive to calculate motion vectors between two frames. - GTAO is great but it doesn't solve blurriness. In GTAO's presentation (page 96 "spatial denoiser details"), you can see that the final SSAO they use is as blurry as SSAO in NFS. - Biggest downside of GI algorithms (PRT / Precomputed Light Probes / Voxels) that require baking is time. It usually takes many hours (can be a day if your scene is big) before the artists could verify their changes. Nowadays, the gaming industry is less and less profitable and they have to ship the game faster. I can understand why they'd go this route. If you mentioned these things in video but I missed it, I would like to apologize in advance.
Presumably doing a full depth pre pass allows them to render the material pass with the depth test set to equals, ensuring that every pixel only has expensive material logic applied once.
@@jonathanlebon9705 the idea is that once you have a depth prepass you can draw your objects with depth testing set to equal. Only fragments that get rasterized at the exact depths as the fragments were during the depth prepass can be allowed to render by the rasterizer. This means that you negate all overdraw, you can skip doing fragment discards (because it can be done in depth prepass) (this saves you shader permutations and ensures that EarlyZ stays working on most hardware) and alleviates you from drawing objects strictly front-to-back (so you can batch them by PSOs and not switch them constantly).
I've struggled to conceptualize what a good typology could look like when the object could be viewed from any angle, so when you criticized it here I wasn't quite with you but curious, then you pull out camera based edge tessellation. With my limited knowledge at least, that seems like a great solution. Really won me over right there.
great observations and explanations , these are fantastic ! lots to think about . at 17:39 the idea of using blockers for early cheap culling reminds me of how "portals" were used in BSP engines , and other very controlled methods of occlusion optimization like precomputed "Potential Visibility Sets" . it does seem like there is potential to revisit these concepts from an automated approach like how Hierarchical LODs distance is calculated , a simulation of the gameplay and possible view angles could generate the PVS along with help from level artists placing "occluder" objects like the walls you mention . the distaste for temporal AA is understandable , mainly because of how intertwined now it is with other systems and how every vfx / shader is tuned under those conditions , that to change away from the blurry softening temporal AA has to fix the look of the environment can often then make the vfx and shaders that were tuned UNDER TAA look incorrectly intense and deepfried as the artists were making adjustments to try and overcome the TAA blur .
Very easy instant sub, I'm a bit out of practice with game dev since working elsewhere after University, but this stuff is gold and I look forward to seeing you grow your catalogue.
1700 drawcalls , That’s pretty well optimized! Culling by layer and size is an option but with hundreds of people adding assets until the last moment , breaking optimization techniques is pretty common. Everybody project start with really good documentation until dead line 😢
I have to point out a few things regarding the TAA. - r.TemporalAA.Algorithm ; this setting controls whether the game uses TAA Gen4 (0) or Gen5(1). Gen 5 is a newer form of TAA that has better coverage, less pixel shimmering and better image clarity. But it costs more. Depending on the GPU, it can drop performance by around 10%. - r.TemporalAA.HistoryScreenPercentage ; from my experience, this setting does nothing in most UE4 games. UE5 has a similar setting, that actually works and improves image quality. A value of 200 has become the default value since UE5.2 - r.TemporalAA.Upsampling 1 ; This is already the default value for UE4. But considering that you are using native resolution, it does nothing. Should be used with r.ScreenPercentage to define the percentage of base screen resolution. - r.TemporalAASamples ; This is not MSAA. This is the number of jittered positions for TAA. Default is 8 in UE4. From my experience, higher values result in a sharper, more detailed image, but with more pixel shimmering. Lower values result in less pixel shimmering, but a blurrier image. I prefer a value of 4. Best regards
r.TemporalAA.Algorithm is the TSR prototype and has significantly blurred motion. HistoryScreenPercentage 200 and Upsampling 1 is why we end up with 4k buffer. It absolutely has impact on quality, it's even stated in the TAA paper by Brian Karis. These two benefit motion, not still camera scenes. r.TemporalAA.Samples 2 and 4 uses the same sample positions as standard MSAAx4 or x2. For instance Decima's TAA alternates between two sample positions like r.TemporalAA.Samples 2 but doesn't use the standard MSAAx2 sample positions.
@@ThreatInteractive I found that TAA Gen5 has much cleaner image and fewer ghosting artifacts. Mind you, I always disable motion blur. Always. I have never seen a UE4 game benefiting in image quality from HistoryScreenPercentage 200. Of course, I have not tested all games. MSAA samples the edges of polygons at a higher rate. TAA samples neighboring pixels. This why MSAA has a significant cost to performance, while TAA is close to being free.
@@winj3ryou didn't understand what he was trying to say based on your MSAA comments. He's not saying the sample setting is MSAA. Also history screen percentage makes motion clearer, I've tested it, it's an objective benefit. You need to do motion tests.
Sometimes it's hard to understand Epic engineers. Unity added APV(Adaptive Probe Volumes) for baked lighting and rightly so. Unreal is actively going to mobile, but does not offer the same technologies. All that remains are unfinished Volumetric Lightmaps, which are mainly for moving objects and cannot replace lightmaps for illuminating the entire scene. It's funny but Unreal has Lumen and it works great and it already has spherical harmonics and information about the color and reflections of the scene, but for some reason Epic don’t want to add a static-baked mode for Lumen, especially since UE already has virtual texture technology. This would be a great replacement for Volumetric Lighttmaps for all the lighting in a scene.
@@aoqia Did you see something there similar to what I wrote about? Megaliths is mainly for video cards with DXR support. Also, if the game is corridor or you need several dozen lights, they are of no use, turning them on can even eat up more productivity than regular lights.
Because it will optimize lumen and make it cheaper to run. If its "too cheap" then people are less likely to need to upgrade. Corporate CEOs and shareholders are interconnected in their network of wealth, they like to maintain that power and wealth, not to dilute it by making everything easier and better for consumers... Elon Musk had his text message leak years ago, you could see how his ultra rich friends throwing money making ideas at a wall to see what stick, some of those ideas are essentially anti-competitive and unethical. So do not assume CEOs and corporate business owners or the likes to be of the same mindset as consumers.
@@dra6o0nPeople with weaker recent cards will just throw upscaling and frame gen at the problem until the game becomes playable, not go out and buy a better GPU.
@@marcelosoares7148 Because the issue is that games that barely have higher fidelity than last gen doesn't need to be upgraded with newer hardware. It's a lot of bad optimizations and computing thrown in to automate and speed up development.
The fact that modern games like this are so sloppily made, with glaring artifacting even without TAA is honestly disgusting and a major brewing accessibility issues for people sensitive to noise. Not to mention people who can get photosensitive epilepsy too...
I'm begging you to do a video on The Finals. It's weirdly CPU heavy, and definitely has that TAA slop, but otherwise the visuals in that game are actually incredible. I feel like it's one of the few titles actually taking advantage of UE5. I'd also really love a dive into how they're doing motion blur. It's literally the only game where I prefer to play with all the effects on at max settings, even though it's a fast paced competitive title and I'm definitely losing out on frames and clarity by having everything cranked.
As for stuff you said in the video, I still love the TAA hate, and the idea you propose at 17:36 already exists in the Source Engine, it's the Occluder texture you can put on brushes, mostly behind walls
@@RADkate I mean, PC Gamer doesn't review PC port quality anymore and they only spit out an article about it when a game gets reviewbombed and they want to spin the "consoles good, pc gamers are pathetic gamergaters" crap.
Proper implementations of TAA will typically employ a form of contrast adaptive sharpening (e.g. AMD has a quite good open source algorithm for this). Since TAA can soften the image somewhat doing this right can produce results that look closer to raw native but with much much better anti aliasing and all at a reasonable cost. UE4 games I’ve noticed don’t seem to do this out typically. DOOM Eternal is a title that actually does have great TAA and provides a sharpness slider as a separate example. TAA is an oddball because there really is a “correct” way to do it and an incorrect way and there is variance in implementation. Poor TAA solutions can be very rough but the good ones are far better and produce high quality anti aliasing with generally great coverage for a small fraction of the cost of older techniques.
Please do more of these analysis videos! Very informative and accurate. Silent Hill 2 remake is my suggestion, I only have an AMD card so I can only access so much info from the game. But still very interesting, as I worked with Unreal for years too.
Man, I wanted a channel to do these kind of analysis for ages now, thank you bro for actually doing it, and explaining everything in detail. Do you accept suggestions? I'd suggest Source Engine, for example, I always wanted to check their render pipeline, specially compared to the new source engine 2 (see cs2 compared to cs:go, for example, where the image quality 'doesn't seem' to be a lot better, but the hit in performance is big)
Subscribed, wow. Great video. Looking forward to you getting to tear down Monster Hunter Wilds. (aka recommending 4070 for 1080p60 medium settings with frame gen)
Doom use ID tech in-house engine, which is why it passes the nature of blurry image of UE. The RT feature of Doom Eternal is also smoke & mirror.... it literally only works on mirror reflection & metal based weapon, other aspect as lightning is not affected. But other than that, it was well optimized, it was pre-2020 so I guess the proper devs were not laid-off yet at that moment.
Basically the devs of Doom are actual engineers who knows their stuff. Some game studios and built in engines like Bethesda are mostly artists. Epic, are more like... Consultants. They have engineers but technical know-how isn't needed to sell their product. Their engine is developed to be spread and garner profit, while Bethesda and ID tech doesn't sell license for the engine.
@@nickochioneantony9288 Id tech engines have always been the gold standard for optimization its how they were able to exist to make commander keen doom and quake and they keep that as a priority for their company epic does what they have since unreal in 1998 prioritize graphical fidelity above all else
@@dra6o0nWell, proprietary engines like id Tech are made for a select few games, and their entire rendering pipeline can be built just for the needs of that game. For engines like Unreal or Unity, they need to support ANYTHING; it can run anything and look good, but when it comes to absolute top-of-the-line work, it won’t be as good as an engine that can tailor its work just for specific games. id Tech 7 is perfect for complex fps games like DOOM Eternal. But what if you tried to use it for GTA 6? Totally different format, different scope, different content scale, and different requirements. This problem was famously encountered by teams trying to adapt the Frostbite engine for racing games at the request of EA.
You know someone messed up when your game gets compared to a game in the Frostbite engine. And comparing a UE game in a genre that UE was designed for to a Frostbite racing sim...? I mean, the NFS series was the reason Frostbite's source started to turn into spaghetti code...
Outside of the TAA part, which is subjective, and in my opinion, the modified TAA looks much worse, as it reintroduces pixel shimmering without significantly improving image clarity. That said, the video is great, and the technical details were well explained. Great job!
Thank you for your work. Your videos explain a lot. Can i suggest creating a course (or several) in unreal engine and/or unity optimization? Those two are among most popular engines not only in the big studio environment, but also for solo and indie developers. That is one of the least present topics on the tutorial sites and it shows by the state in which many games are released . More and more games are created by hobbyist and/or the hobby of creating games becomes a career path. Good habits from the start will be of benefit for the gaming scene.
Great video, as usual! I have a video idea for you. Depending on the original game engine you are testing, you could recreate a similar scene in Unreal or Unity or flip it around to add a challenge. You can just implement all your ideas and then compare the results.
At 14:33 it would be cool to see a vertical graph, with horizontal bars that appear at the same time as the text, their length proportionate to the listed milliseconds on each line. TBH I personally find it weird when you say "we" all the time but it seems like mostly your personal effort and script.
I am not sure what software they use but RenderDoc gets you basically the full breakdown of a frame. But I am assuming there are unreal specific tools that give more info.
Each hardware vendor also has their own software that hooks into their hardware's performance metrics. AMD has Radeon GPU Profiler, NVIDIA has Nsight Graphics and Intel has the Graphics Performance Analyzers suite, which is what he used in the video.
Great vid ! Always fun listening what you have to say on game optimization even though I sometimes don't get it but I'm slowly getting there haha, can't wait for the channel to blow up :D
The more I watch these videos, the more I respect people who work on graphics for AAA games. Each of the mechanisms you mention almost seem to have a world of complexity, and then there's devs that combine all (probably most) of them perfectly.
I really think a lot of it is about giving experienced developers and artists enough time to make all these adjustments. I’m curious as to whether the seemingly ludicrous triangle count in the wireframes shown in this video are a result of having too few artists being forced to crank out models far too quickly and not having time to properly fix them up.
Yeah, unfortunately I don't really think UE TAA is.... salvageable. There's a bit you can do, but sharp motion clarity without severe jittering & aliasing isn't one of them 😬 And believe me, the community has tried with all sorts of tweaks, but you need to choose either of those 2 sides.
@@MLWJ1993 Seems like highly detailed geometry comes at the cost of more aliasing at the same resolution/overdraw, and the larger the native screen resolution the better the GPU utilization. Seems like a faster GPU pipeline over more Smid chunks, would help. Which could explain AMD GPU's propensity to scale much better at lower resolutions like 1440p-1080p (ignoring driver overhead)
This full depth pre-pass is illegal. There are so many established ways to cull most objects being rendered to the depth buffer: PVS, Hierarchical z-buffer occlusion culling, Coverage buffer, etc. For crying out loud there already generate a depth hierarchy; Hierarchical z-buffer culling would have been the most logical thing to implement.
Ok mr youtbe commentator. All rendering engineers using depth prepasses for decades were just stupid, should've listened to you - a person who never created anything but watched a youtube video.
@Genebriss You wouldn't know this but I am working on my game engine so knowing things like this is important for me. Who said that a depth pre-pass is bad? Of course many games have used a depth pre-pass. But they don't draw everything like is done here but only objects that cover most of the screen space. That's how other games have done their depth pre-pass.
There has to be other reasons they didn't do that, like making the game seem impressive, just generating buzz, good or bad, over how hard it is to run, or creating an incentive to sell more hardware.
To be honest, Unreal has some of those culling solutions already. Or similar enough ones that could be adapted for those use cases. The problem is mostly workflow related. If you don't tag assets early enough, it's hard to add culling planes and similar things later (because of the scale of the game). As an example, flagging assets to be removed from depth pre-pass can be tricky, and you either have someone manually do it, or you do it when you establish the workflow, or you write an automation tool for that. Totally doable, but costly. And, most importantly, the right people have to be aware of it. I think there is plenty of room to learn from videos like this. But these ideas have to reach the content creation pipeline, and that's a gap hard to bridge. These initiatives usually come from very proactive engineers that have to advocate for the extra work put into it. And, because the game is built in Unreal, most resources tend to be shifted from Rendering Engineers to Tech Artists or Artists - I think. Usually, a central Team would have resources to work on such things. But they often don't have a say on content creation pipeline, that's game specific. So some proactive person from the game team has to bridge that gap again, and so on. That's why it takes time to get this sort of improvement in games like this. You have to keep people around for long enough and keep track of these improvements alongside so many other things, so they don't lose visibility and get fixed for the next title. I think every game could benefit from a really really polished vertical slice where all of these techniques are applied. Then out of those learnings you map all techniques and then try to scale those to an open world content creation pipeline.
Wouldn't decreasing resolution in the depth pre-pass cause false-positive z-culling at edges? I think only using large objects (relative to camera) for the pre-pass makes the most sense for optimization in the depth pre-pass.
please keep talking about this, not only is it interesting to hear its validating to see so many unspoken concerns and thoughts ive had explained in such detail.
To try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/ThreatInteractive . You’ll also get 20% off an annual premium subscription.
PLEASE READ FOR UPDATES & RESPONSES:
1. Watch this video in 4K (as in streaming settings) as any lower compression will hide the visual details discussed.
2. We would really appreciate it if viewers could share on *giant game related subreddits. These prevent self promotion but these can really push our channel's success by the thousands.*
3. Some clarification on what was mentioned at 1:46. Sometimes when starting the game, CPU issues cause the frame rate to stay around 35-38 FPS, even though the GPU has room to perform better regardless of V-Sync. Other times, after reopening the game, the CPU issue goes away, and we can use the full GPU to reach the V-Sync limit of 60 FPS. We’ve even hit 72 FPS with full GPU usage when V-Sync is off.
We have a few methods to avoid this CPU bug like making sure V-Sync is off in the save file, restarting the computer, and launching the game as the first application after booting up (other than Steam or related apps). Once the game is running in this better scenario, V-Sync can be toggled without problems, as long as it’s off before closing or saving.
However, when using Intel GPA, we can’t seem to get this "good" CPU performance, even with those tricks. This could be due to the complexity of Jedi Survivor, the profiling overhead or vendor application interference. Because of the 35-38 FPS limit caused by the CPU, we use the command r.MaxFPS 30 to make performance comparisons easier, especially when comparing with NFS 2015.
4. Here are the commands both UE4 developers and gamers can use with many UE4 titles.
r.TemporalAA.Algorithm 0
r.TemporalAA.HistoryScreenPercentage 200
r.TemporalAA.Upsampling 1
r.TemporalAACatmullRom 0
r.TemporalAAFilterSize 0.09
r.TemporalAASamples 2 (MSAA x2)
r.TemporalAACurrentFrameWeight 0.6
5. Why is using them in UE5 a bad idea? Because r.TemporalAA.Upsampling 1 in UE5's source code forces a higher value than r.TemporalAASamples 2 which means a higher r.TemporalAACurrentFrameWeight will display lots more jitter. Now if you can V-sync around 120hz, you might be able to get away with it. You can try these commands in UE5 without r.TemporalAA.Upsampling 1 but the reason thats enabled in the first place is for higher quality pixel placement.
*6. At 6:51, while the depth buffer is the only render target that didn't have a render target clear, our software still shows us that it's being written to. Please take this into consideration when referencing the performance shown.
* 7. We see some people complain about shimmer in the modified TAA. But people saying this are also the ones who are okay with massive amounts of ghosting and blur in the stock TAA. This portion is not accounting for the neglected content underneath TAA. As we stated in out FIRST video, clear TAA cannot fix broken effects and shaders that rely on smear. DLAA is an absolute joke in motion and the unique footage we showed shook Nvidia so much that they released a "fact or fiction" or in other words *damage control video* in just 14 hours after we made this video to relive non-blur biased views this video will generate from consumers.
*8. Some good news regarding UE5.5, you can use our TAA commands as long as the newly introduced r.TemporalAAScaleSamples is set to 0!
*9. Regarding the comments on the early Z pass, we're saying it's inefficient and the suggestions we made also imply a change to how we occlude objects using depth buffers.
*10. In response to Deveno linking our video out context(see our Twitter/X), we analyzed patch 9 to confirm those 8th gen optimizations did not make it to patch 9. The reason most likely is because the project for the 8th gen uses a very modified(optimized) copy of the the PC/9th gen version. Which means they would have to upload the 8th gen version on PC as a separate release or erase the current version on steam due to how unreal and steam work. This is backed up by the backwards compatibility videos showing the 8th gen version running on 9th gen consoles. All the bloated issues are still in the PC version.
*11. 🚨 Official Threat Interactive Discord 🚨 discord.gg/7ZdvFxFTba
*12. Stay Tuned.
I've tried r.TemporalAA.HistoryScreenPercentage 200 in Assetto Cosra Competizione and while it looked incredible, it absolutely destroyed my performance, if I understand correctly it's the equal of 200% supersampling, so you are rendering in 4K and downsampling to 1080p. Am I correct? But these are still very helpful, only r.TemporalAASamples 2 and r.TemporalAACurrentFrameWeight 0.6 alone does wonders to any UE4 TAA.
you sir are a blessing to everyone in teaching people just how bad modern optimization really has become
@@snesmochait's not just that, he actually actively teaches ways it can be better
What hardware were you running the game on?
Why do you recommend using Vsync and an FPS over 50 for the tweaked TAA to work best? I almost always rely on Freesync/VRR over Vsync nowadays, usually with an FPS cap which can reduce input lag if it’s ingame/engine.
These devs did brag about how quickly they put this game together. And it shows.
Its a shame. It really is a massive upgrade over the last game gameplay wise, but the performance is so, so poor.
I was about to post a comment mocking whoever at Respawn said that but then I went and reminded myself of the Jedi: FO release date, and they did very well with around 3 years of development time through covid (so not even a proper 3 years) even tho the game's performance is fucked. Shades of 7th gen era but they fell short. Sure bragging is out of touch but not sure what this comment is waffling about
LMAO, reading this right after saying that the devs were probably rushed is hilarious. Who brags about making a game in record time? Brag about how happy and comfortable the devs were while making the goddamn video game, it's hard mental work.
@@ShuckleII The people who brag about that aren't "the devs", it's management.
Modern game devs are horrible and also the work flows are beyond outdated. This is literally because working at a game dev is only what unlucky bottom tier programmers do.
This guy is basically confirming what we all suspected: as hardware gets better, devs get sloppier, and customers don't benefit.
Devs have less time and more pressure to make games faster. John Carmack wouldn't be able to deliver Doom and Quake today.
It's not the hardware's fault. It's rushed development causing issues
low level API's don't help, we've traded the security of a stable foundation made by a select group of experts for the vague promise of potentially higher performance if everything is made right everytime by an unrealistically competent dev
I would state it this way: tech influencers usually benchmark hardware, not software.
They always answer the question how well a GPU runs a given piece of software, and never do it vice versa.
Threatinteractive is finally someone who flips it, and benchmarks software on a given piece of hardware.
i like dijkstras view on this "when computers were small there were no problems when computers became big problems became gigantic it is indeed hard to make performant quality software nowadays
The best practices for TAA absolutely made my teeth grind when I saw that gdc .. it's like no one cares about how the game looks in motion, they only care about how it looks with a screenshot.
screenshots are what advertise the games jraphics
@@EyeOfJanuary That used to be true, but i think most people look at games pre-release via UA-cam now and the infamous bitrate hides the crimes.
The problem is that these studios hire mostly cheap juniors to work on these titles. More seasoned proffesionals are too expensive to keep on and are usually fired at the end of each project to start the hire cheap cycle again. Biggest offender in this is Forza. After every release the entire technical team is fired and the wheel is literally reinvented with interns and cheap juniors dying to prove themselves. The problem isn't studio laziness, it's incompetence and cost cutting.
Cost cutting and yet they still announce the budgets of hundreds of millions... I don't like to count someone else's money, but I'm really curious about where these budgets go besides the studio's CEO's and directors' pockets. Or rather what's the percentage of the budget that actually went into making of the game.
and those poor juniors have no real mentorship or help, they have to fend to themselves completely cluelsss.
@@Hirokuro_Asura They probably do something like your state government does. Cut corners on projects, leftover money goes to general funding, and they siphon that general funding into projects they want that will line up their pockets.
It could be both as well!
over 5 ms for basically static lighting is insane. in an optimized game 5 ms are the entire CPU frame time.
The video analyzes GPU time, not CPU time.
5ms means nothing, "poorly optimized" games from a decade will run like that on modern hardware. If you shipped a game on a console, that outputs 4k 120FPS, and it runs its frames at 5ms, you still left 3.2ms on the table that could've been used to improve the visuals or image quality.
What matters is not some arbitrary frame time, it matters what the cost for the resulting visuals is, and yes, for many titles, that's underwhelming.
@@Aidiakapi Lol no
Game dev here. It totally depends on what type of game we're talking about and what graphical settings. A game like this couldn't possibly hope to get an entire CPU frame down to 5ms on modern hardware. Around 3-5ms CPU alone would likely have to be devoted to just rendering-related tasks such as culling, submission to the GPU, read-backs, UI updates, etc. And that's none of the gameplay itself, or any other underlying systems like scheduling, audio, etc., which you'd be looking at probably at least another 5ms+ for that. General optimization only gets you so far, especially when we're talking about something that's multi-platform and running on a bulky 3rd-party engine. Maybe, just maybe, they could've spent another year or two doing nothing but optimizing the hell out of it to get it running as perfectly as possible on all platforms, but that's rarely economically viable, and it still wouldn't hit 5ms, especially not if they're using UE Blueprints.
All this is to say, yes, the game is poorly optimized, and should be better, but saying a large game like this could have ever possibly hit 5ms CPU time on modern hardware is completely unrealistic. And even if it was, it wouldn't matter, because the GPU time would still easily eclipse that. In principle, yes, there's usually a way to get it done, but it's rarely feasible.
@@Frisbie147
RE: he doesnt even realise that the game already has the rtao that he recommended
It's not RTAO, it's GTAO and mentioning unreal's implementation isn't worth our viewers time because it's a slow and poor implementation.
@@Aidiakapi but the point is that it's 5ms that's almost entirely wasted/needless, in this case, a _third_ of the total render time
and anyways, ideally there is some headroom so particularly intensive scenes/moments don't stutter
DLSS 5.0: render one frame per second, and interpolate the rest.
DLSS 6.0: use generative AI to imagine what _that_ frame would probably look like.
DLSS 7.0 uses You to predict how the game should look like!
@@testplmnb aka just read a book. :D
@@Teasuti DLSS 7.0: Your own imagination
DLSS 8.0: Forces you to blink to stop rendering in each frame your eyes are closed
DLSSX Requires a separate AI card.
The voice the industry needs to hear.
@@aicraglednay Thank You so much!!! We are honored.
19:41 Holy crap, I’ve wanted something like this the moment I turned on per-pixel lighting in Dolphin. It has always bothered me how we’ve basically solved the smoothness of a model’s surface but we have nothing when it comes to the paltry few edges, as usual this issue was solved in 2008 and nobody ever heard about it because of the chaos of information.
Haha “nobody heard of tessellation” lol. Right.
Tessellation is much MUCH less optimised than topology, very complex to iterate modelling wise(for saving, what, few k of poly?), and prone to tank games due to shoveling un-checked amounts of dynamic geometry in the rendering pipeline. As proven by crysis2.
Oh. And since it is not topology, every detail stretches the 2d textures, rendering it useless for any real detail other than noisy stuff like sand, rocks or asphalt…
It is also problematic to use in many modelling styles and level design.
I a web developer so I have little knowledge about these topics. But I research them after watching and more and more i Understand why games have been so heavy lately, especially UE games. Thank you!
Make badly optimize games.
Have big corporations sponsor your AAAA games.
Encourage consumers to buy the latest hardware.
Profit.
Money flows in a cycle, with big engine companies like Epic being in bed with many industry leaders, to gain wealth and power.
You can't gain power through humble interactions and niceties.
In my whole UA-cam life I have never hit "subscribe" so fast. Looking forward for more.
TAA is indeed being butchered - Hell Let Loose has multiple TAA presets, but none provide good AA. The community found a good preset that produce better results than the presets provided by the developer. Fortunately, the developer listened to the feedback and included the community preset along side the other presets (unfortunately not enabled by default). For a PvP shooter where every moving pixel is important, this is extremely valuable.
I luckily found the "Community TAA" option by chance. I was using the standard TAA and it looked... odd especially when aiming near windows. Searched around and found the Community TAA tried it and it did way better.
Anti-aliasing ghosting must be garbage when you're trying to determine the exact shape to aim at in a competitive shooting game. And I'm annoyed at it without playing shooters.
The only good AA is SSAA
Taa is the worst thing to ever happen to video games. Ps3 games at 720p look miles sharper and more stable than most games at 1440p with taa today
@@testplmnbhave fun running anything modern at 40fps
the most interesting parts of these vids is the breakdown of the pipeline and all the stuff that happens, just fun to learn about
This dude gives vibes of a person who does work of four people better than the ones who currently does it, and this people come to you complaining he has "bad attitude" towards them.
this is a common ego issue in the dev space
This content is in a new level of quality, please keep pushing stuff like that! :D
Agree
So most of the optimization techniques are things that already exist in many older engines, such as the legendary CryEngine tessellation? Engines and devs really are developing backwards...
First of all. The old toy is not as interesting as a new one.
Second. Modern development is artist driven, so basically engineers are trying shove in ridiculous models and gorillions of autogenerated shaders and choose the most bruteforce and foolproof methods.
@@SuperXzm Pretty on point. We used to talk a lot about TECHNOLOGY, nowadays it's just needlessly high-poly models shoved into everything, and everything else took a nosedive.
It's important to also be aware of that old tech which seemed good at that point actually had many limitations and didn't actually scale well. Tessellation is one such thing. It actually worked very poorly in most cases. There is a reason that a lot of terrain solutions does their own tessellation, and why we got the mesh shaders instead. But neither tessellation nor mesh shaders work well with ray tracing and they need speciall pre processed data. There are many things left to figure out. Modern rendering can do a lot of cool things, but it's also very complex to combine and use all of it together.
@@Girugivery well put analysis
They used Unreal Engine.
Which is to say, they used someone else's general purpose off-the-shelf engine.
Which is to say, they're not in the same league with the sorts of developers who have in-house engines.
Is this an oversimplification? Yes. But it's a youtube comment, so who cares.
I wish all games were as polished as this dude's face. Not dissing. He is taking care of himself. I've never been this well put together in my life.
Is it not a computer rendering...?
@@aregranhaug8617 No, Kevin Jimenez is a real human. I work with him. He works out, does not drink or do drugs. Italian, Spanish heritage & of course American. He is a VERY hard worker and he deserves so much support.
You got my sub by 15 mins, this is the content Digital Foundry is missing.
I look forward to more technical deep dives, get more and more deep on the subject!
Thank you! Share in popular discords and gaming subreddits!
Digital Foundry is a bunch of tech fans being fan(boy)s, not a bunch of tech experts offering critiques.
0:45 - LOL Redditors are bootlickers, they'll tell you the FOX engine looks terrible and only runs well because MGSV is a desert, while under the same breath giving Epic Games the glaze constantly. Two PS3 rhythm games (The Project DIVA F games) locked itself to 30FPS compared to the 60FPS in previous entries, and was one of the first games to be emulated on RPCS3 with high framerates, and it didn't use any of the SPU cores that the PS3 had. I don't buy the "Just because it's on consoles, that means it's magically optimized" narrative.
those arent bootlickers, those are just stupid.
bootlickers can be smart. those people arent.
It’s kind of nuts that DIVA F and F 2nd didn’t use one of the PS3’s main features when it was exclusive for that platform. Now that I think about it, I think X ran at 30FPS, too… or maybe that was only on Vita… I don’t really remember since I dumped it after Arcade came out.
@@AROAH X ran at 60 on PS4, only on the Vita was it 30.
@@AROAH X only ran at 30FPS on the Vita. The PS4 had upgraded visuals and ran at 60FPS.
fox engine does look like shit tho, I think at least in mgs5 it uses reinhard tonemapping like it's 2003 for some damn reason
Need more of such content. UE5 being more widely adopted is a disaster. People are made to believe that snake oil solutions like upscaling and frame gen is the way forward and I'm glad there are at least a few of us who can see through this BS.
I remember in 2019 when 'Upscalling' is a premium feature that only the latest gpu (rtx 20 series back then) can only achieve.
But nowaday games looks absolutely dogshit in performance if we disable upscalling. The latency in Frame Generation is also laughable in the current state.
I don't know why nvidia & amd pushing these feature, as it is still premature in reaching the desirable graphical videlity... It even makes the whole debacle of Stagnation in current console generation.
@@nickochioneantony9288"only the latest gpu supports this"
Sees backlash.
Brings feature to backwards compatible gpus.
Yes its all for profit.
Why AMD and Nvidia does this?
Blackrock.
Tin foil hat as it seems, a narrative and motive is needed to be ambitious and influential.
@@nickochioneantony9288 AMD does it because nvidia did it, and people stopped buying AMD GPUs because they didn't have those features.
Also upscaling is a great way to get more fps without throwing more hardware at it, the problem is that game devs now assume that it will be used so they put even less effort into optimizations hoping that upscaling will pick up the slack.
@@dra6o0n lol what? amd did it because nvidia did it, thats literally for profit.
I'm glad for people able to call those things out because, even though I can notice something is off, I can't tell properly what is wrong.
Some notes:
depth prepass cannot be a different resolution use different geometry, because this woild cause black artifacts. The prepass is also used for fragment culling afaik.
Gtao is on unreal, but has smearing issues and does not wprk well with dithering and depth blending - and depth blended materials would render as dark blobs. There is also a bug in ue4 that causes gtao to essentially not work, that the fix needs to be backported from ue5.
Temporal aa upsampling is unnecessary for most uses and imo is too expensive to be worth it, unless you are rendering to a lower resolution (which ue5 uses by default, thanks to its superior upsampler)
You can implement a technique similar to the face culling you described, it cam help with the reliability of hardware occlusion and precompited visibility, but because you cannot prioritize certain objects in the prepass over others. You could use unreal's software culling set to only use those objects, but really the cheapest solution is to use smartly llaced distance culling volumes calibrated based on the distance.
For some features, the full depth prepass cannot be disabled as it is used for other things.
GTAO is in UE, but it's pretty slow with reference.
You can even find mobile implementations but not in unreal.
There was mod for GTAO in Survivor, I tested it and it worked, the visuals in open environments are surprisingly close to Ray Traced ones.
I'm slowly getting into graphics programming and this is really educational
I like the idea of an "occlusion potential" for determining whether meshes should be included in the depth pre-pass. The volume of the mesh might be useful (assuming all meshes are "airtight" without any missing faces - or a heuristic approach could be used to guesstimate virtual faces when calculating mesh volume) which would be stored in a table on the GPU. Then the omission of the occluder from the depth pre-pass would be dependent on the mesh's volume divided by the distance from the camera (and scaled by the tangent of half the camera FOV angle, etc). However, if there are a lot of open meshes used for things like wall pieces and whatnot, that are just a bunch of front-facing triangles and not a closed airtight surface manifold, perhaps the mesh's total surface area would be better instead? Surely there's a combination of mesh size, volume, and surface area that would be a good heuristic for which meshes should actually be used for calculating the occlusion potential. Just using the AABB of a mesh, or the spherical size of a mesh (i.e. center of min/max AABB and distance to farthest vertex) doesn't account for meshes with a lot of holes/cracks/gaps and would still include them in the depth pre-pass. This is something I'll be thinking about for a while.
For cylindrical object rendering it seems like some kind of "beam particle" representation could be used instead, where you're literally just passing points along the axis of the geometry to the GPU and it's generating a screenspace triangle strip that has the proper cylindrical worldspace coordinates and texture coordinates calculated for each fragment to create the illusion of a cylindrical object conformed along the polyline. This would require some maths to accommodate for perspective projection so that the illusion doesn't fall apart as the camera moves closer to such geometry, but I believe it's something worth looking at.
At the end of the day though, it's really the lighting compute that is the meat of this game's frame time and it would be a lot of fine-tuning all of the other phases of rendering a frame just to squeeze out a few more fractions of a millisecond per frame. These guys didn't write UE's renderer, they just made a game with it - and likely didn't respect hardware limitations and performance as much as they should've.
I also wanted to say that it's important to distinguish between frustum culling and occlusion culling. Coarse occlusion culling on the CPU can go a long way when there is a lot of individual geometry in a large scene, and it's something that a lot of modern engines completely forego - instead relying on the GPU just having thousands upon thousands of individual meshes thrown at it for it to contend with. The Godot game engine, for instance, had zero occlusion culling for a long time (after it had gained 3D rendering capability) and relied exclusively on frustum culling. Back in my day, you didn't have a game engine unless you had an occlusion culling algorithm. Heck, if all you had was an occlusion culling algorithm then you had the central core foundation of a game engine upon which the rest of its bells and whistles could be built. I couldn't believe Godot was a 3D game engine with zero occlusion culling whatsoever, and calling itself a "game engine". Anyway, I digress...
I think it would've been useful for the curious newbies out there if it had been made clear that the "depth mipmap" and "HZB" are one-and-the-same. HZB = Hierarchical Z-Buffer, where a max() miptree is generated from the depth buffer by taking the largest value (i.e. the closest Z value, because depth is stored inverted, as 1/Z) out of each 2x2-pixel area of one mip level to be used as the depth value for the next higher mip level's pixels, rather than averaging them together like a regular mipmap. I don't think you need to explain all the ins-and-outs of graphics rendering, but it's my opinion that people who are still learning would get more value out of your content if you pointed out the non-obvious. Instead of saying "HZB" just say "hierarchical Z-buffer", for instance. I think that this more informative content could be made more accessible, in terms of its informational content, to the audience that existing tech tubers have. I, for one, am tired of just seeing framerates, but then again I've been a graphics coder for 25+ years :P
I look forward to more videos like this :D
Thanks for a very detailed video.
There are a few points I would like to add.
- Depth prepass became a new standard whether with occluder meshes or actual geometries or reprojected from the previous frame (see GPU-driven rendering pipelines). It often makes things faster (but not always). It is also mutually exclusive with occlusion culling. You can use both.
- Tessellation doesn't work well with reprojection algorithms (TAA, ...). The tessellation makes it very difficult and expensive to calculate motion vectors between two frames.
- GTAO is great but it doesn't solve blurriness. In GTAO's presentation (page 96 "spatial denoiser details"), you can see that the final SSAO they use is as blurry as SSAO in NFS.
- Biggest downside of GI algorithms (PRT / Precomputed Light Probes / Voxels) that require baking is time. It usually takes many hours (can be a day if your scene is big) before the artists could verify their changes. Nowadays, the gaming industry is less and less profitable and they have to ship the game faster. I can understand why they'd go this route.
If you mentioned these things in video but I missed it, I would like to apologize in advance.
I appreciate Cal having the courage to speak up about his in-game performance.
Presumably doing a full depth pre pass allows them to render the material pass with the depth test set to equals, ensuring that every pixel only has expensive material logic applied once.
Could you elaborate on your presumption please?
I may not understand but you've piqued my interest.
@@jonathanlebon9705 the idea is that once you have a depth prepass you can draw your objects with depth testing set to equal. Only fragments that get rasterized at the exact depths as the fragments were during the depth prepass can be allowed to render by the rasterizer. This means that you negate all overdraw, you can skip doing fragment discards (because it can be done in depth prepass) (this saves you shader permutations and ensures that EarlyZ stays working on most hardware) and alleviates you from drawing objects strictly front-to-back (so you can batch them by PSOs and not switch them constantly).
It's problematic when the main character's actor knows more about game optimization than the developers.
😂😂😂😂
😂😂
I actually considered you were legit because of how similar they look XD
I had to check!
If I didn't watch Cameron on Shameless and Gotham I'd of been so confused to see someone who looks like him ripping into the game
I've struggled to conceptualize what a good typology could look like when the object could be viewed from any angle, so when you criticized it here I wasn't quite with you but curious, then you pull out camera based edge tessellation. With my limited knowledge at least, that seems like a great solution. Really won me over right there.
Cal Kestis out here tearing down his own game
Bro switched to the dark side💀
First video of yours that got recommended to me, im intrigued. Thanks for the insights!
great observations and explanations , these are fantastic ! lots to think about . at 17:39 the idea of using blockers for early cheap culling reminds me of how "portals" were used in BSP engines , and other very controlled methods of occlusion optimization like precomputed "Potential Visibility Sets" . it does seem like there is potential to revisit these concepts from an automated approach like how Hierarchical LODs distance is calculated , a simulation of the gameplay and possible view angles could generate the PVS along with help from level artists placing "occluder" objects like the walls you mention .
the distaste for temporal AA is understandable , mainly because of how intertwined now it is with other systems and how every vfx / shader is tuned under those conditions , that to change away from the blurry softening temporal AA has to fix the look of the environment can often then make the vfx and shaders that were tuned UNDER TAA look incorrectly intense and deepfried as the artists were making adjustments to try and overcome the TAA blur .
Very easy instant sub, I'm a bit out of practice with game dev since working elsewhere after University, but this stuff is gold and I look forward to seeing you grow your catalogue.
1700 drawcalls ,
That’s pretty well optimized!
Culling by layer and size is an option but with hundreds of people adding assets until the last moment , breaking optimization techniques is pretty common. Everybody project start with really good documentation until dead line 😢
Crunch tends to do that
how about 1 draw call 😂😂
@@botbeamer just bake all static 🤗
At a certain point draw calls are no longer the bottleneck.
I don't understand everything but .. I like this content. It goes much deeper than any so called "tech channels" out there
Keep it up
I have to point out a few things regarding the TAA.
- r.TemporalAA.Algorithm ; this setting controls whether the game uses TAA Gen4 (0) or Gen5(1). Gen 5 is a newer form of TAA that has better coverage, less pixel shimmering and better image clarity. But it costs more. Depending on the GPU, it can drop performance by around 10%.
- r.TemporalAA.HistoryScreenPercentage ; from my experience, this setting does nothing in most UE4 games. UE5 has a similar setting, that actually works and improves image quality. A value of 200 has become the default value since UE5.2
- r.TemporalAA.Upsampling 1 ; This is already the default value for UE4. But considering that you are using native resolution, it does nothing. Should be used with r.ScreenPercentage to define the percentage of base screen resolution.
- r.TemporalAASamples ; This is not MSAA. This is the number of jittered positions for TAA. Default is 8 in UE4. From my experience, higher values result in a sharper, more detailed image, but with more pixel shimmering. Lower values result in less pixel shimmering, but a blurrier image. I prefer a value of 4.
Best regards
r.TemporalAA.Algorithm is the TSR prototype and has significantly blurred motion.
HistoryScreenPercentage 200 and Upsampling 1 is why we end up with 4k buffer. It absolutely has impact on quality, it's even stated in the TAA paper by Brian Karis. These two benefit motion, not still camera scenes.
r.TemporalAA.Samples 2 and 4 uses the same sample positions as standard MSAAx4 or x2.
For instance Decima's TAA alternates between two sample positions like r.TemporalAA.Samples 2 but doesn't use the standard MSAAx2 sample positions.
@@ThreatInteractive I found that TAA Gen5 has much cleaner image and fewer ghosting artifacts. Mind you, I always disable motion blur. Always.
I have never seen a UE4 game benefiting in image quality from HistoryScreenPercentage 200. Of course, I have not tested all games.
MSAA samples the edges of polygons at a higher rate. TAA samples neighboring pixels.
This why MSAA has a significant cost to performance, while TAA is close to being free.
@@winj3ryou didn't understand what he was trying to say based on your MSAA comments. He's not saying the sample setting is MSAA.
Also history screen percentage makes motion clearer, I've tested it, it's an objective benefit. You need to do motion tests.
I thought TAA always jittered using a halton sequence
That was awesome. Please more of these full-frame breakdowns
Sometimes it's hard to understand Epic engineers. Unity added APV(Adaptive Probe Volumes) for baked lighting and rightly so. Unreal is actively going to mobile, but does not offer the same technologies. All that remains are unfinished Volumetric Lightmaps, which are mainly for moving objects and cannot replace lightmaps for illuminating the entire scene. It's funny
but Unreal has Lumen and it works great and it already has spherical harmonics and information about the color and reflections of the scene, but for some reason Epic don’t want to add a static-baked mode for Lumen, especially since UE already has virtual texture technology. This would be a great replacement for Volumetric Lighttmaps for all the lighting in a scene.
You should watch the new UE5 demo thing they posted :D
@@aoqia Did you see something there similar to what I wrote about? Megaliths is mainly for video cards with DXR support. Also, if the game is corridor or you need several dozen lights, they are of no use, turning them on can even eat up more productivity than regular lights.
Because it will optimize lumen and make it cheaper to run. If its "too cheap" then people are less likely to need to upgrade.
Corporate CEOs and shareholders are interconnected in their network of wealth, they like to maintain that power and wealth, not to dilute it by making everything easier and better for consumers...
Elon Musk had his text message leak years ago, you could see how his ultra rich friends throwing money making ideas at a wall to see what stick, some of those ideas are essentially anti-competitive and unethical.
So do not assume CEOs and corporate business owners or the likes to be of the same mindset as consumers.
@@dra6o0nPeople with weaker recent cards will just throw upscaling and frame gen at the problem until the game becomes playable, not go out and buy a better GPU.
@@marcelosoares7148 Because the issue is that games that barely have higher fidelity than last gen doesn't need to be upgraded with newer hardware.
It's a lot of bad optimizations and computing thrown in to automate and speed up development.
thanks Cal
single handedly tackling the whole gaming industry, with engines and hardware alltogether, fucking legend
The fact that modern games like this are so sloppily made, with glaring artifacting even without TAA is honestly disgusting and a major brewing accessibility issues for people sensitive to noise. Not to mention people who can get photosensitive epilepsy too...
Also TAA blurryness + 30fps genuinely makes me motion sick
You are so underrated never stop doing what you do
I'm begging you to do a video on The Finals.
It's weirdly CPU heavy, and definitely has that TAA slop, but otherwise the visuals in that game are actually incredible. I feel like it's one of the few titles actually taking advantage of UE5.
I'd also really love a dive into how they're doing motion blur.
It's literally the only game where I prefer to play with all the effects on at max settings, even though it's a fast paced competitive title and I'm definitely losing out on frames and clarity by having everything cranked.
Love the content! What would you say is the best TAA in a game without doing a custom change in a config file or using a mod?
OH MY GOD YOU SMILED FOR THE FIRST TIME DURING THE AD READ
As for stuff you said in the video, I still love the TAA hate, and the idea you propose at 17:36 already exists in the Source Engine, it's the Occluder texture you can put on brushes, mostly behind walls
Amazing analysis, love this type of content.
Good work bro! Keep it up!
men diginal foundry need to see this dude
They would disagree, they are pro-TAA :)
I doubt it's in DF's interest to expose how devs are getting sloppy or are colluding with hardware companies to make people have to upgrade more.
@@RADkate *videos
@@RADkate I mean, PC Gamer doesn't review PC port quality anymore and they only spit out an article about it when a game gets reviewbombed and they want to spin the "consoles good, pc gamers are pathetic gamergaters" crap.
@@HankBaxter Majority of money is made on the console side, but you can keep spewing this conspiracy.
Devs expaining why they need 200k tris to render a cardboard box:
Proper implementations of TAA will typically employ a form of contrast adaptive sharpening (e.g. AMD has a quite good open source algorithm for this). Since TAA can soften the image somewhat doing this right can produce results that look closer to raw native but with much much better anti aliasing and all at a reasonable cost. UE4 games I’ve noticed don’t seem to do this out typically. DOOM Eternal is a title that actually does have great TAA and provides a sharpness slider as a separate example. TAA is an oddball because there really is a “correct” way to do it and an incorrect way and there is variance in implementation. Poor TAA solutions can be very rough but the good ones are far better and produce high quality anti aliasing with generally great coverage for a small fraction of the cost of older techniques.
CAS is so nice , doesnt fuck over text and ui elements with this weird artificial artifiacty look some other sharpening post processings have
Please do more of these analysis videos! Very informative and accurate. Silent Hill 2 remake is my suggestion, I only have an AMD card so I can only access so much info from the game. But still very interesting, as I worked with Unreal for years too.
Man, I wanted a channel to do these kind of analysis for ages now, thank you bro for actually doing it, and explaining everything in detail.
Do you accept suggestions? I'd suggest Source Engine, for example, I always wanted to check their render pipeline, specially compared to the new source engine 2 (see cs2 compared to cs:go, for example, where the image quality 'doesn't seem' to be a lot better, but the hit in performance is big)
Subscribed, wow. Great video. Looking forward to you getting to tear down Monster Hunter Wilds. (aka recommending 4070 for 1080p60 medium settings with frame gen)
I think this type of a video would be interesting for Doom Eternal given its insane optimisations.
Doom use ID tech in-house engine, which is why it passes the nature of blurry image of UE.
The RT feature of Doom Eternal is also smoke & mirror.... it literally only works on mirror reflection & metal based weapon, other aspect as lightning is not affected.
But other than that, it was well optimized, it was pre-2020 so I guess the proper devs were not laid-off yet at that moment.
Basically the devs of Doom are actual engineers who knows their stuff.
Some game studios and built in engines like Bethesda are mostly artists.
Epic, are more like... Consultants. They have engineers but technical know-how isn't needed to sell their product. Their engine is developed to be spread and garner profit, while Bethesda and ID tech doesn't sell license for the engine.
@@nickochioneantony9288 Id tech engines have always been the gold standard for optimization its how they were able to exist to make commander keen doom and quake and they keep that as a priority for their company epic does what they have since unreal in 1998 prioritize graphical fidelity above all else
@@dra6o0nWell, proprietary engines like id Tech are made for a select few games, and their entire rendering pipeline can be built just for the needs of that game. For engines like Unreal or Unity, they need to support ANYTHING; it can run anything and look good, but when it comes to absolute top-of-the-line work, it won’t be as good as an engine that can tailor its work just for specific games.
id Tech 7 is perfect for complex fps games like DOOM Eternal. But what if you tried to use it for GTA 6? Totally different format, different scope, different content scale, and different requirements.
This problem was famously encountered by teams trying to adapt the Frostbite engine for racing games at the request of EA.
You know someone messed up when your game gets compared to a game in the Frostbite engine. And comparing a UE game in a genre that UE was designed for to a Frostbite racing sim...? I mean, the NFS series was the reason Frostbite's source started to turn into spaghetti code...
Absolutely phenomenal content. Subbed plus hope the industry pays attention
Good vid as always man.
incredible in-depth video, congratz!
3:10 PREACH. "AI" is a scam
Babe wake up
Threatinteractive just posted
You have taught me so much about graphics and optimization
That’s really a thing the industry should do
Thank you for this!!!
I'm learning how to program right now and I have a new goal, learn how to optimize the shit out of games.
I wish I could apply your TAA settings for all my games 😅
I'm still just waiting for games to look as good as the tanker mission in MGS2 did back in the day.
Outside of the TAA part, which is subjective, and in my opinion, the modified TAA looks much worse, as it reintroduces pixel shimmering without significantly improving image clarity. That said, the video is great, and the technical details were well explained. Great job!
Thank you for your work. Your videos explain a lot. Can i suggest creating a course (or several) in unreal engine and/or unity optimization? Those two are among most popular engines not only in the big studio environment, but also for solo and indie developers. That is one of the least present topics on the tutorial sites and it shows by the state in which many games are released . More and more games are created by hobbyist and/or the hobby of creating games becomes a career path. Good habits from the start will be of benefit for the gaming scene.
Every time I scroll on my feed this video pops up with a different thumbnail. I'm starting to question reality
I would be interested to see you do a vid on hydroneer's issues such as the light collisions or something related that noticeably hits the fps
Keep on making these videos, man. All of this needs to be talked about and one cannot rely on nor expect certain other outlets to do them.
Thanky you for this very informative video!
Excellent video.
You have impressive knowledge for someone who looks so young! How old are you? Great video.
Really good stuff. Keep it up.
Great video, as usual! I have a video idea for you. Depending on the original game engine you are testing, you could recreate a similar scene in Unreal or Unity or flip it around to add a challenge. You can just implement all your ideas and then compare the results.
This is the standard Nvidia "optimizations" new games get to force us to require DLSS and frame gen
Each new video gets better and better. Im a hobbyist but i learned alot from your videos, great technical analysis and presentation.
Amazing and thorough breakdown.
At 14:33 it would be cool to see a vertical graph, with horizontal bars that appear at the same time as the text, their length proportionate to the listed milliseconds on each line.
TBH I personally find it weird when you say "we" all the time but it seems like mostly your personal effort and script.
Its "we" because the presenter is representing his team.
Holy shit cant wait for the Monster Hunter video in a few months
subbed !
Really great video
I'd love to see a tutorial style video for how you dissect theses games, the things you look for and how you interpret the results.
Preach brother!
Good breakdown, subbed
I'm actually curious as to how these extra passes are extracted from the captured scene. The breakdown is amazing, by the way; same as the NFS one!
I am not sure what software they use but RenderDoc gets you basically the full breakdown of a frame. But I am assuming there are unreal specific tools that give more info.
@@redotix9952 I see! That's super cool. Thanks!
Each hardware vendor also has their own software that hooks into their hardware's performance metrics. AMD has Radeon GPU Profiler, NVIDIA has Nsight Graphics and Intel has the Graphics Performance Analyzers suite, which is what he used in the video.
hey, love ur videos so far, it would be cool if you did an analysis on starfield / creation engine draw pipeline
Great vid ! Always fun listening what you have to say on game optimization even though I sometimes don't get it but I'm slowly getting there haha, can't wait for the channel to blow up :D
Looking forward to an anti aliasing specific video!
The more I watch these videos, the more I respect people who work on graphics for AAA games. Each of the mechanisms you mention almost seem to have a world of complexity, and then there's devs that combine all (probably most) of them perfectly.
I really think a lot of it is about giving experienced developers and artists enough time to make all these adjustments.
I’m curious as to whether the seemingly ludicrous triangle count in the wireframes shown in this video are a result of having too few artists being forced to crank out models far too quickly and not having time to properly fix them up.
Great Content!
Hey, nice breakdown of performance. Which tool are you using for frame capture analysys?
Please upload regularly brother. You are awesome.
No, he should not upload regularly. Let him cook.
Twice a month is ideal, once every 2 weeks. Once a month if he really needs the time
I'm not convinced by your modified TAA - it seems to cause major aliasing issues?
Yeah, unfortunately I don't really think UE TAA is.... salvageable.
There's a bit you can do, but sharp motion clarity without severe jittering & aliasing isn't one of them 😬
And believe me, the community has tried with all sorts of tweaks, but you need to choose either of those 2 sides.
@@MLWJ1993 Seems like highly detailed geometry comes at the cost of more aliasing at the same resolution/overdraw, and the larger the native screen resolution the better the GPU utilization. Seems like a faster GPU pipeline over more Smid chunks, would help. Which could explain AMD GPU's propensity to scale much better at lower resolutions like 1440p-1080p (ignoring driver overhead)
This full depth pre-pass is illegal. There are so many established ways to cull most objects being rendered to the depth buffer: PVS, Hierarchical z-buffer occlusion culling, Coverage buffer, etc. For crying out loud there already generate a depth hierarchy; Hierarchical z-buffer culling would have been the most logical thing to implement.
They are doing full res depth pre-pass that we will never see, but the actual visible elements like SSAO are rendered in like 240p. fucking lol.
Well, you don't see what the CPU side pre-pass already decided not to send.
Ok mr youtbe commentator. All rendering engineers using depth prepasses for decades were just stupid, should've listened to you - a person who never created anything but watched a youtube video.
@Genebriss You wouldn't know this but I am working on my game engine so knowing things like this is important for me. Who said that a depth pre-pass is bad? Of course many games have used a depth pre-pass. But they don't draw everything like is done here but only objects that cover most of the screen space. That's how other games have done their depth pre-pass.
There has to be other reasons they didn't do that, like making the game seem impressive, just generating buzz, good or bad, over how hard it is to run, or creating an incentive to sell more hardware.
To be honest, Unreal has some of those culling solutions already. Or similar enough ones that could be adapted for those use cases.
The problem is mostly workflow related. If you don't tag assets early enough, it's hard to add culling planes and similar things later (because of the scale of the game). As an example, flagging assets to be removed from depth pre-pass can be tricky, and you either have someone manually do it, or you do it when you establish the workflow, or you write an automation tool for that.
Totally doable, but costly. And, most importantly, the right people have to be aware of it.
I think there is plenty of room to learn from videos like this. But these ideas have to reach the content creation pipeline, and that's a gap hard to bridge.
These initiatives usually come from very proactive engineers that have to advocate for the extra work put into it. And, because the game is built in Unreal, most resources tend to be shifted from Rendering Engineers to Tech Artists or Artists - I think.
Usually, a central Team would have resources to work on such things. But they often don't have a say on content creation pipeline, that's game specific. So some proactive person from the game team has to bridge that gap again, and so on.
That's why it takes time to get this sort of improvement in games like this. You have to keep people around for long enough and keep track of these improvements alongside so many other things, so they don't lose visibility and get fixed for the next title.
I think every game could benefit from a really really polished vertical slice where all of these techniques are applied. Then out of those learnings you map all techniques and then try to scale those to an open world content creation pipeline.
Ironically the area at 4:05 was exactly the point where I uninstalled and got a refund. 1080p with a 4060 was not quite enough..
Wouldn't decreasing resolution in the depth pre-pass cause false-positive z-culling at edges? I think only using large objects (relative to camera) for the pre-pass makes the most sense for optimization in the depth pre-pass.
please keep talking about this, not only is it interesting to hear its validating to see so many unspoken concerns and thoughts ive had explained in such detail.
i love these more tecnical videos, i found a gem