   HLSL & many lights: doubts
  Hi guys !I've read some good discussions in this forum about how to render many lights using HLSL.I'm developing an FPS engine, so I expect to be kinda an average of a dozen lights VISIBLE per frame. The question is, how to render them ?I personally don't like the idea of rendering the whole scene as many times as the number of lights. To me it sounds too slow.Deferred rendering seems to be to hard for now... ( for now :D )Today I decided to use an approach where you have an array of lights properties inside the pixel shader. It looks like this:static const int MAX_LIGHTS = 10;float3 vLightPosition[MAX_LIGHTS];float3 vLightColor[MAX_LIGHTS];int    iLightCount;  //  number of lights to take into accountthen you use a for cycle to add every light contribute. It works great.Questions are:1- do you think this is a good approach ?2- why the higher is MAX_LIGHTS, the slower is the rendering, regardless of iLightCount ? With MAX_LIGHTS =40 the engine runs slow even with just one light.3- I know there is a limit to MAX_LIGHTS, but I don't know why. Could someone explain it ?And how have you resolved the task of having N lights ?THANKS A LOT GUYS,have a good developing ;)   
  The typical issue with this approach is that even with ten lights in a scene, the odds are pretty low that a given pixel will be affected by more than two or three lights.  This results in some pretty heavy calculations for a bunch of lights that don't contribute to the final output.You could try using dynamic branching, but it would still be pretty inefficient to follow this path.  That is partially the momentum behind developing deferred renderers - its not easy to do it with forward rendering [grin].Check out Wolfgang Engel's light pre-pass renderer in ShaderX7 for an interesting take on 'many' light renderings.   ;  do they need to be dynamic?if they dont, they you can get away with using lightmaps for simplicity.theres lots of documentation on how to generate them :) and they are super simple to render too..and you can use as many lights as you want!and if you want to make things complex, theres always PRT/SHlife is a lot simpler with a minimal number of dynamic lights.   ;Quote:Original post by Matt_Dlife is a lot simpler with a minimal number of dynamic lights.Sure, but not nearly as dynamic!  [grin];  Maybe lightmaps will come later, but now I wanna be able to handle at least 4-5 dynamic lights.What type of lightning model were using titles like DooM3, FEAR, Far Cry and similar ???   ;Quote:Original post by NiGoeaHi guys !I've read some good discussions in this forum about how to render many lights using HLSL.I'm developing an FPS engine, so I expect to be kinda an average of a dozen lights VISIBLE per frame. The question is, how to render them ?I personally don't like the idea of rendering the whole scene as many times as the number of lights. To me it sounds too slow.Deferred rendering seems to be to hard for now... ( for now :D )Today I decided to use an approach where you have an array of lights properties inside the pixel shader. It looks like this:static const int MAX_LIGHTS = 10;float3 vLightPosition[MAX_LIGHTS];float3 vLightColor[MAX_LIGHTS];int    iLightCount;  //  number of lights to take into accountthen you use a for cycle to add every light contribute. It works great.Questions are:1- do you think this is a good approach ?2- why the higher is MAX_LIGHTS, the slower is the rendering, regardless of iLightCount ? With MAX_LIGHTS =40 the engine runs slow even with just one light.3- I know there is a limit to MAX_LIGHTS, but I don't know why. Could someone explain it ?And how have you resolved the task of having N lights ?THANKS A LOT GUYS,have a good developing ;)I can tell you that the slowdown is likely caused by a very low-level concept that probably isn't even mentioned in all the various shader tutorials out there. It has to do with register usage and the number of threads your graphics card runs to actually do shading, etc. but it's very nuanced and I won't go into detail for fear of confusing you/instilling possible wrong ideas. It's dependent on your hardware, too.EDIT: Then there's also the straight-up loop unrolling that happens for older shader models, too. Meant to include that in my original response but glossed over it somehow :\ Long story short-- you're still doing calculations for 40 lights.Out of curiosity, what's 'difficult' about deferred shading, exactly? Though I recall being thrown somewhat by initial descriptions of the technique, I can safely say most of my problems were caused by less than optimal descriptions of how it worked. Chances are you may be a victim of this too.Finally-- Doom 3 uses a regular forward-shading pipeline that does a Z-only prepass for dropping obscured pixels before any shading gets done. Other than that it just makes heavy use of scissor and culling operations. F.E.A.R. is a plain forward-shading pipeline that batches lights somewhat. No idea on Far Cry.[Edited by - InvalidPointer on June 26, 2009 3:56:44 PM];Quote:Original post by NiGoeaWhat type of lightning model were using titles like DooM3, FEAR, Far Cry and similar ???Doom 3 used a unified lighting model where everything was done with multipass dynamic light sources.  FEAR and Far Cry used a mix of light maps and dynamic light sources...I'm not sure about FEAR but Far Cry would either multipass the lights or do up to 4 or so in the shader (depending on the shader model path that was being used).  Crysis uses completely dynamic lighting with forward rendering, but CryEngine 3 has switched to a light pre-pass approach.;Quote:Original post by InvalidPointerQuote:Original post by NiGoeaI can tell you that the slowdown is likely caused by a very low-level concept that probably isn't even mentioned in all the various shader tutorials out there. It has to do with register usage and the number of threads your graphics card runs to actually do shading, etc. but it's very nuanced and I won't go into detail for fear of confusing you/instilling possible wrong ideas. It's dependent on your hardware, too.EDIT: Then there's also the straight-up loop unrolling that happens for older shader models, too. Meant to include that in my original response but glossed over it somehow :\ Long story short-- you're still doing calculations for 40 lights.You are the man I was looking for :)I've just opened another topic about this fact, because I noted others new weird things...I invite you to come there to answer, if you don't mind ;-)Anyway, are you assuring me that the loop is running 40 times ?? If so, why an internal counter increments iLightNum times ? (come to the other topic where I'm talking about this).Quote:Out of curiosity, what's 'difficult' about deferred shading, exactly? Though I recall being thrown somewhat by initial descriptions of the technique, I can safely say most of my problems were caused by less than optimal descriptions of how it worked. Chances are you may be a victim of this too.Well, it's just a feeling. For sure, it's ways more difficult than standard lightning techniques.Moreover, I've read it doesn't allows transparency (which is, right now, something I don't care about...).Anyway, I planned to switch to that advanced lightning model. But I'm still undecided between deferred of light pre-pass.Quote:Finally-- Doom 3 uses a regular forward-shading pipeline that does a Z-only prepass for dropping obscured pixels before any shading gets done. Other than that it just makes heavy use of scissor and culling operations. F.E.A.R. is a plain forward-shading pipeline that batches lights somewhat. No idea on Far Cry.So Doom3 goes like that:- render without lights- for each pixel of the frame buffer:* go back to the 3D position and normal* for every light, add contributeis it like that ? it doesn't sound new... it looks like Light Pre-PassQuote:Original post by MJPQuote:Original post by NiGoeaWhat type of lightning model were using titles like DooM3, FEAR, Far Cry and similar ???Doom 3 used a unified lighting model where everything was done with multipass dynamic light sources.  FEAR and Far Cry used a mix of light maps and dynamic light sources...I'm not sure about FEAR but Far Cry would either multipass the lights or do up to 4 or so in the shader (depending on the shader model path that was being used).  Crysis uses completely dynamic lighting with forward rendering, but CryEngine 3 has switched to a light pre-pass approach.So Far Cry uses at maximum 4 dynamic lights ??   