More questions! Lets hope @DanielW will find time to come here and answer it all
What is “FTT Bloom/Streaks” thats mentioned on Trello as done in 4.14? Something like this? GPU FFT Bloom - YouTube
1.5 Related to bloom, is there anything planned to make the quality of the current bloom in UE4 more adjustable? Currently it’s hard coded. I talked more about that here: Reduce bloom quality to a single gaussian blur? - Rendering - Unreal Engine Forums Currently its not possible to reduce quality enough for it to be usable in VR regarding performance, but with lower quality it would become usable. And a scene without any bloom looks quite bad unfortunately.
The “Fine Grained Cluster Triangle Culling” thats also mentioned on Trello, what’s that? This? http://gpuopen.com/geometryfx-1-2-cluster-culling/ By how much does it increase performance? It’s marked for November, is it already done in dev-rendering?
Related to that, I’m waiting for almost 4 weeks now to see the new stuff from dev-rendering merged to master, will the next merge happen today? :rolleyes: Always waiting for new optimizations and whatever you put in there in such a long time!
Forward renderer! You said you will “probably” not get dynamic shadows into 4.15, now I’m more interested in when it will hit master since I use master for my project. Could it still be done this year? Also same question for SSAO. I have to wait until it supports 1 directional light with dynamic shadows, since that’s what my sun is. And SSAO. Sun can move and without shadows that looks really bad unfortunately. So I’m forced to use deferred with TAA until that’s supported and as you know TAA doesn’t look too nice in VR.
In a game where everything is dynamic its already really hard to get good performance in VR, and even harder without forward… So it hurts a bit that exactly those games that depend on “everything-dynamic” with nothing baked are hurt most by the currently missing features in the forward renderer and as a result have to use deferred.
Also, do DF shadows work with the forward renderer? Not using those currently, but would be nice to later be able to use those.
I don’t know too much about that task except that it’s being worked on. Clearly it involves a FFT transform into frequency space, and then…something. It’s heavy research and may not pan out. Normally we don’t talk about things until they are clearly working out.
I haven’t looked at our bloom in a long time, sorry.
It’s a research task based on http://www.frostbite.com/2016/03/optimizing-the-graphics-pipeline-with-compute/
The AMD link you posted describes a similar algorithm. Basically most scenes are bottlenecked by the GPU’s fixed function triangle processing rate, yet a large number of triangles are not actually visible due to being out of the frustum, being occluded, being zero-area, or backfaces. The fixed function triangle unit is pretty slow at culling these. If you run a compute shader over the triangles each frame you can cull them down much faster. The task hasn’t been making much traction lately.
There will be a merge in the next few days, we’re currently in testing.
I can’t make any guarantees on when I’ll be able to get to dynamic shadows for movable lights unfortunately as it’s very difficult for me to predict when I’ll get a to work on it. It’s near the top of my list of things to do though. SSAO is more work because currently it’s relying heavily on TAA for smoothing, so the forward implementation will have to achieve good quality without that.
Yes, because shadows are still done deferred in the forward renderer (which is why the don’t work properly with MSAA), all the various shadow techniques like inset shadows, RTDF shadows, capsule direct shadows etc work out of the box, on opaque pixels at least.
That definitely looks very interesting. Anything that improves performance is really interesting, and that sounds like it could make a huge difference. Related to that, do you know when more of UE4s rendering will use asynchronous compute (on PC)? That in general seems to be able to give very nice performance gains. I remember AMD saying that doing post processing asynchronously can improve performance by almost 50%.
Will the shadows stay deferred or is that just for now and later they will they have to be forward for working properly with MSAA?
We don’t have any plans for async compute on PC yet. We barely leverage async compute on consoles, and that needs to happen first, then we need to get our d3d12 RHI to parity with d3d11, which also hasn’t been accomplished yet. It’s a surprising amount of work.
I’d like to keep shadows deferred in the forward path as it allows sharing all the same shadowing features with deferred and it’s really powerful to be able to decouple shading from shadowing methods like that. Even UE3 leveraged deferred shadows. However if we can’t find a way to make deferred shadowing work efficiently with MSAA we may have to switch to forward shadowing, which will be a lot of work (reimplement every shadowing method).
Hey @DanielW, I just wondered… Would it be relatively easy to only support SSAO with TAA in the forward renderer as a start and only later add support for SSAO with MSAA?
I think forward + TAA gives a great performance improvement over deferred + TAA, so that alone would be great already, since the only thing that stops me from moving to forward is SSAO currently. I actually think in my game MSAA doesn’t really work because I just have way too much texture aliasing, but moving to forward and putting the gained extra performance into more screen percentage probably looks a lot better too, and it allows SSAO to still benefit from TAA
Btw, the distance field shadow performance improvements you added recently are sounding really, really awesome!
Yes it would be easy to add SSAO to the forward renderer with TAA. It’s just a matter of outputting to the IndirectOcclusionTexture, which is already there to support indirect capsule shadows. I’ll try to do it in the next month just for you =)
I’m quite sure I’m not the only one who’s happy about that, it also allows to give graphics settings to the user to select if TAA + SSAO is worth the visual quality of the SSAO over the clearness of MSAA. Switching between deferred and forward isn’t possible I think, so there is no way to let anyone enable SSAO at any cost currently. And SSAO just looks incredibly good in all-dynamic lighting scenarios compared to no AO at all. And its also quite cheap.
So, awesome, can’t wait for it to appear on github
Hey @DanielW, just want to ask if you still plan to do it or if its already done. Last Dev-Rendering merge to master was 1.5 weeks ago, so I can’t know what happened in that time. And I obviously can’t wait for finally being able to switch to the forward renderer
Also, with the forward renderer, could you tell me if it would be possible to access the IndirectOcclusionTexture in the base pass pixel shader (FPixelShaderInOut_MainPS)?
Oh, great! Thanks! I currently face the problem that with the deferred renderer I think I can’t access the SSAO in FPixelShaderInOut_MainPS due to it being calculated earlier (if I understand it correctly), and I need SSAO (but not shadows) to be applied on top of emissive materials. So with the forward renderer (once it supports SSAO…) I can just add the occlusion (I don’t have capsule shadows) after the emissive value is already added to the color and then SSAO will be added on top of emissive materials, that’s another great advantage of the forward renderer then
I actually tried to find out how to add SSAO to the IndirectOcclusionTexture, but obviously I didn’t know the renderer good enough for that. So I will just have to hope that you or someone else who knows how to do it will find some time to add it :o Probably have to release my game without forward then and only later update to forward.