Quick GLSL uniform variable question

Started by
9 comments, last by taby 17 years, 12 months ago
I'm working on my per-pixel lighting shader, and I'm trying to get it to support more than one light Normally it always used gl_LightSource[0] for all the calculations. This worked fine, and hardly reduced the framerate (about 60 FPS on a 9700 Mobile) Then I decided to make it so the program can tell the shader which light to use. I added a uniform integer called current_light, and used gl_LightSource[current_light] for the math instead. That was the only change it made, and it reduced the framerate down to below 1 FPS. What happened? Is it bad do index based on that? I tried to use arrays and calculate all the lights in one loop, but GLSL told me that by doing that I had exceeded the hardware limit (32) of floating-point varyings.
"ok, pac man is an old gameand, there are faces which is eatin up shits" - da madface
Advertisement
youre running in software, check the glsl forums at www.opengl.org this has been discussed a couple of times.
So indexing with a precompiled number runs in hardware, but using a user-specified value makes it run in software?

Do you know any links that would show me how to enable multiple lights?
"ok, pac man is an old gameand, there are faces which is eatin up shits" - da madface
i believe u will have to hard code the number of lights in the shader
eg make one shader for 3 lights another for 4 lights etc
the problem is whilst recent cards are getting more and more flexible all the time theyre still a long way off with the flow control etc of cpus.

though do it easy like me and do one light at a time which is the easiest way esp if youre shadowing
How do I do one light at a time? Would I need to render the scene twice for 2 lights?
"ok, pac man is an old gameand, there are faces which is eatin up shits" - da madface
Are you doing this lookup in a vertex or fragment shader ? In the latter case, this is a limitation of current hardware. In the former case however, you should be fine. Vertex shaders can dynamically index into arrays (it essentially compiles down to an ARL opcode). So try to offload as much as you can to the vertex shader.
How would I do the lookup in the vertex shader only? I use gl_LightSource[] in both.

Edit: Ok, never mind that, I just send the fragment shader a gl_LightSourceParameters object. But how?

It won't let me declare it varying because it's an object, but if I leave out the qualifier the lighting stops working...

Edit (Remix): Never mind, I've got it all under control. Screenshots soon

[Edited by - Foobar of Integers on April 23, 2006 8:27:48 PM]
"ok, pac man is an old gameand, there are faces which is eatin up shits" - da madface
Ok, update.

I rewrote a bunch of the fragment shader to fix the couple of glitches it had. However, after trying a few methods I found on google to support multiple lights, it still drops down into software mode. I'm kind of lost here.

More update:

This doesn't seem to be a programming problem, I compiled the code on my Windows box (with the 7800GT) and it handles 3 per-pixel lights at once with no framerate drop from 1 light. Screenie: http://rav.efbnet.com/imagebin/images/1145847473.png

[Edited by - Foobar of Integers on April 23, 2006 9:23:58 PM]
"ok, pac man is an old gameand, there are faces which is eatin up shits" - da madface
One other method is to store your light information into a texture, one texel per light, and then use a sampler in GLSL to get that data.

Uniform variables needed: 1
I'll give that a shot tomorrow, it seems like a pretty solid solution. Plus, it'll avoid making me work on my Windows machine just to get decent performance. GLSL in Windows is just... painful.
"ok, pac man is an old gameand, there are faces which is eatin up shits" - da madface

This topic is closed to new replies.

Advertisement