Positioned spot light - white light appearing from nowhere behind

Hi. I am having a problem with a spot light positioned within a scene. The beam is constrained to an angle and projects forwards from the source in the expected way, however all objects behind the source are illuminated with saturated white light which seems to come from nowhere. The attached image and code demonstrate the problem in a simple chequerboard scene using a red light source positioned in the middle of the central globe, pointing to the right with a beam cone angle of 45 degrees. When the red light is switched off the white saturation also disappears. The additional diffuse light is just there to allow the scene to be observed more easily and does not change the problem symptoms.

I’ve not found any reference to this effect on the web, so could it be a Fedora implementation bug ?. I’m not able to test on any other OS.

FYI: My platform is Fedora 17 Linux. I have tested this on a number of different machines with different graphics hardware.

Any thoughts / suggestions most appreciated.
Thanks.

Update:

The test cc has now been built on a Windows machine and the problem is not evident. I don’t know if there are differences in any of the library versions of the various components, but it looks like this is a library bug as suspected.

One of your problems is you need to define and enable your lights before you start drawing objects. You’re getting different results on different systems because on some it only runs display() once, but on the 2nd display() run LIGHT1 is enabled and it does something different. This is because you’re leaving stray GL state set differently across runs of display().

On the system where you don’t see the red light, push a window in front of that window and then move it away, and watch it change. Here on my system, display() is only invoked one on startup unless subsequently occluded, so I see exactly the same result for 1st draw whether I’ve got LIGHT1 enabled or disabled.

You’ve got other problems, but that’ll get you further. Another thing you should note is that the MODELVIEW transform active at the time you set your light source positions and directions is used to transform the object into eye space.

After moving LIGHT1 up to the top of redraw with LIGHT0, disable LIGHT0, comment out the plane draw code, and comment out the GL_SPOT lines for LIGHT1. Here I see a red sphere. Go from there.

Also, folks in fixed-function OpenGL typically set up a viewing transform using gluLookAt or similar (rather than explicit Translate/Rotate comments). But that’s totally your choice.

Thanks for your advice. The drawing order and state leaking from draw to draw call make good sense.

I couldn’t reproduce the pink sphere as you described, but have done some further work to understand why that may be. As the light is inside the sphere I assume it would illuminate the inside surface and so not be visible from outside. To make use of this I’ve set the material properties for the inside (GL_BACK) of the sphere, set to cull GL_FRONT faces, set the lighting model to 2 sided and finally set the front face to GL_CW before drawing the sphere. I think what is happening here is that all but the last step cause the inside surface to be illuminated and to be the only surface processed, and the last step causes the face directions and normals to be reversed resulting in the inside face being drawn on the outside. I may have that explanation wrong, but it seems to make some sense to me, and explains the new result (attached). Now the sphere surface that falls within the spot lamp beam is illuminated by the spot lamp giving a very pleasing lantern lens effect. I’ve also put in some attribute pushing and popping to reduce state leakage between stages.

By the way I seem to have confused myself with the saturated white light problem. Now I am trying the tests again, the image is constructed correctly (without the saturated white light to the left) on all of my Fedora 17 test machines apart from one. The attached screen shot is from an HP mobile workstation with the following graphics hardware:

lspci -> 01:00.0 VGA compatible controller: nVidia Corporation G92M [Quadro FX 3600M] (rev a2)

The other machines show the left of the chequerboard in the same grey as appears on the right and the left of the sphere totally black as I would expect. This is making me suspect a hardware compatibility problem with this particular graphic card.

Ok - it turns out I’m not completely loosing the plot after all. I did see this saturated white light behind the spotlight problem on another machine. That machine is a desktop unit and reports the following graphics hardware:

lspci -> 01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1)

Am I right in assuming that the graphics accelerator on the card is doing most of the grunt work in generating these images and so is likely to be responsible for the problem ?

I have a hunch for you. Try:

[FONT=arial][b]glMaterialf(GL_FRONT_AND_BACK, GL_SHININESS,  1e-4 );[/b][/FONT]

If not, try this too:

[b]glLightf(GL_LIGHT1, GL_SPOT_EXPONENT, 1e-4);[/b]

Suspecting a pow(0,0) in the shader, which is NaN. If not, try:

glDisable( GL_LIGHT0 );

under your LIGHT0 code. Let’s make sure we know which light is causing this.

That machine is a desktop unit and reports the following graphics hardware:

lspci -> 01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1)

Let’s see the output of this:

glxinfo | grep OpenGL

That’ll tell us not just the GPU but which vendor’s driver’s you’re running and which version:

Am I right in assuming that the graphics accelerator on the card is doing most of the grunt work in generating these images…

For the final rendering, yes. But there’s a fair amount the driver is doing in terms of generating the code that will run on the GPU.

I tried the extra code you suggested but the problem remained the same.

The 2 problem machines report the following:

lspci ->
01:00.0 VGA compatible controller: nVidia Corporation G92M [Quadro FX 3600M] (rev a2)
glxinfo ->
OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NV92
OpenGL version string: 2.1 Mesa 8.0.3
OpenGL shading language version string: 1.20
OpenGL extensions:

lspci ->
01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1)
glxinfo ->
OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NV34
OpenGL version string: 1.5 Mesa 8.0.3
OpenGL extensions:

The two that are working correctly report:

lspci ->
00:02.0 VGA compatible controller: Intel Corporation N10 Family Integrated Graphics Controller
glxinfo ->
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel® IGD
OpenGL version string: 1.4 Mesa 8.0.3
OpenGL extensions:

lspci ->
01:05.0 VGA compatible controller: nVidia Corporation NV44A [GeForce 6200] (rev a1)
glxinfo ->
OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NV4A
OpenGL version string: 2.1 Mesa 8.0.3
OpenGL shading language version string: 1.20
OpenGL extensions:

Please let me know if you need any more info. Thanks.

[QUOTE=windchine;1239383]I tried the extra code you suggested but the problem remained the same.

The 2 problem machines report the following:


[FONT=verdana]01:00.0 VGA compatible controller: nVidia Corporation G92M [Quadro FX 3600M] (rev a2)
OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NV92
OpenGL version string: 2.1 Mesa 8.0.3

01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1)
OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NV34
OpenGL version string: 1.5 Mesa 8.0.3[/FONT]


[/QUOTE]
Install the NVidia graphics driver package using your package management tool (or download from Official Drivers | NVIDIA). You’re running nouveau, which is an open source graphics driver for NVidia cards.

You’ll then see something like:


OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce ...
OpenGL version string: ... NVIDIA 302.07

Thanks - good suggestion. I’ve tried the nVidia driver on all 3 machines and in all 3 cases the spotlight scene rendered correctly without the white light on the left. The machine that was previously working now renders the OpenGL much faster and is completely stable.

The story is not quite so bright with the other two however. The laptop locks up and needs a hard reboot (repeatably) about 60 seconds after logging in to Gnome3 - just long enough to test the light problem and to run another OpenGL app which frustratingly runs much faster and better with the nVidia driver. The other desktop that was showing the problem works but the Gnome3 shell is spinning the CPU on 99% utilization which inevitably slows everything down somewhat. This machine needed the legacy 173xx nVidia driver so this may be the cause of that incompatibility.

Anyway - all other things aside, the driver change certainly fixes the spotlight problem and speeds up scene rendering. Thanks for your support with this problem - it’s nice to understand where the error was coming from.

EDIT:
For interest the 2 new problems resulting from the switch to the nVidia driver seem to be described by the following nvnews threads:

http://www.nvnews.net/vbulletin/showthread.php?p=2567721
http://www.nvnews.net/vbulletin/showthread.php?p=2567722

For interest, the original problem with stray saturated white light on the left of the image is no longer present when using the nouveau driver with the latest updates to Fedora 17.