ah ah ça parle architecture j'adore
bon perso je ferais le truc en une dizaine de fichiers, forcément dès que l'on commence à songer à faire un moteur ça devient un peu volumineux avec pas grand chose

pour que ça reste organisé, il faut forcément des dossiers

bon en restant dans un truc modeste ... ( tu fais comme tu veux pour les noms des fichiers, je fai ça vite fait )

device/device.*
device/device_sdl.* // dérivé du device
device/device_glut.* // dérivé du device
device/device_win.* // dérivé du device
device/device_w11.* // dérivé du device
node/scene.* // implémente un array<node*>
node/light.* // dérivé de node
node/node.* // base pour les nodes dérivés, ne contient que les données superflues ( texture, mesh, ... )
node/real.* // node de rendu de mesh ( standard)
node/skybox.* // dérivé de node
node/geometry.* // classe qui va générer les meshs
node/mesh.h // juste une structure avec des float* ( vertices, indices, TCoord et ... et normales )
render/draw.* // rendu graphique des éléments ( utilisé par les nodes )
render/raytracer.* // implémenté dans draw, au final je pense que c'est le mieux
redner/texture.* // chargement intégré pour pas  se casser la tête ( tga c'est pas compliqué à charger )
math/vector2d.h
math/vector3d.h
math/line2d.h
math/line3d.h // utilisé par le raytracer
math/matrix4.h // utilisé dans le device pour modifier la matrice de perspective, enfin sauf si tu veux utiliser les fonctions standard, donc optionnel je pense
math/array.h // pas indispensable, mais dans la "scène" il te faudra utiliser des std::vector et pas des std::array, trop lent

vite fait, je pense que c'est tout, mais tu verras vite fait que tu voudras rajouter des fonctionnalités ...

ps: ne faire que des headesr n'est pas la solution je dirais même que c'est super emmerdant après, à chaque modif ça va recompiler chaque fichier où ton header est inclus, directement ou non

edit: oublié la spec de real

ha bein oui qu'est ce que je raconte moi
Je comptais faire simple mais en y réfléchissant un peu ça va pas le faire, dans l'exemple tout le code de raytracing est dans une même fonction, mais c'est pas flexible, y a la scène, les lumières, les matériels...... En fait je crois que c'est l'occasion de faire 2 tp en 1, raytracer+ l'organisation en C++, je pense que ça peut être que bénéfique pour les membres comme moi qui sont pas trop branchés POO.
Donc je sais pas trop comment procéder, je sais qu'irrlicht utilise des Interfaces comme tu le disais plus haut Magun, mais j'ai peur que ça alourdisse le code ?, enfin je sais pas combien ça va faire de fichiers tout ça, dis moi ce que t'en pense, mais il faudrait peut-être faire aussi des classes: scene, Lumiere, Mesh.... afin que le moteur soit aisément améliorable, sans pour autant qu'il y ait trop de fichiers, j'ai d'ailleurs fait que des headers justement pour alléger le nombre de fichiers.
Comment verrais-tu la chose ?

non déclarer le raytracer dans la classe de rendu, pas celui de l'écran

j'ai pas trop le temps la vite fait 2/3 truc...
virtual permet de redéfinir les fonctions sur les classes/structures dérivées et du coup faire un appel du style mère->fonction(); qui fait une sorte de redirection automatique vers fils->fonction();

le raytracer doit être dérivé de draw, pas du device, ou le cas échéant être implanté dedans, en protected
s'il est implanté faire des fonctions style, enableRaytracerRendering, disable..., isEnabled... getRaytracer, setRaytracer ( au cas où l'utilisateur veut faire sont propre raytracer dérivé )

pour la fonction opengl je pensais à glRasterPos3f qui, si mes souvenirs sont bons, retourne une position 2d(screen) d'une position3d, ça peut aider
pour les sources je pensais que tu pouvais récupérer mes classes device et draw, et les simplifier quelque peu par exemple mais tu fais comme tu veux

Salut Altaïr !
Je pense que le problème est le fait que ton code qui recrée le node soit situé dans la boucle de rendu car ton ordinateur le recrée a chaque fois. D'autre part, ton fichier 3D peut contenir une erreur de frappe au niveau du nom. Si rien ne marche, ça peut aussi être parce que tu réécris

 scene::IAnimatedMeshSceneNode* node = smgr->addAnimatedMeshSceneNode(model);

alors qu'il suffirait d'un

 node = smgr->addAnimatedMeshSceneNode(model);

Voila Teste et dit moi, je te rerépondrai si tu as besoin

Assassin's Creed ca roxx

Bonjour, j'ai un perso qui se déplace dans la map BSP donnée avec Irrlicht. J'ai attaché un "ISceneNodeAnimatorCollisionResponse" à ce perso et les collisions marchent parfaitement. Je voudrais modifier un des paramètres de ce collision animator pendant l'exécution, mais lorsque je modifie un paramètre dans la boucle de rendu(que ce soit directement dans la boucle ou par une fonction appelée dans la boucle), le collision animator ne marche plus du tout et je n'ai donc plus aucune collision.

J'aimerais donc savoir s'il y a un moyen de changer un paramètre d'un collision animator au cours du programme. Merci.

Voici mon code si vous voyez une erreur de ma part:
La création du collision animator:

La boucle de rendu, par exemple ici je change la gravité de l'animator avec anim->setGravity, après cela le collision animator ne marche plus du tout.

J'ai essayé de mettre la modification avant le beginScene, après le beginScene, et après le endScene, mais toujours le même résultat. Par contre si je le fais avant la boucle de rendu, la gravité est changée normalement et le collision animator marche toujours parfaitement.

j'en demandais même pas tant, c'est très gentil de ta part, je vais enfin pouvoir avancer (hmmm ou plutôt démarrer mais bon ^^=

merci encore pour ton aide

merci mais j'avais espéré un petit bout de code pour exemple
car j'ai cherché hier soir et je n'ai vraiment pas réussi (je débute vraiment...pour tout ce qui est des cameras, event etc je peux me débrouiller avec des tutos mais là y'a pas grand chose qui traite ça)

par contre quand tu dis que le jpg ne supporte pas la transparence, tu parles bien de l'alpha? pas de la texture à lui appliquer?

merci encore

et bien oui il faut utiliser le flag EMT_TRANSPARENT_ALPHA_CHANNEL, mais l'ordre n'a pas d'importance, que ce soit avant ou après quoi que ce soit ( enfin après l'initialisation mais ça je pense que tu t'en doutes )

tu devrais désactiver le flag EMF_FOG aussi, histoire d'être sûr, je ne sais plus s'il y est par défaut ... je ne crois pas mais bon
sinon pour info le jpg/jpeg ne supporte pas la transparence, il te faut passer par un png/tga/bmp ( mais irrlicht ne supporte pas l'alpha en bmp ( mode: argb 32bit ) il me semble, à voir dans les sources ... )
donc du coup, forcément ton éditeur d'image remplace l'alpha channel par une autre couleur

oui oui je sais que ce n'est pas utilisable t'en fais pas, j'ai mis ça dans mon code en me disant "ça marche poooo...)

non en fait j'ai du mal à m'expliquer: j'arrive à créer mon terrain et à mettre la texture principale dessus:

jusque là ça va mais par contre je ne sais pas comment déclarer l'alpha de ma texture "détail" et sa texture associée
je me doute qu'il faut utiliser un truc du genre : >setMaterialType(video::EMT_TRANSPARENT_ALPHA_CHANNEL); mais après....

merci pour ton aide en tout cas, c'est bien sympa