- Crytek: they call it Deferred lighting contrary to Deferred shading. The technique is mentioned in the new Cry Engine 3 presentation here
- Garagegames in their new Torque 3D engine currently in beta. Read the article from Pat Wilson in ShaderX7 and the garagegames website
- Insomniac came up with a Pre-lighting approach that is similar to this. See Mark Lee's presentation from GDC 2009 here
- DICE is using it since a long time already
- I believe EA used it in Dead Space :-)
- Carsten Dachsbacher described a similar idea in his article "Splatting of Indirect Illumination" here and in ShaderX5
One of the interesting areas in this context is the ability to implement a one-bounce global illumination effect with the data in the G-Buffer and the light buffer ...
10 comments:
A minor correction - Stalker does not have light pre-pass rendering; their combine stage is a full-screen quad, they don't render geometry twice.
I removed it from the list :-)
In doing some research, I found an in depth post that goes against some of the recent love for deferred lighting:
http://gameangst.com/?p=141
I would be interested in hearing any comments you might have. It is awesome to see well a reasoned discussion from industry veterans on the cost/benefit of different renderer schemes. So thanks for those links!
Hey Matthew,
I read the post and think he has good points here. You should implement this stuff and see what fits for you. it is pretty easy to go back and forth between a deferred renderer and a Light Pre-Pass renderer.
You actually do not necessarily have to do a second geometry pass if you do not want.
The main reason to do this is that you have a wider variety of materials.
Have a fun with the implementation!
How would you go about integrating pre-pass lighting into particles? (To avoid forward rendering which would be require a duel implementation of each light type).
I had an idea that you could slice the particle into non-overlapping groups and render the groups (as sheets) from back to front over the scene, allowing you to pre-pass light them a sheet at a time.
When reading your ShaderX7 articles on the light pre-pass renderer (by the way, very good article ;) ), I was also thinking that a one bounce light reflection would be great for simple global illumination. That would be a big approximation because we miss some informations (material properties, incoming light direction, etc) but that would be very nice.
I think that's what Crytek is using for their global illumination effect shown in their new presentation, but not described...
Atm im working with the "older" deferred lightbuffers. Simply storing a texture index per pixel in a float16x4 texture which is read back in the mainpass and lookups the per pixel light informations. So u can just have 4 overlapping lights per pixel. I will try the accumulated version if i get my shader X7 book hopefully these days.
The article from Matthew is really nice.
I just wonder how u guys handle AA in all those deferred solutions? My guess is u don't... since while i was playing around with my first deferred renderer i found that getting "acceptable" AA would cost quite much. Thats why im still trying to have AA working for our lighting system.
Even on crytects presentation they stated "... we are working on it"
PS: Btw what i dont understand is in the presentation at the end this show shows "Global Illum" on and off, but how to they get light bouncing from the backside of those walls in front of the character? Do they render a second pass from the light view? I dont get it where those normals/light values would come from?
Hi,
I'm wondering if you see any performance increase on mobile graphics card with this solution ?
Hey Wolfgang,
light pre-pass rendering seems to be a really cool idea and, since many developers are using similar approaches nowadays, also seems to be very useful.
But after reading a lot of documents regarding this technique, I'm still wondering how you would implement
different lighting-models/material-types on top of it. For me it seems that the light pre-pass technique is as limited to very few lighting-models
as a deferred renderer and is actually not as flexible when it comes to different material-types/lighting-models as you claim.
As Adrion Stone mentioned in his blog (Matthew B. already posted the link to his article), different lighting-models can not really be built into
the material-shaders in the final forward render-pass but require different/additional
attributes in the G-Buffer for usage during the lighting-pass which, when implemented with light pre-pass, probably kills both the flexibility and fill-rate
(e.g. Oren-Nayar needs a material-roughness attribute to compute the incoming irradiance at a pixel, Ashikhmin-Shirley needs tangents and binormals for irradiance computation etc.).
Do you have any experience with those issues to share?
<<<
But after reading a lot of documents regarding this technique, I'm still wondering how you would implement
different lighting-models/material-types on top of it.
<<<
You replace parts of the lighting equation with different terms. You can check out my SIGGRAPH talk or any of my Light Pre-Pass talks to get more information about this.
I think I also described it in the ShaderX7 article.
Post a Comment