I know next to nothing about audio, can I do that filter in youtube editor?

@@bazhenovc754 pretty sure the youtube editor just lets u throw on music. but for future reference, any semi-proper video editing software should let u do it w/an audio effect

I think we've pushed our luck with AA for too long and have to face the simple fact: we cannot generate data where there is none. I was wondering a while ago why you get AA for free with path traced images, until I realised there are 50+ samples per pixel so it's basically 50x SSAA. TAA attempts to get the extra samples required for SSAA from adjacent frames whilst neglecting the integrity of motion, and FXAA is just a post processing affect that basically applies a smoothing filter to edges: absolutely no substitute for the real thing. The only real options are MSAA, whose image improvement vs performance impact scales rather nicely. Or AI upscaling/frame generation featuring a temporal component, which could do with some improvement, particularly with AMD.

Unreal Engine 5 does look better than crisis 3 by miles, and it does break some of these rules.

@@DrTheRich Texture resolution? Sure. Gloss accuracy on materials? Crysis 3 still looks better. And MSAA 4x blows TAA away not to even mention 8x.

@@eclipsegst9419 KZbin keeps deleting the lengthy reply I've typed for no reason, so you're in luck. Anyway, if you are comparing an 11 year old crysis 3 demo to a recent ue5 demo, and come to the conclusion crysis 3 still looks better, I can't help you... And no, it's not because of texture resolution.

@@DrTheRich I said the vegetation and material handling was better. Not the entire experience. UE has a poor PBR system that's why everything looks like plastic. UE also only offers FXAA and TAA, both very crappy forms of anti aliasing. Sure Crysis 3 doesn't have RTGI, but the remaster does and CryEngine 5.7. CryEngine got SVOGI running back when UE4 had failed to make it work at a playable framerate. Now Lumen also tanks frames but they just tell you to shut up and use DLSS. UE is an arena shooter engine it chokes on open worlds unless you make them as cartoony as Fortnite.

I'm not saying high framerate is only good for input latency, I'm just putting an emphasis on input latency. I wanted to keep the video small and focused.

@@bazhenovc754 fair enough

He never said it was the only reason. He said it was the MOST important reason, which is true.

@@MHjort9 imagine being so full of yourself that you would openly state an opinion as fact. I think they are of equal importance and input lag isn't allways tied to framerates.

@@brett20000000009 Framerate is not the only factor but it always influences input latency and always will. In some games it's less important, but if you don't prioritize latency in fast-paced games you're doing it wrong, period. You can call it an opinion as much as you like, it's still the opinion of anyone who has standards.

VSync microstuttering is an implementation issue, I don't think you need to have a CPU side FPS limiter if the renderer is implemented correctly. I'm not against FPS limiters I just don't see a lot of value in it. Using 200% frame buffer defeats the purpose of TAA, that's basically supersampling and you don't need TAA at that point. It could be a good option for high-end GPUs but as of today 20% of PC market is still using NVIDIA 10xx series GPUs so I don't see that being a viable option anytime soon. To my knowledge, nobody is implementing TAA in the way that you described. There are several games that trade off AA quality to further reduce ghosting and it's usually a fairly reasonable tradeoff that comes at the cost of image stability. I still think that we should move away from TAA and temporal amortization, it's been around for 10+ years already and I don't see a lot of improvement there, the last breakthrough was AI TAA and it seems that this is the best we can do. Even with AI there is still tons of issues on translucent surfaces.

If an fps-limiter solves the problems of v-sync, why should we let it out? I'm talking about upscaling with 100% input and 200% output resolution. This is not supersampling, merely upscaling to a resolution beyond native (somewhat like DLSS quality + DLDSR, but more like 4x DSR + DLSS performance). Blur is a natural result of resampling over and over again in motion, but a 200% frame buffer slows this blur down a lot. Even with sub native input resolutions. The upscaling itself gets more expensive, but not too much: about 1.6 ms on my 3070 when upscaling to 4k. 4k is getting mainstream already, I only need 85 fps+ to use it with backlight strobing. Not because almost no one plays like this, but because I have never seen such good image quality and motion clarity before. It would be a shame to go back to 60 fps sample and hold, no TAA, because TAA has not been good in the past. Game developers just need to learn how to output the right motion vectors and make their games with motion clarity in mind, at least on higher end devices Of course, it is good to make games without relying on TAA as well. Fast paced games don't need a lot of detail and can do well without TAA. For dense foliage however, TAA is quite necessary for a pleasurable experience. I think it looks better by itself than no TAA, but it needs a 200% frame buffer to avoid headaches. A few traces of shimmering due to the TAA being as weak as sufficient should not be an issue. You would get them with less detail and no TAA anyway Also, I think TAA should be a personal preference for everyone. It's not something to forcibly enable or leave out completely. The last thing, unless you really know what you are doing

​@@normaalewoon6740 How exactly does an FPS limiter solve vsync stutter? You need to render consistently at your target refresh rate, if you can't render at 90/60/whatever the native refresh rate is then you need to query the graphics API for what lower refresh rates the monitor/TV supports and use that. Once the refresh rate is selected try not to change it at runtime. Using an arbitrary value as a frame limiter is plain wrong, if you just sleep on that without correct synchronization with the GPU then we're back at missing vblanks and inconsistent frame pacing. Alternatively the user can set lower refresh rate in the OS settings (on laptops or steam deck, the OS usually won't let you enter arbitrary values) and that would get reported to you as a native refresh rate and all is good in theory. Or you can disable vsync and just sleep on the FPS timing - this doesn't really solve any of your problems because the monitor cannot present frames faster than native refresh rates, so you still get bad frame pacing + inconsistent image tearing on top of that. Some users have a very strong misconception that disabling vsync makes the game more responsive (and a lot of games don't implement it correctly so this misconception is not entirely unfounded), so it's a good idea to have an option to turn vsync off and leave it on by default. Most users don't change the defaults so it's really important that defaults are good. Regarding TAA - it's an interesting take, but again I've not seen anyone else implement it the way you described and I cannot judge the quality of it without seeing some demos first. I'm open to changing my mind and reevaluating my position on stuff when presented with evidence, right now after 10 years of TAA my stance is that it's not good. Also 1.6ms on a 3070 is an exorbitant cost if you want to target 85Hz+ refresh rates - it's a very high end GPU, I've mentioned already that 20% of the PC market is sitting on 10xx series, maybe in a few years you could reasonably target 20xx min spec GPU but right now it is what it is. On a side note, I'm not saying that we should limit everything to 60Hz, I'm saying that we should not render at lower than 60Hz (unless the user specifically opts in for this). My personal preference is 120Hz, I think beyond that you're starting to see diminishing returns and it would generally be an overkill. VR needs more than 120Hz though because otherwise you get motion sickness, also you need to always present at consistent frame rate because again motion sickness. And you absolutely cannot have image tearing in VR because again motion sickness.

​@@bazhenovc754 When v-sync alone caps the framerate, it allows for CPU buffering. This takes some time and it causes motion problems, resulting in lag and microstutter. An fps-limiter disables this buffering completely and makes the frame pacing smooth and direct. I should have mentioned that I mostly use custom refresh rates. The default settings are too limited. Not only number wise, but also because they lack the high vertical total that I need to minimize crosstalk with backlight strobing. I use whatever framerate I can run stable at. Most of the time, somerwhere between 75-100 fps. However, some games only support fps-limiters of 60 and 120 fps In fortnite, you can use epic TSR. It has a 200% frame buffer and it's not blurry like all those bad TAA implementations in motion, especially with 100% input resolution. You can also use 4x DSR (0% smoothness) + DLSS performance to get 100% input with 200% output. Default TAA is much lighter than advanced upscaling and can use a 200% frame buffer as well, which may bring it to 2 ms on a 1060 when upscaling to 4k. It's not potato cheap, but worth using if you ask me I guess my playstyle is a bit more demanding than the 'sweet' 60 fps. I need a framerate above the visible flicker threshold, about 85 fps, without any framedrops. 60 hz strobing is flicker free for me with a much reduced brightness (about 30 nits), but I don't like it so I only use it rarely when I can't do better but still want to play 120 fps would be perfect for immersive types of games, while 240 fps is good for fast paced games. That does not mean 1000 fps isn't any better, in fact it's a lot better, but it's probably not worth sacrificing features for. There are other techniques to create a 1000 fps experience too. With an eye tracking device, it's possible to use eye movement compensated motion blur. Non-deformed frame buffer resampling based on eye motion is another possibility. It could replace strobing and framegen in the future

@@normaalewoon6740 With DX12/Vulkan you have explicit control over the CPU buffering and if you implement that correctly it's no longer an issue, you absolutely can do it without both microstutter and tearing at the same time.

I mean, FG kinda requires some form of TAA which is already banned and it has pretty bad artifacts at times. I'm not sure, I'm open to change my opinion on it but so far I'm not very impressed by the latest developments in FG.

@@bazhenovc754 Actually framegen doesn't require TAA at all, it's just most games that support it are using forced TAA or forced TAA while using framegen. I have used framegen with taa off and it looks way better, try cyberpunk with the config file changed to turn off taa and use the dlssg-to-fsr3 mod. I think you can also do it in ratchet and clank

@@brett20000000009 I didn't know that, I'll investigate it further.

That's a good point, I need to think about it. Maybe we can allow rendering translucent objects at a different resolution as long as it follows the general lower resolution rules? I want to test it and see how it looks in practice.

If you can compute it in 1 frame without temporal amortization - it is allowed.

This is a good article: gafferongames.com/post/fix_your_timestep/ It's about physics in particular but does a good job at illustrating the general idea.

For MSAA to work you need to have a low-poly geometry, otherwise the performance cost will bite you and it will be much harder to run at 60Hz or higher. SMAA was in my opinion the best non-temporal AA solution. This is a very good related overview: alextardif.com/Antialiasing.html

Can you link them here? I'd like to see them too.

​@@bazhenovc754 I think I sent it but the thing I was worried about happened. I think it detected it as a spam/bot message Regardless the two videos I'm referring to are "This issue is plaguing modern gaming graphics" and "Tech Focus: TTA - Blessing or Curse?". both are the top two results when searching "TTA" on YT

Thanks! Sadly I don't have anything to say about TAA, basically AI-assisted TAA is the only way to go because without AI the quality is just not there no matter how much effort you're putting into it. Specular anti aliasing in general needs more research I think, it was mostly abandoned in favor of TAA but I think there's still a lot of room for improvement there.

@@bazhenovc754 Very well said. I am getting uncomfortable from bad Temporal/TAA as my eyes cannot properly take blur generated on a display.

I'll copy my reply about MSAA from my own comment: MSAA is not better than TAA for several reasons: 1. Performance hit is too much on "modern" art - MSAA works extremely poorly when triangle density is high, in worst case with 4x MSAA you are hit with 16 times more pixel shader invocations if your triangle overlaps a lot of adjacent pixel centers, this can easily quadruple your frame time, especially if you have complex shaders. MSAA compression is also designed for large triangles, it doesn't work if your art direction needs high triangle density. This assumes forward renderer, with deferred you get all these issues on top of crazy bandwidth increase which is just not practical. 2. It does not address specular aliasing, MSAA works by computing a coverage mask for subsamples and stores the result of your pixel shader invocation for each affected subsample. It does not shade each individual subsample, it only interpolates the resulting colors. It's not supersampling, because supersampling would actually invoke the pixel shader for each subsample instead of interpolating it. There is another way to reduce shader aliasing by filtering your roughness and normal maps, this is called "von Mises Fischer" or "vMF" filtering, it doesn't completely remove specular aliasing but helps a lot with it. Some games do VMF with combination of something like non-temporal SMAA and I think it's a pretty good compromise (and doesn't need motion vectors), but you need a rather complex art production pipeline and someone who enforces art guidelines. This is often very expensive to do unless you have a strong tech art discipline in your team. AI TAA is not really that bad, give it a try. XeSS/DLSS have almost zero ghosting and really good image clarity and stability, they only struggle when there's a lot of translucency and particles on the screen. Now if you have a VR game your situation is very different, you cannot use TAA in VR at all because people will start throwing up when playing your game, so your only option is MSAA or SMAA. This severely limits what art direction your game can have and increases art production costs/time. And you pretty much have to implement a vMF pipeline in your project. FXAA is really not an option nowadays, it needs to retire with honor and dignity.

This was discussed in the video, 2 pass forward is generally faster than deferred. The cost of having an extra depth pass in a modern optimized forward renderer is lower than the cost of using that much extra bandwidth in a deferred renderer, especially so if you use the "stamps in 2D on the color buffer" approach - this will waste a metric ton of bandwidth. In order to for a deferred renderer to compete with forward at all you need to use a tiled deferred shading with a compute shader that caches gbuffer samples in TGSM.

You need to work on your listening comprehension, chief 🙂You are taking phrases out of context and constructing an imaginary windmill to attack, the phrase "cannot do this" does not refer to SSR and I explained earlier in the video what a forward renderer is in the context of this presentation.

He's saying that you need to produce TAA motion vectors and SSR normal/metalness/roughness. That's a G-buffer.

They've added a forward renderer because their deferred renderer didn't work in VR (too slow), it's pretty good but there are some features missing or not supported.

@@bazhenovc754I always assumed forward rendering has always been there even before UE 4

For mobile...At least mobile forward support custom data which is key to stylized/toon renderer, while mobile deferred is not@@bazhenovc754

Yes I would 🙂Bandwidth is very expensive on mobile.

You only need to render prepass with the alpha clip enable, but render it after all opaque. Then the main pass can be rendered fully opaque with earlyZ, the depth buffer will naturally have gaps where texture alpha was 0. The prepass with a pixel shader will be more expensive and I don't think this is a solvable problem. You can optimize geometry, i.e. www.humus.name/index.php?ID=266 to reduce that overhead.

I bought a new expensive one, next video should be better.

I used both "deck-ull" and "dee-kal" pronunciations in the video to offend as many gfx programmers as possible.

I don't think you can do a lot of improvements for deferred shading, unless you start heavily compressing the data you can't really reduce the bandwidth and compression is always at the expense of quality. I have a mixed feeling about ray tracing in general, I understand the appeal but at the same time I feel like ray tracing needs extremely heavy temporal component that makes it look bad in motion most of the time. ReSTIR seems to be a way to go (the biased variants) and I don't think you need deferred shading for that either.

You're messing up tiled/clustered shading with deferred rendering. These are completely different techniques which do not contradict each other.

@@charlieking7600 I'm not. Tiled rendering is often presented as a benefit of deferred. Most deferred rendering tech demos have hundreds of point lights to show it off.

The kind of forward renderer discussed in this video would be firmly in the “Forward+” category already. Depth/normal/etc prespasses, occlusion, clustered lighting and decals… all of these are “forward+” things

Dishonored 2 is in the top 5 of my most favourite games of all time, I absolutely loved it! I'd like to hear more about your shader explosion issue if you have the time, can you pinpoint what exactly caused it in the first place? My general thoughs on this is that if you have a good decal system like in idTech5 then you can use decals most of the time when you need various surface variations and your art team doesn't have to create a new shader every time they want a slightly different scratch on the surface and they can just use decals for these small details. Of course you still have gameplay-specific shaders, but there shouldn't be 50k of them right, Doom managed to ship with like 100-ish shaders in total and visually it looks amazing.

sounds like a self control problem, there is nothing about forward that says you have to use a billion shaders, deferred simply imposes the limitation

Can you elaborate which statements? I admit that most of my experience is with consoles and PC, although I did work a bit with various mobile GPUs. There is TBDR and TBIR, you don't need a depth prepass on a TBDR because the HW already deals with overdraw for you with FPK/HSR, so a depth prepass is just not doing anything useful. But you still need it on a TBIR if you have a forward renderer, all my other arguments should still apply though? I know that you can try to keep the G-Buffer in the tile memory and that mitigates a lot of bandwidth issues, but if you need the G-Buffer for postprocessing (SSR or anything that needs arbitrary sampling of the render target) then you're forced to move it off-tile anyway or scale down and make other concessions (same issue with an on-tile depth buffer - if you have anything going on with your postprocessing you can't really keep it on-tile because you'll need it later). Not to mention that on-tile memory is a scarce resource and there might not be enough of it for a fat G-Buffer. So I still don't see any distinct advantages of deferred renderer over the forward renderer even on TBDR - on these types of GPUs forward renderer at worst shouldn't perform worse than a deferred renderer but it comes with a lot of flexibility. And from what I've seen, all TBDR vendors recommend using a forward renderer anyway.

Hi @@bazhenovc754, great talk by the way, I forgot to mention in my last comment xD. As you pointed out, things like mobile GPUs having some sort of HSR which makes the depth prepass suboptimal, but you still need the depth for things like the SSAO mask generation. To be able to stay in tile memory (you should be able to get more than enough for the GBuffer data) mitigates a lot of bandwidth, not entirely as you will still have to end up writing once to let later passes use the GBuffer but at least you will stop doing multiple writes/loads. Also, some of the comments focus a lot in the assumption of Compute for everything, which is true for Desktop and Console territory but overall on mobile maximizing the use of fragment shaders is still the general advice. So, overall I agree a Forward renderer, as long as you have a really limited amount of lights is going to be the most efficient approach. Unfortunately, modern graphics tend not to align well with this approach as you might need access to material information later in the frame (i.e screen probes based GI techniques, reflections ...) which force people to end up having to write some sort of GBuffer anyway.

There are better ways to reduce the amount of shaders that you have, decals being one of them. If your art team does not have to create a unique shader every time they want to have some small scratches on the surface or other minor details then you won't have the shader explosion problem in the first place.