Sky Configuration During Game
The current sky animation parameters, in an extended
way, should be executed at any time during a game,
as soon as a new configstring is transferred to the
Makes the current sky more lifely, adds to atmosphere at
If used heavily, adds to network traffic. Adds to
setup costs for sky rendering.
Requires rewrite of handling of sky related configstrings
during the game.
- CS_SKYAXIS as before, but can be changed at anytime.
Migration to new axis should be done by lerping,
to smooth changes. Could be used for tumbling effects.
Might better be implemented with Quaternions and
- CS_SKYROTATE as before. Changes during game would allow
for accelerating/deccelerating the apparent rotation
of the map with respect to the sky.
- CS_SKYACCEL. Rotation alone would limit to interpolation,
so lag might cause visible jerks when the sky comes to
a halt. In most cases, acceleration will be zero, so
this might be redundant, but expense is minimal.
- CS_SKY as before. Changing this at runtime should cause
a noticeable jerk because of texture cache trashing,
so use is probably very limited.
- CS_SKYBLEND: new, a string with 4 values, RGBA, which
are used to tint only the sky textures. Allows for
day/dawn/night cycles, and other effects.
- CS_SKYSTYLE: new, a string that sets a light level
for the sky as a configstring for lightstyles,
which modifies the skyblend. This could be used for
flickering sky animations, and scripted cycles.
Decals/patches (a sun) for the sky would add a lot, but
that is not a mere extension of an existing rendering step
like the proposed changes above, and might be difficult
due to the projection details required for environment
mapping. Tumbling skies and accelerating rotation as well
as varying blends/lighting would animate the existing
static sky and contribute to illusions of being immersed
in a moving vehicle/pod/space station.
Submitted 980407, revised 980420,
comments to firstname.lastname@example.org.