Bon alors je corrige quelques erreurs, et je réponds au passage :
1°) MD2 = keyframes... MD3 aussi donc oublies les bones avec. De plus le MD2 est une antiquité.
Le .X gère les bones par contre (même obligatoires, sauf erreur).
Cependant, si tu fais un personnage animé, on ne peut que recommander d'utiliser une librairie du type Cal3D qui s'inscrit très facilement dans Irrlicht et possède beaucoup de fonctions (même s'il elle reste très très lente).
Aussi :
Keyframes : On stocke chaque frame dans un nouveau modèle (ça c'est l'idée, la réalisation est parfois différente).
Bones : On attribue une partie du corps à un nom dans le squelette et on ne déplace que le squelette.
On en déduit :

• Les bones sont plus faciles à modéliser, plus rapides à modéliser, plus logiques.
• Les bones ne prennent quasiment rien en mémoire, on stocke juste le mouvement de quelques membres et basta.
• Les keyframes sont archi lourds en mémoire... Mais plus rapides... Pour animer par keyframe on n'a besoin que de faire une interpolation bête et méchante entre les deux frames, aucun vrai calcul. Je ne sais pas pourquoi tout le monde dit partout que les keyframes sont plus lents.

Même s'ils sont un peu plus lent, les bones sont les seuls utilisés dans les jeux modernes, à vrai dire, ne pas les utiliser est inimaginable.

2°) Le format .irr est tout con, c'est juste une sérialisation de plein d'attributs sur les nodes... il te suffit d'en ouvrir un pour voir ça très vite

3°) Screugneugneu, je sais pas où tu as entendu ça mais c'est un tissu de conneries... Il faudrait un manchot paranoïaque pour rendre Irrlicht .NET CP bien plus lent qu'Irrlicht. Oui je défends mon produit, et alors ?!

4°) Oui, non peut-être.
Oui car on peut tout faire.
Non car essaye de charger une scène lourde, ça va lagger.
Peut-être car c'est hautement customizable, comme un jour l'a dit un grand homme "je peux te faire une scène de 100 polys qui lag et une de 1 000 000 fluide". Tout dépend de toi, arrêtez de dire qu'OGRE est plus rapide qu'Irrlicht... Moi je sais pas faire de bons trucs avec OGRE, ça rentre pas en compte ?!

7°) Cf post de Copland sur la news sur le site d'Irrlicht... Irrlicht est moins côté mais peut tout aussi bien faire, cf 4°)

8°) Réponse bête et méchante : oui, maintenant OGRE a son petit système de matériaux tordu et il te faudra peut-être réfléchir un peu.
PS Copland : Pas de multi-pass ? C'est que tu as mal cherché, j'en ai eu besoin et il suffit de se le faire soi-même (multiple render target avec un rendu à la file sur des quads... rien de bien excitant).

9°) Sauf erreur -pas très sûr de moi- les animations fonctionnent, pas les .Material... Mais une implémentation plus complète existe sur le forum d'Irrlicht.

10°) Je te renvois au forum d'Irrlicht, un vrai bordel mais un bordel intéressant
Peut-être que celui du wrapper sera aussi bientôt un bon forum, on commence à le voir se réveiller et après tout, c'est là qu'a été postée la première démo de l'eau
Sinon, au niveau des trucs à faire pour mieux connaître... Bah étant donné que je n'étudie pas l'info du tout -mon truc étant plutôt les maths- et que je suis plutôt autodidacte dans le domaine, je ne peux que te dire qu'il faut bidouiller... Les tutoriels d'Irrlicht ne seront jamais suffisants à mon avis, il faut que tu lise des tutoriels (comme ceux de développez.com) sur OpenGL, DirectX, voire OGRE... 99% de ce que tu apprendras là sera réutilisable avec Irrlicht, sans parler des algos récurrents et des choses importantes communes. Et si tu t'intéresse aux shaders, oublie aussi le forum d'Irrlicht (pas celui là, l'officiel, hein ), et pose tes questions dans des endroits comme les forums sur OpenGL ou DirectX... Sauf si c'est vraiment lambda lambda, personne ne pourra te répondre -soyons honnêtes.

PS : DeusXL, DeusXL !!! J'avais 9 ans quand j'ai trouvé ce pseudo, jeu de mot avec mon nom et des centaines d'autres choses (sisi je vous jure) et je le trouve assez nul comme ça sans qu'en plus on l'écorche (admins, changez mon pseudo svp ).

Bon alors je corrige quelques erreurs, et je réponds au passage :
1°) MD2 = keyframes... MD3 aussi donc oublies les bones avec. De plus le MD2 est une antiquité.
Le .X gère les bones par contre (même obligatoires, sauf erreur).
Cependant, si tu fais un personnage animé, on ne peut que recommander d'utiliser une librairie du type Cal3D qui s'inscrit très facilement dans Irrlicht et possède beaucoup de fonctions (même s'il elle reste très très lente).
Aussi :
Keyframes : On stocke chaque frame dans un nouveau modèle (ça c'est l'idée, la réalisation est parfois différente).
Bones : On attribue une partie du corps à un nom dans le squelette et on ne déplace que le squelette.
On en déduit :

• Les bones sont plus faciles à modéliser, plus rapides à modéliser, plus logiques.
• Les bones ne prennent quasiment rien en mémoire, on stocke juste le mouvement de quelques membres et basta.
• Les keyframes sont archi lourds en mémoire... Mais plus rapides... Pour animer par keyframe on n'a besoin que de faire une interpolation bête et méchante entre les deux frames, aucun vrai calcul. Je ne sais pas pourquoi tout le monde dit partout que les keyframes sont plus lents.

Même s'ils sont un peu plus lent, les bones sont les seuls utilisés dans les jeux modernes, à vrai dire, ne pas les utiliser est inimaginable.

2°) Le format .irr est tout con, c'est juste une sérialisation de plein d'attributs sur les nodes... il te suffit d'en ouvrir un pour voir ça très vite

3°) Screugneugneu, je sais pas où tu as entendu ça mais c'est un tissu de conneries... Il faudrait un manchot paranoïaque pour rendre Irrlicht .NET CP bien plus lent qu'Irrlicht. Oui je défends mon produit, et alors ?!

4°) Oui, non peut-être.
Oui car on peut tout faire.
Non car essaye de charger une scène lourde, ça va lagger.
Peut-être car c'est hautement customizable, comme un jour l'a dit un grand homme "je peux te faire une scène de 100 polys qui lag et une de 1 000 000 fluide". Tout dépend de toi, arrêtez de dire qu'OGRE est plus rapide qu'Irrlicht... Moi je sais pas faire de bons trucs avec OGRE, ça rentre pas en compte ?!

7°) Cf post de Copland sur la news sur le site d'Irrlicht... Irrlicht est moins côté mais peut tout aussi bien faire, cf 4°)

8°) Réponse bête et méchante : oui, maintenant OGRE a son petit système de matériaux tordu et il te faudra peut-être réfléchir un peu.
PS Copland : Pas de multi-pass ? C'est que tu as mal cherché, j'en ai eu besoin et il suffit de se le faire soi-même (multiple render target avec un rendu à la file sur des quads... rien de bien excitant).

9°) Sauf erreur -pas très sûr de moi- les animations fonctionnent, pas les .Material... Mais une implémentation plus complète existe sur le forum d'Irrlicht.

10°) Je te renvois au forum d'Irrlicht, un vrai bordel mais un bordel intéressant
Peut-être que celui du wrapper sera aussi bientôt un bon forum, on commence à le voir se réveiller et après tout, c'est là qu'a été postée la première démo de l'eau
Sinon, au niveau des trucs à faire pour mieux connaître... Bah étant donné que je n'étudie pas l'info du tout -mon truc étant plutôt les maths- et que je suis plutôt autodidacte dans le domaine, je ne peux que te dire qu'il faut bidouiller... Les tutoriels d'Irrlicht ne seront jamais suffisants à mon avis, il faut que tu lise des tutoriels (comme ceux de développez.com) sur OpenGL, DirectX, voire OGRE... 99% de ce que tu apprendras là sera réutilisable avec Irrlicht, sans parler des algos récurrents et des choses importantes communes. Et si tu t'intéresse aux shaders, oublie aussi le forum d'Irrlicht (pas celui là, l'officiel, hein ), et pose tes questions dans des endroits comme les forums sur OpenGL ou DirectX... Sauf si c'est vraiment lambda lambda, personne ne pourra te répondre -soyons honnêtes.

PS : DeusXL, DeusXL !!! J'avais 9 ans quand j'ai trouvé ce pseudo, jeu de mot avec mon nom et des centaines d'autres choses (sisi je vous jure) et je le trouve assez nul comme ça sans qu'en plus on l'écorche (admins, changez mon pseudo svp ).