Although the current shader gallery does much to show off the possibilities of the shader languages it is of little help when it comes to categorize and use the files given in the "share/crystalspace/data/shader" directory in one's installation.

In that case a list of the shaders, their usage contexts, list of input parameters and their range of values as well as a resulting image (or more, as the case may be) as an example would help much to choose the correct one for a task at hand.

Although it doesn't turn out to be a step-by-step tutorial, I hope those pointers may help along:

3rd person view means that the camera is centered on the actor character as it is moving through the world.

The main concerns are, in that order

• That the actor doesn't walk through obstacles
• Have the camera follow the actor
• That the camera view isn't cluttered by some object

The first item on the list should be fairly easy to handle - bind the collider_actor to the acting object in question instead to the camera. Having that done you should come up with a fixed-view camera and the actor moving around the world space respecting any possible collisions.

Next comes the camera movement.
There are different ways to have the camera bound to a certain object. The easiest would be to periodically read the position and bearing of the object, add a certain vector and angle and have the camera position and bearing set with these values.

Last comes the method how to keep the field of view free from any obstacles.
As one could see in different games there are different ways to achieve this goal, ranging from moving the camera nearer to the actor, past the obstacle, rotating the camera around the actor or simply not drawing the obstacle or making it transparent.
The easiest way would be to do a TraceBeam() between the actor and the intended camera position (mind the direction of the beam - actor to camera) - it catches any object which sits right in the middle of the field of view between the camera and the actor as well as the position where the beam hits the first object on its way into the camera. Placing the camera in front of that given position should be a piece of cake in that case.

Of course, of course, that was more or less a hack to see if it would set things right... Some function like "StopAnimAction(cost char *name)" to (prematurely) stop the action animation being played.

One scenario for multiple locked animations would be to mix an animation of "sitting down" together with "reading something". Sitting just affects everything from the waitline down (pelvis and legs), reading manages the positioning of the arms. Combining both would result in a figure sitting somewhere at a table and reading.

Another tack is to reduce the idle animation simply to breathing or suchlike - and let the handling of certain "waiting" animations (like shuffling the feet or scratching oneself) being done by the surrounding game engine - in most cases it has its own ideas of how the creatures pass their time. Then, state animations may be done like "sitting_down" (letting the creature sit down and leave it at that, with locked=1) and "stop_sitting_down" (for gracefully standing up) or suchlike.

Next, one may blend a locked action animation into the figure to have it look a certain direction - have two animations like "head_turn_left" and "head_turn_right" where the head is turned 90 degrees to the left or right, respectively - and use the weight to adjust the actual angle. Using the delay values one can leave it to the animation subsystem to have the head turned in a graceful manner.

Hmmmnnn.... That warrants for another class of animations, let's call them "state animations", which may consist of a pair of one locked animation (transition from default to changed state) and one non-locked animation (transition back to default) with some function like "SetAnimState(char *state, bool ison, float delay)" to transform the figure into a given state (like sitting down, lying on a floor or such) and back to normal. Perhaps together with a blend weight...

Definitely need to think about that further.

Granted, I'm not sure where this is better situated. It is more a feature request for an existing plugin.

Enough forewords, here it comes:

Playing around with SprCal3D I found it quite suitable for my character animation needs, but there is just one thing that is present in the Cal3D library which is passed on quite inadequately in the CrystalSpace SprCal3D plugin.

When using cal3dstate->SetAnimAction(action_name,blend_in,blend_out); where anim_name describes an animation with the "lock" state set (meaning the animation gets stopped at the last frame and won't be faded out) you can't get rid of the animation with any other means than calling sprcal3d->ClearAllAnims(); .

As a quick patch I did what is described in the following diff:

Code:

--- sprcal3d.cpp.orig   2005-10-05 12:14:32.000000000 +0200
+++ sprcal3d.cpp        2005-10-05 12:15:49.000000000 +0200
@@ -1756,6 +1756,14 @@
 bool csSpriteCal3DMeshObject::SetAnimAction(int idx, float delayIn,
                                                float delayOut)
 {
+  if (idx == -1 && last_locked_anim != -1)
+  {
+     calModel.getMixer()->removeAction(last_locked_anim);
+     last_locked_anim = -1;
+     is_idling = false;
+     return true;
+  }
+
   if (idx < 0 || (size_t)idx >=factory->anims.Length() )
     return false;

To be short, it adds the option to do a cal3dsprite->SetAnimAction(-1,0.0,0.0); to remove the previosly set "locked" anim, though it is lacking any handling when there is more than one locked animation active (as it is with ClearAllAnims() as well).

Hope it helps.