Interesting. I'm wondering why this did compile with gcc actually. I see that you have committed a fix already.

In case anybody who can't compile the engine wants to play with this: Here is a build of the current mesh branch.

So I think I (partly; there is still a gotcha when entering a water basin sideways or from the bottom) know what's the problem with swimming currently - the proper solution is to always interpolate rotations the "short way". As far as I see this no longer allows interpolation between an arbitrary amount of animations. I therefore suggest to introduce an animation stack instead: The lowest two animations are combined, then the result is combined with the next animation, etc.

C4Script functions

I also suggest a somewhat extended script interface to simplify otherwise redundant code which calls AnimationSetState each frame:

bool AnimationPlay(int stackpos, string animation, array peval, array weval)

Starts the given animation at the given stack position. The animation is combined with the result from the combination up to the animation which is at the next smaller stack position. This animation has its associated weight (see below), and the previous animation uses (1 - weight). Afterwards, the result is combined with the animation with the next higher stack position in the animation stack. This means that the weight of the lowest level in the stack is unused. Also, stackpos == 0 is not allowed since this is reserved for ActMap animations. It is possible to set values smaller or larger than zero however (to combine before ar after the ActMap animation is combined). The function returns false if there is already an animation being played at the given stackpos.

bool AnimationStop(int stackpos)

Removes the animation at the given position from the stack.

bool AnimationSetState(int stackpos, array peval, array weval)

Changes the way the animation at the given position is currently being played.

Value evaluation

peval and weval can be constructed via helper functions, much like the arguments for FindObject(s). They define how the animation is being played. All of these are applicable to both peval (determines how to choose the current animation position) and weval (determines how to choose the current animation weight). Possibilities include:

Anim_Const(int value)

Set position or weight to the given value. This is what AnimationSetState currently does.

Anim_Linear(int start, int end, int length, int atend)

Interpolate linearly in time between start and end. This means that in the frame of the function call the value (position or weight) will be set to start, and after length frames it will be end. atend defines what to do after length frames. The following values are possible: ANIM_Loop (restart at start), ANIM_Hold (keep end until a new call to AnimationSetState is being done, or the animation is removed) or ANIM_Remove (remove the animation from the animation stack).

Anim_XDir(int start, int end, int length, int atend)

Base the animation speed on the object's current xdir. This is meant for the Walk and Run animations to synchronize the Clonk movement with its animation. length defines after having moved how many pixels in X direction the animation is supposed to reach end.

Anim_YDir(int start, int end, int length, int atend)

Same as Anim_XDir, but for vertical movement (scaling).

Anim_RSin(int start, int end)

Calculate the value like "start + Sin(Abs(Angle(0,0,GetXDir(),GetYDir())), end - start)", i.e. use start for horizontal movement and end for vertical movement. This is meant to be used for the swimming animation weights.

Anim_RCos(int start, int end)

Same as above, with Cos replaced by Sin.

Final notes

Let me know if any other position/weight evalution functions make sense to achieve required behaviour (hangling?) without resorting to a Frame=1 timer.

Note also that, using this functionality, it is possible to have the same animation multiple times within the stack (also allowing different animation position). This might make sense for example when blending from one animation to another, but getting back to the original animation before the blending has finished.

So let me know your opinion on this before I actually get to implementation :). Maybe stack is not the right term after all, since it is possible to insert/remove animations in the middle as well. It rather refers to the way how the animations are being combined... suggestions for other terms are welcome though.

But this should also be able for Cinema 4D. It's also very popular for Clonk Graphics. Not as much as Blender, but its also used.

A note on material scripts:

All material scripts (*.material files) are loaded into the same global material pool. I therefore suggest to prefix all materials used for an object with the object's name, separated by a slash from the material name, so for example instead of "Body" use "Clonk/Body". The idea behind this is to be able to share materials for multiple objects, and to be able to inherit materials (not all of this is implemented yet, but I hope it to be at some point). There is one catch however: To be able to use or inherit a material, it must be loaded already. This is only guaranteed if the material script file is in the object itself or one of the parent objects. Loading material scripts from System.c4g would be another nice thing for global materials that should always be available.

Meshes can now also be loaded from OGRE binary format. Please use this format instead of XML where possible as it is smaller in size and can be loaded significantly faster on engine startup. To export into OGRE binary format from Blender make sure the "OgreXMLConverter" button is pressed when exporting. There is also a standalone tool that ships with OGRE called OgreXMLConverter which converts existing meshes from XML into binary format.

Thank Isilkor for implementing this feature. Or buy him a pizza on the OCM.