"If you cannot explain something in simple terms, you don't understand it." This video really shows how deep an understanding you have on the shader topic. Thanks so much!
Should also mention all lighting in doom eternal is dynamic. The "pre-processing" that is being done is called clustered forward rendering, in which a culling stage reduces the lights sampled in a specific part of the scene.
Yep, unfortunately had to cut out clustered rendering to keep the talk focused and under half an hour. It's a very cool technique explained in the Doom Eternal graphics study by Adrian Courrèges (one of my sources at the end).
@@benmandrew I figured, thought I should clarify for those that are curious about the technique and "prepossessing" (technically correct but I would have just called it a culling pass, preprocessing implies a static, pre-runtime/serialised nature to which the light culling pass is not), definitely beyond my paygrade, but is really cool.
Definitely still a heady topic for me, but thank you for explaining it. Specially for the emerging trends and outlook in the end, definitely interesting.
Is curious how everybody who illustrates a depth buffer always use the reverse depth approach, where white is closer and black is farther, more curious is that the reverse depth buffer distributes the depth precision much better than the original, 'forward' depth buffer, where closer objects have a depth close to 0 and far objects have a depth closer to 1 😊
Correct, for those interested this is due to the non-linear perspective transformation (1/z) either combining with or cancelling out the somewhat-logarithmic distribution of points in IEEE floating point numbers. A really good explanation is on the Nvidia developer website -- developer.nvidia.com/content/depth-precision-visualized.
Thank you! Been going back and forth between defferred and forward as it's a lot more effort using forward shading - requiring much more planning and optimising. I plan to force myself to use Forward rendering during development and commit to a much more optimised game rather than go for dynamic lighting.
@@donovan6320A shader can loop over many light sources during the same rendering step, but many screen space effects are compromised if you don't use deferred.
@@donovan6320Deferred is only important if you need some extra data from each separate rendering step that isn't easily generated by forward only, but lighting can be calculated in a single step for forward nowadays.
@@donovan6320I found out more about it, modern hardware still supports a lot of light sources in forward mode simply by iterating over them but there are methods to improve this via something similar to culling. If you use a method for global illumination that is good enough, deferred or forward don't matter that much because the lighting is calculated in another rendering step.
why is forward always portrayed as lights x meshes. i have never written a forward renderer like that. just put the lights in a buffer and then send the lights affecting a mesh as indices. gives you 1 uniform branch for the loop but that should be fine and way faster than multiple draw calls lol
Deferred rendering has the advantage of calculating lights per block and not per pixel, decreasing the GPU overload, so it doesn’t matter how many lights cross your blocks because it won’t affect performance. If I’m not mistaken, Apple has TBDR Patents and has been using it on the iPhone since 2017.
7:25 In webgpu, the vertex and fragment shader code is provided to the pipeline. This means that a pipeline can only execute 1 fragment shader. So to render the scene we wouldn't just have the nested loops: lights>objects, but rather materials>lights>objectsWithThisMaterial, and for each material set a different pipeline. Am I missing something here? is that pipeline-per-material, the intended way to draw the objects for this case? 19:30 In WGSL it doesn't seem to be possible to use some samplers inside branching code. Is there a way around that?
why do you repeat "moving the g-buffer" ? It doesn't need to move. It's only ever allocated once. It is written once for each frame. Once it has been written, it is read-only. I do not understand. Do we transfer its contents between RAM and VRAM frequently or something?
But surely you just put your lights into a GPU buffer and then you can sample the buffer whilst drawing meshes. That makes it just M draw calls for M meshes, with sampling into the buffer for N lights which is really not any different from deferred, other than that deferred avoids redrawing fragments - but even a depth prepass on forward solves that issue.
