Discussion :

[djo.mos]

Bonjour tout le monde.
Je crois que je l'ai évoqué avant ça, mais je vais devoir en reparler.
En fait, j'ai commencé le projet (pharaonique) de développer un moteur
3D décent, à base d'OpenGL bien sur, puisque j'envoie ce post sur ce forum ;-),
et sur Delphi, mais c'est pas très important vu qu'on parle d'openGL.

C'était tentant, c'était alléchant, c'était un cauchemar ! J'ai commencé il y'a à peu près
une année de ça, j'y ai mis beaucoup de zèle, et je me retrouve aujourd’hui avec des dizaines
de milliers de lignes de code qui ne fonctionnent pas, j'en suis à la V4, sans avoir jamais
terminé ni la V1, la V2 ou la V3, et j'ai récemment abandonné la chose : c'était devenue trop
ennuyant : avoir à réécrire des larges portions de code, avoir à changer l'architecture plusieurs
fois par nuit.
Bref, je vais passer au vif du sujet : Je demande votre aide, vous qui programmez en OpenGL, pour
savoir :
- pour qu'elle architecture avez vous opté pour vos grands projets ?
- quelle méthodologie, POO ou classique ?
- Est ce que la modularité justifie l'effort et le temps qu'elle demande ?
(par exemple j'ai en un temps décidé de partitionner mon moteur en plusieurs DLL (6 au dernier
recensement)
- Comment gérer vous l'ajout de nouvelles techniques à votre ancien code ?
(par exemple pouvoir ajouter le bump mapping ou le per-pixel lighting sans avoir à recommencer de zéro ?)
- Comment faire pour que l'on puisse avoir des résultats tangibles dès les premières étapes ?
(il m'arrivait de passer près d'une semaine de dur labeur avant de pouvoir tester et visualiser ce que j'ai rajouté !)
- Comment faire pour que l'on puisse créer des effets sans avoir à programmer ? Quelques trucs ?
- Quelle est la meilleure façon pour que diverses techniques de base co-habitent : par exemple les lightmaps, l'ombrage, les reflections ...
(par exemple les fameux shaders de Quake3 : on peut créer des effets étonnant avec un simple fichier texte !)

Toutes les remarques sont les bien venues, et ces questions ne sont que des exemples, soyez libre de vous exprimer
même si ça ne répond pas directement à une de ces questions !

Merci d'avance.

[venomelektro]

salut

developpez un moteur est un lourd travail pour une personne seule, tu as bien du courage

j ai moi aussi fait la chose , et est ete comfronté a pas mal des problemes que tu as cité : comment ajouter les nouvelles techno a l ancien code, modularité etc..

d une maniere generale, tu peux de toute facon pas tout mettre dans le moteur , c est bien d avoir les bases dans des fonctions ou classe et d utiliser cette base pour coder

ex : il y a bcp de facon de coder le bump mapping , pourquoi coder en dur dans le moteur une technique pluto que l autre ?

donc pour moi l utilité d un moteur n est pas forcement de tout permettre mais de fournir une bonne base de codage : gestion des textures, math : vecteurs, matrices etc.. , loadage de differents formats 3d, octree et truc dans le genre

[djo.mos]

Oui, je suis d'accord avec toi, mais sans une bonne architecture, bien structurée dès le départ, ce serait très difficile d'ajouter des fonctionnalitées au moteur, non ?

Moi, j'ai essayé avec les plugins, càd fournit au départ le noyau et quelques modules standards, puis de développer le reste (les effets) comme plugins, mais je patauge complètement dans la gestion de l'ensemble

[venomelektro]

Comme je t ai dis seul, t auras du mal a faire un moteur du niveau de ogre par exemple (c est impossible a faire seul, trop de taf)

sinon justement tu peux t inspirer de bon moteur open source comme ogre ou crystal space

moi de mon coté, je me suis juste contenté de mettre les fonctions de base pour pouvoir coder des jeux 3d simples rapidement et c est le principal atout de mon moteur , sa simplicité

essaye de mettre en avant quelque chose de precis dans ton moteur pour le demarquer de la " concurence " et surtout diffuse le car c est les personnes qui l utliseront qui le permettront de continuer et te fourniront le meilleur feedback

[bafman]

personnelement, pour un jeu, je commence par delimiter ce qui sera utilisé, et une fois cette limité posé, je peut commencer, sinon on se retouve toujours a vouloir ajouter le dernier effet de parallax bump virtual displacement offset über mapping et on doit tout refaire...

donc commence par poser les limites techniques du jeu, puis ensuite pense le en terme de "sous librairies", c'est a dire que le but est de faire un maximum de choses independantes les une des autres, comme ca elle seront reutilisables par la suit, et tu peut même deleger le travail a quelqu'un d'autre si le besoin s'en fait sentir...

[djo.mos]

C'est vrai que ça aurait été beaucoup plus simple si je developpais le moteur pour un jeu, la je saurais ce que dont j'aurais besoin, mais le problème est que je veux juste developper le moteur, du moins pour l'instant, donc j'ai interet à le rendre le plus géneral que possible.

Comme tu l'as dit "venomelektro", ce serait impossible de développer quelque chose de solide tout seul, j'en suis bien conscient.
Ce que je compte faire, c'est de définir une base, une sorte de protocole pour mon moteur, pour que ca soit possible que plusieures personnes puissent travailler la dessus en parallèle, mais j'arrive pas à bien cerner tous les aspects de la chose, je ne suis pas Carmack ni Abrash.

et une question pour "bafman", t'as dit :

puis ensuite pense le en terme de "sous librairies", c'est a dire que le but est de faire un maximum de choses independantes les une des autres,

peux tu stp donner plus de details ?

Moi, j'ai pour l'instant défini le format des plugins effets, qui sont des DLL exportant les fonctions suivantes :
- startupModule(un pointeur vers toutes les informations disponibles) : Pour initialiser l'effet.
- preRender : appelé avant le rendu
- postRender : appelé aprés le rendu
- timer(t) : appelé toutes les x ms
- shutdownModule : arrete l'effet

ça sert par exemple à développer des trucs du genre vision nocturne ou scissoring, si vous voyez ce que dont je veux parler.

J'espère que je me suis fait comprendre, je sollicite vos conseils pour développer une base solide et à architecture ouverte pour que je puisse la diffuser et que d'autres developpeurs prennent le relais !
Si vous êtes interréssés, j'utilises Delphi, et je serais ravi si quelqu'un accepte de m'aider.

[shenron666]

Je voudrai juste dire 2 petites chose, la première étant le souvenir d'un forum, je sais plus lequel, où quelqu'un disait "ceux qui programment des moteurs c'est parcequ'ils ne savent pas quoi faire comme jeu" et paf lol tu rends cette affirmation vraie

la deuxième chose c'est, pourquoi tant de DLL ?????
il existe aussi des librairies statiques, les DLL c'est par exemple le renderer qui peut-etre chargé dynamiquement selon l'utilisateur, un renderer directx, un renderer opengl, donc le programme en charge 1 sur les 2, mais 15000 DLL cela n'a pas d'intérêt et je me demande même si ça n'alourdirai/ralentirai pas le programme

de mon point de vue, je vois le découpage du programme en terme de fonctionnalités (mais pitié, pas une DLL par module ) :
- Gestion des fichiers
- Gestion du texte
- Gestion des textures
- Gestion du rendu
- Gestion des entrées (clavier/souris/joystick)
- Gestion du Son
- Gestion de l'interface utilisateur (GUI)
-...

plus dans la globalité de la chose concernant chaque parcelle du "moteur"
je trouve que les tutoriaux de Loulou24 sont très bien fait pour cela, même s'il demandent à bien s'accrocher si on ne connais pas bien la POO :
http://loulou.developpez.com/tutoriels/moteur3d/

travaillez sur papier, foncez pas dans le tas dès le début, structurerz votre développement et vous verrez, ça passera mieux

[bafman]

voila c'est exactement ce que je voulais dire en parlant de "sous librairies", c'est a dire decouper le tout en petites partie de prog independantes les une des autre. Le must pour ca c'est de réellement developper ces partie de facon independantes (un projet pour chaque module), et lorsque tu en a besoin tu les regroupent tous dans le même projet.

par exemple pour le projet sur lequel je travail a l'heure actuelle, on est 2 a coder, et pendant longtemps, on a été chacun de notre coté a coder des partie du logiciel totalement differentes (renderer, gestion des particules, gestion du son, gestion du GUI...) sans aucune interaction entre elle, ce sont des partie logicielles totalement reutilisable dans un autre projet...

[djo.mos]

Je ne comprends pas pourquoi vous etes contre une myriade de DLLs ? coté performance je ne pense pas que c'est pénalisant, par contre coté modularité, c'est le TOP ! on peut mettre à jour par exemple la partie qui traite les transformations en remplacant la DLL coresspondante, sans rien toucher aux autres ! ça oblige à developper les modules d'une façon indépendantes, vous ne pensez pas ?

Pour l'instant, j'essaie de faire de petits tests pour avoir une vue d'ensemble de la chose, je developpe donc un petit moteur 2D, histoire de simplifier la chose, et je suis aux modules suivants (chacun dans une DLL):
- Gizmo : traite des transformation
- Lights : !!!
- Materials : !!!
- Sprites : !!!
- Kernel : le noyau qui s'occupe de charger les autres modules et propose l'interface.

Mais, vous avez peut etre raison, diviser le projet en plusieurs DLL complique beaucoup la tache de leur chargement et gestion.

[shenron666]

on peut mettre à jour par exemple la partie qui traite les transformations en remplacant la DLL coresspondante, sans rien toucher aux autres !

Si tu modifies une DLL, tu dois recompiler les programmes/bibliothèques qui l'utilisent car les points d'entrées des différentes fonctions ne sont pas forcément les même
donc au final, tu dois recompiler plus que ta DLL et remplacer l'exe

c'est pour cela que JE ne trouve l'utilité des DLL que dans les cas où, l'exemple le plus courant étant celui du renderer, deux (ou plus) DLL pour gérer de 2 façons différentes (ici DirectX ou OpenGL)
avis personnel inside

[djo.mos]

Si tu modifies une DLL, tu dois recompiler les programmes/bibliothèques qui l'utilisent car les points d'entrées des différentes fonctions ne sont pas forcément les même

Pas si j'effectue le chargement des DLL d'une façon dynamique à l'exécution.

Une question, est ce qu'il y'a quelqu'un autre que nous trois dans ce forum ?

Manifestez vous les gars ! vous ne voulez tout de même pas qu'on ferme le forum d'OpenGL pour raison d'inactivité prolongée !

[bafman]

mais y'a plein de monde sur le forum openGL... la preuve je reponde regulierement a pleins de questions si les gens ne reponde pas sur ce post c'est juste qu'ils ne savent pas quoi repondre...

[djo.mos]

Bon, oubliez svp cette remarque imbécile.

Je crois que le sujet est un peu trop géneral, je vais donc spécialiser un peu.

Pour ce qui est des transformations, ca ne pose pas vraiment de problème. Mais pour les materiaux, ça se complique un peu.

Je sollicite donc vos conseils sur ce module, celui qui s'occupe du texturing (et probablement du lighting).

Est ce que ce serait plus judicieux de se tourner vers le GLSL ou est ce que le multitexturing avec des techniques comme les light maps et le bump mapping ont encore de beaux jours devant eux ?
Peut être faut il implementer les deux ?

[shenron666]

Pour moi tout cela fait partie du renderer, ou du moteur de rendu en français

pour ce qui est du multitexturing, le glsl l'utilise, justement pour le lightmapping et le bump mapping, bien que pour le lightmapping le glsl devrait pouvoir s'en passer je pense

de mon avis, le multitexturing d'aujourd'hui a encore de beaucx jours devant lui étant donné que toutes les cartes ne gèrent pas les sahders ou du moins par encore correctement ni avec suffisemment d'efficacité
mais s'il faut parler en terme d'années, c'est vrai qu'il vaudrait mieux se mettre à la programmation des shaders vu tout ce qu'ils apportent en terme de flexibilité

[djo.mos]

C'est vrai que pas tous les cartes supportent, du moins efficacement, les shaders. Surtout les ATI qui sont à la traine.
En fait, je ne me suis lancé dans les shaders que lorsque ma Radeon 9200 a tombé en panne et que j'au utilisé une GeForce 2 de rechange : C'est ahurissant que le GeFOrce II supporte les shaders et pas une Radeon 9200 !

sinon, même pour le multitexturing (je veux dire pur et dur, sans shaders), il y'a un problème : le nombre d'unités de texturing : avec 2 pour la GeFOrce II, ce sera très difficile je pense de faire des effets décents : bumpmapping et lightmapping au même temps par exemple, non ?

[shenron666]

le nombre d'unités de texturing : avec 2 pour la GeFOrce II, ce sera très difficile je pense de faire des effets décents : bumpmapping et lightmapping au même temps par exemple, non ?

que quelqu'un me corrige si je me trompe mais la geforce2 possède 4 "pixels pipelines" avec chacun 2 unités de textures ce qui en théorie permet de traiter 8 textures en 1 seule passe
(d'après ce que je trouve sur le net la geforce6 possède 8 "pixels pipeline" avec chacun 1 unité de texture et traite 16 textures en 1 passe, je ne sais pas comment ils comptent )

[bafman]

attention a ne pas confondre pixel pipline et unitée de textures...
un pipeline est une zone de la carte graphique capable de traiter des pixel, chaque pixel pouvant adresser un certain nombre d'unitée de texture, mais ca ne donner pas pipeline * unitée de texture...

si tu a 8 unitée de texture, tu ne peut en adresser que 8, quelque soit le nombre de pipeline que tu possede (et c'est pour ca qu'une GF6200 peut realiser les même effets qu'un 6800GTXHPQD surpuissante, la 6200 le faisant simplement plus lentement car il y a moins d'unitée de traitement en parallele)

sinon pour info c'est la GF4 qui possede 4 unitée de texture, a mon avis la GF2 ne doit en posseder que 2

[djo.mos]

Je confirme, la GeForce 2 n'a que deux unités de textures, on ne peut pas aller au dela de GL_TEXTURE1.

[djo.mos]

Bon, je vois que le sujet bifurque, dévie et prend des directions inattendus, mais ça reste pédagogique, je pense.

Une question maintenant à propos du lighting :
C'est quoi la meilleure technique pour l'éclairage : qui soit rapide, standard (pas d'extensions spécifiques) et avec des résultats probants ?
Presonellemnt je dirais les lightmaps, qu'est ce que vous en pensez ?

[djo.mos]

En fait, "shenron666" a déja posté sur ce thème, mais je me permets de relancer le sujet pour pouvoir en parler avec plus de marge de libérté.