Видео

You will not get correct results either way, gbuffer normals are not color and if you use alpha blending on that you will get random results and it will look bad. This is the same issue with deferred shading as well - you can't alpha blend normals and material properties, that data is not color. So with that regard, the texture format doesn't matter that much. If you need bilinear sampling you can split some stuff into separate filterable render targets, but try to keep the overall bandwidth under control (i.e. 128 bits in total, use 3 MRT 32bits color filterable, 32bits normal filterable, 64bits packed non-filterable) but keep in mind MRT is going to be a bit more expensive even if the overall bits per pixel is equivalent. Same goes for alpha blending, if you have a ton of translucent geometry it might make sense to keep the color separate with alpha-blendable format. For transparency you essentially have 2 options: 1 - separable blending, color target uses alpha blending, all other targets replace the data. This will make the color appear blended, but AO will be using the translucent front surface as input and AO won't be visible behind it. 2 - only use alpha blending and don't touch gbuffer normals at all. This will make the color appear blender, but AO will be using the opaque surface behind it as input - AO will be visible behind the translucent surface, but won't be applied to the translucent surface itself. Same goes for DOF and other that uses gbuffer inputs in one way or another. Depending on your game, you can use either 1 or 2 or both - the difference will be in how these things interact with post processing (different types of artifacts). Experiment with that and find the right combination that works for your game.

@@homematvejif you have any kind of complex post processing, you are going to move the gbuffer off tile, with forward rendering this is 2 render targets less than deferred. The post processing is unchanged in both cases. By “complex” I mean effects that need to access adjacent pixels - any kind of antialiasing for example. Sure you can run simple stuff like tone mapping on tile, but then your AA quality will suffer if you run it post tonemap. I can assure you that I’ve heard about tile based architectures and I can also point you to vendor documentation that clearly recommends forward shading - community.arm.com/arm-community-blogs/b/graphics-gaming-and-vr-blog/posts/killing-pixels---a-new-optimization-for-shading-on-arm-mali-gpus You need to learn more about the hardware, TBDR in particular.

Some time next year, I'm working on this in my free time and unfortunately I don't have as much free time as I'd like to.

I have a separate video about deferred shading: ruclips.net/video/QVbOp1h-Jb4/видео.html

@@bazhenovc754 Amazing man! Thank you for taking the time out of your day to link it, I look forward to watching it.

Compute triangle filtering, here is the link: github.com/GPUOpen-Effects/GeometryFX I'll add it to video description.

Yes, I have no problems with that.

@@bazhenovc754 Thank you very much, this video is very enlightening

@@bazhenovc754 Thank you very much, this video is very enlightening

I did the boring part for you so you can focus on writing fun shaders :)

Indirect draw calls are a prerequisite here. You basically have an array of draw call structures and a counter. A compute shader does the culling test and, if passed, atomically increments the counter and writes the draw call values. Then it's submitted for execution using a SINGLE cpu call (e.g. ExecuteIndirect on DX12)

The link is in the description: advances.realtimerendering.com/s2020/RenderingDoomEternal.pdf

@@bazhenovc754 I saw that after a while, it is not a very helpful pdf :( There should be a talk somewhere

If you are rendering at 240Hz you can just jitter frames, don't even need to do history blending. At that framerates your brain is doing the blending for you, here's a shadertoy demo with the effect (don't forget to change the shader parameters as the source code comments say!): www.shadertoy.com/view/tl2fRy

All games *have* to use since kind of ray tracing because it's the only way test for real shadows in general. the difference is real games test them ifrequently

DLSS is nvidia-only.

For the low percentage of users that have a DLSS compatible card. And (imo) the graphics upgrades from the last decade really haven't done much to AAA gaming

I get temporal reuse for raytracing and cloud volumetrics, but what other technologies is it necessary for? I know you can do hair without it and it looks alot better than undersampling it and using temporal re use. Also you are missing the fact that taa adds ghosting, alot of it. It also adds shimmering to things that should not be shimmering. Also the blur is very strong in motion and makes the image look like an oil painting. Foliage especially lose so much detail. DLAA helps alot of these thing but it doesn't remove any of them completely. You can focus it to remove one almost completely but the other two things get worse. AI TAA(dlaa) are also VERY expensive compared to TAA and other AA options.

“Without temporal reuse, half of modern graphics aren’t possible” Good.

Blurry is “about it”? That’s kind of a big damn deal. As for going back to 2010, that’s just absurd. Not all techniques since then are incompatible. The first game I played that really embraced this nonsense was Talos Principle 2, and I don’t care how much the word “modern” is bandied about, that games visuals fall apart the moment the camera moves. It’s not subtle. After you stop moving you can see the fidelity slowly return and the accumulated lighting errors correct as it catches up over the space of a second or two. It looks _bad_, no matter how pretty the screenshots look.

He doesn't like on demand async lighting, however pre-generated lightmaps I don't forsee him having an issue with so long as it is guaranteed loaded and only applied to static geo before rendering, the bigger issue seems to be things not loading at runtime and so things popping in, looking unresponsive and then popping in and out or being out of sync He never said you can't precompute things, more that runtime calculations of things that cannot be done in a single frame blended over multiple frames just looks terrible and should not be done at runtime, which is true.

What he is saying is Target at least 60 FPS or the users refresh rate, whichever is lower. You can go higher but never go lower

Have you played Minecraft Bedrock with raytracing? It doesn't handle lighting correctly, each light lefts for several seconds when source is removed.

@@charlieking7600 1 bad implementation does not mean the technology is fundamentally bad

You have to realize that the average person is a sludgedwelling numbskull

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 RUclips 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.

That's really not going to affect your eye-health whatsoever, it is uncomfortable tho.

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.