WIP Deferred Shading

I hear multi-sampling can be weird in deferred rendering systems. Is it working well for you (if I may ask)? Can it “piggy-back” on the engines/LWJGL’s normal MS system?

Hey @kwando you should see this http://www.lu.se/o.o.i.s?id=12588&postid=2797861

It measures power consumption and the conclusion is that deferred rendering is more power efficient than forward rendering. Interesting in the context of mobil, also, you can make the case that you are saving the earth by implementing this :slight_smile:

@androlo, hardware multisampling can generally not be used in deferred rendering. Supersampling would work but it is going to be slow as hell.

For the moment a FXAA filter is used, but there is other image space techniques that can be used to alleviate the aliasing.



@jmaasing Nice paper :slight_smile: Two of the authors (Björn and Micheal) have been my teachers :stuck_out_tongue:

It’s interesting to see that DS is viable in mobile context, my guess would have been that the excessive texture fetching would have killed the integrated GPU.

I have made some extensive refactoring and created a way for me to visualize my GBuffer.

The lighting pipeline is now fully linear and in HDR, no automatic exposure so far though.

http://i.imgur.com/Z1B5D.jpg

5 Likes

What’s that striped image?

That is depth encoded into a rgba texture.

mhh why do you encode depth in a rgba texture?

@nehon Currently my GBuffer uses RGBA8 textures and the precision in one channel is not enough to reconstruct the world position.

why don’t you use a depth buffer for depth? you could use the hardware depth buffer. A lot of hardware now supports 24 to 32 bit depth buffer and that’s enough precision to reconstruct position buffer efficiently.

You would save the packing and unpacking overhead…

I can’t bind a DepthTexture to a ColorTexture slot on my FrameBuffer, or at least I couldn’t last time i tried. My system has support for 32-bit depths so it would indeed be nice if it worked…

I swear, it did not work before but now it does :stuck_out_tongue: (Did a quick test). Thanks for noticing this, now i can strip some of my ugly shader code ^^!

also you could just let the hardware compute depth for you instead of writing it yourself in the gbuffer shader

That’s what i do for the FPP. It’s faster.

Great! Now I have reconfigured my system to use the Z-buffer instead. Still working :slight_smile:

1 Like

@EmpirePhoenix I don’t thing deferred lighting should be used.

Or if it is…deferred shading should also be done.

IMO an additional pass is absolutely what you want to avoid. It’s already what is killing shadows performances.



The unique material problem is not really an issue IMO, since most of the time, we’d want to use lighting with the same lighting equation.

Little updates:

I’ve implemented deferred spotlights and added a simple volumetric effect to them :slight_smile:



http://i.imgur.com/lH9ZW.jpg

http://i.imgur.com/EJXlf.jpg

http://i.imgur.com/bIDjR.jpg

3 Likes

ohhhhhhhhhhhhhhhhh

Very nice work

How is it compared to forward rendering? and without the 60 fps cap?

To be honest it’s quite slow and without any post processing it runs about 140 fps on my macbook pro…



With post processing (2x FXAA and Bloom filter) it runs in about 100 fps…



The good news is there is plenty of stuff to optimize though (my shaders are doing tons of unneeded things), but I will deal with that later… especially since I plan to cram in SSAO and soft shadows into my render budget.



I haven’t compared the same scene with forward rendering, but I don’t think it would like the 50+ lights in this scene…

Wow. Those volumetric spotlights looks great. Do they “work” well from all viewing angles?



EDIT: Looks like light shafts could be made using a similar technique? Like light coming in from a window etc.

well 140 fps with 50 lights looks fine for me to be honest.

1 Like

@androlo, Yupp they work “well enough” in most angles…



The effect is a cheap cheat, it’s just a cone which is rendered with no face culling and additive blending + some attenuation and soft intersections with geometry.



@Empire Phoenix, Yupp it not that bad. The initial penalty for deferred rendering is quite high (filling the G-buffer), but after that is paid it’s really cheap to add more lights and geometry to the scene.