Enabling during-game server-side control of OpenGL fog on the clients allows for adding another feature to gameplay, orthogonal to existing mods, maps, and extensions. Changing it during the game offers a range of possibilities. As an experimental feature, it is cheap to implement, and easy to apply. Implementation is resembles sky/environment mapping configuration.
Advantage:
Any map, mode or mod could be played on a server with "fogging", enforcing different tactics and strategies, and refreshing the gameplay. It means changing the game rules with an orthogonal feature.
As a secondary use, reducing bandwidth and number of entities to draw is possible. Changing the fog during the game - lowering and raising the veil, so to speak - should do for some interesting play.
Disadvantage:
OpenGL driver and or 3D accelerator hardware might not handle fog correctly, or only at a severe performance penalty.
Effort:
A set of server side configstrings, like for the sky, mapping to the OpenGL fog parameters:
CS_FOGTYPE : string, "none", "exp" | "exp2" | "linear"
CS_FOGPARAM : float, either one (density), or,
for "linear", two (start and end value)
CS_FOGCOLOR : float, four (RGBA)
See OpenGL Red Book, pp. 243-244 for details.
In all three cases, the effective distance has to be calculated by the server. Effective distance is given by fog factor f(max_z) < epsilon for some sufficiently small epsilon (that is, the original color is gone, it's all fog). We might want to have that in our GameDLL for AI purposes, and gi.trace isn't going to help, so we need a game_import function
// Effective range of view. float (*rangeOfView)();Alternatively, this function could be exported by the DLL to the server.
The server does need this function to calculate z_max as the effective rear clipping plane. The server will cull network transmission by visibility, so the client will not get any entity data of entities beyond the clipping plane (speed up, limitation for client side bots). The test is a dot product and check for the sign and value as opposed to the bounding box radius, and reasonably cheap.
Like the sky configstrings, the fog parameter has to be transferred to the client. The client passes it through to the OpenGl renderer, which can call
glEnable( GL_FOG ); glHint( GL_FOG_HINT ); glFog( ..., ... );more or less independend of everything else. This feature, like shadows or mirrors in Q1/Q2, is experimental - if the 3D hardware or the OpenGL driver exacts an unacceptable performance penalty, you can't use it.
Like sky configstrings, the changes should be applicable at runtime. Changes at FRAMETIME will be more than sufficient; scripting or interpolation seems to be inadequate.
Additional special handling for lights might be necessary. Lights do not have a wider range of visibility, compared to walls, with a simple fog added.. Fog parameters could be changed for FULLBRIGHT lightsources.
Colored light will not bounce of/tint the simple fog, so if you are nearby a colored lightsource, which is behind you, the color that is e.g. used to tint your model or your gun's viewmodel has to be used to tint the overall fog used, to fake the effects of scattering and reflection.
Related:
This is different from spatialized fog implemented by mechanisms for volumetric lighting. It might be thus redundant, or a nice replacement/addition.
Like with all graphics configuration (gl_flashblend), a client side gl_fog switch would be subject to exploit for cheating. In multiplayer, all such commands affecting the display should be subject to server approval.
Submitted 980416, revised 980428, revised 980429, comments to Bernd Kreimeier.