in the program I am working on, nearly everything is inside of display lists. But now I have to implement per pixel lighing/bump mapping, and I guess the display lists can no longer be used, as for bump mapping/per pixel lighting, the geometry data is no longer static but changes (when the light source moves), as the light vector (transformed to face tangent space) is used as texture coordinate input for the normalization cube map. I simply would like to know if I am right with this.
With a vertex program you can deal with display lists.
Without a vertex program, you have to compute yourself the half-angle vectors and things like that which change dynamically per-vertex, and in this case : no you may not use display lists .
This is the case for emboss style bump mapping, but there are extensions to allocate arrays in AGP mapped memory and keep the data transfer to the card fast. However, probably even more portably (broadly supported) and faster, you can compute the displacement of the vector in a vertex program without the need for dynamic geometry. Even more sophisticated things are possible on modern hadrware like a true L.N calculation per pixel with a vertex program to set up the colors & tangent space transform for the DOT3 texture operation, in fact the vertex setup is very similar to the light vector transform to tangent space in emboss bump mapping anyway.
This DOT3 bump mapping is not particularly tricky, it’s been possible since GeForce (1) class hardware so it’s pretty ubiquitous now.
well as far as i know the kind of bump mapping i mean is NOT emboss bump mapping!? am i wrong? afaik emboss bump mapping is something completely different.
I rather mean the following (very simple case):
texture unit 1: normalization cube map with light vector as input
texture unit 2: normalization cube map with vertex normal vector as input
tu1 and tu2 blending mode dot3
texture unit3: color texture
blending mode: modulate
should result in per pixel lighting… but as i said, i guess its not possible to use display lists any longer.
what kind of bump mapping technique do you think is “best” anyway? if its possible, to get diffuse and specular bump mapping/per pixel lighting include a texture map, a normal map and a gloss map in a single pass AND to run in nvidia as well as ati hardware? is that possible at all?
but what bump mapping technique would you generally recommend? I just started to work on it and i really don’t know where to start (except for my simple per pixel lighting idea. would this work anyway?).
I guess for specular bump mapping with a gloss map you do at least need register combiners, better fragment program?
specular (eventually with gloss map) in the 2nd pass
You need at least 3 texture units for specular+gloss, so will have to do without gloss maps on GeForce1/2.
>> I guess for specular bump mapping with a gloss map
>> you do at least need register combiners
You can do it with register combiners, but you don’t “need” them.
Though, if you have a nVidia card you will be able to get a much higher specular exponent with NV_rc than you would with ARB_combine/ARB_dot3
At best, if you can use fragment programs, you don’t even need to use normalization cubemaps since you can normalize the vectors in the fragment program. But keep in mind that only high-end cards do support ARB_fragment_program actually.
for fragment program i need at least a gf fx I guess?