Merci pour toutes vos réponses, je me permet juste d'entrer dans le détail pour un point, celui des anims puisqu'il est au coeur de mes préoccupations. Je suis allé voir l'API d'Irrlicht et j'ai pris deux catégories de meshs animés : MD2 (keyframe) et X (skeleton).
1) Pour le MD2, je vois bien comment l'animer au travers de la fonction getFrameLoop() : on choisit un intervalle de l'animation et le moteur change à chaque MainLoop() de Frame. Enfin, cela me parait logique comme cela, quoique dans l'idéal, je pense qu'une anim ne doit pas fonctionner en fonction du framerate, mais doit être gérée par directement par un gestionnaire de temps de jeu afin que chaque anim aille à la même vitesse sur chaque machine. Cela doit être possible, pouvez vous me dire comment ?
2) Pour le format X, on a plus de fonctions, j'extrapole ici le fonctionnement, mais sans connaitre réellement la réponse, dite moi si je me trompe :

• getDrawableSkeleton() : réccupère le mesh correspondant au squelette du mesh actuel
• getJointCount () : renvoi le nombre de joints
• getJointName () : renvoi le nom d'un joint
• getJointNumber : renvoi le n° du joint
• getMatrixOfJoint () : renvoi la matrice contenant chaque joint

Et la dernière, plus enigmatique pour moi setCurrentAnimation () - Sur quoi s'applique t-elle ? Que lui passe t-on en paramètre et surtout, ça marche comment techniquement ? Mon hypothèse est que ça fonctionne comme un keyframe, mais à base de bones. Irrlicht déplace ainsi les bones suivant l'animation enregistrée dans le modèle, puis effectue les calculs relatifs à la modification du mesh pour "suivre" en quelques sortes le bones associés. C'est ça ? Ca signifierait donc qu'il y a un algorithme permettant d'effectuer ce calcul qui pourrait éventuellement être réutiliser pour autre chose. Je suppose que c'est pas la carte graphique qui est capable de faire ça.

Je trouve également les éléments suivants :

AMT_MS3D Milkshape 3d skeletal animation file.
EAMT_OBJ Maya .obj not animated model.
EAMT_BSP Quake 3 .bsp Map, not animated.
EAMT_3DS 3D Studio .3ds file
EAMT_X Microsoft Direct3D .x-file. Can contain static and skeletal animated skinned meshes. This is the standard and best supported format of the Irrlicht Engine.
EAMT_MY3D My3D Mesh, the file format by Zhuck Dimitry.
EAMT_LMTS Pulsar LMTools (.lmts) file. The Irrlicht loader for this was written by Jonas Petersen
EAMT_CSM Cartography Shop .csm file. The loader for this was created by Saurav Mohapatra.
EAMT_OCT .oct file for Paul Nette's FSRad or from Murphy McCauley's Blender .oct exporter. The oct file format contains 3D geometry and lightmaps and can be loaded directly by Irrlicht
EAMT_B3D Blitz Basic .b3d file, the file format by Mark Sibly.

Donc, suivant les concepteurs d'Irrlicht, X serait le meilleur modèle (static and skeletal animated).
Par avance, merci.

PS: Je suis pas trop d'accord quand Kedu nous dit que la gestion de la cinématique s'apparente à la description que Copland a dit sur l'animation par KeyFrame. Je vois pas le rapport personnellement : pour faire de l'IK, faut des jointures et un squelette, sinon je vois pas comment ça peut fonctionner. Et donc c'est différent du système par Keyframe. Mais c'est comme ça qu'on fait avancer la discussion.

Merci pour toutes vos réponses, je me permet juste d'entrer dans le détail pour un point, celui des anims puisqu'il est au coeur de mes préoccupations. Je suis allé voir l'API d'Irrlicht et j'ai pris deux catégories de meshs animés : MD2 (keyframe) et X (skeleton).
1) Pour le MD2, je vois bien comment l'animer au travers de la fonction getFrameLoop() : on choisit un intervalle de l'animation et le moteur change à chaque MainLoop() de Frame. Enfin, cela me parait logique comme cela, quoique dans l'idéal, je pense qu'une anim ne doit pas fonctionner en fonction du framerate, mais doit être gérée par directement par un gestionnaire de temps de jeu afin que chaque anim aille à la même vitesse sur chaque machine. Cela doit être possible, pouvez vous me dire comment ?
2) Pour le format X, on a plus de fonctions, j'extrapole ici le fonctionnement, mais sans connaitre réellement la réponse, dite moi si je me trompe :

• getDrawableSkeleton() : réccupère le mesh correspondant au squelette du mesh actuel
• getJointCount () : renvoi le nombre de joints
• getJointName () : renvoi le nom d'un joint
• getJointNumber : renvoi le n° du joint
• getMatrixOfJoint () : renvoi la matrice contenant chaque joint

Et la dernière, plus enigmatique pour moi setCurrentAnimation () - Sur quoi s'applique t-elle ? Que lui passe t-on en paramètre et surtout, ça marche comment techniquement ? Mon hypothèse est que ça fonctionne comme un keyframe, mais à base de bones. Irrlicht déplace ainsi les bones suivant l'animation enregistrée dans le modèle, puis effectue les calculs relatifs à la modification du mesh pour "suivre" en quelques sortes le bones associés. C'est ça ? Ca signifierait donc qu'il y a un algorithme permettant d'effectuer ce calcul qui pourrait éventuellement être réutiliser pour autre chose. Je suppose que c'est pas la carte graphique qui est capable de faire ça.

Je trouve également les éléments suivants :

AMT_MS3D Milkshape 3d skeletal animation file.
EAMT_OBJ Maya .obj not animated model.
EAMT_BSP Quake 3 .bsp Map, not animated.
EAMT_3DS 3D Studio .3ds file
EAMT_X Microsoft Direct3D .x-file. Can contain static and skeletal animated skinned meshes. This is the standard and best supported format of the Irrlicht Engine.
EAMT_MY3D My3D Mesh, the file format by Zhuck Dimitry.
EAMT_LMTS Pulsar LMTools (.lmts) file. The Irrlicht loader for this was written by Jonas Petersen
EAMT_CSM Cartography Shop .csm file. The loader for this was created by Saurav Mohapatra.
EAMT_OCT .oct file for Paul Nette's FSRad or from Murphy McCauley's Blender .oct exporter. The oct file format contains 3D geometry and lightmaps and can be loaded directly by Irrlicht
EAMT_B3D Blitz Basic .b3d file, the file format by Mark Sibly.

Donc, suivant les concepteurs d'Irrlicht, X serait le meilleur modèle (static and skeletal animated).
Par avance, merci.

PS: Je suis pas trop d'accord quand Kedu nous dit que la gestion de la cinématique s'apparente à la description que Copland a dit sur l'animation par KeyFrame. Je vois pas le rapport personnellement : pour faire de l'IK, faut des jointures et un squelette, sinon je vois pas comment ça peut fonctionner. Et donc c'est différent du système par Keyframe. Mais c'est comme ça qu'on fait avancer la discussion.