Cal3d, New Character Animation Format

[mikeman]

small question...do the cal3d files store the names I give the bones in blender? If so, is it ok to have some uppercase letters in the bone names, or only lower case?

I'm not sure, but I don't think it stores names. In any case though, I don't think uppercase or lowercase matters.

 

----------------

Okay, now a very serious question:

 

I'm already in the process of adding Cal3D support. I manage to load and animate models(cally model) with more than one mesh and anims. But before proceeding further, I need to know some things, so I can intergrate the whole thing with the game.

 

As I understand, a character is represented by an "actor" structure. There is a list with all the actors in the game. An actor has a "cur_frame" member that is the current animation keyframe. The renderer draws all the actors using that info.

 

Now, for bone animation I would need to change some of that. "Cur_Frame" is not enough, since Raduprv mentioned that he wants the players to perform more than one animation(e.g walking and fighting at the same time), and the animations are supposed to be smooth.

 

I will examine the code myself, but I need to know how the animation is currently handled. I suppose the client takes the animation info for all the actors from the server. Which information(current keyframe, or only current animation?), in what format, when(every frame?every 100ms?...), and how?

 

Please post only if you're sure of what you're saying. I would like to hear from Raduprv about this.

Edited January 23, 2005 by mikeman

[Wytter]

Hey mikeman,

 

First of all, I uploaded a new version of the Doxygen documentation to: http://wytter.tfm.ro/elc/docs.zip

 

--------

 

Now to answer your question, this is how the animations are handled in the client:

 

When the client recieves a new actor the initial animation is set through an Uint8 (in a variable called frame - look at add_actor_from_server() and add_enhanced_actor_from_server(). The frame can be either of the following:

 

#define frame_walk 0
#define frame_run 1
#define frame_die1 2
#define frame_die2 3
#define frame_pain1 4
#define frame_pain2 11
#define frame_pick 5
#define frame_drop 6
#define frame_idle 7
#define frame_harvest 8
#define frame_cast 9
#define frame_ranged 10
#define frame_sit 12
#define frame_stand 13
#define frame_sit_idle 14
#define frame_combat_idle 15
#define frame_in_combat 16
#define frame_out_combat 17
#define frame_attack_up_1 18
#define frame_attack_up_2 19
#define frame_attack_up_3 20
#define frame_attack_up_4 21
#define frame_attack_down_1 22
#define frame_attack_down_2 23

The different frames for the given actors are set in the actor definition structure (actors.h):

 

typedef struct
{
       char skin_name[50];
       char file_name[50];

       char walk_frame[20];
       char run_frame[20];
       char die1_frame[20];
       char die2_frame[20];
       char pain1_frame[20];
       char pain2_frame[20];
       char pick_frame[20];
       char drop_frame[20];
       char idle_frame[20];
       char idle_sit_frame[20];
       char harvest_frame[20];
       char attack_cast_frame[20];
       char attack_ranged_frame[20];
       char sit_down_frame[20];
       char stand_up_frame[20];
       char in_combat_frame[20];
       char out_combat_frame[20];
       char combat_idle_frame[20];
       char attack_up_1_frame[20];
       char attack_up_2_frame[20];
       char attack_up_3_frame[20];
       char attack_up_4_frame[20];
       char attack_down_1_frame[20];
       char attack_down_2_frame[20];

       body_part head[5];
       body_part shield[10];
       body_part cape[20];
       body_part helmet[20];
       weapon_part weapon[80];

       shirt_part shirt[22];
       skin_part  skin[4];
       hair_part  hair[9];
       boots_part boots[20];
       legs_part legs[16];

       double walk_speed;
       double run_speed;
       char ghost;
} actor_types;

Currently all actor definitions are loaded through init_actor_defs() in actor_scripts.c, which is an extremely ugly and hard-coded way of doing this (it's definately on our TODO to rewrite this so it'd probably be loaded from an xml-format).

 

Now, when the actor has been added from the server the server will set the animation frames through add_command_to_actor() in actor_scripts.c. It's still an Uint8. The animation frame that the client gets from the server is added to a command queue that holds up to 10 commands that the actor is going to do client-side.

 

Now, changing between the different commands and movement is done via the timer thread, whilst the direct animation is done in the main process (where network and displayal is handled). See my_timer() in timers.c. This timer is at max called every 10s ms, but initiated as every 1000/(18*4) miliseconds.

 

Now, the framenames in the actor_defs is actually just the initial frame names - the animation timer thread is updating the frame # of the given frame-type when animating the actor, so the server doesn't have to send every frame, but just initiate a certain movement - this could for instance be rotation or walking, that always does a fixed number of frames and moves the actor n meters/rotates the actor m degrees.

 

Animation:

First the next_command() is called.

If the actor is not currently busy executing a previous command this function will check the next command in the command queue (actor->que), then initiates that command by copying the first frame from the actor_defs and setting the # of frames left, speeds and rotations.

 

Next the actor needs to be animated - which implies switching between frames and changing the rotation/movement of the actor. This happens in move_to_next_frame(). It will check the data given by next_command() and the number of frames left to execute the given command. It will move to the next frame by changing the cur_frame string and increasing the frame number. If the frame does not exist it will set the cur_frame string to it's initial value <frame type>01 (i.e. walk01).

 

The timer thread will now push a userevent (EVENT_ANIMATE_ACTORS) that makes sure that the main thread animates the actors - that is, changing the x, y, z positions and rotations according to the speeds/directions specified in next_command().

 

I hope this helps to understand how animation is done currently. Perhaps Radu can tell you a bit more indepth about this though

[Malaclypse]

small question...do the cal3d files store the names I give the bones in blender? If so, is it ok to have some uppercase letters in the bone names, or only lower case?

 

Hi Roja,

 

yes it stores the bones names as mentioned in my previous post (the skeleton paragraph). And they are stored in a case sensitive manner. But this shouldn't care you right now. You can name then in any mixture of upper and lower case letters and numbers. More important is, the mapping of meshes to bone names must be equal, if you want to interchange skeletons and/or meshes.

[Roja]

Ok next question... Does it matter where the mesh's pivot is? Should it be in the middle of the mesh object? or on the floor, at the center for all of the mesh pieces? Or is that pivot not even goign to be exported at all so it won't make a difference with the cal3d files?

[Malaclypse]

As far as I see, the pivot will not get exported. There's nothing in the files, that indicates the use of a pivot point, nor did I found anything in the cal3d API.

[Roja]

Ok, here is the final list of bones that I've put on:

 

head

shoulderR

shoulderL

armupR

armupL

armlowR

armlowL

handR

handL

swordR

swordL

back3

back2

back1

root

hipR

hipL

thighR

thighL

calfR

calfL

ankleR

ankleL

footR

footL

cape1

cape2

cape3

swordR

swordL

 

30 total.

There might be a few more for different weapons, but i'm not sure on how many yet.

Animations planned:

 

default

walk

into sit

sit

out of sit

into fight

fight idle

out of fight

punch1

punch2

kick1

kick2

hack1 (for single handed weapons)

slash1 (for single handed weapons)

hack2 (for polearms)

slash2 (for polearms)

pain

spell on self

spell on others

swim

 

*ride animals?

*bow

*crossbow

*slingshot

 

There will be many more special animations(mostly all battle attacks), however these will be the defaults.

 

Questions:

1. What is the limit in the length of the animation name?

2. Will we be able to ride animals?

3. the bow, crossbow and slingshot I originally made the arrow animated, coming out of the quiver. I did this by using floating bones, which I cannot use in cal3d. Waht I did was had the arrow in teh quiver, then the player's hand reached back to grab it, took the arrow, strung it on the bow and fired(the arrow would be on the string in one frame, then the next frame back in the quiver). How will we do this now? It's impossible for me to animate the arrow without a floating bone-the floating bone gave me the ability to move that bone anywhere I wanted. The bow strings will have to be animated with 2 bones attached to a third for the wood part of the bow, which is then attached to the hand.

Perhaps I can place the arrow on a bone attached to the hand, however the arrow would have to appear at a specific frame in the "firing arrow" animation. Is that possible? IOW.. animation starts: hand goes back to grab the arrow.. THEN at that frame the arrow will appear in the animation until it is let go from the string.

[mikeman]

1) The animations are saved in seperate .caf files, so it's 255 characters, if that's what you're asking. I haven't seen Cal3D store internally any animation name, it just loads them using the filenames it gets from the .cfg file.

 

2)This is not an animation-specific question, riding animals is a new gameplay feature, right? Anyway, as far as animation goes: IMO, adding a completely new "animal-player" skeleton and new animations for it is too much.

 

I *think* all it needs is to add a new "ride" animation to the player, that match the movement of the animal. The animal model doesn't need any changes(unless there are actions it executes only if the player is controlling it). Both models are seperate as always, and I just place the player on top of the animal executing the "ride" animation, and maybe move him up/down according to the bounding box of the animal.

 

From what I understand, animations are "localized", that is a "combat" anim can be restricted to the bones of the upper half of the body, so the player can ride and execute other actions as well.

 

3)I'm sure it can be done. Of course, the bow(and generally all the weapons) needs to be a seperate mesh from the body, so I can flag them visible/unvisible.

 

-------

I also have a question: What is the benefit from using texture masking? As I see in the game, you already have support for different hair,face,clothes,boots... What more you want to achieve with it?

[Roja]

Ok great so riding animals will be possible (the animations will be np for me, just take a lot of time ).

 

 

Texture masking:

1. Be able to show skin on the legs, and torso (currently we cannot do that), while having different colored clothes still somewhere on those parts of the body.

This I need mainly for other future playable characters, like Minotaurs, who'd look stupid in the clothes we have now.

2. More clothing variety(skirts, shirts that show your arms, etc...), maybe face paint, sandles, etc etc...

Just an overall more variety of things possible, that we currently cannot have because of the limitations.

[Leeloo]

3. Swimsuits

 

One thing to consider... If you ride an animal, and get attacked, what will happen? Do we need combined riding/fighting animations? Some animations could possibly be reused, e.g. kicking can not. Or do they simply attack the animal first, kill it, and then attack the player?

[Roja]

I would have to make specific fight animations for riding on the animals. The normal fight animations can not be used, unless you want to kill your horse's head instead of your enemy

But there are some more major issues if we make fighting on animals possible (like, which side do you attack from? you have to be near your enemy, unles syou just want the animals to fight each other and you just ride the animal).

 

But in fact there's an even bigger problem that maybe you can help us solve, not related to cal3d: The creatures in the game only have ONE square that they take up, so for bigger creatures in the game(deer, bears, etc), half of their bodies go through each other if they fight, or fight with you, and also go through other objects. Would suck if you're riding a horse, and face off with another rider, both heads would be stuck inside each other.

[mikeman]

Btw, what about shading the models? I noticed that you currently don't do that for characters. There's no reason not to shade them, at least per-vertex lighting is possible for most machines today. It would be a shame to have bone animation and cool skins and yet the players to look flat-shaded.

 

I've played a little with that, using the old format(since I don't have player models in cal3d format):

 

http://img140.exs.cx/img140/3891/elshading9kh.jpg

 

I've used face normals and not vertex normals, but you can notice the difference.

[mikeman]

But in fact there's an even bigger problem that maybe you can help us solve, not related to cal3d: The creatures in the game only have ONE square that they take up, so for bigger creatures in the game(deer, bears, etc), half of their bodies go through each other if they fight, or fight with you, and also go through other objects. Would suck if you're riding a horse, and face off with another rider, both heads would be stuck inside each other.

Hm. That is a collision detection issue, and I have the impresson that collision detection is handled by the server.

[Roja]

Vertex shading would be nice. Actually though with the new shadows the model is pretty well shaded.

[mikeman]

Actually though with the new shadows the model is pretty well shaded.

New shadows? If you mean the shadows casted by objects, that's another issue.

[Wytter]

Try typing:

%use_shadow_mapping 1

 

In-game - or set it as

 

#use_shadow_mapping = 1

 

in el.ini

 

They were not made default as there are still some issues (they look horrible on snow)

[mikeman]

Yeah, but as I said, shadow mapping and the like are for casting shadows, finding whether an area should be lit or not. It has nothing to do with the actual lighting calculation(gouraud shading,phong shading...), which gives the surfaces a smooth appearance.

 

I'm talking about smooth shading the surfaces based on the light direction and the normals. They're two different things.

[Roja]

I'm not even sure as to how to do vertex shading in blender..guess i can find out, but it's really not a big deal, i mean it doen'st look like there's a big difference in those screenshots. I think it'd be more useful for some static 3d objects.

[mikeman]

I'm not even sure as to how to do vertex shading in blender..guess i can find out, but it's really not a big deal, i mean it doen'st look like there's a big difference in those screenshots. I think it'd be more useful for some static 3d objects.

It has nothing to do with modelling, the shading is entirely programmer's work.

[Roja]

oh, ok then

[mikeman]

And actually, it does make a big defference, it adds A LOT to the detail of the models. It makes them look like real 3D objects instead of flat-shaded ones. I've implemented smooth shading now:

 

http://img197.exs.cx/img197/9852/elsmooth5rt.jpg

 

I added 2 screens without textures, so that the amount of detail it adds is more apparent. And of course it's dynamic, so it looks way better in motion.

[Roja]

oh wow..yeah that does look great, good job!

Btw, my progress on the models will be a bit slow..as I work fulltime 5 days/week. However I'm going to start animating the first model today..so i'll try to get you a few animations to play with soon.

[mikeman]

Don't worry, I too will usually have time for this only on weekends(I've got University, and a part-time job).

[Entropy]

Great job

Keep up the good work.

[70347]

Perhaps I can place the arrow on a bone attached to the hand, however the arrow would have to appear at a specific frame in the "firing arrow" animation. Is that possible? IOW.. animation starts: hand goes back to grab the arrow.. THEN at that frame the arrow will appear in the animation until it is let go from the string.

 

I don't know much about 3d stuff, but wouldn't it be possible to have one bone in the quiver and another bone on the arm? When the animation starts the bone in the quiver is visible and the bone on the arm is invisible, but then when the arm reaches back for the arrow the bone in the quiver disappears at the same time as the bone on the arm appears. When the animation is finished the bone on the arm would go back to being invisible and the bone in the quiver would become visible again. This should look like what you had planned on before.

 

If bones can't be made invisible or if this is what you meant from the beginning then just ignore this.

[Roja]

70347: all the bones have to be attached to the 1 skeleton, so "invisible" or floating bones can't work.

 

 

As for the other things...looks like EL's stuck with small monsters for good. We'll just have to make the best out of it