[Sushi]

if such a feature would be welcome.

Let's just say that people would probably be naming their babies after you.

Creating light-maps is an idea that's been kicked around a bit, but nobody has taken the time to figure out how to make it work.

[The E]

Well, I'd love to get a better/faster light handling code. The engine keeps track of up to 256 light sources, I'd really like to see more than 8 of them.

EDIT: That shader of yours has a syntax error, causing it to fail on Radeons. It should also fail on GeForces, so what did you test it on?

To elaborate, you treated envReflect (a varying vec3) as a normal variable, which will fail according to the GLSL spec (varying variables are treated as runtime constants).

Here's a corrected version:

Code: [Select]

#ifdef FLAG_LIGHT
uniform int n_lights;
#endif

#ifdef FLAG_DIFFUSE_MAP
uniform sampler2D sBasemap;
#endif

#ifdef FLAG_GLOW_MAP
uniform sampler2D sGlowmap;
#endif

#ifdef FLAG_SPEC_MAP
uniform sampler2D sSpecmap;
#endif

#ifdef FLAG_ENV_MAP
uniform samplerCube sEnvmap;
uniform bool alpha_spec;
varying vec3 envReflect;
#endif

#ifdef FLAG_NORMAL_MAP
uniform sampler2D sNormalmap;
varying mat3 tbnMatrix;
#endif

#ifdef FLAG_FOG
varying float fogDist;
#endif

varying vec4 position;
varying vec3 lNormal;

#if SHADER_MODEL == 2
  #define MAX_LIGHTS 2
#else
  #define MAX_LIGHTS 8
#endif

#define SPEC_INTENSITY_POINT 5.3 // Point light
#define SPEC_INTENSITY_DIRECTIONAL 3.0 // Directional light
#define SPECULAR_FACTOR 1.75
#define SPECULAR_ALPHA 0.1
#define SPEC_FACTOR_NO_SPEC_MAP 0.6
#define ENV_ALPHA_FACTOR 0.3
#define GLOW_MAP_INTENSITY 1.5
#define AMBIENT_LIGHT_BOOST 1.0

void main()
{
vec3 eyeDir = vec3(normalize(-position).xyz); // Camera is at (0,0,0) in ModelView space
vec4 lightAmbientDiffuse = vec4(0.0, 0.0, 0.0, 1.0);
vec4 lightDiffuse = vec4(0.0, 0.0, 0.0, 1.0);
vec4 lightAmbient = vec4(0.0, 0.0, 0.0, 1.0);
vec4 lightSpecular = vec4(0.0, 0.0, 0.0, 1.0);
vec2 texCoord = gl_TexCoord[0].xy;

 #ifdef FLAG_LIGHT
  #ifdef FLAG_NORMAL_MAP
// Normal map - convert from DXT5nm
vec3 normal;

normal.rg = (texture2D(sNormalmap, texCoord).ag * 2.0) - 1.0;
  #ifdef FLAG_ENV_MAP
vec3 envOffset;
envOffset = normal;
  #endif
normal.b = sqrt(1.0 - dot(normal.rg, normal.rg));
normal = normalize(tbnMatrix * normal);
  #else
vec3 normal = lNormal;
  #endif

vec3 lightDir;
lightAmbient = gl_FrontMaterial.emission + (gl_LightModel.ambient * gl_FrontMaterial.ambient);

#pragma optionNV unroll all
for (int i = 0; i < MAX_LIGHTS; ++i) {
  #if SHADER_MODEL > 2
if (i > n_lights)
break;
  #endif
float specularIntensity = 1.0;
float attenuation = 1.0;

// Attenuation and light direction
  #if SHADER_MODEL > 2
if (gl_LightSource[i].position.w == 1.0) {
  #else
if (gl_LightSource[i].position.w == 1.0 && i != 0) {
  #endif
// Positional light source
float dist = distance(gl_LightSource[i].position.xyz, position.xyz);

float spotEffect = 1.0;

  #if SHADER_MODEL > 2
if (gl_LightSource[i].spotCutoff < 91.0) {
spotEffect = dot(normalize(gl_LightSource[i].spotDirection), normalize(-position.xyz));

if (spotEffect < gl_LightSource[i].spotCosCutoff) {
spotEffect = 0.0;
}
}
  #endif

attenuation = spotEffect / (gl_LightSource[i].constantAttenuation + (gl_LightSource[i].linearAttenuation * dist) + (gl_LightSource[i].quadraticAttenuation * dist * dist));

lightDir = normalize(gl_LightSource[i].position.xyz - position.xyz);

specularIntensity = SPEC_INTENSITY_POINT; // Point light
} else {
// Directional light source
lightDir = normalize(gl_LightSource[i].position.xyz);

specularIntensity = SPEC_INTENSITY_DIRECTIONAL; // Directional light
}

// Ambient and Diffuse
lightAmbient += (gl_FrontLightProduct[i].ambient * attenuation);
lightDiffuse += ((gl_FrontLightProduct[i].diffuse * max(dot(normal, lightDir), 0.0)) * attenuation);

// Specular
float NdotHV = clamp(dot(normal, normalize(eyeDir + lightDir)), 0.0, 1.0);
lightSpecular += ((gl_FrontLightProduct[i].specular * pow(max(0.0, NdotHV), gl_FrontMaterial.shininess)) * attenuation) * specularIntensity;
}

lightAmbientDiffuse = lightAmbient + lightDiffuse;
 #else
lightAmbientDiffuse = gl_Color;
lightSpecular = gl_SecondaryColor;
 #endif

 #ifdef FLAG_DIFFUSE_MAP
 // Base color
vec4 baseColor = texture2D(sBasemap, texCoord);
 #else
vec4 baseColor = gl_Color;
 #endif
 
vec4 fragmentColor;
fragmentColor.rgb = baseColor.rgb * max(lightAmbientDiffuse.rgb * AMBIENT_LIGHT_BOOST, gl_LightModel.ambient.rgb - 0.425);
fragmentColor.a = baseColor.a;

 #ifdef FLAG_SPEC_MAP
 // Spec color
fragmentColor.rgb += lightSpecular.rgb * (texture2D(sSpecmap, texCoord).rgb * SPECULAR_FACTOR);
fragmentColor.a += (dot(lightSpecular.a, lightSpecular.a) * SPECULAR_ALPHA);
 #else
fragmentColor.rgb += lightSpecular.rgb * (baseColor.rgb * SPEC_FACTOR_NO_SPEC_MAP);
 #endif

 #ifdef FLAG_ENV_MAP
 // Env color
  #ifdef FLAG_NORMAL_MAP
vec3 envReflectNM = envReflect + envOffset;
vec3 envIntensity = (alpha_spec) ? vec3(texture2D(sSpecmap, texCoord).a) : texture2D(sSpecmap, texCoord).rgb;
fragmentColor.a += (dot(textureCube(sEnvmap, envReflectNM).rgb, textureCube(sEnvmap, envReflectNM).rgb) * ENV_ALPHA_FACTOR);
fragmentColor.rgb += textureCube(sEnvmap, envReflectNM).rgb * envIntensity;
  #else
vec3 envIntensity = (alpha_spec) ? vec3(texture2D(sSpecmap, texCoord).a) : texture2D(sSpecmap, texCoord).rgb;
fragmentColor.a += (dot(textureCube(sEnvmap, envReflect).rgb, textureCube(sEnvmap, envReflect).rgb) * ENV_ALPHA_FACTOR);
fragmentColor.rgb += textureCube(sEnvmap, envReflect).rgb * envIntensity;
  #endif
 #endif

 #ifdef FLAG_GLOW_MAP
 // Glow color
fragmentColor.rgb += texture2D(sGlowmap, texCoord).rgb * GLOW_MAP_INTENSITY;
 #endif

 #ifdef FLAG_FOG
fragmentColor.rgb = mix(fragmentColor.rgb, gl_Fog.color.rgb, fogDist);
 #endif

gl_FragColor = fragmentColor;
}

[Valathil]

Yeah well the last time I programmed shaders was like 10 years ago or so  . Tested it on a Geforce 260 with the 275.50 beta drivers. Dont know why it runs while it shouldn't  . Thanks for the fix!

Creating light-maps is an idea that's been kicked around a bit, but nobody has taken the time to figure out how to make it work.

Can you elaborate on the light-maps I think you mean something different than me. A lightmap as is understand it would be additional rendering passes that generate the lit texture by accumulating the many ligths in a off screen framebuffer and then the final rendering pass puts the ship on the screen with the precalculated texture applied. I on the other hand would propose to send the parameters of the lights encoded in the rgba channels of a non filtered texture and then iterating over the lights in the shader. However i dont know how feasible such a technique would be and if there would be any performance issues e.g. the gpu cant calculate all lights parallel in the stream processors or other problems i cant imagine, its just an idea that popped into my head. As I said before the last time I did anything in OpenGL and shaders was a long time ago.

[The E]

Well, lightmaps as canonically defined are a rather obsolete technique, and one I don't think is very applicable to FSO, given that we do not have any static geometry whatsoever.

The only way I know of to realistically render more lights is to switch FSO to a deferred rendering setup, but that would mean a complete revamp of the render architecture, something that I for one am not knowledgable enough to do.

I do have trouble understanding your proposed way of doing it though. It sounds like a deferred rendering setup in which you have a render pass dedicated to rendering only lights, another to rendering textures, and a final one to composite it all together.

[Zacam]

P.S.: Lurking is my speciality  And then out of nowhere BOOM  epic

Epic, indeed. This has brought a HUGE ass grin to my face and my profuse thanks! You ever have another idea like this, don't be shy about speaking up on it.

Just...wow. I didn't even really think about that as being a "problem" or something that I even noticed, but now I just can't not see it anymore, and this makes a HUGE amount of difference, for being so small a change.

Though, here is one that has been plaguing me for a while. On SM2.0 cards, because we use n_lights in the engine (and they don't get that so well, apparently) we get weapons effects "sticking around" long after they should and they end up "painting" the POV on to other objects that have reflected the weapons effect "light". Now, I'm pretty sure there is a way around that, but I'm afraid it means manually unrolling our loops to handle. If you can estimate that at all and chime in some feedback, that would be awesome.

If not, then no worries, this is definitely a "made my day" first post if ever there was one.

[The E]

And yeah, this little fix will be in the next MediaVPs.

[Valathil]

Well, lightmaps as canonically defined are a rather obsolete technique, and one I don't think is very applicable to FSO, given that we do not have any static geometry whatsoever.

The only way I know of to realistically render more lights is to switch FSO to a deferred rendering setup, but that would mean a complete revamp of the render architecture, something that I for one am not knowledgable enough to do.

I do have trouble understanding your proposed way of doing it though. It sounds like a deferred rendering setup in which you have a render pass dedicated to rendering only lights, another to rendering textures, and a final one to composite it all together.

Let me try to explain differently: When you pass the 8 lights to the shader file they are an array right? Well an array is nothing more than a consecutive stream of certain data types e.g. floats or integer. And what is a texture? A consecutive stream of color information bytes so its like an array in a way. So what if we can put the data that we normally send via array gets sent via a texture instead. That would result in an array that is a size of our choosing not limited to 8 entries. And while you address an array with its index you adress a texture with texture coordinates. So you can take a loop that iterates over 0 to MAX_LIGHTS(whatever that may be then e.g. 256 per engine limitations) and generate texture coordinates to lookup the light parameters inside the texture that stores the lights. This texture is of course generated every frame to update the changing lights in the scene. But I wouldn't call this "rendering" per se, it's more of a memory copy operation (optimizable by directly storing the lights as the shader required format in the first place inside a byte array that gets sent as the texture). However as said before there are many issues that are not fully explored with that setup. I dont know if floating point textures are even possible given that the light coordinates and so on are probably floats so there would be a problem of accuracy when converting to fixed point if its just 8 bits per channel ( that would look craptastic  imagine the whole space in a mission with just 256 possible positions in all 3 dimensions). I really haven't kept up with the times in rendering API capabilities. So again no guarantees or anything just a brainfart that shot through me as I read the 8 lights limitation thing.

Though, here is one that has been plaguing me for a while. On SM2.0 cards, because we use n_lights in the engine (and they don't get that so well, apparently) we get weapons effects "sticking around" long after they should and they end up "painting" the POV on to other objects that have reflected the weapons effect "light". Now, I'm pretty sure there is a way around that, but I'm afraid it means manually unrolling our loops to handle. If you can estimate that at all and chime in some feedback, that would be awesome.

This should be fixable in C by setting the color of "expired" lights to 0.0.0 (black).

[The E]

Problem is, a light needs more than the 4 pieces of information a texture can hold. Let's see, just off the top of my head, you need:

--Light coordinates (for positional lights)/Light direction (for directional lights)
--Colour value (rgb + intensity)
--Attenuation information

It's a lot of data to cram into a texture. While you can do it by using adjacent fields to store all that info, you need to keep in mind that in order to look up the info required you'd need at least <Number of lights in scene>*3 texture lookups, which are expensive as ****.

Not to mention that you'd lock up one precious TMU for that light texture. Given that on a full, all-bells-and-whistles render pass you already need at least 5, (6 if someone were to finish a height map implementation), you'll get awfully close to the 8 you can safely use.

[Valathil]

See thats what I was "hoping" for. Information about TMU limitations and the required lightsource data. Yeah right I remember, lookups ARE expensive  . Ok so i realize im the newbie here and this will probably be something you thought of already but I'll just throw it out there. What about passing the lights as uniforms checking with the vertex shader if this light source is worth rendering and then process them in the fragment shader or is there a limitation of how many uniforms can be passed as well?  .

[The E]

Well, we already do sort lights as best we can. Given that the engine renders each object seprately, we can adjust the number of lights dynamically to use the 8 "most significant" lights for that object.

Regarding limits for uniforms, yes they exist. They are largely implementation-dependant (That is, you have to consult your GPU manufacturer for the data). On my Radeon Mobile 5470, the maximum amount of uniforms to be passed is 4096. Note that a single float/int/bool/whatever takes one slot, a vec2 takes 2, a vec3 3, a mat4 16, and so on.

OpenGL Caps Viewer and OpenGL Extensions Viewer are invaluable tools to figure this stuff out.

Ultimately, defining your own light structs is one step that you'd have to do when doing a deferred renderer.

[Valathil]

Well, we already do sort lights as best we can. Given that the engine renders each object seprately, we can adjust the number of lights dynamically to use the 8 "most significant" lights for that object.

Yes I looked at that on the SVN. You sort by intensity and attenuation I cant come up with anything better than that. But if we assume for a moment that we are allowed more than 8 lights by passing them to the shader by uniforms ( sort of like lets try 32 lights  4 pos + 4 dir + 3 color + 3 attenuation * 32 = 448 well within limits) sorting isn't going to cut it performance wise. I think we need to think about eliminating lights that are not contributing to the lighting on a per polygon basis. The models are based on BSP trees so there aren't any back face polygons present as I understand it. This means that by calculating based on light position, direction and vertex position and normal it should be possible to figure out on which side the light is on on a per vertex basis. We can then eliminate the light from rendering simply because the polygon faces the wrong way which is now handled as I saw it in the fragment shader on a per pixel basis. On average half of the polygons of a model are facing away from the light anyway which should eliminate on average 16 lights so were down to double the fragement shader load. this of course can be done with 16 so were back to 8 to conserve performance for now. However more lights are even considered for inclusion because there is not a 8 limit upfront which should reduce lights flickering on and off. What would be great to know would be an average number of active lights in a normal combat situation ( not a BoE).

EDIT: I consider the texture idea dead this is a whole other idea 

[The E]

Well, I think you could do most of that in the vertex shader, given that all the data you need to do it is present there. I think you could fill up a bool array the size of MAX_LIGHTS, go through the current vertex' normal, check that against the light data, then write a true or false. In the frag shader, if bool_array[number of light you're processing] is false, skip to next light.

Should work, I think.

At any rate, I think you can't do it without defining your own light structure, which means a few changes to the rendering architecture.

[Valathil]

Yes a rewrite is all but inevitable but looking at the code itself it looks pretty simple and well structured. I could do some little experiments in my cave with a box of scraps and look what I can hack together. Then everybody will name their babies after me.

Let's just say that people would probably be naming their babies after you.

Even though Valathil isn't such a great name for a baby if you think about it  and my real name is even worse.

[chief1983]

When I read it, it sounds a lot like 'falafel', so yeah, bad baby name

I'm interested in seeing the results of your experiment.

[Valathil]

Its more waalathil  (th as in theory) not wallafil 

[chief1983]

I mean not exactly like it, just kinda rhymes with it too much.

[Valathil]

Anyway dont name your Baby Valathil...

... or falafel

[chief1983]

I actually planned on naming my baby falafel.

[Trivial Psychic]

Its more waalathil  (th as in theory) not wallafil 

Is that elvish (Token)?  How does it translate?

[Spoon]

So have you noticed how the environment maps on the ships are always flat on the poly's like they reflect from a perfect mirror? Really doesn't work together well with bump mapped surfaces. This is especially noticeable in mods like WoD where you have SHINY ships. So after a little tweaking from my end here is the fragment shader for environment map displacing by bump map. This looks S W E E T in WoD, just try it (PROTIP: Ray Mark 3 in F3 Lab). Feel free to use and abuse this just thought I'd pitch in with a small idea to make those sweet shaders even better. I hope I used the newest version of the shaders as a baseline but the patch is simple enough so porting it should be easy.

WoD mentioned
Could someone post a screenshot of this? I wanna see 

Oh and welcome to the forums, may your stay be long and productive (: