I am using openGL to render a texture bitmapped 3D object with lighting. To that end, I use GL_MODULATE when setting the GL_TEXTURE_ENV_MODE via glTexEnvf. If I set my material’s emissive property to (0.0, 0.0, 0.0), then I can only get the ambient colour to work from the range (0.0, 0.0, 0.0) to (0.5, 0.5, 0.5). Anything above that effectively turns off the lighting effects, and the geometry appears as if it was rendered using GL_DECAL. Effectively, the ambient lighting overwhelms the direct lighting to the point where you can’t notice the directed light. I have tried to adjust both the light’s ambient property and the material’s ambient property with the same result.
I would expect that I should be able to set an ambient light value of (100.0, 100.0, 100.0) and the image would turn out bright white, because a very high ambient light would cause everything to appear bright.
Am I not understanding how to use OpenGL’s lighting subsystem, or should I be searching for a bug in my code?
Also, what type of illumination model (i.e. lighting equation) is being used? Phong Illumination?
Not absolutely sure, but the ambient color may get clamped to [0,1] before being multiplied by texture color in [0,1] range too. Better check the official spec .
What about doing two passes, with blending enabled, glBlendFunc GL_ONE GL_ONE : first draw ambient texture, then add a lighting pass. It will saturates more the colors.
Thanks Z. The specifications were a help. It appears that the primary colour is used with GL_MODULATE to combine with the texture colour. In order to get the specular highlight working correctly, I am now using the GL_SEPARATE_SPECULAR_COLOR for the glLightModel. This makes the lighting formula in the spec (section 2.14.1) look similar to the form of Phong illumination.
However, I still cannot get the ambient lighting to make the object’s texture appear brighter only darker. This is due to fact that the “primary colour” is not what I would consider being an actual colour limited to a range 0.0 to 1.0. It seems more like a hack to call it a colour, when it is really a part of a formula used to determine the resulting colour. Therefore, I believe it shouldn’t be clamped like a proper colour, even though it is. Am I understanding things correctly?
Furthermore, I am using Windows, and I have found that I now have to use an extension to do separate specular colouring. This means I have to set my graphics driver to fully enabled. Now textures are rendering through the graphics hardware and they are turning out in lower resolution and colour depth. It is faster, but I would prefer the higher quality of using the software instead of the hardware. Is there any way I can turn off the hardware acceleration of the texturing and still use the vendor’s extension for separate specular colouring?
I know you suggested to do two passes, but will that get rid of the clamping problem? I would guess that the clamping would still occur between passes.
It’s looking like this is becoming more tricky than I thought. Perhaps I will post this to the advanced forum, if I can’t get it resolved soon.
Okay, I got the two pass rendering to work, as described. However, I am now having problems with self-occlusion and back face culling. Self-occluded points are being added to the blend instead of being overwritten, as previously done. What’s the standard procedure for dealing with this?
I’ve seen several examples where the depth buffer is disabled during blending, but the depth buffer may be useful to determine occlusion. However, I’m worried about the resolution of the depth buffer limitting the detection of occluded vertices near non-occluded vertices. Any thought anyone?
I don’t uderstand why software/hardware acceleration toggle should lower the quality of textures. Normally it should be nicer when accelerated… What is your setup OS/card/ram/driver versions ?
If you really want software acceleration aned extension, go for www.mesa3d.org , very nice. There is full opensource code, but I have found some brebuilt dll on recent versions(sorry I can’t find them anymore).
About self occlusion :
In the case where nothing should be transparent (much easier), you do the first pass normally, writing depth buffer and without blending.
On second pass, as you draw exactly the same 3d data, you can disable depth write, but must keep depth testing enabled !!! You may want to fiddle with the gl depth comparison, starting with glDepthFunc(GL_LEQUAL).
In theory there is no problem with depth precision, as exact same geometry rendered twice must have the same coordinates in screen space.
By the way, it is not “occluded vertices” but “occluded fragments”, as it is done per pixel, not by vertex.
Thanks again. I never would have thought to disable just the depth writing and use GL_LEQUAL, but together those two things produced a blending.
Unfortunately, I still cannot get the ambient looking correct. In Phong illumination, the ambient colour is multiplied by the texture colour and then summed with the diffuse and specular components. The OGL lighting equation does not have this ambient multiplication built into it.
In my method described in my second post, the ambient-diffuse component was represented in the primary colour and thus clamped to 0-1 range. When multiplied with the texture you could never brighten, only darken it with a value less than 1. With your approach a similar problem happens. If I set the material’s ambient values to zero, then the effects of the ambient colouring disappear. For example, If I set the ambient material to (0.1, 0.1, 0.1), then it will wash out the dark areas when blended with the texture, causing the contrast to go down. The blending is a summation, when Phong illumination requires multiplication.
Is it not a common thing to do texture mapping with Phong illumination?
Also, I notice that some of the back face lines from the first render shows through as black lines in a few spots. I tried to cull them, but I get a mostly black back side with some speckled dots. I don’t know what is causing this.
As for my System, I am using WinXP with NVIDIA GeForce4 MX 420 64 MB 5.2.1.6. I can look for a newer driver, but I have seen the problem on other newer computers.
Oops. I spoke too soon. It looked like it was working, but I now realize my diffuse lighting does not turn out at all. The ambient is correct. What I was seeing is the specular component only. I can only see it, if I set the GL_SHININESS to >= 0.2. The same results are seen for both separate specular mode and diffuse, and I am not using attenuation, so that shouldn’t be the problem. I’m guessing this would have to do with the position of the vertices relative to the light, but wherever I put the light I have this problem. Also, the specular lighting doesn’t cover as much of the object as I would have expected, even at a very high shininess exponent.