Bonjour,

Je rôde depuis quelques semaines autour de ce moteur que je découvre petit à petit. Je réalise plusieurs tests, mais j'ai beaucoup de mal à trouver des réponses à mes questions. Veuillez excuser la simplicité de ces dernières, mais je vous promet, j'ai beaucoup cherché et j'ai besoin de vos lumières:

1) Dans le cycle de création d'un petit jeu 3D utilisant des animations via Bones, puis-je utiliser les outils suivants :
Maya et Irrlicht
Si oui, comment, au travers d'une exportation MD2 ?
Quel avantage à passer par des bones plutôt que des Keyframes ? Est-ce qu'il faut utiliser d'autres outils comme Cal3D ? Connaissez-vous un bon tutoriel qui commence par une modélisation sous Maya et qui se termine par un affichage Irrlicht ?
Quelqu'un a-til déjà utilisé le D3DX animation controller ? C'est quoi ? C'est mieux que passer par MD2 ?

2) Les scènes .irr

J'avais commencé par ma faire un petit éditeur de scène XML quand je suis tombé sur les fonctions permettant de charger les .irr, mais je n'ai rien,  ou presque rien, trouvé sur le format du fichier. Y-a t-il une source quelque part ? (pas de l'API, mais du format XML des fichiers irr donnant accès à toutes les possibilités de l'API).
IrrEdit n'est pas OpenSource, c'est ça ? On peut utiliser d'autres outils pour modéliser des mondes et les importer sous Maya ? Je pense à un truc du genre d'oFusion pour Ogre.

3) J'ai entendu dire qu'Irrlicht CP était beaucoup plus lent qu'Irrlicht, c'est vrai ?

4) Le sceneManager d'Irrlicht est-il capable de charger de grosses scènes comme sait le faire le système octree d'Ogre ? Est-ce facile de customiser ce dernier comme j'ai pu le voir dans une démo de SIO2 (le gars semblait utiliser des shaders HLSL pour l'animation)

5) Quels sont les outils complémentaires qu'on peut utiliser pour modéliser un jeu ?
iJe pense par exemple à ZBrush pour donner du relief à certaines textures...
Motion Builder, je connais pas, c'est utile pour faire des animations ? On peut réccupérer avec Irrlicht ?

6) j'ai beaucoup aimé le "Making of le monde des ronrons", en connaissez-vous d'autres qui entrent autant dans la technique ?

7) Sous Ogre, il y a de gros jeux comme Ankh, connaissez-vous d'aussi gros projets pour Irrlicht ?

8) Les shaders semblent être réalisés dans un lanage à part, comme le HLSL(Microsoft), le CG(nvidia), et j'en passe. ça signifie que si on en trouve sur le net réalisés pour Ogre par exemple, ils fonctionneront avec Irrlicht ?

9) L'utilisation de fichiers .MESH fonctionne, mais qu'en est-il des skeletons et des animations ? Peut-on charger des fichier .Material et si oui comment (j'ai pas trouvé la fonction) ?

10) De façon générale, je me sent assez perdu en dehors des tutoriaux d'Irrlicht. Comment faire pour apprendre d'avantage car les tutos sont très limités... Je n'ai pas trouvé beaucoup de sources. Pouvez-vous me guider un peu ?

Par avance, merci.
Greg
www.benicourt.com

Hello,
Alors je vais essayer de répondre aux questions pour lesquelles je pourrai t'apporter quelque chose.

1°_Alors comme format 3D, j'ai remarqué que le format .B3D était assez rapide sous irrlicht.
Je ne sais pas si il existe un plugin d'export pour Maya, en tout cas évite le .X il est assez lent sur se moteur.Sinon lavantage d'une animation par Bones c'est que chaque vertexs sont regroupés sur un Bones, donc l'animation peut être calculé que sur les membres en mouvements.Une animation par Keyframe, tout les vertexs du modèles seront recalculés à chaque mouvement, ce qui est au final plus lourd, demande plus de calcul et donc plus lent.

2°_Désolé je ne me suis pas encore servi des scene en irr.Perso je modélise mes scenes sous max et exporte au format B3D.

3°_Irrlicht CP plus lent ? non je pense que c'est une idée préconçu car l'ayant moi même essayé, je n'ai pas remarqué de lenteur particulière par rapport à Irrlicht en C++.

4°_Oui irrlicht est cappable de charger de grosse scene, à condition que tes modèles uniques ne dépassent pas les 65535 vertexs par Objet (par Buffer donc).
Pour ce qui ets d'optimiser, je comprends pas bien ta question, mais tu peux programmer tes propres SceneNode et donc customiser directement la phase de rendu, donc créer tes propres algo d'occlusion et companie.

5°_Des outils complémentaires, tout dépends du style de jeux que tu veux faire, si tu veux faire du Terrain3D y'a L3DT qui est pas mal, si tu veux du décors intérieur, tu peux utiliser des éditeurs de maps de Quake Q3Radiant...Sinon oui je pense que ZBrush peut s'avérer sympa pour les textures, à condition de savoir l'utiliser correctement.
Motion Builder je ne connais pas.

6°_Concernant le Making Of de Christophe Kohler, je n'en connais pas à l'heure actuelle d'aussi bon, aussi complet, et aussi détaillé.C'est vraiment le seul document propre que j'ai trouvé dans se domaine.

7°_Je ne connais pas de gros projets aboutis sous Irrlicht, il y a eu récemment un jeux de course futuriste qui a fait son apparition, preuve est qu'irrlicht atteint une maturité qu'il n'avait probablement pas il y a encore 6 mois .

8°_Concernant les shaders, je n'ai que très peu de connaissance dans le langage.
La seule chose que je pourrais te dire, c'est qu'à ma connaissance Irrlicht ne gère pas encore le multipass pour le rendu des shaders(sauf erreur de ma part).Donc non tout les shaders ne seront pas forcément adaptable sur irrlicht.

9°_Heu tu me poses une autre colle...

10°_C'est assez surprenant de te voir dire ça, car tu as un CV assez impressionnant pour un pti gar comme moi .Mais tu dois sans doute parler de programmation 3D et donc là ça devient plus compréhensible.Pour ma part chaque fois que j'ai besoin d'infos sur la prog 3D je pense direct à http://www.gamasutra.com .Ensuite, je ne pourrai que te conseiller de te trouver un livre sur la programmation de jeux vidéos.Pour ma part étant faché avec l'anglais (un livre étant vraiment trop long pour moi en anglais), j'ai choisi la Programmation 3D Directx9 par laurent Testud que je trouve vraiment superbe et que je conseille à beaucoup de monde.

Voilà j'espère t'avoir aidé un peu .
@+

Petites complétions : (ca se dit? )

3) Tu parles de la version .NET ou C++? Ca parait un petit peu embrouillé. Il y a irrlicht officiel (donc C++), le wrapper officiel .NET, et le wrapper .NET de DeusXL (irrlicht .NET CP) non officiel. Entre les 2 versions .NET il y a peu de différences du point de vue perfs je pense (.NET CP doit être plus rapide pour quelques trucs car plus abouti) et il y a pas photo du point de vue de l'utilisabilité, le non officiel est plus avantageux.

4) Tu peux charger un modèle avec l'octree donc pas de problème

6) Je connaissais pas!!! excellent un peu de lecture

My two cents...

Merci pour toutes ces précisions Copland. Je me suis intéressé de près à la 3D il y une quinzaine d'années, mais à l'époque on était déjà content de pouvoir texturer ses faces. J'ai bossé sur 2 jeux vidéos à l'époque. Mais les choses ont tellemment changé - j'aimerais revenir dans le domaine, à titre personnel, pas forcément professionnel.

J'ai testé Crystal Space et Ogre : je me suis un peu cassé les dents - j'ai trouvé Crystal Space trop "fermé", réservé à un public qui suit de très près le developpement du moteur, comme ceux qui ont réalisé Planeshift. Le CEL est une très bonne idée, mais si peu documenté à mon goût. J'ai beaucoup aimé Ogre, mais je me sentais perdu au milieu de toutes les possibilités. Et puis Irrlicht CP .NET est venu croiser mon chemin, et j'ai été séduit. J'aimerais réaliser un petit jeu depuis plusieurs années, et je collecte donc toute sorte d'infos pour m'aider dans cette tâche. Il tendrait vers le jeu Ankh, mais avec une toute autre histoire, et plus de possibilités. Je ne compte pas réaliser seul ce jeu, peut-être le financer, je ne sais pas encore. Je veux déjà être certain de comprendre tous les aspects et toutes les phases du développement d'un jeu en 3D. Le Making of du "monde des ronrons" nous présente une aventure fantastique, mais il y a encore de nombreuses zones sombres. Quand je commence à rentrer dans le détail, la difficulté semble exponentielle.

Par exemple, comment réaliser de bonnes animations sans mocap ? Peut-on réaliser un système assez simple avec quelques caméras seulement, y-a t-il d'autres alternatives ? Certains utilisent des shaders à priori pour remplacer l'éclairage d'Irrlicht, tout cela me dépasse pour l'instant. Je sais que je suis trop pressé, je cours après la poule sans avoir trouvé l'oeuf, mais j'aimerais avoir une vue d'ensemble de tout cela afin d'entrer par la suite dans le détail comme  j'ai toujours procédé, mais là j'arrive pas à trouver ce genre d'infos : tout le monde semble rentrer dans le détail, mais ne maitriser qu'un tout petit aspect du procédé général...

En tous cas, merci à tous ceux qui livrent régulièrement leurs résultats comme Copland, c'est grâce à eux qu'on commence à avoir confiance dans un moteur comme Irrlicht.

Merci par avance aux autres qui pourraient m'éclairer sur les autres points, ou apporter des précisions supplémentaires.

Bonjour tout le monde

Tu ne peux pas réaliser tes mesh,les texturer et les passer dans ton jeu...

Essayes de trouver un type qui te bidouille dans ce domaine...

Tu n'auras pas assez de temps...ou il faut travailler 24/24...

Donc utilises ceux déjà construits:.


Dans le moteur de Irrlicht tu as différente actions que tu peux appliquer sur un mesh et non un .mesh.

Par exemple sur le mdl .md2 tu as des plages d'action:attaque, repos ,salut...et tu peux aussi determiner à l'image pres sa stature....par exemple un salut: entre 105 et 120(c'est un exemple)...ou encore sa position dans la scene...ou sa rotation...son agrandissement...

Tu peux aussi le faire déplacer tres facilement...ou tirer...des boules de feu...ou en recevoir...

Pour du skeleton il n'est pas utilisé car il sert uniquement dans le cadre de l'élaboration de ton mesh...avec ton logiciel de ton choix...

Ainsi que pour les textures que tu vas appliquer dessus...

Le SceneManager de Irrlicht n'éxiste pas à proprement parler ...tu as un device...et ensuite tu construits ta scene en reliant par la methode connue des noeuds aux objets ou aux personnages...

Le meilleur exemple et celui intitulé Demo...tu as un ensembles de routines tres bien faites...

Une excellent base pour construire une application...
Il te faut décortiquer chaque routine avec ses paramétres et ensuite ça roule tout seul....

Pour Maya je pense que cette usine à gaz est réservé aux pros car d'un cout tres élevé...
Simplement Wings 3d et Blender feront l'affaire et largement...

Avec deux personnages ,une boite qui tourne ,un feu,une SkyBox je suis déjà a 240 fps..il me reste pas grand chose pour mes autres personnages...mais ils évoluent dans un décor .x qui effectivement ralentit pas mal le FPS...

Les personnages et la boite,je les ai emprunté à Doom...et je compile avec Emacs (pour l'instant)...

Un conseil:tu ecrits une ligne de code et tu compiles...et ainsi de suite...c'est la seule solution pour obtenir quelque chose de correcte...

Une personne dessine les personnages et les contruit...l'autre programme la trame du jeu...

Mais pour réaliser une application importante il ne faut pas passer par Irrlicht tres fgourmand en fps..

Tu la contruit avec du c++ plus une bonne bibliotheque...mais bon il faut se taper une tonne de doc ..

Il te reste aussi l'asm ...pas mal non plus...mais bon...pour faire un pong il te faut dix pages de code...


Sur Linux+ un type a fait un topo sur un jeu en Java plus une bibliotheque 3d...faudrait voir si ça tourne bien...car le pb principal c'est la FPS et pas autre chose...

Tu te construits un pong et tu vois ce que ça donne...

Le WebMaster de ce site va organiser un mini concours sur Irrlicht...
('c'est pas une bonne idée)

Cordialement

Merci aitina pour ta réponse. J'espère cependant que tu as tort concernant Irrlicht. On disait pareil d'Ogre au début et il tient vraiment la route au final.
Cependant, je ne peux pas utiliser ta méthode du "je teste ligne à ligne". J'ai besoin de tout modéliser avant, d'où ce besoin de comprendre tous les aspects de  la modélisation d'un monde en 3D et de la création d'animations, avec les technologies actuelles temps réel. En fait, j'ai pas trop envie de m'éclater à tester Irrlicht, j'aimerais savoir si je peux l'utiliser dans le cadre d'un vrai projet. Je ne compte pas recréer un moteur de rendu car ce serait réinventer la roue, et je n'ai pas envie d'y passer 3 ans pour avoir un moteur ringard et dépassé. Pas question non plus de réutiliser des personnages existants, car le développement d'un jeu, c'est la création d'un univers ex-nihilo : j'ai déjà le scénario, le game design, etc. Il me faut maintenant arriver à passer d'un format papier à une modélisation 3D, et toutes les autres étapes nécessaires à son exploitation au sein du jeu.
Personnellement, j'ai bossé un peu avec Blender et je ne doute pas qu'on puisse faire des choses très sympas. D'ailleurs pour Crystal Space, c'est génial car on peut importer les scènes complètes et même programmer un jeu sans une ligne de code directement sous Blender. Mais je trouve que Maya, loin de la complexité de 3DSMax, est vraiment bien adapté au monde du jeu vidéo (de nombreux outils permettent de modéliser poils, cheveux, etc...).
Sous Ogre, on utilise le skeleton pour l'animation, en dehors de modeleur, directement à l'exécution et si je m'en refère e tsi j'ai bien compris Copland, c'est possible sous Irrlicht aussi (voir sa réponse).
Sinon, de façon générale, oui bien entendu, je ne compte pas faire tout moi même - je n'en aurais pas les compétences, ni le temps, et probablement pas l'envie. Mais il me faut tout comprendre cependant. J'ai essayé toutes les démos et codes sources qui me sont tombés sous la main, mais j'ai l'impression que dès qu'on veut faire quelque chose d'un peu plus poussé, c'est Terra Icognita, non ? Y-a des gens qui touchent à priori d'après ce que j'ai pu voir (Copland, DeusEx, SIO2, ...) mais je me demande comment ils font - z'ont vraiment du mettre le nez dans le cambouis, ou bien je suis passé à coté de quelque chose...

Je crois que sur ta question sur les animations par skeleton j'ai pas bien compris.
Tu parles d'un systeme de Skeleton sous Ogre individuel à ton modeleur? Ou du skeleton que tu poses et anime sous Maya ?
Je sais que Ogre à une classe de Skeleton, mais je n'en sais pas plus à se niveau là.
Si tu peux détailler exactement ce que tu espères faire avec les anims, ça aiderai à mieux cibler le problème et son éventuelle solution.

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 ).

Dernière modification par DeusXL (11-11-2013 10:38:46)

> "lavantage d'une animation par Bones c'est que chaque vertexs sont regroupés sur un Bones, donc l'animation peut être calculé que sur les membres en mouvements"
C'est pas ça une animation via skeleton ? C'est pas le principe de la cinématique inverse ?
C'est plus rapide et moins gourmand en mémoire ?

Quelques questions supplémentaires :

1) Ce que je souhaite savoir, c'est si Irrlicht gère l'animation via Skeleton, et si oui, est-ce limité à un certain type de Mesh (B3D, X, ?), ou bien tout passe t-il par une interpolation entre le Keyframes. La technique de l'interpolation de keyframes, je la connais bien. Celle des bones sous 3DS Max aussi, mais par le moteur, je ne vois pas trop comment ça fonctionne en vérité, j'imagine qu'on définit des pivots et des jointures, ou plutôt qu'on les réccupère des modèles et qu'on anime en fonction, non ? Ca doit être plus dur, non ?

2) En outre, y-a t-il un lien possible entre le modèle animé via Skeleton et une éventuelle utilisation d'un moteur comme ODE ? Plus précisément, est-on obligé de redéfinir chaque jointure, chaque pivot, le poids, le type de friction, etc... ou bien peut-on importer cela d'un logiciel comme 3DS MAX ou Maya ?

3) Encore une autre question liée au LOD. Existe t-il un LOD sur les mesh, un LOD sur les textures, un système d'imposteur (remplacement de l'objet par un billboard) ? Ou bien doit-on tout programmer sous Irrlicht ? Y-a t'il des fonctions pour morpher un objet en un autre ?

4) Et au niveau des effets spéciaux, dispose t-on de Lens Flare ou de brouillard volumétrique ? Je n'ai pas trop compris non plus en quoi le système d'ombre n'est pas très bon sous Irrlicht, c'est parce qu'il n'utilise pas les shaders ? Facile à implémenter ? Quid du HDR ?

5) Quelqu'un a-t-il déjà fait un système de streaming permettant de charger en cours de déplacement les objets utiles du monde, avec heuristique ?

6) Si je dois prévoir l'impact d'un laser, quelle fonction utiliser pour connaitre le point d'impact (le système de collision ou dois-je passer par un moteur physique) ? ça fonctionne aussi avec une trajectoire courbe ? Y-a t-il des fonctions pour manipuler les b-splines ?

7) Concernant la gestion de  l'eau

8) Y-a t-il des exemples de source de path finding avec Irrlicht ?

9) Pour le scripting, je suis tombé sur IrrLua, est-ce au point à votre connaissance ? Y-a pas la même chose version Python ?

Par avance, merci.
Greg

Désolé DeusXL, j'ai trop aimé le livre Deus Ex Machine (le dieu sorti de la machine), alors j'ai confondu, mais c'est bien toi la bête dont je parlais ;o)
Et merci pour ta réponse.

Alors pour les différences Skeletal/Bones, il est possible que j'ai confondu les deux -entre ces trucs appelés par les modeleurs... je m'emmêle... J'arrive pas à faire vraiment la différence, moi je parle du type d'animation qu'utilisent les librairies comme Cal3D.

3) Il n'existe rien de tout ça -sauf un LOD pitoyable sur la pitoyable TerrainSceneNode-, on doit tout programmer... Voilà pourquoi je dis qu'il faut avoir des connaissances en API type DirectX et OpenGL... Maintenant j'aurais tendance à te dire que dans un jeu de niveau professionnel, on a toujours besoin de le faire soi-même, le fait que ça soit présent dans la librairie -comme ça l'est peut-être déjà dans OGRE- n'est pratique qu'au début pour ne pas se soucier.

4) Il y a quelques effets qui datent -sauf à la limite le Parallax mapping qui est atroce sous OpenGL mais passe sous DirectX, là encore il te faudra apprendre toi-même les shaders pour faire mieux. Les ombres dans Irrlicht sont assez lentes mais très précises et assez jolies -avec cependant quelques bugs. Facile à implémenter ? Sais pas, j'aime pas les ombres moi.
HDR ? pas implémenté par défaut, là encore ça dépend du rendu que tu veux... Dans 99% des cas les gens ne veulent qu'un simple effet de Bloom quand ils demandent du HDR. Faire du HDR est possible en faisant un multi-pass artificiel, c'est pas très dur honnêtement.

5) Plus ou moins c'est ce sur quoi je travaille en ce moment.

6) Irrlicht possède quelques fonctions sympatiques de physiques... Des collisions assez bien gérées -impacts Lignes/boîtes, Lignes/liste de triangles...- et pas trop lentes... Bien sûr pour un niveau professionel il te faudra utiliser des librairies de physique plus abouties.

7) La Water scene Node donnée avec est pitoyable, mais heureusement de courageux développeurs se sont penché dessus et en ont sorti une toute nouvelle génération en GLSL/HLSLS Cf forum du wrapper ou forum officiel

8) cf à la fin

9) IrrLua est un binding pour Lua d'Irrlicht, je suis pas sûr que ce soit ce que tu cherches exactement... Si c'est le cas alors oui ça existe pour Python, j'ai juste oublié le nom

PS, note importante :
Irrlicht est un moteur de RENDU ! Pas un moteur de JEU !
OGRE aussi, mais OGRE est plus travaillé par sa communauté donc donne l'impression -fausse- de mieux s'intégrer à d'autres librairies.
Ce que ça veut dire est qu'Irrlicht ne t'aidera qu'à afficher tes trucs et à faire deux trois tests de collision... Les scene nodes avec lesquelles il est livré -type WaterSceneNode officielle, TerrainSceneNode officielle- sont de très mauvaise qualité. En aucun cas, Irrlicht ou OGRE n'intègrent des algos de pathfindings, de network ou autre... Ca c'est des moteurs de jeu qui le font.

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).

Si tu dois le faire toi même c'est qu'il n'est pas implémenté en natif dans le moteur, c'est surtout en se sens là que je répondais.Et toujours dans ton sens, tout est réalisable à condition de le programmer soit même là dessus je suis bien d'accord à condition d'en prendre conscience dès le départ et de vouloir mettre les doigts dedans, certaines personnes attendent d'un moteur qu'il fasse ce qu'elle demande sans trop de complexité et sans avoir 50 bidouilles à programmer...

Je n'ai pas regardé, mais si irrlicht supporte les anims du format B3D, se format là est nettement mieux pour les animations par rapport au .X qui est lent à n'en plus finir.

[EDIT] j'ai un vieux modèle B3D sur un cd qui doit trainer, je le recherche et le test pour vous dire se qu'il en est à se niveau là.

Oui, je suis conscient du fait qu'il s'agit d'un moteur de rendu, contrairement à Crystal Space, qui se veut être plus un moteur de jeu. D'ailleurs, je ne cherche pas trop à comparer Ogre et Irrlicht, je m'appuie juste sur ce que j'ai vu sous Ogre pour mieux situer les temps de développements éventuels pour implémenter telle ou telle chose. Si une fonctionnalité ne dispose d'aucun exemple et qu'elle est peu documentée, je ne m'aventurerais pas trop dans cette direction. J'irai un peu dans le sens de Copland au niveau des fonctions implémentées, pas que je ne veuille pas à terme mettre le nez dans le moteur, mais surtout afin de pouvoir évaluer, ne serait-ce qu'en surface, ce qui reste à implémenter et la difficulté liée à cette implémentation.

En tous cas, merci pour vos réponses, je suis un peu plus éclairé sur ces questions - reste que je sent que je vais avoir des difficultés à animer mon premier personnage... Cal3D, oui... j'avais vu ça pour Ogre, pas trop utilisé, juste vu des exemple, bidouillé un peu et recompilé le tout. Les fonctions étaient toute prêtes... Pour irrlicht, j'ai vu un tutoriel pour la version 0.6 d'irrlicht, j'espère que c'est encore valable car quand on débute, rien de plus démotivant que passer des heures à vouloir faire marcher un exemple sans l'avoir vu au moins une fois tourner. Le fait que ce soit très lent (d'après vos posts) n'est pas très encourageant non plus. Reste la suggestion de  Copland, avec le B3D (c'est du Blitzz ?), mais je connais pas - à voir, je me demande si c'est pas du keyframe cependant.

Difficile de faire un travail de conception au milieu de tout cela. J'ai l'impression que je vais devoir valider quasiment toutes les phases techniques, ce qui revient à rédiger au moins 50% du code, sans les optimisations. J'aurais aimé pouvoir dresser un plan précis de ce qui doit être fait, mais je ne sais même pas quel type d'objet utiliser... Quant à ODE, j'ai l'impression que je vais devoir soit me faire un petit éditeur pour gérer tout cela, soit tout décrire dans un fichier XML à la mimine. Il me semblait qu'oFusion pouvait gérer cela, mais y-a pas d'import possible sous Irrlicht, je pense.

Quelqu'un a t-il des informations sur le partage des propriétés physiques entre les modeleurs <---> Le format d'objet <----> Irrlicht/ODE ? J'ai vu que Copland a bossé sur un circuit (joli travail), mais je crois qu'il a tout codé à la main concernant la liaison roue-voiture, poids, etc. ?

IrrLua, c'était pour me faire un mode console avec Interprétation du code. Pouvoir faire une boucle et afficher par exemple 20 fois le même objet, mais sans compilation derrière...

J'ai vu qu'il y avait quelques moteurs de jeu qui fonctionnent avec Irrlicht (comme RabCat), mais rien d'Open Source à priori... c'est dommage.

Dernière modification par benicourt (12-02-2007 17:49:06)

Pour la physique, tout dépend ce que tu veux.Si c'est du cube ou de la sphere ça reste simple.Si tu veux des collisions sur des formes géométriques complexe, il te faudra programmer une partie pour gérer les trimesh.Attention, Ode gère très mal les collisions TriMesh VS TriMesh, il veut mieux utiliser des formes Standard VS TriMesh.
Sinon il y a aussi Newton qui est un bon compromis, un petit peu plus lent que Ode mais je pense qu'il est plus stable, le mieux et de tester plusieurs exemples creé avec et de te faire ta propre opinion.Pour moi c'est Ode, mais pour d'autre ça sera Newton, chacun sa préférence .

Sinon pour l'animation j'ai vérifié, le B3D semble fonctionner à merveille.Il s'agit en effet du format natif du moteur Blitz3D,qui a l'avantage de supporter le lightmap pour les calculs de lumières statique.Quand à la façon dont irrlicht gère se format là, je sais pas mais sous blitz3D les bones étaient gérées ainsi que les bipeds de 3dsmax, espérons que sous irrlicht c'est la même chose.

D'après mes dernières recherches concernant les animations, il semble que le gros avantage de passer par un système de Bones/skeleton est qu'on peut joueur plusieurs animations en même temps (jambes, bras tout en tournant la tête par exemple), ce qui semble impossible via keyframes (sauf à séparer chaque élément en différents objets animés), il faudrait prévoir toutes les combinaisons.

Il semble aussi que ce système n'existe pas en natif sous Irrlicht, mais il est possible d'utiliser Cal3D - cependant le rendement serait catastrophique.

Les autres formats permettant l'animation (.X .MS3D ou .B3D) ne seraient que des systèmes via keyframes. Ca ne signifie pas que d'origine ces format soient ainsi, car ils fonctionnent bien avec des bones sous le modeleur, mais une fois sous Irrlicht, ils fonctionnent en Keyframes avec interpolation.

PS: une percée dans l'animation ? http://irrlicht.sourceforge.net/phpBB2/ … t=skeleton

Dernière modification par benicourt (12-02-2007 19:02:20)

@Copland : Je sais que ce mode n'existe pas par défaut dans Irrlicht, je précisais juste que c'était facile et ne nécessitait aucune modification du core (c'est plus propre si on en fait, cependant), pour éviter toute ambiguïté lorsque tu dis que ce n'est pas adaptable :p

Sinon oui, j'avais oublié l'avantage des animations multiples. Il me semblait cependant avoir entendu que le .X était géré en bones sous Irrlicht mais ça m'a toujours semblé étrange.

Et enfin : Oui, SIO2 fait un bon boulot, on va obtenir des trucs sympas

@benicourt : Tout d'abord j'apprécie ta démarche et te souhaite la bienvenue sur ce forum.

En complément de certains points que tu as soulevé : la lecture du making of du "monde des Ronrons" m'a fait comprendre que la conception d'un jeu passait bein souvent par la conception des toolkits voire de SDK. (cf: son outil de conversion de modele 3D ainsi que son outil de conception des animations faciales)

Concernant IrrLua, j'ai cru comprendre que tu utilisais C# ; après avoir testé récemment les fonctionnalités de compilation à la volée de C# je me suis rendu compte du potentiel de cette méthode... A tester si ton choix d'IrrLua n'est pas encore fixé.

J'ai également apprécié l'intervention de DeusXL qui indiquait qu'Irrlicht était avant tout un moteur de rendu et ça ne comporte selon moi que des avantages. Je pense qu'il serait intéressant d'ailleurs de créer prochainement un post qui pourrait s'intitulerait "Comment vous intégreriez votre moteur de jeu à Irrlicht ?" car je suis sûr que nous avons chacun de notre côté des idées intéressantes.

Merci Kedu,

kedu :

Concernant IrrLua, j'ai cru comprendre que tu utilisais C# ; après avoir testé récemment les fonctionnalités de compilation à la volée de C# je me suis rendu compte du potentiel de cette méthode... A tester si ton choix d'IrrLua n'est pas encore fixé.

J'avoue être passé à coté de cela - cela signifie t-il qu'on peut mettre un code source en mémoire et l'éxécuter sans passer par le compilateur ?
Sinon, le script garde son utilité car on peut instancer des variables et les utiliser au travers du script - mais si ça tombe on fait pareil avec la  compilation à la volée. Tu peux nous en dire un peu plus ?

Est-ce que comme la fonction Eval de PHP, les variables utilisées restent accessibles dans le programme principal et vice et versa ?

Tiens au fait, les features d'Irrlicht annoncent :

Irrlicht Site :

Skeletal animation: A skin is manipulated by animated joints. The Irrlicht Engine will do this when loading .ms3d or .x files. It is easily possible to attach objects to parts of the animated model. It is possible e.g. to attach a weapon to the hand of a model, which will be moved as the hand moves, with only one line of code.

C'est peut-être là la différence entre skeletal animation qui signifirait "gestion de la cinématique inverse", et les bones qui sous-entende un morphing du mesh pour suivre la déformation engendrée par le bones (c'est mal dit, mais j'espère que c'est explicite). Qu'en pensez-vous ?

Donc normalement ça devrait marcjer avec les fichiers .x, mais parait que c'est lent ! Plus lent que Cal3D ou bien différent comme supposé ci-dessus ? et concernant les Ms3D.

On ne parle pas de Collada, mais normalement ça supporte les animations ce format. Pas intégré la gestion des anims collada sous Irrlicht semblerait-il? On dirait que c'est encore une bêta d'ailleurs le chargement collada ? Avec son système simple de jointure, cela semble bien répondre à mon besoin de définition pour ODE, qu'en pensez-vous ? Bon, imaginons qu'il faille redévelopper le chargement de fichiers COLLADA, est-ce qu'Irrlicht permet
1) De lier des objets entre eux par des jointures de telle sorte que bouger un entraine le mouvement de l'autre (mais pas seulement en translation, rotation aussi suivant le type de jointure, exemple on avance l'avant bras, Irrlicht calcule le déplacement du bras ?)
2) D'effectuer l'interpolation de forme entre un keyframe et un autre ? Je sais qu'il le fait au travers du chargement de l'objet, mais je veux dire dynamiquement, par prog, on lui donne deux objets et on demande les frames intermédiaires, c'est possible ?

Dernière modification par benicourt (12-02-2007 21:06:12)

Pour la compilation du code source à la volée, c'est le cas avec n'importe quel langage .NET... Tu peux tout compiler, à la volée, et l'exécuter parfaitement inscrit dans ton code compilé une seule fois...
Gràce à cela, je ne connais aucun programme C#/VB qui utilise des langages de scriptings comme LUA, le fait de pouvoir compiler et exécuter à la volée sans rien faire (un peu comme le PHP eval()) et en étant intégré dans le code pré-compilé rend de telles méthodes assez inutiles.

En me mouillant un peu, voilà ce que je pense point par point... ça fera toujours avancer le sujet.

benicourt :

C'est peut-être là la différence entre skeletal animation qui signifirait "gestion de la cinématique inverse", et les bones qui sous-entende un morphing du mesh pour suivre la déformation engendrée par le bones (c'est mal dit, mais j'espère que c'est explicite). Qu'en pensez-vous ?

Non je pense que ce n'est pas la bonne explication du texte que tu as cité. Je pense que dès que l'on parle de squelette ou de skeletal animation (oh yeahh) on fait directement référence aux bones qui le compose. La gestion de la cinématique s'apparente à la description que Copland t'a donnée sur l'animation par KeyFrame.

benicourt :

Donc normalement ça devrait marcjer avec les fichiers .x, mais parait que c'est lent ! Plus lent que Cal3D ou bien différent comme supposé ci-dessus ? et concernant les Ms3D.

Je ne vois pas pourquoi cela serait si lent voire plus lent que Cal3D ; un peu plus lent mais moins gourmant en mémoire que l'animation par keyframes. (moins de stockage de données nécessaires)

benicourt :

l...COLADA...

Aucune idée

benicourt :

lier des objets entre eux par des jointures de telle sorte que bouger un entraine le mouvement de l'autre (mais pas seulement en translation, rotation aussi suivant le type de jointure, exemple on avance l'avant bras, Irrlicht calcule le déplacement du bras ?)

Je vais peut être te décevoir mais en reprenant l'explication de l'extrait de texte en anglais cité plus haut, tout ce qu'Irrlicht pourra faire c'est comprendre que tu attaches par exemple une arme au bones de la main droite... L'animation même du squelette et de ses bones se fait normalement dans un logiciel d'animation 3D. Irrlicht ne fera que lire les différentes animations pré-enregistrées en quelques sorte.

benicourt :

D'effectuer l'interpolation de forme entre un keyframe et un autre ? Je sais qu'il le fait au travers du chargement de l'objet, mais je veux dire dynamiquement, par prog, on lui donne deux objets et on demande les frames intermédiaires, c'est possible ?

Je ne sais pas trop si je saisis bien la question. En tout cas tu sembles vouloir animer tes modèles par le code, alors que je pense que la méthode la plus courante est de les animer dans un logiciel d'animation puis de les lire dans le moteur graphique.

=> Voilà quelques éléments de réponses ; que la communauté n'hésite pas à corriger mes abérations

Je tiens juste à dire que la différence entre Skeletal et Keyframes au niveau de la vitesse réside plus dans ce que tu fais avec qu'autre chose... Cal3D est incroyablement lente à mon goût par exemple, alors que d'autres l'utilisent très bien...
Maintenant je le redis : si tu veux animer un personnage dans un jeu, ne te demande pas Keyframes/Skeletal, c'est déjà vu... Demande toi plutôt quel système de skeletal tu veux.

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.

Dernière modification par benicourt (13-02-2007 10:04:33)

Mais je vois pas pourquoi tu te poses la question du squelette, perso quand je veux un modèle, je le modélise, je l'anime avec un squelette sous max, et je l'utilise sous Irrlicht.
Ensuite si tu veux pouvoir récupérer la position d'un bones pour placer un objet dans sa main je pense qu'irrlicht le fait bien sur les X et B3D.
Maintenant le mieux serait que tu décrives exactement ce que tu comptes faire avec tes persos, et ont pourra t'apporter une solution plus claire et directe.
Pour ce qui ets du B3D, il gère à parament le Skeleton sous irrlicht car dans ses méthodes ont retrouve :
GetJointCount()
GetJointName()
GetJointNumber()
GetLocalMatrixOfJoint()
GetMatrixOfJoint()
GetMatrixOfJointUnanimated()
RecoverAnimationSkelton()
SetAnimateMode()
SetInterpolationMode()
SetJointAnimation()
StoreAnimationSkelton()

A en déduire par les méthodes, j'aurrai tendance à associer le "Joint" à "Bones".
Et à priori ça parle bien de skeleton.

merci Copland,

Ma démarche est plus de savoir "ce qu'on peut faire" et de voir "comment le faire", que de me fixer sur une idée de vouloir faire en sorte de le faire avec Irrlicht. J'ai une bien meilleure vision de ce qu'on peut faire maintenant en animation. Il y avait un flou à cause de la physique et d'une mauvaise compréhension du système de bones sous Irrlicht. Maintenant, je sais que :
- Même sous une animation Bones, on travaille un peu comme avec les Keyframes. C'est Irrlicht qui fait le calcul à partir des bones.
- Quand je vois un personnages qui tombe dans les escaliers avec ses membres qui bougent dans tous les sens, ce n'est pas à proprement parler du domaine de l'animation. Chaque membre du personnage est un objet lié au corps via des jointures et le moteur physique gère l'ensemble. A cela on pourrait ajouter une animation, mais ne compliquons pas les choses pour la réflexion.

Maintenant, c'est clair de ce coté là (à moins que je ne me trompe). De nouvelles questions s'ajoutent donc : Peux t-on paramétrer les données physiques d'un objet de des ces sous-éléments sous le modeleur (tel que Maya) ou bien, il faut le faire soi-même après modélisation ? Je ne sais pas si le format X supporte ce genre de données ou s'il  est possible d'exporter "à part" ces éléments. Mais là, je peux aller chercher sous Maya ou dans la définition des formats de fichier. Si quelqu'un sait ça me fera gagner du temps. [copland a répondu à cela dans un autre thread - pas fassable dans le format en tous cas].

Dernière modification par benicourt (13-02-2007 12:51:11)

Bonjour à tous,

Je suis nouveau sur ce forum, je m'interesse depuis peu à irrLicht, et je pense que ça va s'accentuer dans les jours qui viennent.
Cependant, je peux vous clarifier certains points qui ne semblent pas trés clair pour certains jusqu'ici : les animations par bones, keyframes (dans le cas d'un fichier MD2), cinématique directe, cinématique inverse.

tout d'abord, la cinématique directe et la cinématique inverse sont deux méthodes 'opposée' de manipulation d'une hiérarchie de bones en vue de leur donner une posture (ou bien de les animer en enchainant les postures dans le temps)

Avec le cinématique directe, on va faire pivoter les bones (et rarement les repositionner, car dans un squelette les os pivotent mais se baladent que trés rarement, sauf en cas de broyage d'une jambe sous un tractopelle par exemple) en partant de la racine de la hiérarchie et en pivotant un à un les bones enfants, exemple : d'abord le bassin, puis la colonne vertébrale, puis l'épaule, le bras, l'avant bras et enfin la main.

Au contraire, la cinématique inverse consiste à agir sur le squelette en repositionnant un enfant afin que les parent suivent le mouvement selon des contraintes de rotation : par exemple on positionne la main d'un personnage à tel endroit, et le coude devra se plier correctement (sans partir à l'envers), l'épaule devra elle aussi pivoter, etc... selon les contrainte et les limitations que l'on a déterminé pour la hiérachie influencée par la cinématique inverse : par exemple on pourra définir que lorsqu'on déplace la main, les modification n'influencent que les bones du bras et ne remontent pas jusqu'à ceux du haut du dos, s'arrêtant à l'épaule.

Donc, comme vous pouvez le déduire, la cinématique inverse est intrinsèquement liée à la notion de bones, de plus aucun format de fichier supportant les bones ne conditionne ou non l'utilisation de cinématique inverse : ceci dépend totalement de votre aptitude à programmer un moteur de cinématique inverse ou à en utiliser un déjà fait.

Du moment qu'un fichier 3d contient une hiérarchie de bones, il est possible d'utiliser de la cinématique inverse dessus.

Sachez cependant que la cinématique inverse est trés gourmande en calculs, pour un jeu il donc trés souvent préférable d'utiliser une animation en cinématique directe, où il n'y a que des interpolations de rotations qui interviennent.

Ensuite, l'animation 'sans bones', ou par 'keyframes' : ceci est plus généralement le résultat d'une animation par bones faites dans un logiciel d'animation, cette animation étant convertie en une suite de posture clés pour l'animation de votre personnage.

Au final, ça n'est ni plus ni moins qu'une série d'étapes de morphing : chaque keyframe correspond à une nouvelle forme, c'est à dire une nouvelle position pour chaque vertex de votre mesh 3d, et pour peu que ça soit bien fait, en 'morphant' votre objet d'une keyframe à l'autre, vous obtiendrez une animation de votre personnage.


Les bones :

Avantages :
- on peut animer séparément chaque partie du corps
- il est possible de parenter dynamiquement des objets sur n'importe quel bones du squelette (un hachoir à viande dans la main droite par exemple)
- on peut effectuer des transitions d'une animation à l'autre
- consomation mémoire faible (en fonction de la complexité de l'animation tout de même)

Inconvénients :
- quoi qu'on en en dise, ça demande 'plus' de calculs que l'animation par keyframes, ou du moins des calculs plus complexes, pour déformer l'objet.
- selon les capacités du moteur d'animation et/ou du format d'objet, les jointures sur le mesh lors de l'animation seront plus ou moins jolies (selon que les vertex peuvent être influencé par 1 ou plusieurs bones)


Animation par keyframes :
Avantages :
- calculs simple pour jouer l'animation, car ce ne sont que des interpolations de points
- les problèmes de jointures peuvent être réglé par l'infographiste en amont au cas par cas
- comme on travaille avec une liste d'étapes de morphing, on peut s'autoriser plus de fantaisies puisque tout est précalculé (par exemple un drapeau qui ondule dans le vent)

Inconvénients :
- ça peut consommer pas mal de ram puisque l'on garde en mémoire la position de tous les points de l'objet pour toutes les images clés
- pas possible d'animer séparément les parties du corps (sauf s'il si on travaille avec des objets séparés bien sur)
- du fait de la consommation mémoire, les séquences d'animation sont limitées en durée

bien entendu, ceci n'est pas une liste exhaustive


voilà, j'espère que ça vous aidera un peu

Alesk