Donc, comme promis, voici mes premières impression après quatre jours passé à
bidouiller avec Irrlicht.
Irrlicht est un moteur très attachant. Il a pour lui d'etre à la fois plutot
simple et relativement complet. Son approche et sa mise en oeuvre déroute les
premiers temps, mais on s'y fait très bien et les fonctions sont nombreuses,
ce qui couvrent la majeure partie des besoin en programmation 3D, du moins à
notre niveau d'amateurs que nous sommes.
Ceci dit, en complément, je dirais que le projet à besoin de murir, en particulier
au niveau de la gestion des rendus, qui se font par des fonctions de sortie qui ne
sont plus employées dans le monde de la 3D depuis déjà un moment, si ce n'est quand
on débute (car plus aisées à comprendre). Travailler sur la géométrie en RAM Video
serait le bien venue et boosterait pas mal les perf, que ce soit en OpenGL ou avec
Direct3D.

Voici, à chaud, quelques points qui cependant ont attiré mon attention, et qui
trouveront peut-etre une explication de la part des 'pro' de ce moteur:

1- lors du multitexturing, soucis au niveau des changements des states de rendu
ou on note une grosse différence entre OpengGL et DirectX9 (D3D9 buggué ?).
Il faut que je teste sur mes autres machines pour voir si ce genre de bug ce
confirme.

2- certains artefacts lors de certains rendus avec D3D9, qui ne sont pas
rencontrés avec OpenGL.

3- le rendu par liste de Vertices/Indices situé en RAM système, ce qui nuit
beaucoup au performances (comme souligné dans mon préambule), surtout dès
que l'on commence à avoir des scènes chargées en polygonnes.

4- Restitution des shadows qui semblent souvent buggués. Il n'aime pas non plus
les mesh trop complexe, mais vue que c'est du shadows volume software, c'est
aisément compréhensible.

5- Indices des mesh uniquement en 16 bits, ce qui limite la géometrie des mesh à
65536 faces. C'est déjà très respectable, mais dans certains cas, c'est une limite
qui peut se révéler gênante. Je pense en particulier à la génération de terrain
ou l'on franchis aisément cette limite.

6- limitation apparemment à deux coordonnées de texture par mesh. La encore, cela
couvre déjà la plupart des domaines, mais toujours dans le cas de terrain, ou dans
pas mal de cas il est souhaitable d'avoir au moins 3 coordonnées de texture, cela
bride un peu les choses (mapping, detail, et... shadows mapping = 3 UV).

Ceci dit, je continue mon apprentissage, mon premier vrai code, je pense, sera de
tenter d'adapter mon moteur de terrain à Irrlicht.

Copland Ecris:

Toi qui a de l'expérience en développement de moteur3D et plus particulièrement
sur DirectX, j'ai entendu dire que le fait d'utiliser le DrawPrimitiveUP de directX avait une
addition sévère sur le FPS (Directx9 programmation de jeux 3D par Laurent Testud), chose
qu'irrlicht utilise à 100%. Sais-tu si c'est vrai, et si c'est modifiable dans irrlicht sans
pour autant avoir à retoucher à 50 fichiers du code source car je dois reconnaitre que niveau
performance, je suis assez coincé sur mon jeux...

Pour avoir regardé cela de près, je t'avoue qu'arriver à un résultat dans ce domaine sans avoir
à modifier pas mal de partie du moteur me parait très difficile. Maintenant, n'ayant pas encore
finis d'analyser les entrailles du code du moteur, je me trompe peut-etre, mais j'en doute.

Aranoth Ecris:

C'est vrai, Irrlicht n'est pas très rapide, contrairement à ce que pourrait faire croire
son nom. Mais c'est en train d'être réglé : jusqu'à présent les VBO n'étaient pas implémentés, c'est
chose faite (en tout cas pour le renderer OpenGL) et ce sera dispo pour la prochaine version.
Donc il faut s'attendre à un petit coup de boost (les Vertex Array c'est sympa mais c'est pas ce qu'il
y a de plus rapide...)

Comme le dit donc Aranoth, la prochaine version reglera peut-etre en partie cette question, car si
les VBO sont implenté pour OGL, ont peut penser qu'il en sera de même pour les buffer de Direct3D.

Mais en attendant je vais continuer à plancher sur le truc quand même...

D'ailleurs, à tout hasard, quelqu'un a t-il réussi à récupérer dans ces codes le pID3DDevice lors
de l'emploi de D3D9 avec Irrlicht. Il s'agit d'un membre privé de la l'objet CD3D9Driver , donc en
théorie cela ne doit pas etre trop possible, sauf si j'ai fait l'impasse sur une fonction qui permet
de retourner cette valeur ?