   Deferred rendering, variable amount of arguments to shader ( like ... in C )
  Hello,Just to see if I understand correctly; in deferred rendering, you don't do light calculations but you store them in a texture. Then when you draw the scene, you use those stored values to calculate the light only once, instead of forward rendering where you have multiple passes blended together. Right? And of course you don't light pixels that aren't written to the screen.I was wondering whether you could pass a variable length argument list to a shader? So if there are a runtime determined amount of lights, you can do it in a single pass? Or maybe pass an array that takes 20 ( disregarding the places that aren't used )? Or write a shader that takes 4 lights, so you can at least do 4 lights at the same time...Or am I missing the point?   
Quote:I was wondering whether you could pass a variable length argument list to a shader?Use a 1D texture.I did use that technique to forward position and proprieties of an arbitrary number of lights to a shader.   ;  Deferred shading is a beautiful thing. It sounds like you're just getting started. The nice thing about deffered shading is it eliminates the need for redundent vertex processing when you need lots of lights (lots of passes). The vertices dont change in between lights so why reprocess them?Lighting is not stored in the "texture" aka the g-buffer, geometry is. Position, normal, and material information for the triangles is stored in the gbuffer. Then in the deferred shading stage, the final scene is composed by referencing the gbuffer and performing lighting calculations per light. In the simplest form the lighting shader in a deferred shading system is utilized by drawing a full screen quad. And in a sense it's a light filter for the gbuffer. You can draw as many of these quads, or filters, using the gbuffer as you want and that's the sweet part. Your only geometry cost during lighting is reading that gbuffer texture, regardless of how complex the scene is.So, in the 'simplest form' you'd have 1 light per shader, say it's a spot light. For each spot light in your scene you'd draw a screen sized quad computing the final output using the gbuffer, adding these passes together as you go.But one major sweet thing about deferred shading is the fact that you only have to draw your lighting primitive (quad up until now) the size of the light on screen.So, a sun is going to pretty much light everything, you'll use a full screen quad for directional lights. But for point lights, they'll have a sphere of influence, there maximum lighting distance. You only have to draw a small circle with which to apply your point light shader. As you mentioned you can combine lights in one shader, but if you do this, it will complicate how you determine the screen size of the lighting primitive.Basically, in conclusion, dont' worry about passing an arbitrary amount of arguements, you wont need it. Get it up and running with a very basic system and then you'll realize more what you need.P.s. ... is the devil.   ;Quote:Original post by bzroom... is the devil.Yay that made me laugh.;  There's a few ways to get the data for multiple lights into your shader...for simplicity you'll probably want it to be the same method you use to for rendering multiple instances of your bounding geometry.  The three most common approaches are filling a dynamic vertex buffer with pre-transformed vertices, filling an array of shader constants with per-instance information and then retrieving it in the vertex shader, and using hardware instancing.  Hardware instancing is the best in terms of performance and flexibility, but is only available on Shader Model 3.0-level hardware and above.  