This is required for glDrawElements() with a core profile. Furthermore, for
meshes that have a fixed face ordering (non-transparent meshes at 100%
completion), this puts more static data on the GPU that we don't have to
upload every frame.
For meshes with non-fixed face ordering, we still have to upload faces every
frame, since the ordering might change if the mesh rotates. We could still
improve this by figuring out if the order actually changed after the sort
step, and only update to the GPU if it has. In many cases it hasn't, so there
is some potential for more optimization there. But that's for later.
Changing the mesh material to something that does not use alpha blending
restores the originial face order. This caused a crash for meshes with
Completion below 1, since all original faces were copied, but the buffer
in the mesh instance was only large enough to hold the number of faces of
the incompleted mesh. To fix this, simply run the standard
select-faces-for-a-given-completion-value procedure.
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.
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.
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.
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.
Julius Michaelis