My understanding is deferred rendering has very high bandwidth limitations so it makes it harder to hit 4k+ resolution at high refresh rates.
So are you looking into alternative rendering pipelines like Clustered Forward Rendering?
For instance there is Forward+ rendering an approach talked about in the Ogre3D development forum and covered here → Forward vs Deferred vs Forward+ Rendering with DirectX 11 | 3D Game Engine Programming
There is Visibility Buffering mentioned in a recent GDC conference → http://www.conffx.com/Visibility_Buffer_GDCE.pdf
There is Clustered Forward Rendering used in Doom (latest version) → DOOM (2016) - Graphics Study - Adrian Courrèges
And probably a lot more approaches to reducing the load/bandwidth for rendering on a GPU at > 4k resolution.
Given the high resolutions used in VR, I imagine this would be of benefit there too. I know a few other VR devs who are itching for a Forward+ solution.
Check out the Clustered Forward rendering using in Doom link above.
Have any games/demos/benchmarks used Forward+ yet, it would be interesting to see what it can do?
Edit: Apparently this demo by AMD uses a form of Forward+ rendering (Light Culling).
Yes.
8 Likes
Forward+ would be really exciting to see in Unity! On a slightly tangential note (sorry for going a bit off topic), it would be awesome if you guys could enable MSAA in forward rendering with HDR when using VR. I can force it to use MSAA when NOT using VR, but trying the same trick with VR results in a black screen.
MSAA + HDR works out of the box in Unity 5.6 (in alpha now, beta soon-ish). Not sure about VR, as there it has complex interactions with whatever the VR platform expects (I’m not working on VR stuffs myself).
3 Likes
That’s fantastic news. Hopefully it works with VR too, that’d be the best possible combination of things 
Well speed + high quality option is welcome on all platforms not just VR… deferred is the high quality option but sometimes you just have too much gpu pressure, so choices are welcome
1 Like
I got a chance to look at the new HDR RenderLoop Unity is working and definitely it will bring a lot of speed to Unity. To give you an idea, it’s similar to The Lab Renderer but on roids! More dynamic lights (32) and a maximum of 16 shadowed lights at once on screen (6 shadows = 1 point shadows) in a single pass. Although not quite sure why 16, having 18 will give 3 point lights at once, maybe to avoid running out of textureinterpolators/instructions? I have to investigate more on that.
Anyway, instead of being segmented, shadowmaps are all atlased in a huge giant depth texture, which is again a lot better.
The ID Tech 666 renderer (the one used for the new DOOM) is definitely the way to go.
1 Like
It does seem like the best of all worlds, it’s not as though we actually need more than 32 lights! in fact I struggle to use 8 thanks to old habits - reusing them cleverly, so 32 is a luxury. I have concerns Unity might miss some optimisations taken for granted with deferred ie buffers etc, we’ll have to see how it all plays out with their new post in performance vs deferred too.
Basically I just want “fast as hell next gen visuals on console bro”.
Yeah - this one is just plain weird… it’s not very useful unless spotlights take less than 6.
Forward+ (or the hybrid approach) is the new way to go.
Tbh, 32 lights for me is more than enough, unless you want to simulate GI only with dynamic lights (good luck with that though). ^^
The new HDR renderer does a depth prepass for a more efficient light culling. This will double your drawcalls as your objects needs to be rendered first in a depth pass and then final color pass but with the benefit of having a depth buffer for special depth effects. It should be a lot faster than traditional forward/defferred rendering when many dynamic lighting and shadows are rendered (with a limitation of 32 dynamic lights, 16 shadows and 32 ref probes) in one pass.
But If you need a basic forward renderer without any depth pre-pass, you can make it. I got one running on SM 2.0 hardware that does up to 3 lights with shadows on it and SM3 with more lights and shadows. If you target SM5, you can have a lot more lights with shadows decode in one pass. Not with the new ScriptableRenderLoop but it’s running on C#.
Instead of doing cubedepth textures, they lay out point light faces in the same depth texture atlas, that’s why 1 point shadows = 6 spot shadows. A good optimization is to update faces of that point shadow only if needed, for instance if some side of the light don’t render anything in its frustum just skip that one and reuse previous ones rendered depth frames. I think the 16 shadows limits have something to do with the way the shadow atlas grid is splitted (gotta have to check that out more in depth btw).
Other benefits of this new renderer is MSAA + HDR, unified lighting (opaque and transparent does the exact same lighting), different objects having different lighting models at once is less tricky, less GPU memory bandwidth, etc. Plus Deferred is known to be very bad with lot of small objects on the screen.
Sticking to traditional Deferred or Forward is not good anymore. Making hybrid approaches is the best way now.
2 Likes
Unreal has added a Forward renderer for VR, that sounds very similar to Doom’s rendered as it divides the frustum into a grid, and apparently provides a 22% performance boost.
RoboRecall the VR game that uses the new system, quite amusing robotic dialogue and looks good.
Unity’s experimental Scriptable Render Loop (unknown ETA), the code for which is public here, is implementing “Cluster FPTL”, which is likely based on Morten Mikkelsen’s “Fine Pruned Tiled Lighting” as mentioned here. Mikkelsen is currently a Unity employee (at least he was last I knew), though he does not appear to be working on this himself.
Note, the C# and shader code for the Scriptable Render Loop is public, but it uses engine features and APIs that don’t exist in any public build so it’s not really publicly usable yet.
He very much is (the “FPTL” folder in that github repo, or “mmikk” among contributors), but it’s true that integration of that is mostly done by Sebastien right now.
Soon… soon…
7 Likes
Very excited, been a bit slow on certain platforms unmentionable…
FPTL sounds interesting (read the link) and im curious to know more details about the implications this will have and how it will be used?
Seeing that it’s not part of the first public beta of 5.6, does it mean it’ll be released in a future beta release or as a separate experimental build?
So FPTL is a version of whats called Forward+?