   Image Space Lighting
  Comments for the article Image Space Lighting
  Decent article.  Very grounded explanation of the technique.  Some suggestions:(1) It would be good to touch on the shortcomings of the technique.  Huge memory requirements; trickiness of alpha blending and antialiasing.(2) Might be good to throw out some of the common terms associated with this so people know what to Google when doing their own research, eg: 'G-Buffer';  I had a strange flashback reading this article. It nicely describes the basics of Deferred Rendering, but where exactly is the difference? Deferred Rendering is well-established and known for quite some time. Plus the references to games using the "built-in" lighting functionality of graphics cards doesn't exactly increase my trust in the article's quality. The omission of the actual shortcomings of Deferred Rendering that Nairb described doesn't help the case either.The article is nicely written, but to me it appears as if it is ten years late.   ;  I kindly disagree, I believe this article is FANTASTIC...I have seen too many posts of people implementing their own deferred renderers and running into all kinds of weird problems. This article as said above provides a clear, compilable, code base that people can reference. I am one of those people that have a complex renderer with normal mapping and custom meshes, and i am having problems with all of my lighting moving with the camera.This code will allow me to see what calculations are in the wrong space.Speaking of which, i dont see you multiplying your camera position with the light position anywhere, which leads me to suspect you dont calculate the lighting in view space? im still looking at the code though maybe i'll find it   ;  In answer to some of your comments, yes - this is not a novel technique, it has been used in several games, and the paper cited is a 2006 paper.There are some large disadvantages to this technique, as mentioned as well. If you use deferred rendering, you must store the scene information into floating point textures the size of the screen, which takes up a lot of memory, and makes hardware-accelerated anti-aliasing impossible (and other forms of antialiasing are typically more expensive or not as good). I agree that discussing more of these drawbacks would have made the article more complete, however, these drawbacks are more related to deferred rendering in general, and this technique only suffers from these drawbacks because it requires deferred rendering.This paper goes through my own implementation of deferred lighting, and walks through all of the steps and explains the math and theory clearly, from deferred rendering, to computing the lighting's area of effect, to rendering the proxy shape and computing the per pixel lighting. There is no great novel difference between this approach and deferred lighting (there are a few differences, but nothing notable). For those who already know a lot about deferred lighting, I can understand why this article might sound "ten years late."Finally, I'm glad the article could be of help to you, AverageJoeSSU. Also, the lighting calculation, as you suspected, is not in view space, it is in world space. The light source's proxy shape is projected to screen space (hence the name) - and this is done by just rasterizing the proxy shape with the scene's modelview matrix. To do the computation in world space, the position of the light source in world space is sent to the shader using a uniform variable. Doing the lighting computation itself in screen space would cause floating point errors, and perspective projection problems, so for simplicity sake, I do the actual lighting computation in world space. It is good to keep track of what variables are in what spaces - in the demo code, the deferred textures store the world position and normal (not the screen space one), so that the lighting computation can be done in world space in the next step.   ;Quote:Original post by terra0novaso for simplicity sake, I do the actual lighting computation in world space. It is good to keep track of what variables are in what spaces - in the demo code, the deferred textures store the world position and normal (not the screen space one), so that the lighting computation can be done in world space in the next step.Yeah. I am trying to do my stuff in view space, and I believe some of my lighting calculations are off because of it.This may sound kind of newb, but could someone explain how these spaces relate to these calculations? I understand what they are, but when you say you do them in world space (i assume this means the HV and all that are in world space), do they eventually end up in view space? Or is that only done to the light's volume?   ;  I found the code useful, since it provides a bare-bones OpenGL deferred renderer example. Seems a little less daunting now. ;)   ;  The lighting computation is done entirely in world space. The resulting color is written to the screen space pixel, so if that's what you mean by "eventually end up in view space," yes. However, the lighting computation is never transformed into view space, the lighting computation (only diffuse in the demo code, but you can compute any brdf) is done entirely in world space, and then the hardware's rasterizer takes care of adding the illumination to the correct pixel in view space.I would strongly recommend against doing the computation in view space - especially if you are using perspective projection. View space with perspective projection is not euclidean - the distance between two points close to the camera is different than the distance between two points far from the camera. Two points in view space could seem very close together by euclidean distance, but actually be very far apart - this will cause serious problems for standard lighting computation unless you correct for this. Save yourself a big headache - do everything in world space (which is euclidean).Oh, and if anyone is confused about the "FBO_SAME_FORMAT" variable in the demo code, this is actually a bug fix for ATI cards. On some ATI cards, all color attachments of the framebuffer must be the same format (ex. GL_RGBA). If you try to compile the framebuffer with color attachments of different formats on an ATI card, you'll get an GL_FRAMEBUFFER_INCOMPLETE_FORMATS exception. NVIDIA cards don't seem to have this problem. The code first tries to use color attachments with different formats (to save space), and if the framebuffer status is GL_FRAMEBUFFER_INCOMPLETE_FORMATS, then it recompiles the framebuffer object using color attachments of all the same format.   ;  excellent, i'll give that a try, converting my stuff from view space to world space.thanks for the advice.;  I read the article, and although it is a very useful introduction into deferred shading, it seems that the comparison with normal lighting is not really fare. In any reasonable old-style engine, you would not iterate trough all lights in the scene for each rendered pixel. You would use you spatial data structure (some octree or whatever) to select only lights for each object that contribute significantly to its color. So, when you have large view-space lights which only light relatively few pixels on one or two objects (for example large lights in outer space), you only apply the lights to those objects. In deferred shading, you would have to render the complete bounding volume of the light, even though hardly any pixels are actually light.I do not want to advocate against the value of deferred shading, but I think that the performance comparison in this article is highly biased because of a bad implementation of old-style lighting.That said, in many situations, deferred shading does outperform old style lighting and therefore is very useful!   