View Full Version : multiple lights and multiple textures
I've read quiete many things about shaders but I still don't understand how you could do such things:
gl_TexCoord = gl_TextureMatrix * gl_MultiTexCoord0;My main wonder is about how to solve that when you have several texture coordinates. Do you do such code for each gl_MultiTexCoord* ?
Can someone give me some examples or good advises ?
It's also the same thing for lighting. Let's say light0 and light2 are enabled but not the others. How do you care of that in your shaders ? Do you use any uniform variables ? Is there or will there have any way in order to know, from within a shader, if a specific light is enabled or not ?
Maybe I've misunderstood some points, so if someone could explain me why it will be fine :)
Is there or will there have any way in order to know, from within a shader, if a specific light is enabled or not ?i dont know about lighitng (i dont use it) but i assume its like texturing, + in glsl ignores enable/disable calls eg u can access light7 position regardless or not if its enabled at all
im not to sure what u mean with the first part with the texture coordinates
Thank you for your care zed and for the information.
So, when using shaders, I must find a way to let the shader knows about which light is enabled, like using uniforms (seems best at the moment).
Unfortunately, I found that doing this way oblige us to complicate our code a bit (as far as I can understand that point at that moment).
Are there any people 'wishing' glsl can/should get the information stored in Enable/Disable calls (like for lights, texture units and so) or am I alone ? Does someone think it could be a discussion subject (even in another forum) or do you think it's a mess and a 'should-not-happen' ?
For multitextures, I'm used to use texture unit 0 with texture matrix 0, and having one texture coordinate arrays (or multitexcoord) by unit. But I can enable, as for lights, texture unit 0 plus texture unit 2 but not the other...
So, I guess, in a shader, I must do some codes like that:
gl_TexCoord = gl_TextureMatrix * gl_MultiTexCoord0;
gl_TexCoord = gl_TextureMatrix * gl_MultiTexCoord1;
...It's somewhat ugly for me, but if that's the way it's got to be, so let's do it this way :)
10-26-2005, 02:21 AM
One of the possible reason why this might be bugging you is because of the fact that we take branching in CPUs for granted. This is not the case with GPUs and was not even available (and hence not practical to use) until recently. As hardware matures, i think that people will shift more and more application logic to shaders and eventually a time will come when people will be writing full-fledged applications in shading languages (but that's a bit too far off right now :) ).
As for your questions about lights (for instance). What i did was to do all rendering with one light at a time (i do not use gl_Light attributes, but pass position and other information via uniforms), and additively blend lighting from multiple light sources. The reason why i did this was because of shader length problems and unavailability of branching. The obvious way would be to do all lighting in just one pass and blend their values in the shader (you can do some (un-)artistic blending effects in there as well).
Okay, I didn't want a full shader program, but more links between core (non-programmable) GL (like knowing which lights and textures are enabled) and the shader language. I personally think it will be better just because (I might repeat myself) it would help making applications designed for systems supporting shaders as for those not supporting them. In fact, this is actually my main interrest: my graphic card supports shaders but is really slow when performing them. More shaders are actually limited in the number of uniform variables you can use with them (if I'm not wrong) and as you said, limited to their length too.
About multiple lights and multiple textures, I was simply thinking to use loops (for faking simple pass) and with avoiding the use of uniforms to know which of them to perform.
Thank you, I think I now got the way to do them.
Powered by vBulletin® Version 4.2.0 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.