Several rendering changes have resulted in a non-rendering build that
failed to build from source. Dummy out all of these functions to make it
work again.
Cherry-picked.
Author: Nicolas Hake <isilkor@openclonk.org>
Date: Wed Jun 17 21:30:56 2015 +0200
Conflicts:
src/lib/StdMesh.h
Instead of transforming all vertices on the CPU every time an animation
progresses, we now only recalculate the skeleton, leaving the heavy
lifting for the GPU. This also means we no longer have to push all
vertices onto the bus every frame, because the mesh isn't changing and
can therefore be stored in a GL_STATIC_DRAW VBO when it's first loaded.
The downside of this approach is that there's only a limited number of
uniforms and vertex attributes we can pass to the shader. At the moment
these limits are a maximum of 128 bones per skeleton, and no vertex can
be influenced by more than 8 bones at once. So far this is no problem,
as the most complex skeleton in the base game uses less than 64 bones
and no more than 6 bone weights per vertex.
This should improve cache coherency by having all surface tiles adjacent
instead of strewn across the heap. This will also remove an indirection
in the common case of only using one tile.
This introduces a new texture, an ambient light map, that is generated
automatically at the beginning of the round by the sky portion of the
landscape. This basically makes everything that is close to sky visible
by default.
The shaders have been adapted so that they deploy direction-independent
lighting for the ambient component, and the current (diffuse) behaviour
for the diffuse component. This makes the shaders use an additional
texture unit that represents the ambient light. We can think about merging
this information into the light texture, but the coordinate systems are
different at the moment, so this could be performed at the stage of light
texture generation.
For meshes, the ambient material is not actually used, but instead a
diffuse light from the front is used. This makes many meshes look more
interesting, maybe also because the ambient material setting of most
meshes are not set correctly at the moment.
This replaces the fragile ShaderRef construction in StdMeshMaterialPass, and
it allows to re-use shaders and/or programs between different materials. This
is some more preparatory work for custom shaders.
As discussed in http://forum.openclonk.org/topic_show.pl?tid=2917, I
have merged all copyright notices into a single file and referenced that
merged file from each source file.
For the updated source files, the timeline has been split into three
parts:
1. Pre-RWD code (before 2001)
2. RWD code (2001 through 2009)
3. OpenClonk code (2009 and later)
All pre-RWD copyright notices have been left intact, as have RWD-era
copyright notices where the file did not have a RedWolf design copyright
notice but only individual author ones. All copyright notices of the
OpenClonk era have been replaced by a single notice ranging from the
first recorded year to the current year (2013). Mape code did not get a
OpenClonk Team copyright notice because it is somewhat separate from the
main OpenClonk codebase and has only been touched by Armin Burgmeier.
This might make the rendering a bit quicker, since the whole texture
environment setup that we do every frame is no longer required --
instead only the shader is bound and a few variables uploaded. However,
this was not the main motivation behind this change.
It also simplifies the code a bit. The texture environment setup is
replaced by GLSL code generation. Another small benefit is that for
texture units in material scripts that do not use an actual texture
image no hardware TIU is being used. This reduces the number of hardware
TIUs required for rendering the Clonk from 3 to 2.
The main benefit of this change, however, is that material specific
and clonk specific color variations can be applied correctly. This mainly
concerns ClrModulation and MOD2 drawing. Before, the ClrModulation was
mixed with the material color, which could lead to incorrect results
depending on what the texture units were doing. Now it is being applied
by the shader after all texture units in the material scripts have been
processed.
Another motivation of this change is to implement support for custom
shaders, which is already foreseen by OGRE material scripts. The
specification has only to be implemented. With this change in place,
both custom shaders and "fixed" processing can share the same code in
the engine, since both end up using a shader for the mesh rendering.
The shader currently works only for directional lights, but should be
easy to extend to also support point lights.
These are the ones that the blender 2.6 exporter sets automatically. We don't
support them yet but we want to be able to load the material script
nevertheless. Many of the additional options are set to their default values
anyway.
Nicolas Hake