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.
While we're still not doing skinning on the GPU, copying the vertex data
to a VBO immediately after updating the animation allows us to re-use
that data for unanimated meshes. It also allows us to store unanimated
data on the GPU, instead of transferring it over the bus for each frame.
Appending and including skeletons works now. Documentation updated.
Skins such as appendto.Clonk.Farmer.skeleton are handled as if the skin name were not included: appendto.Clonk.skeleton
This also changes a bit the structure of how meshes are reloaded in general,
in particular mesh materials are only reloaded once and not once per
C4DefGraphics instance. (Fix crash on reload with included skeletons, cherry picked from commit 2f69aa4850ab7a4b621e5f30cbc537d40f32c0df)
Fix linking of C4Script standalone tool (cherry picked from commit b03a332b73463b378c94e4e92b66d45b923b3b9c)
Animations are now part of the skeleton, and skeletons are loaded before meshes. They are stored in a map in StdMeshSkeletonLoader. This is only the first part of changes for #1180.
When using AttachMesh() with the flag AM_MatchSkeleton the behaviour was changed. The child mesh no longer uses the transformation of the bone in the parent skeleton by order, but by name.
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.
Pre-computed floating point numbers can be safely used in the comparison
function, whereas recomputation every time the sort function is called might
lead to a crash when the computed number is slightly differently every time,
because the sort function would return different results for the same faces.
I believe a possible cause for this is a object's model with a very low completion. However, I am not sure where the right place is to make sure everything goes alright in that case.
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.
The usage of timsort instead of std::sort at this point is twofold. First,
it's faster in our case where the array is already sorted in many cases
(remember this is called at least once a frame). And it's not just a bit
faster either but a lot. I have measured a factor of 7 on my system.
Second, in our Windows autobuilds there is a crash within std::sort which is
very hard to debug because it's hardly reproducible with anything other than
the autobuilds (I tried hard). If the crash goes away with timsort then
great, if not then maybe it's easier to debug since the code is in our tree.
Otherwise loading a savegame with an attached def mesh fails if the mesh
has neither attached meshes or animation nodes since the [ChildInstance]
section ends up empty in which case StdCompilerIniWrite does not write the
section at all.
Instead, retrieve the number on demand during serialization. This saves
lots of unnecessary code and makes serialization actually not modify the
objects. At least with the exception of nInfo, but that should be save.
The BitfieldAdapt had a builtin default of 0 for serialization, so it needs
that default when deserializing. Also remove that builtin default.
When AnimationNodes were loaded out of order, some of them were thrown away
when their vector was shortened. Don't shorten the vector during load.
Nicolas Hake