As you see bump-mapping works but I am only computing a perturbation normal not a normal map normal. To get my light-direction I loaded a deluxe map I generated in FTE Quake which seems to be a stored average of all the light directions on the map. Unfortunately I am having a horrible time getting normal mapping working from here and I don't really see what the problem could be. For now I will have to put it on the back-burner unless someone can give me some direction. Theoretically there shouldn't be a problem since perturbation works and I seem to have the right tangent. Oh well, on to other things, I will revisit this later.

*Update - normal mapping fixed:



**Update Bump w/ Gloss:

Spike?

.lux files should be in object space.
Just draw them without bumpmapping as a single texture and ensure that they're some sort of light shade of blue. That applies to your bumps/normalmaps too.
Basically the normalmap and lux map need to be similar colours (identical = no bumps, complete contrast = bumps going the wrong way).

Ensure the textures are normalised. FTE does this as part of lightstyle blending/uploading. I'm not sure how effective doing that in the glsl would be.

The maths you want is (normalmap dot lux) * diffuse * lightmap
There's no need to consider surface normals/orientation/rotation.

Happy now, Zalon?

I'm always happy

Thanks for the reply spike. I finally had a chance to sit down and look at this again. My code was fine, the problem was because I accidentally was loading the spec map as the norm map (programming blunder of the year.) Here's just bump w/o spec:



Spike: The maths you want is (normalmap dot lux) * diffuse * lightmap

Multiplying the diffuse by the light-map gives me the wrong pixel values in glsl. In order to get the right values I do a blend:
vec3 pixel = mix(base_map.rgb, gl_TextureEnvColor[1].rgb, light_map.rgb);

This also has the added benefit of blending dynamic lights properly.

Yeah, forgot to mention that normalmaps being textures (logically 0 to 1) means you need to scale and bias them in order to make them actual normalmaps, mneh. still, if it works it works.

Is it my imagination, or are you lighting the far side of the bricks? The lights on the wall highlight the bottoms of the bricks when there's meant to be a torch in that corner somewhere in the middle of the right edge. Certainly none at floor level. The floor also looks lit away from the corner rather than the parts that ought to be facing, though I'm not quite sure where the brighter lights are here.

It does look a little like that. I wrote a function that renders orbs at all the non-torch light locations. As you can see the torch lighting on the floor looks correct so I think the light-orb in the hallway is offsetting the wall lighting.

I checked all the texture mappings and the only thing that seems inconsistent for causing a few lighting abnormalities is the deluxe-map. Is this how it looks in FTE or did I miss something:

Bump/Gloss update:

You know what the next step is though, right?

Use the blah_bump texture (presumably packing the heights into the alpha channel of the normalmap) and displace the texture based upon viewing angle.
So that your bricks really do stick out of the surface.

And yeah, when using bumpmapping, pre-baked lighting on your diffuse textures really does spoil the effect.

Yeah that's a good idea. Spike while I have your attention, I'm getting some strange behavior where at some angles the rendering of some (not all) faces gets fudged:

Here the face is wrong:


Here the face is correct:


This problem seemed to have disappeared for a time and has recently returned. I'm guessing it has to do with some default behavior. Have you encountered this or any ideas what the problem could be?

nvm it's just a problem with passing the texture coords so it's not related to anything else in the shader code which is why it's an intermittent problem.

bumping this with this.
any progress here? we could really use this!