Discussion :

[Invité]

Bonjour à tous. Je suis un debutant en c++ et en programmation 3d, mais j'avance très vite grâce à d'excellents sites que j'ai trouvé. Sinon je programmais déjà en java donc je ne suis pas un neophyte complet en programmation . Voici pour l'intro.

Voulant progresser dans les domaines c++ et programmation 3d j'ai décidé de faire moi même un moteur 3d, qui resterait très modeste, rassurez vous je ne compte pas refaire ogre en mieux lol
Eh oui, je pense que réinventer la roue est très utile pour progresser en c++ et pour ensuite mieux se servir d'un véritable moteur 3d performant, ou pour coder des jeux 3d très basiques simplement grâce à un moteur que je connaîterais par coeur puisque c'est moi qui l'aurait codé .
Mon moteur serait codé en 3d avec opengl puisque j''ai trouvé d'excellents tutoriaux dessus, de plus il serait en accord parfait avec la sdl pour l'implementation de opengl, en effet les deux sont portables.

Venons aux problèmes : j'ai cherché de la documentation sur comment bien structurer un moteur 3d et je n'ai trouvé que peu d'informations qui m'ont conduit à la structure et l'organisation suivante de mon moteur. En effet je ne veux pas commencer à coder sans savoir clairement où je vais, sinon je risquerais de me planter à un moment et de devoir tout refaire parce que je n'avais pas prévu un truc.

Structure du moteur en très résumé : (la vrai structure du moteur est plus complète que ça sur papier rassurez vous (texture, lumiere,...)

une classe principal nommé Rendu serait le gestionnaire de base du moteur. Ce serait le noeud principal qui comprendrait donc des coordonnées et une orientation précise dans l'espace. Cette classe dériverait d'autres classes comme celle de la gestion de la caméra ou la classe Affichage. En clair, je cree un noeud (une instance de la classe Rendu), je le place, je creer un cube par ex à cet endroit avec une camera, et des que je bouge les coordonnes de ma classe Rendu, je redessine tous les objets liees à ma classe (mon noeud), la camera et le cube bougent donc en meme temps.

Le problème se situe au niveau de ma classe que j'ai nommé Affichage. En clair elle récupéreait des vertex qui formeraient des polygones pour faire des objets 3d. Mais comment les envoyer à ma classe Rendu (mon noeud) pour qu'elle affiche ces solides. Sous forme de tableau à 3 dimensions (x y z) ou bien sous forme de structure struct Vertex et struct Polygon.

De plus une fonction renvoyant une structure n'existe pas, ou bien comment faire ?
Enfin si je fais un AfficheCube(largeur,longueur,profondeur,...) pour afficher un cube par exemple, et que j'arrive à renvoyer les coordonnées à Rendu, qui les stockeraient dans une structure ou un tableau pour les afficher, si je fais une deuxieme fois un AfficheCube(largeur,...), ou un autre solide^, par ex AfficheSphere(...), il va supprimmer le premier et le remplacer par le deuxieme; puisque je n'aurais qu'une seule structure ou tableau à 3 dimensions dans Rendu où seront enregistrées les coordonnées.


Où alors peut etre que ma structure du moteur est totalement erroné, dans ce cas si vous pouviez m'aiguiller vers une bonne structure pour un moteur 3d, car la doc la dessus est tres dur a trouver même en anglais.

Merci d'avoir pris le temps de tout lire, je sais sûrement que je n'ai pas dû être clair sur certains points mais mon problème est dur à expliquer.

Merci d'avance à ceux qui prendront le temps de me répondre

++ et bonne prog

PS : j'ai deja regardé un peu le tutorial sur la conception d'un moteur 3d par Laurent Gomila et bien que traitant tous les aspects d'un moteur, ce tutorial semble d'un niveau encore trop élevé pour moi

[Bakura]

http://www.amazon.com/Ultimate-Game-...e=UTF8&s=books

Je ne sais pas ce que vaut ce livre, mais il a l'air très bien

[Laurent Gomila]

Je pense que progresser en programmation 3D en faisant un moteur 3D, ce n'est pas ce qu'il y a de mieux. Apparemment tu as encore beaucoup de concepts à aborder, et qui font que tu vas un peu galérer lors de la conception de ton moteur ; il faut avoir un certain recul sans quoi on se retrouve vite à ne pas savoir ce que l'on fait. Pour apprendre, rien de vaut de petites démos ciblées sur une technique ou un concept particulier.

Enfin bref.
Concernant la structure du moteur, les deux choses primordiales sont une classe de rendu qui encapsule l'API 3D (et qui est la seule à y toucher), elle comporte notamment tout ce qu'il faut pour créer une texture, des VB / IB, chnager les états de rendu, et afficher des primitives. Seconde chose : la structure de la scène (le scenegraph). En gros c'est une un arbre qui décrit la hiérarchie de la scène, et qui permet de placer les entités dans le repère global par transformations successives.

Après, le reste n'est qu'encapsulation de textures, VB / IB, shaders, ... et quelques gestionnaires pour se simplifier la vie (gestionnaire de ressources, de polices de caractères, de modèles, ...).

[Invité]

Je pense que tu as raison. Je vois à quels points il me manque des informations essentiels :

-par ex "une classe de rendu qui encapsule l'API 3D" pourrait être ma classe Rendu mais "la structure de la scène (le scenegraph)" je ne vois pas du tout comment l'aborder.

-De plus dans tous les tutoriaux que j'ai pu lire je ne vois pas mentionner d'index buffer ou de vertex buffer ou de primitives.
J'affiches mes points et mes polygones à coup de glBegin(GL_...) et
glVertex3d

Mais merci beaucoup de tes conseils, néanmoins je pense toujours poursuivre le moteur, quitte à ce qu'il ne soit capable d'afficher que des solides basiques, gestion de la camera basique, lumieres et textures. Ce serait déjà plus que très bien pour moi. De toute façon comme je l'ai dit ce moteur n'est qu'à but pédagogique. ce serait plus un set 3d qu'un réel moteur, seul si je parviens à mes objectifs je le continurais peut etre.

[Edouard Kaiser]

Commence à te renseigner sur les VBO (vertex Buffer Object) en OpenGL alors !

[Invité]

Merci, j'ai déja trouve un tutorial parlant de ca, je vais donc m'orienter vers cette solution.

Mais bon si quelqu'un peut m'aider quant à la structure même des classes du moteur, car j'avoue être un peu paumé, je pensais etre sur la bonne voie avec mon noeud principale symbolisé par la classe Rendu.
Si j'ai bien compris je cree une classe qui va s'occuper de faire tout afficher grâce à l'api 3d, et une autre classe permettant de tout positionner et de transformer. Ces 2 classes principales ayant pour dérivé toutes les autres classes mineures comme les loaders,...

J'espere être sur le bon chemin

++ et bonne prog

[Bakura]

Essaye de te créer un loader d'objet 3D. Le format ASE est très simple Ca te permettra d'afficher autre chose que des cubes et des sphères .

[Laurent Gomila]

Le graphe de scène ce n'est rien d'autre que des entités reliées sous forme d'arbre. Chaque entité possède une matrice de transformation locale (généralement décomposée en position, rotation et échelle) relativement à celle de son parent. Par exemple, un lacet sera attaché à une chaussure, elle-même attachée à une jambre, elle-même attachée à un corps.
Après, une telle hiérarchie peut aider pour les tests de visibilité etc...
C'est comme une interface graphique, où chaque contrôle est positionné relativement à son conteneur (fenêtre, panel ou autre). Et les tests de visibilité, c'est comme savoir sur quel contrôle a été effectué un clic de souris.

[ash.ice.loky]

J'aime pas ASE.

Si tu connais un peu le XML (ceux qui connaissent pas lèvent le doigt !!) il y a COLLADA avec colladaDOM, EXCELLENT et simple comparé a du 3DS

[bafman]

voila en gros ma façon de concevoir un moteur :

un package de base qui va contenir tout les truc bas niveau et réutilisable independament du moteur. on va donc trouver ici tout ce qui est vecteurs, matrices, mais aussi la gestion des textures, des fontes, shaders et autres trucs plus ou moins lié aux api graphiques, d'IO et autres. c'est aussi la dedans que je met la classe qui gere ma boucle de jeu principale (la c'est plus discutables, mais je la met la dedans car c'est du reutilisable non lié à un projet donné)

un package pour le moteur de rendu. dedant, je met tout ce qui est lié à mon scène graph (qui est d'ailleur généralement plutot un rateau qu'un graph )
c'est ici qu'on va trouver les conceptes de noeud, d'entité affichable, mais aussi tout ce qui est gestion des models et de la scène

ensuite, je fait généralement un package pour chaque autre concepte (Particules, moteur physique, son). l'objectifs de ces package est de ne dependre que du package de base.

ensuite, une fois que j'ai tout mes package prets, je fait un package central propre au jeu qui va utiliser tout mes autres package.

maintenant, dans la collection les truc que je fait mal :

• pas d'indepandance par rapport au API : les classe textures et autres attaquent directement OpenGL/SDL, mais etant donné que je developpe exclusivement sur cette plateforme, ca ne me derange pas plus que ca
• le package de rendu utilise le package de moteur de particules (ce qui est logique), il y a donc une dependance vers ce package qui devrait plutot être un sous package du rendu qu'un package independant (mais comme il a été developpé bien avant, ca reste comme ca )

[Invité]

D'après toutes les informations que vous m'avez donné (bien gentillement ) je vais essayer de restructurer le moteur.

Est ce une facon plus "juste" de le programmer de cette manière :

Une classe X qui va etre la base de mon graphe scene, elle aura donc des coordonnées précises et une orientation précise dans l'espace. Elle dériverait de la class Loader pour charger des modèles 3d, de la class caméra pour afficher une caméra à l'endroit du noeud,... Cette classe aura donc comme variables x, y, z, angle de rotation,...

Mais cette classe aura un constructeur surchargé permet de passer en paramètre une instance de cette même classe X.

En clair je crée une instance de X, I1, je le place ou je veux et je y met un cube, et une caméra.

Puis je cree une seconde instance de X, I2, qui aura en paramètre pour le constructeur la premiere instance de X : I1

Je fais par ex I2.getX(instance de I1) get Y get Z get angle ,... puis je place mon noeud grace au setX(),... en getX+2 getY+3,... ce qui fait que I2 sera lié à I1.
Quand je change les coordonnées de I1, celles de I2 changent aussi, mais pas par rapport à I1 (j'espere que je suis assez clair). Sa position relative à I1 reste la même puisque sa position depend de celle de I1 grace, par ex à :
I2.setX(getX(I1)+2.5)

Je peux maintenant affciher un cube en I2, dont l'origine restera toujours à +2.5 sur l'axe X, par rapport à l'origine du cube I1 ou de la caméra I1.

Donc est ce que ca pourrait etre une sorte de scene graph tres simplifie pour mon moteur.

Ensuite une classe Y recupere le tout et affiche tout + gestion evenement + gestion du FPS,...
Et j'afficherais le tout grace au VBO (j'ai deja touve des tutoriaux dessus je vais voir ca).

J'espere que c'est ca parce que sinon je sens bien que je vais jamais arriver à coder un moteur même très simple, il faudrait que j'arrive à trouver quelqu'un avec un peu plus d'experience que moi, sinon va y avoir 5 questions par semaine de ma part lol .

++

PS : Si c'est bien ca (pour un moteur tres simple je parle, je conçois bien que ogre a une structure à peine plus évolué ), il me reste un problème, surement basique en POO, mais dont je ne trouve toujours pas la solution.

En partant de l'exemple d'avant, si je charge un modele 3d grace a mon instance de X : par ex I3.getMesh(...), j'enregsitre dans quoi les vertex, un tableau ? une structure ? Si oui, des que je ferais un second getMesh je vais supprimer les vertex du tableau ou de la structure du premier mesh pour les remplacer par le deuxieme. A moins que je cree une nouvelle instance de X pour chaque mesh chargé, mais ca me parait un peu lourd

Merci d'avance à ceux qui ont eu le courage de lire les problèmes d'un néophyte en 3d (il faut bien commencer un jour ), et à ceux qui me répondront

[Invité]

Allez un petit up pour mon post

SVP repondez moi pour le post d'avant, regardez ce que j'ai deja fait pour le début : j'ai mis le .rar en piece jointe.

Je sais, ce n'est encore rien mais je débute, et j'ai besoin d'aide

Merci d'avance ++

PS: la class main affiche des cubes juste pour le test du graphscene, plus tard je le ferais avec des VBO si j'y arrive

[bafman]

Une classe X qui va etre la base de mon graphe scene, elle aura donc des coordonnées précises et une orientation précise dans l'espace.

jusque ici, ca va, a part qu'il faut mieux utiliser une matrice pour stocker tout ca (ca facilite nettement les transformation, que ce soit pour l'API 3D que pour toi même)

Elle dériverait de la class Loader pour charger des modèles 3d, de la class caméra pour afficher une caméra à l'endroit du noeud,... Cette classe aura donc comme variables x, y, z, angle de rotation,...

alors la, stop... tu melange la gestion du graph de scène et la gestion des données stockée dans ce graph... pourquoi un noeud doit-il savoir charger un modèle ?
en fait, généralement, dans les graph de scènes, les noeuds stockent des "drawables" abstraits qui peuvent être soit des models, soit des moteurs de particules, soit des truc autres, mais en aucun cas ils ne savent ce qu'ils contiennent réellement. ainsi, on peut etendre le graph de scène pour qu'il prenne en compte de nouveaux concepts aux quels on avait pas pensé avant (les billbords par exemple)

si tu veut te faire une bonne idée de ce qu'est un graph de scène relativement bien géré, regarde la doc de l'API Ogre

[Invité]

Tout d'abord merci de ta réponse

jusque ici, ca va, a part qu'il faut mieux utiliser une matrice pour stocker tout ca (ca facilite nettement les transformation, que ce soit pour l'API 3D que pour toi même)

Je ne vois absolumment pas comment implémenter ca ???
Moi je donne mes coordonnées à mon instance de la classe Graphscene, puis j'affiche mes cubes grâce à des glRotated et glTranslated selon les coordonnées de mon instance de Graphscene.
Enfin pour un petit moteur comme le mien tu penses appremment que ce n'est pas le plus gros probleme, donc ca va .

alors la, stop... tu melange la gestion du graph de scène et la gestion des données stockée dans ce graph... pourquoi un noeud doit-il savoir charger un modèle ?

Effectivement c'est complètement faux, mais comme tu vas pouvoir voir dans le fichier joint ci dessous je n'ai pas procédé ainsi.

Telecharge ce fichier et tu verras : en résumé je cree une classe qui dérive de Graphscene pour chaque concept, comme pour ma class Camera par ex.
Je ferais pareil pour le loader, la lumière,...
Est ce une maniere plus juste de coder mon graphscene

Voici le fichier, ou on voit clairement comment je compte gerer mon graphscene.

++ et merci d'avance à ceux qui me répondront

PS : Je vais m'attaquer au loader maintenant, apres seulement j'implementerais tout le reste. Donc je vais vous poser une petite question, comment est structuré le format ASE (qui est le plus simple dit on). J'ai vu la faq developpez.com qui renvoie un site ou telecharger ce loader, mais pas d'explication sur le format, et sur le site des format (je sais plus le nom ) , il n'y est pas, il y a tout les format comme le .3ds,... mais pas le ASE; pourtant j'ai vraiment chercher pendant tout le week end, même sur les sites anglais ce format n'est pas expliqué, et je n'ai trouvé aucun code qui gère chaque fonction du loader avec des commentaires précis, donc svp

[Laurent Gomila]

Moi je donne mes coordonnées à mon instance de la classe Graphscene, puis j'affiche mes cubes grâce à des glRotated et glTranslated selon les coordonnées de mon instance de Graphscene.
Enfin pour un petit moteur comme le mien tu penses appremment que ce n'est pas le plus gros probleme, donc ca va

Ce n'est pas gênant non. Mais bon, en interne OpenGL va construire une matrice lorsque tu vas appeler glRotate et glTranslate, puis l'envoyer en tant que matrice MODELVIEW. Autant le faire toi-même (surtout qu'après ça simplifie les futures autres opérations que tu vas effectuer sur les noeuds de ton graphe de scène).

Sinon pour le format ASE : http://bakura.developpez.com/tutorie...newton3/#LII-A

[Edouard Kaiser]

Je ne vois absolumment pas comment implémenter ca ???
Moi je donne mes coordonnées à mon instance de la classe Graphscene, puis j'affiche mes cubes grâce à des glRotated et glTranslated selon les coordonnées de mon instance de Graphscene.
Enfin pour un petit moteur comme le mien tu penses appremment que ce n'est pas le plus gros probleme, donc ca va .

Au contraire c'est trés important, toutes les transformations dans ton espace reposent sur des matrices quelque soit l'API utilisée (Direct3D ou OpenGL) et Dieu que c'est pratique ! Penche toi sur un cours de Math à l'occasion tu verras ça t'aideras à y voir plus clair

[Invité]

Merci de vos réponses.

Pour les matrices je vais essayé de voir ça quand j'aurais déja rélisé ma liste d'objectifs pour mon moteur. (j'ai déja fait 10^-37% de ce que je voulais faire, c'est déjà pas mal lol )

Merci Laurent, j'ai telecharge le code et je vais essayé de déchiffrer ca.
Au juste le format ASE ne gère pas les animations en lui même, c'est bien ca ?


Et donc pour mon code, je suis sur la bonne voie ? ou il faut encore changer des trucs

++ et merci

PS : sinon j'ai plus trop de questions là, je vais essayer de coder le loader, en plus le code du loader que tu m'as envoyé est codé avec des VBO donc ca va me faciliter la tache puisque c'est toi qui m'a conseillé cette approche
Je sens que ce topic va devenir le thread officiel de tous mes problèmes avec mon moteur, allez mais y a que comme ca qu'on apprend

[bafman]

Telecharge ce fichier et tu verras : en résumé je cree une classe qui dérive de Graphscene pour chaque concept, comme pour ma class Camera par ex.
Je ferais pareil pour le loader, la lumière,...
Est ce une maniere plus juste de coder mon graphscene

ha oui, vu comme ca, ca parait plus correct, mais en fait ca ne resoud pas le problème
en fait, ton graph de scène va contenir des noeuds, chaque noeud ayant une position/orientation/fils/pere/... Quand on se place strictement du point de vu du graph de scène, tu n'a besoin de rien d'autre pour pouvoir gerer ton graph, il est donc préférable de decoupler les noeuds de ce qu'ils contiennent.
dans ogre par exemple, tu a des noeuds qui contiennent des movableObjects, et les differents objets affichables heritent de movableObject. On peut ainsi facilement etendre les possibilitées d'affichage du graph sans pour autant toucher au graph, et, point très important quand on developpe son moteur, on peut même modifier le comportement du graph sans pour autant devoir repasser dans toutes les classe lié à l'affichage...

[Invité]

Malheureusement je comprends assez mal ce que tu veux dire

Que représente les movableObjects ?

C'est une classe qui a justement pour dérivés les concepts comme la caméra ou la lumiere, ou alors je suis complètement à coté de la plaque (probablement )


Merci d'avance

++ et bonne prog

PS : que c'est dur de programmer un projet qui fait plus de 2 classes lol, on croit toujours (enfin moi je croyais) que le plus dur serait de savoir comment coder la chose, alors qu'en fait savoir comment on va s'y prendre pour structure le projet (classes, algorithmes,...) est bien plus compliqué, une fois qu'on a tout ca y a plus qu'a coder, on sait déja ou on va concrètement

[Invité]

Les movableObjects doivent être des objets qui bougent, non ?

Moi, de mon côté, j'ai une approche un tout petit peu différente, mais qui au final revient au même.

Mon objet gNode est un élément de mon arbre, et ensuite, je le dérive, de manière a obtenir un movable, un model, des particles, etc...

j'utilise une classe de ce genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
class gNode {
   protected:
      vector3 position, orientation;
      boundingVolume bounds;
 
      gNode childs[];
      int nb_childs;
   public:
      /* methods here */
      virtual void update()=0;
      virtual void render()=0;
};

Enfin, rien de très compliqué quoi Mais je met les branches de l'arbre directement dans les éléments graphiques... Je ne sais pas si c'est bien ou pas, en tout cas, je le voyait plus simplement comme ça.