History: SoC2011 Modern Illumination Techniques

Source of version: 11 (current)

[https://bitbucket.org/andreiradu/ogre-gsoc2011-modernillumination|Repository]
[http://www.ogre3d.org/forums/viewtopic.php?f=13&t=63763|Project Thread]

!Project Proposal
My proposal focuses on implementing several modern illumination techniques, that are either related to, or benefit from deferred shading. Most of these have been used in several shipped games, while a 
couple are still considered 'bleeding edge'. My list of features is prioritized, and I tried to make sure that each milestone delivers an usable and thoroughly documented piece of code. 
!!Light Pre-pass
This technique is an alternative to deferred shading, promising lower memory bandwidth requirements and a somewhat higher material system flexibility, at the expense of adding another geometry pass(which is relatively cheap). It was first introduced by Wolfgang Engel via his blog{FOOTNOTE()}http://diaryofagraphicsprogrammer.blogspot.com/2008/03/light-pre-pass-renderer.html{FOOTNOTE}, and after developed trough several articles in the ShaderX and Gpu Pro series.
The rendering process starts by rendering normals and depth information into a slim G-Buffer(the normals can be stored in polar coordinates, which leaves 16 bits for depth; this should be enough 
precision, and requires a single RGBA8 render target; we use a 16 bit floating point render target for clarity). Next, for each light in the scene, N*L*light_color and RV^n(for the phong model) are rendered into a light buffer(also a single RGBA8 target, or a RGBA16F to support HDR). A second geometry pass is performed(while keeping the Z-Buffer from the first pass, thus there 
is no over-draw), and the lighting equation is reconstructed, using the material info. 
This technique has been used in several shipped games, and a rather impressive demo, involving a large number of light sources, can be found at {FOOTNOTE()}http://www.confettispecialfx.com/river-of-lights#more-92{FOOTNOTE}. A larger performance gain is achieved when some post-processing effects like motion blurred or precomputed ambient occlusion are performed(and thus would require a larger G-Buffer in a classical deferred shading approach).
In my implementation, the alpha channel of the light buffer contains the specular term raised at a light-specific value, and multiplied by NL and attenuation. The specular term(NH) is recalculated at merging by division with the luminance of the diffuse channel. 

!!Inferred Lighting {FOOTNOTE()}http://graphics.cs.uiuc.edu/~kircher/inferred/inferred_lighting_paper.pdf{FOOTNOTE}
This builds on the previous technique and tries to use smaller resolution buffers. The main issue that arises is that rope-like artifacts appear on object edges(due to sampling issues). The proposed solution is using another buffer that stores both linear depth and a semi-unique ID of that surface(two adjacent surfaces shouldn't have the same ID). This is used in the final material pass to bias the bilinear filtering that would occur due to sampling a smaller light buffer.
The main purpose for this is reducing the cost of illumination, since lighting is performed at a lower resolution.I used a light buffer with 0.75 the height and 0.75 the width of the viewport, so a ~44% reduction in lighting calculations. Artifacts are present along curve surfaces, and lighting detail on pixel sized objects or highlights is lost(temporal aliasing occurs due to this as well). 
Another important issue is that performance can be easily traded for visual accuracy(we simply need to use smaller or larger light/G buffer). To the extent of my knowledge, this has not yet been used in a shipped game. 

!!Reflective Shadow Maps
Reflective shadow maps are used, in this implementation, as a form of instant radiosity. The purpose is to provide one bounce global illumination for diffuse surfaces. The technique starts with the idea that every point that would give one bounce GI is captured by the light's shadowmap. So we store extra information in the shadowmap(normal and flux), and generate Virtual Point Lights(VPLs) based on that. We then use these pointlights to light the scene. Since several hundred point lights are needed to get good results, using a deferred technique is mandatory. 

Normally the RSM would also contain world-space position, and the flux would contain the albedo multiplied by the attenuation(both from distance and from spotlight cutoff). However, OGRE doesn't currently allow Shadow Textures to be MRTs, so the world-space position was dropped(it's computed at VPL generation from depth), and the flux only contains the albedo(attenuation is factored in at VPL creation).

VPLs use two attenuation factors: first a squared distance attenuation is applied. Then the dot product between the VPLs normal and the surface normal is factored in. 
VPLs are splatted as unit spheres that are scaled and deformed(they reach a hemisphere shape) in the vertex shader. They are rendered using instancing(the difference in framerate between using/not using instancing is almost two orders of magnitude; less than one fps to over 50 on my configuration).  

!!Light Propagation Volumes {FOOTNOTE()}http://www6.incrysis.com/Light_Propagation_Volumes.pdf{FOOTNOTE}
This is a global illumination approximation technique, that can be used for low frequency lighting situations. The first step is partitioning the scene in a grid. Normally, the grid would have varying cell size, but for my implementation I will only implement a fixed size grid. The scene is then rendered into a set of Reflective Shadow Maps Each VPL's position is then determined, and converted to a spherical harmonics representation{FOOTNOTE()}http://www.ppsloan.org/publications/StupidSH36.pdf{FOOTNOTE}. The VPL's in each cell are then 'accumulated'(we perform a summation in SH space). Low frequency direct illumination can be approximated as well by creating VPL's from environment maps or area lights.
Next the depth and surface normal at each point is used to reconstruct a coarse approximation of the scene's geometry(surface information stored in the RSMs is also used; additional information can be 
obtained by using depth peeling). This geometry information is used per cell to obtain occlusion data for each incoming direction. This is also converted into SH space and accumulated.
Implementation Details: The whole technique can be implemented as a single compositor. The grids will consist of flattened 3D textures(2D textures that contain several slices) and a custom rendering pass will be used to inject the RSMs into it(sample the RSM and render the point lights directly in SH coordinates). Light propagation is computed in a fixed number of passes, using ping-pong buffers(in each pass each cell looks at it's six neighbors). 
Two open-source stand-alone implementations exist at {FOOTNOTE()}http://lee.fov120.com/lpv.zip{FOOTNOTE} and {FOOTNOTE()}http://blog.blackhc.net/wp-content/uploads/2010/07/LPVPrototype.zip{FOOTNOTE}.
!!Demos
The demo extends the deferred shading demo with a drop-down that selects the lighting technique used. The options will be: forward rendering, deferred shading, deferred lighting, inferred lighting, spherical harmonics lighting and light propagation volumes. Additionally, when selecting deferred shading, deferred lighting or inferred lighting, there will be an option to activate Reflective Shadow Maps. Debugging outputs are also extended to allow the viewing of the light buffer, for deferred lighting and inferred lighting, and object IDs for inferred lighting. 
!__Schedule__
The only other commitment I have this summer are my third year exams, and I'll finish those around the 10th of June. That gives me roughly 10 weeks of actual work.



• __Preparation period__ – Find out what the community expects from this project. Get familiar <br />with the inner workings of the compositor framework.
• ''Weeks 1-2(June 12th'')– Implement and optimize Light Pre-Pass and Inferred lighting
>• ''Week 3(June 26th)''Implement Depth Peeling(useful for both LPV and SSDO)
• ''Week 4(July 3rd)''Implement SSDO
• ''Week 5-6(July 10th)''Implement RSMs(I want to implement these so that they can be used without LPV)
• ''Week 7(July 24th)''Implement reconstructing the scene geometry from the various depth and <br />normal information available; add optional depth peeling<br />• ''Week 8(July 31st)''Finalize LPV 
• ''Week 9(August 7th)'' Analyze possibilities to add direct lighting and glossy reflections to the LPV compositor
• ''Week 10(August 14th)''Document everything. Make sure to note possible areas for <br />improvement. 

!!Some further development ideas: 
• SSDO can easily be extended to accommodate one bounce global illumination
• LPV can be optimized by allowing cascading grids(recursively subdivided; think of a octree)
• The SH representation from LPV can be used as a basis for further development in SSDO(instead of accessing a cube-map for each direction, we could use the per-cell <br />representation)
• Depth Peeling can be used for transparent objects in any deferred technique
Why I'm The Person For This Project<br />I am a computer science student, in my third year, and the courses I followed span from object oriented <br />programming to software engineering, to computer graphics and computer architectures. I consider <br />myself to be well prepared in all of these fields, especially since I have taken a special interest in them. <br />I'm also quite a talkative and sociable person, and enjoy working with others. I am currently involved <br />in a large scale virtual reality project that uses an Ogre based client. You can find more about my work <br />from my blog{FOOTNOTE()}http://andreiradu.blogspot.com{FOOTNOTE} or my projects page{FOOTNOTE()}http://graphics.cs.pub.ro/~andreiradu{FOOTNOTE}.<br />Why OGRE?<br />I have a great interest in computer graphics and engine design, and hope to work in the field in the near <br />future and has helped me improve in both fields. I also learned a lot from Ogre, both in coding style <br />and in terms of engine design(I often find myself skimming trough open source engines' doxygen <br />documentation to see how different modules work together). <br />Anything Else<br />My proposal might look a little ambitious, or unfeasible, but I believe that I have the needed skills and <br />motivation to implement it. Plus, I don't have anything planned until early September :) 	+	The only other commitment I have this summer are my third year exams, and I'll finish those around the 10th of June. That gives me roughly 10 weeks of actual work.
-	{FOOTNOTEAREA()}{FOOTNOTEAREA}
History: SoC2011 Modern Illumination Techniques

Source of version: 11 (current)

Search by Tags

Latest Changes

Search

Online Users
