I implemented bump mapping in the quake engine but I have a problem on “some” (most of them are fine) polygons the light seems to dark.
You can see a shot of it here: http://studwww.rug.ac.be/~cholleme/tenebrae/bugshot.jpg
(Compare the floor to the wall and you will see what I mean)
I wondered if anyone recognized this specific error. (everyone seems to be doing bump maps here )
Some info on the techique:
-Normalization cube map with nomal map. (My tangent space is ok since it is used for texture coordinate genereation, anyway |N.(S x T)| = 1 and I have checked it multiple times)
-Distance attent. is ok (I havend changed it since I’m using bump maps)
Oh and if you’re interested in the code that is done per vertex it is. (The if is due to the way Quake stores it’s normals)
//calculate local light vector and put it into tangent space
VectorSubtract(lightOr,cl.worldmodel>vertexes[ind].position,lightDir);
tsLightDir[0] = DotProduct(lightDir,surf->texinfo->vecs[0]);
tsLightDir[1] = DotProduct(lightDir,surf->texinfo->vecs[1]);
if (surf->flags & SURF_PLANEBACK) {
tsLightDir[2] = -DotProduct(lightDir,surf->plane->normal);
} else {
tsghtDir[2] = DotProduct(lightDir,surf->plane->normal);
}
Actually i’m against pasting code because it is so boring to read all those posts with tons of code pasted into.
It may not be a bug - this is what will happen if the light is very close to a surface and the scale factor is high ( that is the heightmap from which the normal map is derived is scaled by a large value ). Try a smaller value ( you’ll get less bumpy surfaces ) or move the light further away from the wall.
[This message has been edited by PH (edited 06-03-2002).]
Thanks a lot moving the light further away fixes it! (I spent hours debugging that)
Any idea how I can fix it (using some trick beside lowering the scale, it was 3 in this case)
Oh and why is it caused? It was not that close to have a zero length vector or anything (or I must be accumulating errors or something)
Lowering the scale won’t actually make the surface brighter, it will lower the intensity of the brick edges ( since they won’t stick out of the wall so much ).
Moving the light is the only thing that will make the surface brighter.
As the light gets closer to a surface, the dot product between the surface normal and the light vector ( to some point P on the surface ) will approach zero if the point P is far from the light.
[This message has been edited by PH (edited 06-03-2002).]
it’s not a bug to be fixed. You have correct behaviour.
The closer the light to the surface the more rapidly L.N falls away. The distance between the surface and the light determines everything about the scale of L.N distribution.
To be correct you need to add range attenuation (which simulated luminaire size)but that will only make the light dimmer in the distance.
The underlying problem is that point lights don’t exist in nature so your example doesn’t seem correct to you. If you had a very bright LED next to a wall in a very dark room, it would look very similar to your example, but range attenuation would dim the floor.
[This message has been edited by dorbie (edited 06-04-2002).]
Its amazing how many times this problem comes up when doing lighting. I mean the situation where people think there is something wrong with their code but in reality it is working perfectly. What they see simply isn’t what they expected to get. Its happened to me many times before. Its also happened to everyone I know that has ever done any graphics programming. Welcome to the club.
One thing you could do ( it will make everything just a bit better looking ), is to add some ambient lighting. Not a lot, just a little like 0.1 . It will actually make things look more realistic. Ambient lighting is very important but usually ignored by many. It is meant to compensate for all the complex light interactions that are difficult ( or impossible ) to model.
possibly implementing some distance attentuation could help… to get rid of the look as the more far away the brighter the light… but else its correct behaviour…
A small note regarding my previous post: the ambient term is per-light ( also attenuated ). It’s not a global ambient term ( as in “clear-color-buffer to ambient” ).
I already have some sort of per light ambient (but I’s was disabled in the image) since I’m using the original light maps as ambient, it actually gives very good, soft ambient in most cases. (Heh discuss this in the unified doom3 thread )
Yes on the wrong looking thing, inspected the real walls here today and in extreme cases it seems to be reasonably correct (my bathroom wall was verry close)
)
(my bathroom wall was verry close)