Given that the new materials have less structure, we want more pronounced yet
softer borders on the materials.
Also they seem to be using an inverted Y-axis for the normals...
There are a number of knobs here that you can meaningfully turn, but
so far they were a bit buried in the code, plus you couldn't easily
override them. By putting them into the "init" slice, it should now
be relatively easy to experiment with light effects.
Concrete changes:
* Skip lighting computation completely without OC_DYNAMIC_LIGHT. Means
that we don't have to fiddle with lighting parameters any more to make
sure that we just get the original texturing.
* Ambient level automatically adjusts so that a Z normal reproduces the
texture in its original brigthness. Might want to change this if we
want the game to be brighter than the UI.
* Don't apply FoW to the Sky - implemented properly this time. We'll
see whether this is a good idea.
This attempts to replicate the look of the "rim shading" change using
less insane methods. Notably
1. Use the same light normals for objects and landscape
2. Change extend_normal so it is less "extreme" (= light is coming from
the front more often)
3. Ramp up weight of edge normals for landscape significantly so they
doesn't *completely* disappear.
4. Ambient light 200% brighter, point lights 150% brighter.
This implements the proposal made in the forum for "shiny" materials -
material can now determine the angle at which the most light is reflected.
Shiny materials might set this lower to approximate a "reflection" effect,
and increase the "spottiness" at the same time. To compensate for the
lack of brightness without light, "emittance" can be used.
Not sure this is the most elegant way to model this - the "proper" way
here would be to have emittance, shading and specular as three separate
light parameters instead of molding one into the other and using the third
to compensate.
Furthermore, this reorganises shaders in a major way: We reduce the
number of shader files down to three, pushing a number of possible
configurations into preprocessor. I believe this should be easier to
understand, which for the moment trumps theoretical extensibility
benefits.
Armin Burgmeier