tag:blogger.com,1999:blog-398682525365778708.post6177873158569097900..comments2023-07-06T02:40:05.577-07:00Comments on Diary of a Graphics Programmer: Light Pre-Pass RendererWolfgang Engelhttp://www.blogger.com/profile/11031097395025597662noreply@blogger.comBlogger44125tag:blogger.com,1999:blog-398682525365778708.post-1630907356303457932014-06-16T12:32:25.581-07:002014-06-16T12:32:25.581-07:00Hi, where can I download RendererDesign.zip the li...Hi, where can I download RendererDesign.zip the link no longer works.tudalexhttps://www.blogger.com/profile/05239172401997704126noreply@blogger.comtag:blogger.com,1999:blog-398682525365778708.post-89694146651236908812011-08-31T12:14:49.420-07:002011-08-31T12:14:49.420-07:00This comment has been removed by a blog administrator.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-398682525365778708.post-4298480359707219482010-10-04T05:59:05.025-07:002010-10-04T05:59:05.025-07:00Hi,
First I want to say that I like the pre-light...Hi,<br /><br />First I want to say that I like the pre-light architecture very much and decided to implement it in OpenGL. Unfortunately, I have problems getting rid of all artifacts when using MSAA.<br /><br /><br /><b>No MSAA</b>: <br /><a href="http://micha.monoid.net/stuffu/pre-light/0_samples.png" rel="nofollow">0_samples.png</a><br />Notice that white curved line looks pretty bad without out MSAA, but the tree(green)/floor(blue) edges are rendered well.<br /><br /><br /><b>With MSAA (8x):</b> <br /><a href="http://micha.monoid.net/stuffu/pre-light/8_samples_nearest.png" rel="nofollow">8_samples_nearest.png</a><br />Here the curved line is fine but the tree(gree)/floor(blue) edge sampling is quite ugly.<br /><br /><br /><b>With MSAA (8x) with centroid sampling:</b> <br /><a href="http://micha.monoid.net/stuffu/pre-light/8_samples_centroid_linear.png" rel="nofollow">8_samples_centroid_linear.png</a><br />I'd say this looks best but still there are tree(gree)/floor(blue) edges which I'd like to get rid of.<br /><br /><br />Any help/hints to improve the quality are very much appreciated. Maybe I'm simply missing a few OpenGL parameters.<br /><br /><br />Thanks and best regards,<br /> MichaelAnonymoushttps://www.blogger.com/profile/07488126278314276322noreply@blogger.comtag:blogger.com,1999:blog-398682525365778708.post-91900097099822720482010-04-22T11:25:50.067-07:002010-04-22T11:25:50.067-07:00It would be super helpful if someone could post sc...It would be super helpful if someone could post screenshot of what MSAA looks like with this technique. The worst case I can think of is something like this:<br /><br />High albedo object in low amount of light, on top of a low albedo object in high amount of light. <br /><br />MSAA with centroid sampling should be pretty good I but there will still be artifacts and I'm interested how bad they are. <br /><br />EricUnknownhttps://www.blogger.com/profile/14269986616600946581noreply@blogger.comtag:blogger.com,1999:blog-398682525365778708.post-46618995828777521362010-03-29T18:42:19.015-07:002010-03-29T18:42:19.015-07:00Hello, I really like this technique and have sarte...Hello, I really like this technique and have sarted putting something together. I have now stumbled onto a problem with normal-maps, or any other mapping which fiddles with the normal vectors.<br /><br />How do you go about implementing a simple normal mapping technique in the context of the pre-light rendering pipeline?<br /><br />I am assuming that we don't want to read-in the normal-map during the depth pass.<br /><br />Best regards, Dan.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-398682525365778708.post-32619327077810152182010-03-21T09:55:34.643-07:002010-03-21T09:55:34.643-07:00I was wondering if anyone ever used a trick like t...I was wondering if anyone ever used a trick like the following to access samples values from MSAA surface using DX9 on PC.<br /><br />For example with MSAA2X we have two samples A & B we can't read, but can we:<br /><br />- resolve to a non-MSAA GBuffer (Gleft)<br />- draw a fullscreen black quad with alpha to coverage enabled and that outputs a constant alpha value (but alpha write disabled) for a 50% coverage so as to mask half the texels (=> half the texels are now black)<br />- resolve again into another GBuffer (Gright)<br /><br />Gleft = (A+B) / 2<br />Gright = (0+B) / 2 (or (A+0)/2)<br /><br />=><br /><br />sample B = 2*Gright<br />sample A = 2*Gleft - B<br /><br />The only problem is the downscale pattern used by the resolve operation. On consoles we can choose between different modes (square, rotated...) but I couln't find any information about this for dx9 PC :(<br /><br />If it works, we could render like this:<br /><br />- render geometry once with MSAA2X, depth buffer test & write, albedo buffer RGB in .rgb + edge in .a (using centroïd trick)<br /><br />- render geometry again with MSAA2X, depth buffer test only, normal XY in .rg, matID (or packed material params) in .b and depth in .a<br /><br />- resolve MSAA buffer into two non-MSAA textures if needed (or resolve "on-the-fly" during lighting if possible)<br /><br />- use the centroïd edge information to clip texels that need supersampling else just compute lighting accumulating albedo and lighting into the non-MSAA buffer<br /><br />- then compute supersampled lighting onto remaining texels, still accumulating albedo and lighting into the non-MSAA buffer.Anonymoushttps://www.blogger.com/profile/16808322273600186441noreply@blogger.comtag:blogger.com,1999:blog-398682525365778708.post-41076576306258986302010-03-20T10:03:29.182-07:002010-03-20T10:03:29.182-07:00oops sorry: eps = epsilon
The idea is to use a sm...oops sorry: eps = epsilon<br /><br />The idea is to use a small treshold value to bias the texkill test so that when the multisampled normals are only a little different then we could use the averaged value to perform the lighting at non-MSAA resolution during the first pass as an optimization.Anonymoushttps://www.blogger.com/profile/16808322273600186441noreply@blogger.comtag:blogger.com,1999:blog-398682525365778708.post-38184532522983710332010-03-20T09:44:26.815-07:002010-03-20T09:44:26.815-07:00That sounds very cool. What is eps?That sounds very cool. What is eps?Wolfgang Engelhttps://www.blogger.com/profile/11031097395025597662noreply@blogger.comtag:blogger.com,1999:blog-398682525365778708.post-64475105887566395192010-03-18T17:29:48.892-07:002010-03-18T17:29:48.892-07:00another stupid trick for edge detection pass on pl...another stupid trick for edge detection pass on platforms that support sampling the MSAA surface with linear sampling: sample the normal buffer twice, once with POINT sampling and once with LINEAR sampling. Use clip(-abs(L-P)+eps). The linear sampled value should be used to compute the lighting of "non-MSAA" texels in the same shader to avoid an extra pass.Anonymoushttps://www.blogger.com/profile/16808322273600186441noreply@blogger.comtag:blogger.com,1999:blog-398682525365778708.post-14425832871140097752010-03-14T04:15:23.210-07:002010-03-14T04:15:23.210-07:00Hey!
The light pre-pass renderer is brilliant ide...Hey!<br /><br />The light pre-pass renderer is brilliant idea , it's fast and has even a really good quality!I used a light pre-pass renderer in my engine and the results are pretty good.<br /><br />thx,<br />Jesse<br /><br />PS: Sry for my bad english... ;)Blogghttps://www.blogger.com/profile/05470613027124244381noreply@blogger.comtag:blogger.com,1999:blog-398682525365778708.post-56546726141686365692010-02-23T13:51:23.020-08:002010-02-23T13:51:23.020-08:00Jason Bracey from jviper2004002@hotmail.com. Is th...Jason Bracey from jviper2004002@hotmail.com. Is the source/sample demo still avilable?Unknownhttps://www.blogger.com/profile/08737374777295841824noreply@blogger.comtag:blogger.com,1999:blog-398682525365778708.post-43971851227139318402009-03-04T16:06:00.000-08:002009-03-04T16:06:00.000-08:00oh and regarding shadows: you treat them in the sa...oh and regarding shadows: you treat them in the same way as in a Deferred renderer. So for the directional light shadows you re-construct the world position and then fetch your shadow atlas. For point and spotlights you do the same ... while you render them. So exactly the same as in a Deferred renderer ... nothing special here.Wolfgang Engelhttps://www.blogger.com/profile/11031097395025597662noreply@blogger.comtag:blogger.com,1999:blog-398682525365778708.post-74816172057094368922009-03-04T16:03:00.000-08:002009-03-04T16:03:00.000-08:00<<<Maybe i'm missing something?<&l...<<<<BR/>Maybe i'm missing something?<BR/><<<<BR/>Yep you are missing the whole idea :-) <BR/>Instead of reading four full-screen -maybe MSAA'ed- render targets you read two for each light. You can pack light properties pretty tightly into the light buffer ... so you might get away with a 8:8:8:8 light buffer. I actually do.<BR/>So it takes much less memory bandwidth per light and because you do not calculate the whole lighting equation for each light while you render into the light buffer it is also cheaper. So overall you can render much more lights ... probably 2 - 3x. My tests show that you save especially on small lights. You can run very high numbers like 512 or 1024 depending on your platform this way.<BR/>Obviously MSAA is easier and material variety is better ... check out the slides for this.Wolfgang Engelhttps://www.blogger.com/profile/11031097395025597662noreply@blogger.comtag:blogger.com,1999:blog-398682525365778708.post-61372592026582672442009-03-04T15:39:00.000-08:002009-03-04T15:39:00.000-08:00I don't see how this improves over basic deferred ...I don't see how this improves over basic deferred shading. <BR/><BR/>You need a separate full-screen texture for each light source. In basic DS, you need one extra buffer for albieto/material (in addition to color/normal). Then multiple lights can be done without extra buffers. In this approach, you need buffers for every light, so seems like it would be slower/consume memory, esp. with lots of lights.<BR/><BR/>Also, its not clear how shadows would be incorporated, since you would still need to make multiple screen-space passes after the light pre-passes to include the shadowing term.<BR/><BR/>Maybe i'm missing something?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-398682525365778708.post-21543655929370393202009-02-27T09:55:00.000-08:002009-02-27T09:55:00.000-08:00Funnily, I came up with the same lighting idea as ...Funnily, I came up with the same lighting idea as you describe and have been developing full featured renderer for an engine I'm working on by using the technique. While back my ex-collegue mailed me saying "Isn't this light pre-pass rendering technique?", so I guess there's nothing new under the Sun, eh? (:<BR/><BR/>I store normal + glossiness factor to the 32-bit "G-buffer" and have two different light buffers: one for diffuse and one for specular, which are used by the material shading as input textures, so specular lighting isn't a problem. This seems to work great for the few different light types I have implemented so far (directional, omni, spot & line light).<BR/><BR/>There are few screenshots available (http://www.spinxengine.com/index.php?pg=news) and I should release few more soon now that shadows & ssao have been implemented as well. The engine is developed as an open source project so you can try it out if you like (requires VS2008 & DX9).JarkkoLhttps://www.blogger.com/profile/11298410439903207225noreply@blogger.comtag:blogger.com,1999:blog-398682525365778708.post-46377733336439440422009-01-03T17:08:00.000-08:002009-01-03T17:08:00.000-08:00Thinking of similar system,so here is my idea for ...Thinking of similar system,<BR/>so here is my idea for commenting.<BR/><BR/>Pass_Initial {<BR/>RenderTarget_01:<BR/>R16fG16fB16fA16f = <BR/>(RG) ScreenSpaceNormal<BR/>(B) Depth<BR/>(A) packed(A = 8bit+8bit)<BR/>( SpecularGlossness + DiffuseffuseRoughness )<BR/>}<BR/><BR/>Pass_ShadowMaps X+ {<BR/>Render all needed shadowMaps<BR/>(optimize using Pass_Initial,<BR/>as visible fragments are known?)<BR/>(extra "z" or "stencil"-buffer test ?)<BR/>}<BR/><BR/>Pass_LightContributions {<BR/>RenderTarget_01:<BR/>R16fG16fB16fA16f =<BR/>(RGB) combined light diffuse<BR/>(A = AntiAliasing Hint ?) <BR/>RenderTarget_02:<BR/>R16fG16fB16fA16f =<BR/>(RGB) combined light specular<BR/>(A = Unused ???)<BR/>}<BR/><BR/>Pass_FinalComposition {<BR/>RenderTarget_ScreenBuffer:<BR/>Forward Rendering of image<BR/>}<BR/><BR/>/Aki R.Tyrianhttps://www.blogger.com/profile/13721881383170086867noreply@blogger.comtag:blogger.com,1999:blog-398682525365778708.post-77769702057312047892008-12-04T12:27:00.000-08:002008-12-04T12:27:00.000-08:00In a nutshell this is right. If you would render t...In a nutshell this is right. If you would render the specular in any other way you would have the same problems minus the re-construction problem that is introduced by this method.<BR/>Obviously there is lots of room for more accurate specular models than Blinn-Phongs and if you want you can also implement a specular texture look-up by using the 8-bit channel as an index.<BR/>A nice extension of the Light Pre-Pass would be to use a better specular term that can be added and that represents more the real physical nature of specular.Wolfgang Engelhttps://www.blogger.com/profile/11031097395025597662noreply@blogger.comtag:blogger.com,1999:blog-398682525365778708.post-71809592540347660582008-12-04T11:07:00.000-08:002008-12-04T11:07:00.000-08:00Ahh, yep. So you just ignore the inaccuracy. Fair ...Ahh, yep. So you just ignore the inaccuracy. Fair enough!Crno Srcehttps://www.blogger.com/profile/00969066805364684888noreply@blogger.comtag:blogger.com,1999:blog-398682525365778708.post-79348096511092020072008-12-02T07:43:00.000-08:002008-12-02T07:43:00.000-08:00I did not consider this a problem out of several r...I did not consider this a problem out of several reasons:<BR/>1. if you have -let's say more than 2 overlapping specular values- and you see artefacts, you might store your specular power value in the stencil buffer part of the depth buffer or somewhere else. You end up with the same solution that Deferred renderers use this way. Most of the time this is not a problem because you won't see more than 2 overlapping specular highlights.<BR/>Let's assume you see more than 2 overlapping specular highlights in your scene: then the mathematical foundation of the specular term is not your biggest problem. Your biggest problem is that your 8-bit channel won't be enough to hold any sensible representation of those three hightlights and you will hope for that the normal map is detailed that no one notices that for an instance your specular calculation overflowed your 8-bit channel and was at the same time not mathematically correct. Your best argument in that case is that you describe with a smile in your face that we are talking about a really rough approximation of a real-life phenomena that we were not able to represent in any meaningful way anyway. After all specular is represented in all games in a wrong way. So we skillfully added one more way on how to do it wrong and we are proud of it because we proved that graphics programmers can fake things cooler than real life :-)<BR/>2. If you can live with the fact that you use a high-end graphics card capable to calculate statistical data with 32-bit precision but still bound to calculate a term that was developed in 1977 by holding a thumb over one of your eyes long enough so that you loose any sense of perspective and color but see a sufficiently performant approximation of a real-life phenomen that hardly ever happens, you might also try the other term I mentioned:<BR/>(N.H^n * N.L * Att)^nm<BR/><BR/>Obviously the highlight will change its shape this way but I promise it won't be more worse than the difference between Blinn-Phong and Phong.Wolfgang Engelhttps://www.blogger.com/profile/11031097395025597662noreply@blogger.comtag:blogger.com,1999:blog-398682525365778708.post-25666625622013346782008-12-02T04:53:00.000-08:002008-12-02T04:53:00.000-08:00I may have missed it, but I never saw how this pro...I may have missed it, but I never saw how this problem mentioned by Damian is overcome/doesn't matter:<BR/><BR/>>><BR/>Two lights:<BR/><BR/>Channel1 = (a1 * b1) + (a2 * b2)<BR/>Channel2 = (b1 + b2)<BR/><BR/>Want a1 + a2<BR/>but ((a1 * b1) + (a2 * b2)) / (b1 + b2) is not a1 + a2.<BR/>>>Crno Srcehttps://www.blogger.com/profile/00969066805364684888noreply@blogger.comtag:blogger.com,1999:blog-398682525365778708.post-66462487568122246032008-10-02T09:12:00.000-07:002008-10-02T09:12:00.000-07:00This <<<or even in the specular value of ...This <BR/><BR/><<<<BR/>or even in the specular value of the MSAA'ed depth buffer. <BR/><<<<BR/>should have been<BR/><BR/>stencil channel<BR/><BR/>We actually do this in one of our games that uses a Deferred Renderer.Wolfgang Engelhttps://www.blogger.com/profile/11031097395025597662noreply@blogger.comtag:blogger.com,1999:blog-398682525365778708.post-52461644155712661352008-10-02T09:11:00.000-07:002008-10-02T09:11:00.000-07:00Regarding specular: if you want you can use specul...Regarding specular: if you want you can use specular in exactly the same way as with a Deferred Renderer. You store a material specular value in the normal buffer or depth buffer or even in the specular value of the MSAA'ed depth buffer. This extended specular factor is used to re-construct specular in the forward rendering == main pass, so that we can use a wider range of materials. This way you can implement skin, cloth and other materials better.<BR/><BR/>Regarding MSAA: I can't say how much artefacts the non-MSAA'ed light buffer will introduce because I didn't implemented it on a PC platform with MSAA (I wrote testers in RenderMonkey). I would expect those artefacts hard to notice.Wolfgang Engelhttps://www.blogger.com/profile/11031097395025597662noreply@blogger.comtag:blogger.com,1999:blog-398682525365778708.post-68921108067344176392008-10-02T08:44:00.000-07:002008-10-02T08:44:00.000-07:00We posted at the same time :)Looking at your sugge...We posted at the same time :)<BR/><BR/>Looking at your suggestion still makes me wonder. If the light buffer is not the same resolution as the accumulation buffer (i.e. MSAA increases effective resolution of accumulation buffer), would there not potentially be edge artifacts where the lights slightly bleed over the edges? But maybe it wouldn't be very noticable?Christerhttps://www.blogger.com/profile/01254163665525434501noreply@blogger.comtag:blogger.com,1999:blog-398682525365778708.post-23045140416976965022008-10-02T08:34:00.000-07:002008-10-02T08:34:00.000-07:00I'd very much appreciate previewing the article. Y...I'd very much appreciate previewing the article. You can send it to kek_miyu at yahoo dot se (Sweden, not .com).<BR/><BR/>I guess part of my MSAA question is because in deferred rendering you would get edge artifacts if using a resolved MSAA g-buffer (and you can't use MRTs either with MSAA I think). I guess I need to do a bit more research, but is it possible to use a non-resolved MSAA g-buffer as shader input, or am I missing something? Can the g-buffer (light buffer) not be MSAA even though the forward renderer is rendering to a MSAA accumulation buffer (RT), and still avoid artifacts?<BR/><BR/>I was just in the starting blocks for a deferred renderer and I thought this technique seemed interesting as well (considering bandwidth and MSAA). Although, it seems that summing the specular half-vector factors won't give the same results for overlapping lights (as the specular power will be applied to the sum of half vector contributions and not the components of the sum), unless the specular power is available in a g-buffer when generating the light buffer. However, I imagine one could probably live with this overly specular behaviour for overlapping lights.<BR/><BR/>Anyways, great stuff and I look forward to reviewing the article!Christerhttps://www.blogger.com/profile/01254163665525434501noreply@blogger.comtag:blogger.com,1999:blog-398682525365778708.post-8431754139577771652008-10-02T08:12:00.000-07:002008-10-02T08:12:00.000-07:00Pat Wilson from Garagegames implemented this in th...Pat Wilson from Garagegames implemented this in their engine. I don't know if this was the XNA based engine ... but he might provide even more implementation details than I can.<BR/>He is currently in vacation but I can forward you his e-mail address.<BR/>One way you can implement this is that you generate a dedicated depth buffer (assuming there is no depth buffer access in XNA) and a normal buffer with the standard resolution and then you render the light properties into the light buffer with a standard resolution. The chain of draw calls for opaque objects would be:<BR/>- Z Pre-Pass with Depth buffer in MSAA mode<BR/>- fill up special depth buffer and normal buffer (this might be one render target)<BR/>- fill up light buffer<BR/>- draw scene with MSAA'ed Depth bufferWolfgang Engelhttps://www.blogger.com/profile/11031097395025597662noreply@blogger.com