Jump to content
Eternal Lands Official Forums
Sign in to follow this  
Roja

Cal3d, New Character Animation Format

Recommended Posts

We're looking for a good programmer to help us implement Cal3d on the client, to have better character animation and new models. The programmer would be working a lot with me on it, since I do all the models, and would have to dedicate enough time to have good communication and work it all out in a reasonable time frame. You have to really know what you're doing on this :)

 

Things I want to accomplish with this new model format:

 

-the ability to have many more animations

-being able to recycle creature animations efficiently

-being able to ride animals

 

Also, things not related to cal3d:

-texture masking (to be able to have a bigger variety of clothing and playable characters).

-swimming

 

If anyone is really SERIOUS about this please post here and pm me :P

Share this post


Link to post
Share on other sites

Whoever wants to pick this up, take a look at cal3dwrap.c in the client, and search for where CAL3D is defined. I've already done the basic implementation (reads in one model and replaces all creatures with it).

Share this post


Link to post
Share on other sites

Hi guys,

 

It seems like I will be doing the conversion to Cal3D. I have looked at the code, but I will start working seriously on it from tomorrow. I *think* it will take some more changes than just the rendering part, though.

 

For instance, the actors now just store the keyframe name they're at, and the renderer just gets a vertex array from the cache and "draws" the model at that frame. Obviously, bone animation needs more than that. I haven't really looked yet how that data is retrieved(obviously, the client gets the animation data for all the actors from the server, right?), and don't know how server/client interaction is implemented for that part.

 

Anyway, a model will be stored something like this:

 

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

.csf file for the skeleton

several .caf files for various animations(walk,fight,stand...)

.cmf files for meshes(could be just one mesh, or more, like head,torso,legs)

.cfg file that binds all the above together

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

 

As a first step, I will try to make a basic system, much like Cicero did it, and let Cal3D do most of the work. I think the way the skinning and rendering is kinda slow though. Cal3D seems to do all the skinning in CPU and then each time you have to copy all the vertex data into a vertex array, and render it.

 

Fortunately, Cal3D has much more than that(infos about skeleton,bones, quaternions...), so later on I can add HW support and do the skinning in vertex shaders, having software skinning as a fallback. Vertex shaders will put a constraint on the number of bones in each mesh, but it will be much faster.

 

Roja, I understand what you mean with texture masking, but swimming? How is that different from the other animations?

Share this post


Link to post
Share on other sites

Swimming isn't different, and in fact that's not really something you'd have to do I don't think...all it is is that a flag needs to be set for when you are on a water tile AND the height of the tile on that water tile is a certain number(then swimming animation starts).

 

 

Also, I need to know how to set up the models for cal3d. Do I need to make the skeleton have ALL the bones we will ever possibly need on it? If so then that will be a lot, but it's doable of course. Just requires a LOT of pre-planning.

Also, can you scale a skeleton up and down for use with different sized characters(dwarves are shorter than humans, orchan are taller than humans, etc)? Or do I need to make a new skeleton for each different sized character?

 

And what about riding animals? is it possible? If so, any specifics on how i should set it up?

Share this post


Link to post
Share on other sites

Hey,

 

Also, I need to know how to set up the models for cal3d. Do I need to make the skeleton have ALL the bones we will ever possibly need on it? If so then that will be a lot, but it's doable of course. Just requires a LOT of pre-planning.

As a model in cal3d contains only one skeleton file I assume that you need to add all bones to it. A cal3d skeleton is simply a list of bones.

 

Also, can you scale a skeleton up and down for use with different sized characters(dwarves are shorter than humans, orchan are taller than humans, etc)? Or do I need to make a new skeleton for each different sized character?

No, you can scale them smoothly. I tried and changed cicero's code to load the cally model, which is included with the cal3d distribution, because I lacked the test model that's referred to by the code, and only saw her feet up to the ankle at first, oscillating on my screen :ph34r:. You can in fact scale any piece of a cal3d model separately, if necessary, i.e. any bone or mesh.

Share this post


Link to post
Share on other sites

Ok, I'm also assuming that each mesh upon export needs to be rigged and animated? Or just rigged?

 

Reason I'm asking is because let's say I made a human model, all rigged and animated and all mesh parts were exported. Now I need to make an elfmodel...do I need to rig all that mesh again, or can i just export hte mesh as is(no bones attached), and you can replace the human mesh with the elf mesh without me having to do the rigging everytime?

Share this post


Link to post
Share on other sites
Ok, I'm also assuming that each mesh upon export needs to be rigged and animated? Or just rigged?

 

Reason I'm asking is because let's say I made a human model, all rigged and animated and all mesh parts were exported. Now I need to make an elfmodel...do I need to rig all that mesh again, or can i just export hte mesh as is(no bones attached), and you can replace the human mesh with the elf mesh without me having to do the rigging everytime?

English is not my native languange, by "rigged" I guess you mean attach mesh parts to bones, right?

 

Well, from what I understand, this is how Cal3D works: We load the skeleton and the mesh(es) using Cal3D routines. Every mesh vertex(besides position,normal, and texture coordinates) has a list of bone IDs it's attached to, along with weight factors for each bone. Cal3D needs to know all that for each vertex, so it can animate the model. If you export a mesh without attaching it to bones, how Cal3D will know that?

 

I guess if the human and elf mesh had the exact same number of vertices, stored in the exact same order, with the only difference that the human mesh is attached to bones, while the elf isn't, I could use the human mesh as a prototype to fill the missing bone information in the elf mesh. But I think that's more complicated and restricting than just doing the "bone attaching" for the elf mesh.

 

As for animations, they don't have anything to do with meshes, animations only affect the sceleton. You don't have to export an animation more than once. I can use the same .caf file for an elf and a human(unless you want the human to walk differently from an elf). As long as the mesh is attached to the right bones, it's all fine. Same for skeletons, I can use the same skeleton for all races, the scaling is very easy.

 

That's what I think, I'll check it out tomorrow more seriously and let you know for sure.

Edited by mikeman

Share this post


Link to post
Share on other sites

Thought it might be useful for all to know a bit more about the several files that cal3d uses. Cal3d comes with a conversion tool to convert the binary *.c?f files to equivalent *.x?f files which are text files in an xml format. I did this on some of the files that come with the cally model to get some information about this.

 

The skeleton file consists of a list of bones, each of which has detailed translation and rotation informations (both global and local), as well as an id, name and parent/child relationship informations. More formally this looks like

<skeleton numbones="20">
 <bone id="1" name="bone1" numchilds="2">
   <translation>x y z</translation>
   <rotation>x y z w</rotation>
   <localtranslation>x y z</localtranslation>
   <localrotation>x y z w</localrotation>
   <parentid>-1</parentid>
   <childid>1</childid>
   <childid>2</childid>
   ...
 </bone>
 <bone id=2" ... />
 ...
</skeleton>

A parentid of -1 as above indicates the root bone of the skeleton.

 

 

A cal3d animation consists of a list of tracks, each of which contains a list of keyframes. Each keyframe contains the time when it occurs, relative to the tracks beginning, as well as translation and rotation information. Each track is bound to a particular boneid, which must match the corret bone of the skeleton in use.

The format of the file is like:

<animation duration="0.3333" numtracks="37">
 <track boneid="0" numkeyframes="31">
   <keyframe time="0">
     <translation>x y z</translation>
     <rotation>x y z w</rotation>
   </keyframe>
   <keyframe time="0.05" />
   ...
 </track>
 <track boneid="1" />
 ...
</animation>

The animation contains as many tracks as the skeleton's bone count, that was used to export this animation. That is every bone of a skeleton becomes an animation attached when they are exported. So it's possible to easily exchange animations as long as the bone count of the different skeletons are the same and the numbering of the bones are equal.

 

 

The mesh file has a list of submeshes, each of which contains a list of vertices, followed by a list of faces. Each vertex has an id, position, normal vector and texture coordinates assigned. Each face has a list of 3 vertexid's that form the triangular face. Formal this looks like

<mesh numsubmeshs="1">
 <submesh numvertices="485" numfaces="592" somemoreattribs>
   <vertex id="0" numinfluences="2">
     <pos>x y z</pos>
     <norm>x y z</norm>
     <texcoord>u v</texcoord>
     <influence id="6">0.6</influence>
     <influence id="5">0.4</influence>
   </vertex>
   <vertex id="1" />
   ...
   <face vertexid="0 1 2" />
   <face ... />
   ...
 </submesh>
 ...
</mesh>

The influence fields here comes from the skeleton! They describe how much influence a bone has on the vertex. Each vertex has at least one influence as far as I discovered. That's why I think you need to rig each model separately. I think if you export only the mesh, without having a rigged model you will not have any information about the influence of the bones to the mesh included. We could attach such a mesh to a different skeleton, but I'm not sure whether cal3d will not throw an error if the influence fields are missing, and even if it didn't throw one, we could not be sure what the outcome looks like. It might also be the case, that the cal3d can't even be used to export meshes only.

 

At last there are material files used by cal3d (*.[cx]rf files). They have a very easy setup and contain some color components (diffuse, ambient and specular) and a shinyness factor and optional some maps, most likely texture maps.

<material nummaps="0">
 <ambient>r g b</ambient>
 <diffuse>r g b</diffuse>
 <specular>r g b</specular>
 <shininess>0.5</shininess>
</material>

 

 

So there are several things a character animator must be aware. If you want to share animations to be used by different skeletons, you must ensure, that any skeleton that will use the animation has the same amount of bones and furthermore, those bones have identical names and id's. Else the mapping between the bones of a skeleton and the track of an animation will not work as expected.

 

Sharing meshes is not as easy. You can of course use the human skeleton as a base for the skeleton of other races as well. Keep track of the scaling factor, so we can easily use a single skeleton file for all races and scale it appropriately. But as it looks to me, you need to rig every model, to get the influences of the bones for the meshes vertices.

 

Hope this helps with this topic.

Share this post


Link to post
Share on other sites

Bones for the character models:

 

Basic Skeleton

-head

-neck

-shoulderL

-armL

-forearmL

-handL

*IKhandL

-shoulderR

-armR

-forearmR

-handR

*IKhandR

-back1

-back2

-back3

-pelvis

-hipL

-legL

-calfL

-ankleL

-footL

*IKfootL

-hipR

-legLR

-calfR

-ankleR

-footR

*IKfootR

 

*Not exported

 

Accessories

-sword,axe,mace,hammer Right hand

-sword,axe,mace,hammer Left hand (but only for a limited amount of weapons)

-staff,polearm (if i'm lucky i will not need a bone for this)

-cape1

-cape2

-cape3

-cape4 (can maybe get away with only 3 though)

-skirt1

-skirt2

-skirt3

-skirt4 (not sure on how many here either)

 

(may or may not need 9 bones for these next 3, might fit them all into just 3 bones. They each need 3 bones because of their strings you pull back)

-crossbow

-bow

-slingshot

 

 

 

Is there any limit on how many bones I can have? sure hope not :o

Share this post


Link to post
Share on other sites
Is there any limit on how many bones I can have? sure hope not :D

Not really. For skinning done in CPU by Cal3D, I don't think there's a limit. If I'm going to add support for hardware skinning(much faster), though, there are some restrictions.

 

For instance, I can load about 32 bones in a vertex shader at a time, and reloading bones is expensive, so it must be done as few times as possible. If the model has <=32 bones, I could load the whole skeleton once. But more bones isn't a problem, I can just sort the polygons,"group" those with similar bones and render them in batches.

 

Anyway, as I see in your description, if we consider the body as one mesh(I guess it will be more though) and the weapons as another, you don't specify more than 32 bones per mesh, whice means I may just reload the boneset just before rendering a new mesh.

 

However, one real restriction is that every *vertex* should not be affected by more than 4 bones(I think it's a reasonable amount). More bones means more shader instrunctions, and that is a real limit.

Edited by mikeman

Share this post


Link to post
Share on other sites
Is there any limit on how many bones I can have? sure hope not :D

But the less bones used in a model would use less resources and you could cut down your list a bit.

In humanoids neck and head could be one unit.

Backbone one unit - it doesnt usually bend that much.

If you can have T shaped bones you can get rid of l and r shoulders.

Don't need hips and ankles they are really just joints.

Edited by MoonlitKnight

Share this post


Link to post
Share on other sites
Is there any limit on how many bones I can have? sure hope not :D

But the less bones used in a model would use less resources and you could cut down your list a bit.

In humanoids neck and head could be one unit.

Backbone one unit - it doesnt usually bend that much.

If you can have T shaped bones you can get rid of l and r shoulders.

Don't need hips and ankles they are really just joints.

Well, if we were aiming to create EL for sub 400MHz processors, then this should be a consideration, but right now, I don't think we should sacrifice animation capability (emotions, better animations, etc.) for performance.

Share this post


Link to post
Share on other sites

I don't think the total number of bones(within reasonable limits) is critical for performance anyway. The memory needed to store the skeleton is relatively very small. It may take some more time to calculate the pose for a more detailed skeleton, but again it's not that significant. The most critical part is skinning, deforming the mesh according to the sceleton pose. The important thing here is not how many bones are there in total(since transformations are localized), but how many bones(maximum) a vertex can be attached to. As I said, 4 is a very reasonable number and makes it perfect for HW acceleration in cards that support vertex shaders.

Edited by mikeman

Share this post


Link to post
Share on other sites

Actually I do need those backbones and neckbones if I want the animation to be nice and smooth, which I do. I might be able to get rid of some of the other bones though.

Usually the vertices only have a 2 bones influence, so 4 should be fine.

I am keeping the mesh parts the same as we have them now:

-legs

-head

-torso

-accessories

 

I find this to be the best way if I want to change meshes. One thing that did cross my mind however was having variable body types, which isn't anything on your part..it's just a lot of work for me if I decide to do it :P It just means a LOT more meshes(same vertex count for each mesh though, and same bone weights).

Share this post


Link to post
Share on other sites
Usually the vertices only have a 2 bones influence, so 4 should be fine.

Great. In fact, it would be nice to let me know (once you're done with the models of course) the maximum number of influences, so I can optimize the code. If you can really limit it to 2 influences per vertex, that would be nice.

Edited by mikeman

Share this post


Link to post
Share on other sites
Well, if we were aiming to create EL for sub 400MHz processors, then this should be a consideration, but right now, I don't think we should sacrifice animation capability (emotions, better animations, etc.) for performance.

Oh no, please don't say that you're planning on increasin system requirements again. EL used to run fine on machines around that speed, then after some time, it didn't anymore. I finally bought a new computer before christmas, that is able to run EL fine again, I don't want to buy another one.

Share this post


Link to post
Share on other sites
Well, if we were aiming to create EL for sub 400MHz processors, then this should be a consideration, but right now, I don't think we should sacrifice animation capability (emotions, better animations, etc.) for performance.

Oh no, please don't say that you're planning on increasin system requirements again. EL used to run fine on machines around that speed, then after some time, it didn't anymore. I finally bought a new computer before christmas, that is able to run EL fine again, I don't want to buy another one.

I meant decreasing requirements, actually.

Share this post


Link to post
Share on other sites

Alright then I'll try my best to keep it to 2 influenced vertices. I'm going to start working on a model today(rigged & animated). I'll keep you updated on when it's done.

 

Here is the texture masking image:

http://img.photobucket.com/albums/v59/ffle...neshiftmask.jpg

 

As you can see there's 1 texture with many different color masks..I think it's self explainatory what it does. We need that :P

The texture format we have now however will stay the same-only addition will be this texture masking to the textures where we need it.

Share this post


Link to post
Share on other sites

Yes this is what I want :)

 

Being able to have X amount of textures with Y amount of combinations, just like in the images I showed you :)

It will mainly be used for skin colors...like say I had 4 different torso textures. They would have 4 differetn skin colors and 4 different shirt colors. Those can be mixed and matched.

 

Thanks!

Share this post


Link to post
Share on other sites

The only problem with texture masking is how to store the "custom" skins build by combining different textures. I'm currently examining 3 options:

 

1) For every player, build the skin upon initialization and store it in a cache. With X textures and Y combinations, we could wind up with Y^X textures for a single type of player. This is of course an extreme scenario, but in any case, the memory requirements for this would be significant.

 

2)Generate it on the fly using multitexturing. The graphics card should support at least as much texture stages as the different textures we're using, and multitexturing could slow down the performance.

 

3)Generate it on the fly each frame using the CPU. Before rendering the model, take the different textures, build the new skin in RAM, load it in the VRAM and render the player. This could be slow though, depends how many character are in the screen at the same time.

 

I'm leaning towards a solution combining 1&3. That is, generate the skin on the fly, but not every frame. Once a character gets within a "range" from the player(the range could be the screen boundaries, but maybe larger), generate the skin and store it in the cache. When it gets "out", release the memory. Most of the time, the custom skin needed will be found in the cache, which will be relatively small.

 

If anyone that has worked before with the client and knows better how it handles texture caching has any ideas about this issue, I'd like to hear.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

Ok. About requirements for EL, I suggest to keep the politics about more powerhungry stuff to be

available as an optional setting. And, Roja, these different textures colours are different characters

schemes, in Planeshift you can't choose hair, head, clothes etc, you choose one type of character that

has a different colour scheme. For that elf there are actually thre colour schemes, that forth one - no

idea what is this for. For example I was playing that blonde one. :unsure:

 

Regards.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×