Hello everyone, I was wondering if it was possible to do per pixel lighting on the programming pipeline in directx. If you know an example or a tutorial that can achive this please let me know. I know how to do per pixel lighting with shaders and it looks great but I can only do two lights. For what is worth, if you know how to support more that two lights with pixel shaders, I'm sure my computers graphic card can't handle it but I will like to know anyway. Thanks.

Any lighting equations implementing in the pixel shader are per-pixel, so yes - it's definitely possible in the programmable pipeline [smile]

Most people tend to use a tangent-space transformation in the vertex shader and then implement their BRDF in the pixel shader. There are 100's of examples of this sort of thing online - just look up "normal mapping", "tangent space lighting" or similar terms...

Quote:if you know how to support more that two lights with pixel shaders, I'm sure my computers graphic card can't handle it but I will like to know anyway.

You have two options, either use a bigger/better shader model (for example, ps_2_0 can do 4 simple lights iirc but ps_3_0 and ps_4_0 could potentially do hundreds via looping constructs) or multi-pass your rendering.

You can do simple multi-passing by using the pass{/*..*/} construct within a technique or you can do it manually using additive blending. It's simple enough to do and supported on all relevant hardware, but it is slower.

A common tactic is to dynamically scale according to the hardware - a decent SM3 card will run a looping shader with 8-10 lights in a single pass, a mid-range SM2 card will run 3-4 passes each with 2-3 lights, and a low-end card will run 10 passes with a single light each. It's not too hard to write code to handle all of these cases.

hth
Jack

Quote:Any lighting equations implementing in the pixel shader are per-pixel, so yes - it's definitely possible in the programmable pipeline

I stated the question wrong and I did not mean programmable pipeline, I was trying to say "in the program". I was asking if I can catch the pixel information and manipulate it before it is send to the card. So I can do the lighting equations in my program instead of the shader? It may be cool to have some calculations done before the shader.

About normal mapping, I've read about it and I get what you are saying, is like preparing your pixel shader in your vertex shader.

So far my card only supports ps_2_0 and that's why I can only do 2 point lights. I haven't even tried to do spots.

Sorry for the misunderstanding.

Quote:Original post by mvtapia
I was asking if I can catch the pixel information and manipulate it before it is send to the card.

You can provide inputs in the form of textures, so if you use a function like D3DXFillTexture() you can provide appropriate inputs. But you can't execute application code on the CPU between the vertex shader and pixel shader.

Quote:Original post by mvtapia
So I can do the lighting equations in my program instead of the shader? It may be cool to have some calculations done before the shader.

What you're describing sounds more like "light mapping" where you compute lighting models, store the results in the texture and then render the results accordingly. This tends to lead to better quality lighting but the trade-off is that it is usually static.

I do similar for one of my more complex lighting models where I can factor out a sin() and tan() operation into a single texture look-up. The lighting model is computed in the pixel shader, but I use the CPU to do some of the hard work first...

Quote:Original post by mvtapia
So far my card only supports ps_2_0 and that's why I can only do 2 point lights.

ps_2_0 allows for 64 arithmetic instructions and 32 texture samples (from 16 unique samplers). Therefore the limitation is purely how much you can represent within that instruction count - if the compiler cannot reduce your HLSL down then compilation fails...

hth
Jack