lighting, pixel vs vertex shader?
Author
Hi everyone, following some advice I've gotten from several people previously, I've gone and tried out different things for rendering multiple lights through the directx effect framework. I'm new to directx so I'm still learning and experimenting with a lot of things.
I tried out 1 pass per light and as expected that's rather slow. So I tried out shading multiple lights in one pixel shader pass. It works and it's much faster doing all the calculation for the lights in one pass. But, I ran into a problem of eventually running out of arithmetic instruction in the pixel shader. So I can't really pass in a lot of lights. Eventually I settle for moving the lighting calculation to the vertex shader. The vertex shader seems to either not have a instruction limit, or it allows for many more instructions. In any case, it works, but the result isn't as smooth as pixel shading.
I'm just curious, the pixel shader seems to allow for a comperatively low number of arithmetic instructions. Do people do lighting calculation in the pixel shader? If so, what techniques are used to deal the 64-instruction limit; by limiting the type and number of lights passed into the shader?
What if I really want a large number of lights, is the vertex shader the only way to go?
Any feedback is appreciated. Thanks.
What I do is render a maximum of 2 lights per pass. so if an object is say affected by 4 lights it will require 2 passes in my engine. Same as for 3 lights. The first pass in that case will render 1 light and the second pass will render the other 2 lights. I also try to limit the number of lights that can affect an object. I also use scissor rectangles and am sure to render the scene objects with ONLY the lights that are truly visible in my scene.
I am using PS 2.0 which has I think a 96 instruction limit.
Other solutions which I currently have not tried and have no experience in but might help you are to look at deferred lighting which allows you to light a scene independent of scene complexity.
I hope this helps,
I am using PS 2.0 which has I think a 96 instruction limit.
Other solutions which I currently have not tried and have no experience in but might help you are to look at deferred lighting which allows you to light a scene independent of scene complexity.
I hope this helps,
1. Most shader 2 hardware actually supports ps_2_x which (depending on the device caps) is capable of flow control, so you can loop over your lights.
2. Shader instruction limits are just something you have to work within, no magic wand unfortunately. Move as much computation as possible to the vertex shader (as long as its a value that will linearly interpolate across the face of the polygon correctly) and pass the values in any spare component (the alpha channel of colours, unused dimensions of texture coordinate, etc). The whole computation doesn't need to be in the VS - just split the work.
3. If you're forced to do some of your lighting per vertex and some per pixel, doing diffuse per-vertex and specular per-pixel looks ok.
4. Assess your lighting model - are you expecting too much for shader 2 hardware? What's more important, more lights or fewer better looking lights?
5. Deferred rendering/shading will get you lots of lights - though it's not a decision to take lightly.
6. Most people scale back the number of lights they have per frame - usually with some form of dynamic "light manager" that merges lights and decides which ones should have the most effect. An example would be a maximum of 8 lights with only 4 of those being per-pixel, and only 2 being full quality per pixel. I know for a fact that some of the best looking "next gen" games are doing even less - it's all about spending the performance budget on what's most important. It's probably only your main scene light source (e.g. sun or closest light bulb) that needs the full advanced_diffuse_bumpy_specular_Fresnel_refraction effect, most'll get away with some plain ol' Lambert & Blinn.
7. Image based and pre-baked lighting isn't dead yet, far from it. Its only the lights that move that need diffuse computing every pixel every frame. Even with specular, there's a lot you can do with a cube map too..
2. Shader instruction limits are just something you have to work within, no magic wand unfortunately. Move as much computation as possible to the vertex shader (as long as its a value that will linearly interpolate across the face of the polygon correctly) and pass the values in any spare component (the alpha channel of colours, unused dimensions of texture coordinate, etc). The whole computation doesn't need to be in the VS - just split the work.
3. If you're forced to do some of your lighting per vertex and some per pixel, doing diffuse per-vertex and specular per-pixel looks ok.
4. Assess your lighting model - are you expecting too much for shader 2 hardware? What's more important, more lights or fewer better looking lights?
5. Deferred rendering/shading will get you lots of lights - though it's not a decision to take lightly.
6. Most people scale back the number of lights they have per frame - usually with some form of dynamic "light manager" that merges lights and decides which ones should have the most effect. An example would be a maximum of 8 lights with only 4 of those being per-pixel, and only 2 being full quality per pixel. I know for a fact that some of the best looking "next gen" games are doing even less - it's all about spending the performance budget on what's most important. It's probably only your main scene light source (e.g. sun or closest light bulb) that needs the full advanced_diffuse_bumpy_specular_Fresnel_refraction effect, most'll get away with some plain ol' Lambert & Blinn.
7. Image based and pre-baked lighting isn't dead yet, far from it. Its only the lights that move that need diffuse computing every pixel every frame. Even with specular, there's a lot you can do with a cube map too..
Quote:Original post by S1CAThis is an important observation that I see relatively few people cashing in on [smile]
3. If you're forced to do some of your lighting per vertex and some per pixel, doing diffuse per-vertex and specular per-pixel looks ok.
Most implementations you'll find in demos/samples don't need to worry too much about performance or hardware limitations so they do the "all or nothing" approach. There is nothing wrong with splitting terms across different stages of the pipeline - it can be a very powerful technique.
For example, LOD lighting - swap out a complex but accurate specular highlight for a cheaper Blinn-Phong if the object is small or at a distance. Move low-frequency lighting to the vertex shader (or upload it as a per-object constant) and keep high-frequency lighting in the pixel shader (Simon's comment about diffuse per-vertex and specular per-pixel)...
Quote:Original post by S1CAI'm sure it'll be around in some form for a long time to come, but I argued against this point in the opening chapter of my section of our book [grin]
7. Image based and pre-baked lighting isn't dead yet, far from it. Its only the lights that move that need diffuse computing every pixel every frame. Even with specular, there's a lot you can do with a cube map too..
I went with the angle that the noticeable trend towards more dynamic models and environments (be it character animation or physics-based) works against the idea of pre-computed/static lighting...
Cheers,
Jack
Quote:Original post by jollyjeffersQuote:Original post by S1CAI'm sure it'll be around in some form for a long time to come, but I argued against this point in the opening chapter of my section of our book [grin]
7. Image based and pre-baked lighting isn't dead yet, far from it. Its only the lights that move that need diffuse computing every pixel every frame. Even with specular, there's a lot you can do with a cube map too..
I went with the angle that the noticeable trend towards more dynamic models and environments (be it character animation or physics-based) works against the idea of pre-computed/static lighting...
To my mind the common rule for this kind of thing realtime graphics has always been "if you can't do it in realtime, find an acceptable approximation or hack. If you can't find an acceptable approximation, do the hard bit(s) offline. If you can't do that do it all offline and suffer the static nature".
That doesn't mean "Quake 2 style additive lightmaps are here to stay", just that some amount of pre-computation and storage is. Think ambient occlusion, think SH, think PRT, etc.
In the approximation/hack territory there's nothing to stop you doing things like rendering local lights (or aspects of) to make it look like you're doing something you're not; hey, sky boxes and plain environment maps are pretending to be big area lights that handle all manner of real-world things that happen with light [smile]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
