Texture shader bump mapping w/ combiners

Now that i have hardware that can do texture shaders im going to give them a try. What i want to do is do the diffuse and sepcular calcs w/ bumps by using the texture shader plus still have the other things i have in my lighitng engine like attenuation, selfshadow etc. Now im writing this b/c i think i have the right idea but im still unsure about the texture shaders.

Here is what i think has to be done, if i am wrong in any part please tell me, i wanna make sure i understand this correctly.

*Enable texture shaders and set them up like this:
nvparse(
"!!TS1.0
"
"texture_2d();
"
"dot_product_reflect_cube_map_eye_from_qs_1of3(tex0);
"
"dot_product_reflect_cube_map_eye_from_qs_2of3(tex0);
"
"dot_product_reflect_cube_map_eye_from_qs_3of3(tex0);
" );

Where i bind tex0 w/ my normal map and i guess bind tex3 with a normal cube map or something.

*Then take this result which i think is in tex3 and multiply that with the attenuation/selfshadow/etc calcs in the combiners.

I think thats kinda close one how to do what i want. The thing im not sure about is the specular. I think the last texture shader instruction there computes the reflection vector which is used for specular but then how do i do the exponent part? I like the idea i can do good looing per pixel specular with a high exponent in the texture shaders but im kinda confused on parts. I looked at some demos but im not sure what they are doing at parts.

Also what does the qs part in the above texshade instructions stand for? I didnt see where they mentioned that in any presentation.

Thanks for your help.

-SirKnight

well, from what i learned just recently (you can look at my last post), the tex shader computes (hn) or (rn) and use this and (ln) as two tex coords in an illumination map. the illumination map is just the dot products itself, i mean (rn,ln)==>(rn^e,l*n)
this way you can have any exponent you want, and not waste combiners on squaring the spcular component.
i think im right, it would be nice to get approoved.

Well that sounds pretty good. The good thing now with the texture shaders is we can have nice looking per pixel specular with a high exponent to look real and not have bad banding problems like with the squaring combiner method.

I have been looking at that bump_reflect_local_light program and i really do like it but i tried out what was said about when the light gets close and yes, the specular gets pretty wierd. It starts to look almost more like per vertex specular in a small way but worse of all there is a little shiny spot that follows the main highlight around like a little puppy. It shoots around from vertex to vertex and in a way its kind of funny to watch. Im not yet sure why this is occuring but im trying to figure out why its doing it.

But, before i do that i need to understand a few things. First, what does the H in that H matrix stand for? I thought halfangle at first but i dont think so. Also why is it computed the way it is? Also the whole texel matrix thing is confusing me. This program shows that to compute the texel matrix, this H matrix thing has to be multiplied with M^-T which i think means inverse modelview transpose. Or is it just inverse modelview and NO transpose. Well anyway, that then is multiplied by the product of S and B, what ever those are. And then it just goes from there. Could any one either explain all of this a bit or show me a place that would? Ive looked around different places but no luck. If i could figure all that out, then i could understand more on doing this type of thing with tex shaders and maybe solve the problem this program has when the light is close.

-SirKnight

[This message has been edited by SirKnight (edited 04-04-2002).]

Doesn’t any one know? Any one at all?

The only thing i dont really get yet is what is being done in the vertex program of bump_reflect_local_light which is what i was asking about in the last paragraph of my previous post.

-SirKnight

Isn’t the problem with that approach that your specular and diffuse get put in the same color channel? Remember that “actual” illumination is more like:

out_rgb = (base_rgb*(diffuse+ambient))+specular

unless the “specular” is “metallic”; i e shades the specular highlight. Most materials (including “metallic” car finishes) are NOT “metallic” in this sense.

Perhaps something cunning could be done in the alpha of the illumination map to figure out how much is contributed from specular and how much from ambient/diffuse.