Lighting

[DRAAK]

...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...

Very interesting. Good work!

[Per]

Question for artists - do you see a need for ambient occlusion? I was thinking that this was important, until I realized that most of our complex stuff is composed of multiple independent models that are dynamically stitched together, and therefore cannot occlude each other, at least not in the usual way with static occlusion maps. Each model by itself probably has very little occlusion.

[Per]

Further updates in master:

• Per pixel lighting
• Hard-coded polygon limit removed (except for oil resource, delivery point and wall models)
• New PIE flag 0x1000 added which prevents a model from being stretched to terrain, useful if it has its own deep foundation

New question: Is there a need for partial transparency for model textures? I would like to remove support for this to speed up rendering.

The reason this is a problem is that any model type that could have transparency (currently relying on hard-coded rules to determine this) is currently depth-sorted for drawing, so that objects further behind are drawn first for colour mixing the transparent surfaces of objects drawn later. For high performance rendering, however, you need to reduce the number of state changes (context switches). That means drawing all objects of the same type (that haves the same texture, shader, etc.) at once, before changing to another type (with another texture, shader, etc.). In turn this means sorting the object list by type rather than by view depth. We can still support full transparency in the shader by simply discarding the pixel fragment. In this case the depth buffer is not changed, so the next object to draw over this pixel will update it, and the result will be as expected.

[MaNGusT]

Question for artists - do you see a need for ambient occlusion? I was thinking that this was important, until I realized that most of our complex stuff is composed of multiple independent models that are dynamically stitched together, and therefore cannot occlude each other, at least not in the usual way with static occlusion maps. Each model by itself probably has very little occlusion.

Nope because we use a premade AO textures and mix them with a standard diffuse textures.
I hoped that devs look at the AR forum sometimes.

New question: Is there a need for partial transparency for model textures? I would like to remove support for this to speed up rendering.

Where is it used?

[macuser]

YES, It is a very nice feature.... please keep partial transparency.

[Jorzi]

Short-range ambient occlusion as a dynamic screen-space 2d filter could be nice, although, as mangust said, we already have ao textures included in our models.
The terrain could possibly benefit from some kind of precalculated ao. The vertex shading it uses now works, but it looks a bit bland sometimes..
Partial transparency is of course very important for smoke, explosions and light effects, but I guess I can manage with 1-bit transparency only for models...

[Per]

No problem keeping support for partial transparency for special effects. AFAICT, partial transparency is not currently used in any models, only for water.

@macuser: Where do you foresee a need for partial transparency?

I guess I am a bit out of date when it comes to ambient occlusion stuff. I am used to thinking in terms of each vertex having an occlusion value that is used to darken the ambient lighting. I remember one format where this value was precomputed and stored, one for each vertex. How do the AO textures work? Are they simply multitextured on top of existing textures to darken them? Do they need separate texture coordinates? I could not find much information on this...

@mangust: Sorry. I am having a bit of trouble keeping up with various web forums.

[macuser]

@per like for anti aliasing on the light mg tower for instance - the struts that hold it up look terrible.

[Per]

@macuser - I see.

Perhaps we can add another PIE flag for those structures that need partial transparency, and keep them out of the normal batched sort order. I will see what I can do.

[Berg]

New question: Is there a need for partial transparency for model textures? I would like to remove support for this to speed up rendering.

Look at the oil derrick the fence is one example of transparency used in models.
The top of HQ's
There is a good few models that use it.

[Jorzi]

@Berg, the derrick and command center only use 1-bit transparency, which would not be removed, but as macuser said, antialiasing would not be possible. This would not be a problem for the derrick though, since the fence goes along the pixels.

@Per: Our use of ao textures is very simple and doesn't require any extra coding, we bake the ao in our favourite 3d program, then we multiply it over our color texture as a separate layer in the image editor. We keep them as separate layers to make editing easier, but we merge them for the final texture, so in warzone, it will be a single image texture and used as such. Essentially we just let the computer do part of the painting for us

Of course, using multitextures and multiple uv-maps would allow for more efficient use of texture space, but imo it's not that necessary.

[MaNGusT]

I've just reread this topic again and I think that we miss something. Now I have a couple of questions to Per...

Why there should be 1 light source for an each type of textures? I thought that at least normal maps and diffuse(regular) textures can use a shared light source....
well, if have 1 light source for an each type of textures separately, so could we use the type of textures as specular color - all it do is takes a color value from coordinates on a special texture and add this colors to a parts of model when reflecting. Using this textures we can reproduce a high quality reflections for those models like a buildings on the urban tileset where a parts of model such as windows and metal tubes reflects with different colors instead of white.

We didn't decide what should be done to explosions... should it be a textured(or not) participles or it will have an additional light sources when explode?
How this methods will impact performance?

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?

What parameters? what is 0.6, 0.6, 0.6? I know only some I need for textures.
-distance of light source (x,y,z)
-multiplier of a light.
-specular level (a level of how bright it reflects)
-glossiness (an area of reflections, will wide or not)
-soften (an amount of "tarnish/dullness")
what else do you have?

and if there are

None of the converters/plugins support this new directive yet.

any info about how to use new light features right? or just try them.

[Per]

I have not looked at drawing code in a while. There have been some other parts of the code base crying for attention (by crashing left and right)... What you say about specular color is interesting. Though I have no more answers in regards to how these things should be done, yet.

If you see my earlier comment (viewtopic.php?f=33&t=7250#p75835), you can experiment with moving the light around and changing its parameters from scripts. The 0.6 numbers are intensity of the light (RGB) from zero to one.

PS I added specular lighting to the game (extra lighting effect depending on camera's view angle to the sun), but in retrospect I think this was a mistake. The effect is very minimal, except that some people thought there was a lighting bug that darkened buildings for no good reason sometimes. So I intend to remove it again.

Hopefully someone else will pitch in and improve the graphics code while I'm busy with other things.

[MaNGusT]

PS I added specular lighting to the game (extra lighting effect depending on camera's view angle to the sun), but in retrospect I think this was a mistake. The effect is very minimal, except that some people thought there was a lighting bug that darkened buildings for no good reason sometimes. So I intend to remove it again.

There was turn light on button in debug mode. I-NoD added it to a future implementing of specular mapping, AFAIK. And without a specular maps all models will shine as hell.
Specular lighting should have at least 2 parameters to looks good - intensity, glossiness (an area of reflections, will wide or not). I can show difference.

setSunIntensity() that has 9 floats giving the ambient, diffuse and specular RGB colours of the sun

what is the difference between the ambient and diffuse?

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

it should be static to me. It will be easy if we will find the best values and then optimize textures for them but extra shininess float is still needed. is all parts of model reflects to the sun? I think yes, there should special specular texture for the proper shininess. As far as I understand, I can't specify specular texture to be loaded and used?

[Per]

I removed the light on button, since light is now always on. We not have support for specular texture/map yet, it is something we need to look at.

Ambient - light coming from every direction
Diffuse - light coming from a light source, scattered equally in every direction
Specular - light coming from a light source, scatter depending on the angle of the polygon to the light source