Going by the DHPOWare bumpmapping example, I was able to create an almost-working bumpmap shader:
There is a single directional light in the scene, but the light vector seems to move with the camera rotation.
I have uploaded the demo here .
If anyone could take a look at the shader, I would appreciate it. I’m going to need to get a few miscellaneous shader features added, and I would be interested in paying someone for some more help.
the light vector seems to move with the camera rotation
When this happens it usually means that you’ve specified your lights - via glLight*() - before you’ve loaded your modelview matrix. OpenGL treats the direction of a light source just as it treats the position of geometric primitives. This means that when glLight*() is called the light direction is transformed by the current modelview matrix. Try calling glLight*() to setup your lights after loading your modelview matrix.
I should have been more specific. The light itself appears correctly. The light calculation in the shader is working.
The bumpmapping however moves with the camera. I don’t think the dhpoware bumpmapping example handles camera orientation.
I vaguely recall in the past I was doing the multiply like in your code. I vaguely recall it did not work either. Pulling my hair out too. 
But I broke it out into separate dot products. I think the tbn calculation is the more difficult part. But assuming you calculated tbn correctly, how about…
vec3 t = normalize( gl_NormalMatrix * gl_MultiTexCoord2.xyz );
vec3 b = normalize( gl_NormalMatrix * gl_MultiTexCoord3.xyz );
vec3 n = normalize( gl_NormalMatrix * gl_Normal );
lightDir.x = dot(gl_LightSource[i].position.xyz, t);
lightDir.y = dot(gl_LightSource[i].position.xyz, b);
lightDir.z = dot(gl_LightSource[i].position.xyz, n);
lightDir = normalize(lightDir);
//grab the normal
vec3 norm = expand( texture2D(texunit1, tex_coord).xyz );
//normalize the light vector
vec3 _l = expand( textureCube(cubemap,lvec1).xyz );
//calculate the diffuse factor
float diffuse = max(0.0,dot(norm,_l));
Hope it helps…
Perhaps you could try it and let me know if you find anything out. 
I could randomly poke at it all day, and nothing would come of it.
I am calculating the vertex mapping axes as below. This worked on my CPU implementation that just set the vertex colors:
For t=0 To counttriangles()-1
a=trianglevertex(t,0)
b=trianglevertex(t,1)
c=trianglevertex(t,2)
'If vertexupdated[a]=0 Or vertexupdated[b]=0 Or vertexupdated[c]=0
v1x#=PeekFloat(vertexarray,a*12+0)
v1y#=PeekFloat(vertexarray,a*12+4)
v1z#=PeekFloat(vertexarray,a*12+8)
v2x#=PeekFloat(vertexarray,b*12+0)
v2y#=PeekFloat(vertexarray,b*12+4)
v2z#=PeekFloat(vertexarray,b*12+8)
v3x#=PeekFloat(vertexarray,c*12+0)
v3y#=PeekFloat(vertexarray,c*12+4)
v3z#=PeekFloat(vertexarray,c*12+8)
w1x#=PeekFloat(texcoordarray[0],a*8+0)
w1y#=PeekFloat(texcoordarray[0],a*8+4)
w2x#=PeekFloat(texcoordarray[0],b*8+0)
w2y#=PeekFloat(texcoordarray[0],b*8+4)
w3x#=PeekFloat(texcoordarray[0],c*8+0)
w3y#=PeekFloat(texcoordarray[0],c*8+4)
x1:Float=v2x-v1x
x2:Float=v3x-v1x
y1:Float=v2y-v1y
y2:Float=v3y-v1y
z1:Float=v2z-v1z
z2:Float=v3z-v1z
s1:Float=w2x-w1x
s2:Float=w3x-w1x
t1:Float=w2y-w1y
t2:Float=w3y-w1y
r:Float=1.0/(s1*t2-s2*t1)
sx:Float=(t2*x1-t1*x2)*r
sy:Float=(t2*y1-t1*y2)*r
sz:Float=(t2*z1-t1*z2)*r
tx:Float=(s1*x2-s2*x1)*r
ty:Float=(s1*y2-s2*y1)*r
tz:Float=(s1*z2-s2*z1)*r
Normalize(sx,sy,sz)
sx=VectorX()
sy=VectorY()
sz=VectorZ()
Normalize(tx,ty,tz)
tx=VectorX()
ty=VectorY()
tz=VectorZ()
'If vertexupdated[a]=0
vertexupdated[a]=1
PokeFloat mappingaxisarray[0],a*12+0,sx
PokeFloat mappingaxisarray[0],a*12+4,sy
PokeFloat mappingaxisarray[0],a*12+8,sz
PokeFloat mappingaxisarray[1],a*12+0,tx
PokeFloat mappingaxisarray[1],a*12+4,ty
PokeFloat mappingaxisarray[1],a*12+8,tz
'EndIf
'If vertexupdated[b]=0
vertexupdated[b]=1
PokeFloat mappingaxisarray[0],b*12+0,sx
PokeFloat mappingaxisarray[0],b*12+4,sy
PokeFloat mappingaxisarray[0],b*12+8,sz
PokeFloat mappingaxisarray[1],b*12+0,tx
PokeFloat mappingaxisarray[1],b*12+4,ty
PokeFloat mappingaxisarray[1],b*12+8,tz
'EndIf
'If vertexupdated[c]=0
vertexupdated[c]=1
PokeFloat mappingaxisarray[0],c*12+0,sx
PokeFloat mappingaxisarray[0],c*12+4,sy
PokeFloat mappingaxisarray[0],c*12+8,sz
PokeFloat mappingaxisarray[1],c*12+0,tx
PokeFloat mappingaxisarray[1],c*12+4,ty
PokeFloat mappingaxisarray[1],c*12+8,tz
'EndIf
I’ll pay $100 if someone can get the directional, spot, and point light bumpmaps working, and average the results for each light together so that it only needs to be drawn in one pass. This seems like kind of a waste of time for me to work on, and I don’t think it would take long for someone to do who had more experience in this area.
You can get most of it for free with the 3dlabs shader gen program.
Just fill out the form and viola. Not sure it does bump maps though…
http://developer.3dlabs.com/downloads/shadergen/
Hope that helps.
ShaderGen produces some good lighting code to learn from, but it doesn’t help me with bumpmaps.
It took some research for me to figure it out. There are a few good tutorials out there. In general, this might help you along…
Even though your using glsl, I’d look at the “The CG Tutorial” book because it has a good section on bump mapping. ( sections 8.2, 8.3, 8.4, 8.5) Be prepared for math.
Also, here are some links…
This is for the fixed pipeline …
http://www.paulsprojects.net/tutorials/simplebump/simplebump.html
Here is another good tutorial. Again it uses CG but I thought the math explanations were helpful ( and might clarify what you glean out of the cg tutorial book especially with the math )…
http://www.blacksmith-studios.dk/projects/downloads/bumpmapping_using_cg.php
The orange OpenGL Shading Language book has a small blurb about bump mapping. Might help you a little less but you can get the glsl syntax from it.
But you’ll notice that most sources will give the shading code but will not be as clear about building the tbn matrix in your application code.
Cynically, when you see confusion in the documentation, then you know its an important subject. ( like shadows ! )
Hope that helps… 
Well I think what’s happening is the shader multiplies the TBN matrix by the NormalMatrix, which includes both the matrix of the mesh, and the camera matrix. What I think needs to happen is it needs to multiply the TBN matrix by the NormalMatrix (which includes the camera orientation) and then multiply that result by just the camera matrix. Does this sound right?
This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.