Lighting

[Per]

I have been working on the Warzone lighting system a bit, and I am starting to generate a lot of questions that I suppose our brilliant artists may be able to answer. This is the thread to discuss how the future Warzone lighting system should be.

There are a lot of parameters to set for the lighting system. The amount of ambient and diffuse lighting, for example. To generate a scene that looks like the current one with dynamic lighting, I needed to set ambient lighting to (0.6, 0.6, 0.6), but I wonder if this might drown out other lighting effects?

We have a single, fixed light source at the moment (the sun) for diffuse and specular lighting. Several people have tried making the sun move to generate moving shadows, but this turned out to be just annoying. I am thinking that the parameter for the light source should be changeable from scripts, so that some maps can be darker, brighter, have the sun at a different position, etc..

There are some other potential light sources as well. Currently explosions light up the terrain by manipulating vertex colours, not using proper lighting. This means that objects that are on top of the terrain are unaffected by such "light sources". OpenGL is only guaranteed to support 8 light sources, but it would be possible to add an OpenGL light source to the 7 nearest explosion effects to add proper lighting to nearby objects as well. I am not sure how important this is, though, as it happens so quickly that people may not notice it.

Then there is the question of support for materials and model normals. Currently normals are only calculated for the terrain, but models also need normals. I am not sure if we want to store normals in the model files (precomputed), or if we want to calculate them when models are loaded? I have noticed that in at least some model formats, each mesh has its own material properties. Should we extend the PIE format to do it the same way, or are there better ways to do it?

Well, those are some initial questions, at least. Once we have a proper lighting system up and running, we can start adding fancier effects like normal maps and the like.

[Deonis]

How can I create more lights than GL_MAX_LIGHTS?

First, make sure you really need more than OpenGL provides. For example, when rendering a street scene at night with many buildings and streetlights, you need to ask yourself: Does every building need to be illuminated by every single streetlight? When light attenuation and direction are accounted for, you may find that any given piece of geometry in your scene is only illuminated by a small handful of lights.

If this is the case, you need to reuse or cycle the available OpenGL lights as you render your scene.

The GLUT distribution comes with a small example that might be informative to you. It’s called multilight.c.

If you really need to have a single piece of geometry lit by more lights than OpenGL provides, you'll need to simulate the effect somehow. One way is to calculate the lighting for some or all the lights. Another method is to use texture maps to simulate lighting effects.

is this?
http://www.opengl.org/resources/faq/tec ... lights.htm
http://www.falloutsoftware.com/tutorials/gl/gl8.htm
http://techpubs.sgi.com/library/manuals ... 48-001.pdf

[Safety0ff]

OpenGL is only guaranteed to support 8 light sources, but it would be possible to add an OpenGL light source to the 7 nearest explosion effects to add proper lighting to nearby objects as well. I am not sure how important this is, though, as it happens so quickly that people may not notice it.

I don't think this is very important BUT if it was only enabled for certain levels of detail, then I'm sure these effects could be appreciated.

Then there is the question of support for materials and model normals. Currently normals are only calculated for the terrain, but models also need normals. I am not sure if we want to store normals in the model files (precomputed), or if we want to calculate them when models are loaded?

I think storing the normals is the best solution.

I have noticed that in at least some model formats, each mesh has its own material properties. Should we extend the PIE format to do it the same way, or are there better ways to do it?

Currently we don't have many multi mesh models (they won't render properly if they don't use the animation system).
I think we should have some way to maximise sharing of materials, so possibly storing materials in a separate files.

All said and done, we could probably just add make a connector specification for the OBJ format and we'd have the same set of features as if we extended the PIE format.

example of what I mean by "make a connector specification for the OBJ format":
Make OBJ objects with a name in the following format: CONNECTOR_# (where # is a number)
Here is what this might look like in an obj file:

Code: Select all

o CONNECTOR_1
v 64 64 0
p v1

This can be extended to arbitrary many vertices per connector which could be used as extra parameters.

@Deonis:
You don't have to worry about the technical side of things.

[MaNGusT]

I don't think that dynamic lights are necessary for a RTS game.
Normal and specular maps require only an 1 light to show properly.
Can't say much about regular explosions but satellite laser's explosion should have its own light "boom" effect of course.

Currently normals are only calculated for the terrain, but models also need normals. I am not sure if we want to store normals in the model files (precomputed), or if we want to calculate them when models are loaded?

I discussed this with I-NoD some time ago... Both methods are good. But if we want a good performance then hard disk is a "weak point". precomputed normals will impact performance while a map loads. So... Devs should decide what they want..

[Safety0ff]

I discussed this with I-NoD some time ago... Both methods are good. But if we want a good performance then hard disk is a "weak point". precomputed normals will impact performance while a map loads. So... Devs should decide what they want..

I believe he meant for models.

[MaNGusT]

I believe he meant for models.

I meant the same.

[Per]

Currently we don't have many multi mesh models (they won't render properly if they don't use the animation system). I think we should have some way to maximise sharing of materials, so possibly storing materials in a separate files.

We should fix the limit on multi-mesh models while we're generally fixing things with the model loader, so that should not be a limitation to consider. I do not see why we need to share material properties. The material properties I currently see a need for are ambient, diffuse and specular colour reflections, and shininess, a total of 10 values (3xRGB+1). We could add one new line/directive in PIE to store that data, one for each level (mesh).

All said and done, we could probably just add make a connector specification for the OBJ format and we'd have the same set of features as if we extended the PIE format.

Then the connector stuff would have to go into a separate file, right? Otherwise we'd make our own incompatible OBJ-like format, and be no better off than now. Then there is animation support, which AFAICT it does not have.

[DRAAK]

...We have a single, fixed light source at the moment (the sun) for diffuse and specular lighting. Several people have tried making the sun move to generate moving shadows, but this turned out to be just annoying. I am thinking that the parameter for the light source should be changeable from scripts, so that some maps can be darker, brighter, have the sun at a different position, etc...

Exactly! For example, three static positions (with different intensity of light)
Approximately as on the scheme:

[Jorzi]

I think static sun + ambient is a pretty good light setup. Precomputed normals are probably a good choice, since there is no mesh deformation in the game. I'm no expert, though.
I agree with mangust that stuff like the laser satellite might deserve their own light. For stuff like a ground shaker barrage, there of course doesn't need to be a light for every shell, not sure what the best way to do that is.
Anyway, I'm very happy to hear about the planned improvemnts

[Safety0ff]

Then the connector stuff would have to go into a separate file, right? Otherwise we'd make our own incompatible OBJ-like format, and be no better off than now. Then there is animation support, which AFAICT it does not have.

No, it could go in the same file. If we were to do it like in the example code it would be valid obj.

Of course warzone would only support a subset of all obj directives (i.e. none of the parametric surfaces).

It is just an idea I am bouncing around.

The material properties I currently see a need for are ambient, diffuse and specular colour reflections, and shininess, a total of 10 values (3xRGB+1). We could add one new line/directive in PIE to store that data, one for each level (mesh).

You're right, no need for separate files.

[MaNGusT]

I have noticed that in at least some model formats, each mesh has its own material properties.

AFAIK in 3ds max it's called sub-object material. Very useful option. but dunno, do we need it for wz.

Should we extend the PIE format to do it the same way, or are there better ways to do it?

I don't see a real reason to do it... for me it would be better to have a fixed amount of "bump" for normal maps and the same for the specular level and glossiness for all meshes.

[zamaszysty]

Speaking ofmax number of light sources in the game ... IS there any way to make it more? Or would it require changes in the game code beyond any coding possibilities? Why am i asking? Because some projectiles could be set as light sources, which combined with "night" effect would make the game an eyecandy despite its age ...

Also with light sources other than "global light sources" (like the sun, moon, or sth like that) there should be some "fading shadows" etc. that would not represent a full structure (that casts the shadow) shape, but only partialy.

[Per]

I have committed code to use real lighting (1 light) now to master. Also added two new scripting functions setSunPosition(float x, y, z) to set the position of the sun and setSunIntensity() that has 9 floats giving the ambient, diffuse and specular RGB colours of the sun. Finally, a new, optional PIE file directive MATERIALS has been added that allows material properties to be specified; as above, 9 floats to give reflective colours and one extra float for shininess. None of the converters/plugins support this new directive yet.

@zamaszysty The limit on the number of lights is driver/hardware/language dependent. There are many tricks that can be used to overcome this limit, though, if we really think this important.

[zamaszysty]

Not really that important to me ... i was just thinking about effects that would atract more players to the game despite its (technologicaly) old. To me it would be just a bonus that wouldn't change anyhow my interest in the game.

[Jorzi]

for me it would be better to have a fixed amount of "bump" for normal maps and the same for the specular level and glossiness for all meshes.

I agree, I think controlling this with texture maps only makes material editing more simple. Or maybe make it so that you can either enter the name of a texture or a simple rgb value for models that lack specular maps...