perpixel diffuse lighting means perpixel calculating this:
normalized(light - pos) dot normalized(normal)
where light - pos can be calculated per vertex in the vertexprogram and then pushed over as texcoord to look up the normalized coord in a normalization-cubemap.
if we do that, we have to use registercombiners to do the dotproduct instead of the texture-shaders.
first: the registercombiners ARE cool and let you do much complex things while not letting you do much simpler other things sometimes
but even nvidia has to say don''t use them for big calculations they are much too inprecious.well if we do so, we have to use a normalmap with rgb-format. that means, not normalized perpixel due linear filtering. we could use a normalmap again, but that only on gf4, where it eats up one additional texturestage and a dependent read. this means we use yet 3 of the 4 texture-stages. one additional for the diffuse-color-map and we''re filled up. now we can do the calculation in the registercombiners and get nice diffuse lighting. mathematically correct but quite unprecious. and it only yet diffuse lighting (ok incl selfshadowing if you want, but thats it). this means it needs a full geforce4 to do that, even a gf1 supports the dotproduct and the cubemaps and all but the gf4 is the first wich can do ONE CORRRECT PERPIXEL DIFFUSE LIGHT. wow.. took quite long, doesn''t it?
next. to do the diffuse lighting in higher precision and with less memory etc, we wanna use textureshaders wich work in mixed floatingpoint, 16bit and 8bit math. there we can use a HILOmap as the normalmap-format and as a result we get a always-normalized normal. but only for the textureshaders, not for the registercombiners afterwards. this means we have to do the dot in the ts. now the ts can do dotproducts in highprecision. but they can''t normalize the point_to_light vector => impossible.
next is to unwrap the equation:
dot(normalized(point_to_light),normal/*yet normalized*/) ==
dot(point_to_light,normal)/length(point_to_light);
this means we could dot by the unnormalized point_to_light vector without problems, if we could dot the point_to_light with itself and use this as a 1d-texture-lookup into the function f(x) = 1/sqrt(x)
but this is not possible in the textureshaders eighter..
so we can''t dot the point_to_light with itself in the shaders, that means we have to use the vector in itself. result: we use a 3dtexture to look up this function:
f(x,y,z) = 1/sqrt(x^2+y^2+z^2). and we need this quite precious => huge 3dtexture. and it is NOT perpixel then but per voxel of the 3dtexture. and you can actually SEE that, too
(the 1d is much more precious because 1) you can have it as 1024-lookuparray and u use damn less memory anyways while the tex3d eats up tons of mem, second the 1d-lookup only depends on distance, not on direction as the 3d-texture does.)well and this was only diffuse lighting..
now if you want more than 1 diffuse light per pass you run out of texture-stages and texcoords.
don''t lets start talking about distance-attentuation and specular lighting and all the fun..
oh, and ever thought of perpixelvariable exponent of the specular? radeon8500 can do it..
the radeon is programable, the geforces arent. only the registercombiners, but not the textureshaders...
my 2 cents..
if you want more, you can get more
btw. even the gf1 can do nice perpixellighting with diffuse and specular and everything, but only with near-to-correct math (and not very near-to
).http://tyrannen.starcraft3d.net/PerPixelLighting shows imho quite good looking stuff..
but you need a high tesselation of the geometry to get nice perpixellighting on geforces wich is sort of stupid, isn''t it?
the idea is to do geometry-independent lighting..
