WHAT
is joining us to delve into the new graphics tools from 4.14. With the Forward Renderer for VR and so much more that just came out, we’ll have plenty to discuss.
Then, and I will announce the November UE4jam finalists and play their games live! Come for the knowledge, stay for the fun!
WHEN
Thursday, December 1st @ 2:00PM ET Countdown]
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.
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%.
Great!
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?
How about adding some other AA method for Forward rendering that is almost as nice as MSAA and work with all the features in forward and deferred paths?
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!
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.
@DanielW, in the stream you said that Epic is not planning to support both Deferred and new Forward renderer on same packaged build due to long shader compile times. If however, one would be willing to wait the extra time, would there be some way to do it without fully rebuilding the system?
I saw that current forward renderer is mixed with deferred code so there doesn’t appear to be an easy way to set a separate target RHI for it (and the setting we have now just toggles between). I see that UE4 does support Switch on both forward and deferred on target RHI’s, I’m still kind of curious why the shader compilation times are issue as people who really need both would surely be willing to wait the time? And it wouldn’t really hurt the others as it would be optional.
Just to give this some more context, I have a game in development that is mainly targeted at desktop but will have additional VR mode. I’d love to use deferred as renderer on desktop and forward for low end and VR (to get MSAA) but since swapping between these isn’t possible atm, I now need to make the game work in forward only. I’m sure that almost all games that have separate desktop and VR mode will be somewhat in the same situation as I am.
Adding my support for this 100% as well. I’ve been planning a hybrid VR game since before VR was viable. A multiplayer game that supports both VR and Standard Clients simultaneously, giving VR players both unique advantages and disadvantages. Given the limits of Forward Rendering I’ve simply planned to wait, counting on the fact that hardware will continue to improve until all features can be supported without it; however any improvements on the software side are gladly welcomed.
I think what said was that they might make it possible in the future to switch between forward and deferred, like 0lento needs it for a VR mode. That wouldn’t automatically mean though that you can use it simultaneously, I think that would mean quite a few changes to the way UE4 renders a scene.
And hey @DanielW, I would still love to finally see SSAO support in forward
You said it would be “easy” to add. I actually made Nvidias HBAO+ work with the forward renderer, there it was really quite simple to let it output to the IndirectOcclusionTexture. Then I noticed that the performance of HBAO+ is really bad in VR though, while SSAO is ~0.45 ms (both eyes), HBAO+ is ~2.5 ms which is way too much unfortunately. So I had to go back to deferred… It definitely showed me how optimized UE4s SSAO is.
Since adding forward support for HBAO+ was so easy, I also tried to add forward support to SSAO, but thats just way harder it seems to me. The SSAO is currently calculated together with all the other post processing in that rendering composition graph, but for making it work with outputting to the IndirectOcclusionTexture, the SSAO has to run before the base pass I think. So it needs to take the depth buffer from the prepass and use that to output to the IndirectOcclusionTexture before any post process stuff has run. I failed at decoupling the SSAO from the render graph. It just relies on a lot of things that just aren’t there yet before the base pass, and the SSAO was not designed to be ever run outside of that graph I think.
Did I miss something or is it just not really that easy?
Oh, thanks very much for these steps! I didn’t know that there would be multiple graphs, that makes it a lot nicer. I wish there would be more (any) documentation about how the different classes in the UE4 renderer work together and where what is done.
I only want to use it together with temporal AA. I’m not sure what exactly you mean, that it will look bad without TAA or actually that it will look worse with forward + TAA than with deferred + TAA? Will the TAA not smooth it out the same in forward like in deferred?
Well, I know you have a lot of stuff to do.