This reverts commit 790219ac7e.
This commit broke support for Mac OS X since Apple only supports OpenGL 3.0
with a core profile, not a compatibility profile. Revert this commit
temporarily for the 7.0 release, until we port all OpenGL usage to the core
profile with 8.0.
This fixes#1495.
It's somewhat experimental by now. The old behaviour can be obtained by
setting normalMapStrengthMax to the same value as normalMapStrengthMin.
I hope this helps a bit with #1418.
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.
This reverts commit 8ef1f908cc. This seems to be
a performance bottleneck on some graphics cards and/or drivers. Clonkonaut
reports issues with a Radeon HD 7800.
This feature is not vital since textures can always be drawn such that they
tile properly at 512x512. While that particular problem with the Radeon card
could probably be worked around, it's just not worth it.
A texture array is conceptionally what should be used in this case. One
advantage of this is that we don't have to generate mipmaps ourselves but can
let the graphics driver take care of it. Same for selection of the mipmap
level. This would even allow to choose different mipmap levels for different
textures.
This is a somewhat experimental change since it makes OpenGL 3.0 a hard
requirement for OpenClonk. I expect that this is fine, but if this causes
failures during landscape creation on common hardware/drivers we should
revisit.
This allows to ignore slice declarations using `#define slice(x)`, which
mill be useful for custom mesh material shaders, allowing to write them
such that they can be used standalone in a mesh viewer but also as slices
for OpenClonk, in which case lighting and color modulation will be applied
automatically.
Armin Burgmeier