Lighting
Lighting
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.
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.
Re: Lighting
is this?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.
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
My 3D reality - https://itvista.ru
Re: Lighting
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.Per wrote: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 think storing the normals is the best solution.Per wrote: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?
Currently we don't have many multi mesh models (they won't render properly if they don't use the animation system).Per wrote: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?
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
@Deonis:
You don't have to worry about the technical side of things.
Re: Lighting
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.
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.
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..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?
Re: Lighting
I believe he meant for models.MaNGusT wrote: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..
Re: Lighting
I meant the same.I believe he meant for models.
Re: Lighting
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).Safety0ff wrote: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.
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.Safety0ff wrote: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.
Re: Lighting
Exactly! For example, three static positions (with different intensity of light)Per wrote:...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...
Approximately as on the scheme:
Re: Lighting
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
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
-insert deep philosophical statement here-
Re: Lighting
No, it could go in the same file. If we were to do it like in the example code it would be valid obj.Per wrote: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.
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.
You're right, no need for separate files.Per wrote: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).
Re: Lighting
AFAIK in 3ds max it's called sub-object material. Very useful option. but dunno, do we need it for wz.I have noticed that in at least some model formats, each mesh has its own material properties.
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.Should we extend the PIE format to do it the same way, or are there better ways to do it?
-
- Rookie
- Posts: 21
- Joined: 26 Dec 2010, 04:46
Re: Lighting
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.
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.
Re: Lighting
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 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.
-
- Rookie
- Posts: 21
- Joined: 26 Dec 2010, 04:46
Re: Lighting
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.
Re: Lighting
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...MaNGusT wrote: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.
-insert deep philosophical statement here-