Skip to main content
GameDev.net gamedev.net
🔒 Locked 🎯 Unreal

[GLSL] gl_LightSource[0] fields always zeroed

Started by Muhammad Haggag Feb 15, 2007 at 12:18 PM 11 replies 8.3k views
Original Post
Muhammad Haggag
Muhammad Haggag
Greetings, While implementing per-pixel lighting in GLSL, I attempted to use the built-in gl_LightSource array instead of creating and setting uniform variables for the light properties. I kept getting black results, and I narrowed it down to this: gl_LightSource[0] fields are all zeroed. I'm 100% positive I'm setting the lights and enabling them--fact is, while gl_LightSource[0].diffuse is all zeros, gl_FrontLightProduct[0].diffuse is the correct (non-zero) value (multiplied by material diffuse, which is (1,1,1,1)). I'm running on this on an X300, with the only available ATi driver for Vista x64. I reproduced the same results with TyphoonLabs "Shader Designer". The stripped-down shaders:
// Vertex
void main()
{
	gl_Position = ftransform();
	gl_FrontColor = gl_Color;
}
// Fragment
void main()
{
	// The following line always produces black. I tried using many fields
	// including position, specular, etc, and all are zero
	vec3 diffuse = gl_LightSource[0].diffuse.rgb;

	// The following (commented) line produces the expected diffuse color
	// vec3 diffuse = gl_FrontLightProduct[0].diffuse.rgb;

	gl_FragColor.rgb = diffuse;
	gl_FragColor.a = 1.0;
}
So: 1. Is this a driver bug, or I'm missing something? Is support for gl_LightSource optional or mandatory for GL 2.0+ drivers?1 2. Anyone ran into this before? Is it a known issue? Any known workarounds? (other than using uniform variables and setting them, obviously [smile]) [1] Pardon the noobiness. I'm used to the Direct3D approach, and have only plunged into GLSL the day before yesterday

_the_phantom_
_the_phantom_
1. the LightPositions stuff is mandatory for GLSL support (1.00 and 1.10) so it should work.. I'm tempted at this point to say driver bug. It would seem, based on what you've said that they aren't reflecting the GL state into GLSL correctly.

2. Can't say I've noticed it on Xp x64, but I haven't done much GLSL for a while so I haven't tested on recent drivers and I don't have a copy of vista atm. As for work-arounds, if my assumption about a driver bug is correct, then all you can do is bypass the built in uniforms and set them yourself...

If you've got a sample app which can be tested on WinXP then I can take a look at it later tonight (or in the next 50mins before I go out...), see if the bug exists on the XP x64 driver or not.
mrbastard
mrbastard
Your sample code works as it should in shader designer under ati's win32 xp Cat 7.1 drivers.
[size="1"]
cmf
cmf
its definitely a driver "bug". actually not implemented yet in atis crappy vista x64 opengl driver (as other things like framebuffer objects or floating point textures too).

the only thing you could do, is to pass those light source values manually to the shader ... or wait for a better driver.
Muhammad Haggag
Muhammad Haggag
Quote:
Original post by phantom
1. the LightPositions stuff is mandatory for GLSL support (1.00 and 1.10) so it should work.. I'm tempted at this point to say driver bug. It would seem, based on what you've said that they aren't reflecting the GL state into GLSL correctly.

I see, thanks.

Quote:
If you've got a sample app which can be tested on WinXP then I can take a look at it later tonight (or in the next 50mins before I go out...), see if the bug exists on the XP x64 driver or not.

I'll create a minimal repro app tomorrow, and upload it somewhere. Either way I'll need it to report the problem to ATi, so we might as well check whether it occurs on XP x64 or not. Thanks for the offer [smile]

Quote:
its definitely a driver "bug". actually not implemented yet in atis crappy vista x64 opengl driver (as other things like framebuffer objects or floating point textures too).

I see. Any other gotchas you'd like to share? You seem to be talking from a (bitter) experience!

Quote:
the only thing you could do, is to pass those light source values manually to the shader ... or wait for a better driver.

I'll have to do it manually, then.

zedz
zedz
i dont think u need to enable the lights (but arent sure)
have u tried it with another of the 8 lights eg light1 IIRC light0 is a special case as in some of the default properties are different from lights 1-7
Muhammad Haggag
Muhammad Haggag
I've uploaded the repro here. This is a binary-only package. You'll need the GLUT dll to run it. The source package is here.

I won't contact ATi until we verify the situation on XP x64.

cmf
cmf

Quote:
I'll create a minimal repro app tomorrow, and upload it somewhere. Either way I'll need it to report the problem to ATi, so we might as well check whether it occurs on XP x64 or not. Thanks for the offer [smile]

atis xp x86 and x64 opengl drivers are quite the same (at least in the way of what extensions are supported).

Quote:
I see. Any other gotchas you'd like to share? You seem to be talking from a (bitter) experience!

there are like 20 extensions missing on my radeon 9800 xt that were supported under xp. including the GL_ARB_pixel_buffer_object extension which they just implemented in their 7.1 xp/xp64 drivers, the other extensions are more or less obsolete ones.

btw. ati needed 5 months longer than nvidia to release a vista opengl driver ... and then they release such a crap :/ and the catalyst control center is the only program that managed to crash vista on my pc yet ...

well, i know from which vendor my next graphic card will be from ...
_the_phantom_
_the_phantom_
Quote:
btw. ati needed 5 months longer than nvidia to release a vista opengl driver ... and then they release such a crap :/ and the catalyst control center is the only program that managed to crash vista on my pc yet ...

well, i know from which vendor my next graphic card will be from ...


I really wouldn't use this as a guide right now, for example NV's Vista drivers are known to be pretty damned bad as well, certainly performance wise... Vista is too new for any pronoucements to be made about driver quality imo (and NV have been slightly losing it driver wise of late as well).

Anyways, Muhammad, I tried the bin package but it failed to start with an application configuration error [sad]
I'll grab the source version and rebuild here later...
cmf
cmf
yeah ... but it's not only vista. when it comes to opengl or non-windows/dx stuff you're better off with a nvidia card. like the nvperf stuff that supports opengl (atis comparable tool only supports dx), supported opengl extensions, aiglx, cg, opengl performance, ...
Muhammad Haggag
Muhammad Haggag
Quote:
Original post by phantom
Anyways, Muhammad, I tried the bin package but it failed to start with an application configuration error [sad]
I'll grab the source version and rebuild here later...

The app configuration error is probably caused by the VC8 DLL runtimes. I'm using the VS8 SP1 runtimes, which would cause the error you describe if used on a machine with an unpatched VS8 installation.

cmf
cmf
to keep this up-to-date: catalyst 7.2 still doesn't solve this ... none of it.
and instead of seeing nothing when you render to a fbo, you can see some weird graphic glitches now.
Muhammad Haggag
Muhammad Haggag
Quote:
Original post by cmf
to keep this up-to-date: catalyst 7.2 still doesn't solve this ... none of it.
and instead of seeing nothing when you render to a fbo, you can see some weird graphic glitches now.

[lol]
I entered this topic hoping that you'd be reporting good news about the new driver (still downloading it). Guess not.

The funny thing is that I ran into even stranger bugs. For example, you'd expect the following GLSL code snippets to do the same thing:
uniform bool isDirectional;// [...]// Snippet #1if(isDirectional){// Do stuff}else{// Do other stuff}// Snippet #2if(isDirectional == true){// Do stuff}else{// Do other stuff}


The funny thing is, the second snippet works exactly opposite to the first--the "Do stuff" branch is entered when isDirectional is false [smile]

Way to suck, ATi.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.