# Applications > Dveloppement 2D, 3D et Jeux > Moteurs 3D >  Meilleure architecture pour un moteur 3D

## 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 dvelopper un moteur
3D dcent,  base d'OpenGL bien sur, puisque j'envoie ce post sur ce forum ;-),
et sur Delphi, mais c'est pas trs important vu qu'on parle d'openGL.

 C'tait tentant, c'tait allchant, c'tait un cauchemar ! J'ai commenc il y'a  peu prs
une anne de a, j'y ai mis beaucoup de zle, et je me retrouve aujourdhui 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 rcemment abandonn la chose : c'tait devenue trop
ennuyant : avoir  rcrire 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 mthodologie, POO ou classique ?
 - Est ce que la modularit justifie l'effort et le temps qu'elle demande ?
   (par exemple j'ai en un temps dcid de partitionner mon moteur en plusieurs DLL (6 au dernier
   recensement)
 - Comment grer 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 zro ?)
 - Comment faire pour que l'on puisse avoir des rsultats tangibles ds les premires tapes ?
   (il m'arrivait de passer prs d'une semaine de dur labeur avant de pouvoir tester et visualiser ce que j'ai rajout !)
 - Comment faire pour que l'on puisse crer des effets sans avoir  programmer ? Quelques trucs ?
 - Quelle est la meilleure faon 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 crer 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
mme si a ne rpond 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 structure ds le dpart, ce serait trs difficile d'ajouter des fonctionnalites au moteur, non ?

  Moi, j'ai essay avec les plugins, cd fournit au dpart le noyau et quelques modules standards, puis de dvelopper le reste (les effets) comme plugins, mais je patauge compltement 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 mme 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 problme est que je veux juste developper le moteur, du moins pour l'instant, donc j'ai interet  le rendre le plus gneral que possible.

 Comme tu l'as dit "venomelektro", ce serait impossible de dvelopper quelque chose de solide tout seul, j'en suis bien conscient.
 Ce que je compte faire, c'est de dfinir une base, une sorte de protocole pour mon moteur, pour que ca soit possible que plusieures personnes puissent travailler la dessus en parallle, 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 dfini 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 aprs le rendu
 - timer(t)  : appel toutes les x ms
 - shutdownModule : arrete l'effet

a sert par exemple  dvelopper des trucs du  genre vision nocturne ou scissoring, si vous voyez ce que dont je veux parler.

J'espre que je me suis fait comprendre, je sollicite vos conseils pour dvelopper une base solide et  architecture ouverte pour que je puisse la diffuser et que d'autres developpeurs prennent le relais !
 Si vous tes interrsss, j'utilises Delphi, et je serais ravi si quelqu'un accepte de m'aider.

----------


## shenron666

Je voudrai juste dire 2 petites chose, la premire 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  ::P:  

la deuxime 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'intrt et je me demande mme si a n'alourdirai/ralentirai pas le programme  ::?:  

de mon point de vue, je vois le dcoupage du programme en terme de fonctionnalits (mais piti, pas une DLL par module   ::evil::  ) :
- Gestion des fichiers
- Gestion du texte
- Gestion des textures
- Gestion du rendu
- Gestion des entres (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 trs bien fait pour cela, mme 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 ds le dbut, structurerz votre dveloppement et vous verrez, a passera mieux   ::wink::

----------


## 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 rellement developper ces partie de facon independantes (un projet pour chaque module), et lorsque tu en a besoin tu les regroupent tous dans le mme 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 pnalisant, 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 faon indpendantes, 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/bibliothques qui l'utilisent car les points d'entres des diffrentes fonctions ne sont pas forcment les mme
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 grer de 2 faons diffrentes (ici DirectX ou OpenGL)
avis personnel inside

----------


## djo.mos

> Si tu modifies une DLL, tu dois recompiler les programmes/bibliothques qui l'utilisent car les points d'entres des diffrentes fonctions ne sont pas forcment les mme


 Pas si j'effectue le chargement des DLL d'une faon dynamique  l'excution.

 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 mme pas qu'on ferme le forum d'OpenGL pour raison d'inactivit prolonge !

----------


## bafman

mais y'a plein de monde sur le forum openGL... la preuve je reponde regulierement a pleins de questions   ::wink::   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 imbcile.

  Je crois que le sujet est un peu trop gneral, je vais donc spcialiser un peu.

  Pour ce qui est des transformations, ca ne pose pas vraiment de problme. 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 franais   ::P:  

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 grent pas les sahders ou du moins par encore correctement ni avec suffisemment d'efficacit
mais s'il faut parler en terme d'annes, 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, mme pour le multitexturing (je veux dire pur et dur, sans shaders), il y'a un problme : le nombre d'units de texturing : avec 2 pour la GeFOrce II, ce sera trs difficile je pense de faire des effets dcents : bumpmapping et lightmapping au mme temps par exemple, non ?

----------


## shenron666

> le nombre d'units de texturing : avec 2 pour la GeFOrce II, ce sera trs difficile je pense de faire des effets dcents : bumpmapping et lightmapping au mme temps par exemple, non ?


que quelqu'un me corrige si je me trompe mais la geforce2 possde 4 "pixels pipelines" avec chacun 2 units de textures ce qui en thorie permet de traiter 8 textures en 1 seule passe
(d'aprs ce que je trouve sur le net la geforce6 possde 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 unite de textures...
un pipeline est une zone de la  carte graphique capable de traiter des pixel, chaque pixel pouvant adresser un certain nombre d'unite de texture, mais ca ne donner pas pipeline * unite de texture...

si tu a 8 unite 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 mme effets qu'un 6800GTXHPQD surpuissante, la 6200 le faisant simplement plus lentement car il y a moins d'unite de traitement en parallele)

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

----------


## djo.mos

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

----------


## djo.mos

Bon, je vois que le sujet bifurque, dvie et prend des directions inattendus, mais a reste pdagogique, je pense.

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

----------


## djo.mos

En fait, "shenron666" a dja post sur ce thme, mais je me permets de relancer le sujet pour pouvoir en parler avec plus de marge de librt.

----------


## shenron666

Je suis d'accord, les lightmap laissent la possibilit d'utiliser diffrentes mthodes :
- depuis la cration dynamique de la texture aux shaders
- utilisation du multitexturing ou rendu en plusieurs passes
- peut-etre la possibilit d'utiliser l'accumulation buffer   ::?: :

----------


## bafman

mais les lightmap ne sont pas dynamique... (d'ou leur nom : light comme lumiere, map comme ... map ou texture quoi ) 
En fait le probleme de la lumiere c'est qu'on est oblig de faire plusieurs passes quelque soit la methode utilise (sauf les lumieres openGL de base   ::twisted::  )

----------


## shenron666

bah pour moi lightmap voulant bien dire "mapping de lumire" en gros je ne vois pas en quoi c'est ou ce n'est pas dynamique.
Il existe les "static lightmap" et les "dynamic lightmap".
Quake utilise les 2 depuis la premire version, les ombres tant des "static lightmap" et les lumires gnres par les tirs, les explosions etc sont des "dynamic lightmap".
Il va sans dire que gnrer dynamiquement une texture pour du lightmapping est consommateur de resources, c'est pourquoi il ne faut pas viser trop haut dans la rsolution de la texture gnre sous peine d'une chute des performances.
Une petite dmo avec le code source ici pour ceux qui veulent : http://www.3ddrome.com/articles/dynamiclightmaps.php

PS: Je pense qu'utiliser un fragment program ou les shaders est la seule mthode qui permette de faire le rendu d'une lightmap en une seule passe, sinon au moins 2 mme avec le multi-texturing

----------


## bafman

non non, l'origine du terme lightmap vient bien du fait que dans quake 1, les lumiere etait stock dans des texture... pour plus d'info, lire le livre "programmation graphique c et assembleur" de michael abrash qui a travaill sur quake 1 avec carmack, c'est tres interessant.

sinon mme avec un fragment program, on est oblig d'effectu une passe par lumiere (ou alors il faut faire un fragment program qui prend en compte l'ensemble des lumiere du moteur... vraiment pas optimis comme technique etant donn que ca oblige a calculer la luminosit pour des polygone qui ne sont pas forcement atteint par la lumiere...

----------


## shenron666

Oki, thx pour l'info, je regarderai a  l'occasion

Sinon pour l fragment program, je pensais bien sr  1 passe par lumire
sinon effectuer un "prcalcul" pour dterminer quelles lumires affectent le polygone ne serait pas possible ?
bon, peut-etre un peu trop complexe pour ce qu'on en tire comme bnfice   ::?:

----------


## djo.mos

Merci pour les infos.

J'ai dja commenc la dessus, et j'ai implement un lighting (dynamique) sur une seule passe ! j'explique
- pour chaque polygone, je teste s'il est visible ou non
- si oui, je remets son light map  0
- je parcoure les lumires de la scnes,qui vont ajouter leur contribution  la texture
- sur l'unit de texturing 0 j'applique le diffuse map, et le lightmap sur l'unit 1

j'ai test divers tailles de light maps, je crois que 16x16 est un bon compromis entre qualit et vitesse : j'atteins les 40 fps avec 25 polygones visibles et 9 lumires, et la gneration des lightmaps n'est pas du tout optimis. est  ce potable ?

----------


## shenron666

40 fps m'a l'air potable avec 9 lumires, tu pourrais nous mettre un petit screen  l'ocaz histoire de voir ce que donne le rendu ?

En tout cas ton approche est intressante, une petite amlioration  apporter ventuellement :
si j'ai bien compris tu initialises ton lightmap en le remplisant de 0, tu devrais plutot le remplir avec la valeur de la couleur ambiante.

----------


## djo.mos

Pour les screens, je vais essayer, mais je n'ai pas de site ou d'espace sur le web pour y mettre les images.
Mais les resultats sont trs convaincantes, un peu sombre mais ralistes.

 Pour ta rq sur la lumire ambiante, j'explique :
je considre que chaque lumire a une composante diffuse LDC et une ambiante LAC, qui sont des vecteurs (r, g, b) de 0  1, et chaque polygone  une couleur diffuse PDC, et la contribution d'une lumire L se calcule ainsi :
 LC = LAC + (X * LDC * PDC)

X est une valeur qui dpend de la distance qui spare le pixel de la lumire, et de l'inclinison de cette dernire.

 Et donc, je dois initialiser le lightmap  0 car chaque lumire a une composante ambiante, qui plus est dynamique !

 Autre chose, je pense que 40 fps pour 25 polygones, c'est pas tellement prometteur. (si je prcalcule les lightmaps, le fps saute  240)

----------


## bafman

quelques petites reflexions sur ta technique :
- tu recalcule la lightmap a chaque passe et tu doit donc l'envoyer  la carte graphique, avec quelques polygone ca va bien, mais envoyer X mille textures a chaque frame la ca ne passera plus...
- tu ne peut plus faire d'addition de lumieres, hors c'est un des gros atout de l'eclairage en plusieurs passe car il permet d'implementer facilement du HDR par la suite (avec un float buffer on peut depasser 1 dans chaque composante, ce qui permet de calculer du HDR avec blooming + tone mapping facilement...)
- tu ne peut pas implementer de bump mapping avec cette methode

sinon le cot sombre vient du fait que tu multiplie la lumiere par la texture diffuse, c'est tout a fait normal, ca marche comme ca avec le lightmapping.

d'ailleurs cette methode est tres exactement la methode utilise par carmack  dans quake 1 pour gerer ses lumieres dynamiques en mode software   ::wink::

----------


## djo.mos

Ok, je suis d'accord.
Sinon, qu'elle est la meilleure mthode ?

----------


## bafman

a priori,  l'heure actuelle, la meilleure methode semble etre celle de Doom 3 (carmack inside   ::wink::  ), qui consiste a determin dans une premiere passe quelle sont les faces et les lumieres visibles (Portal + bsp + PVS dans Doom 3), ensuite
[/code]
on affiche l'ensemble des faces visible dans le Zbuffer (ecriture dans le color buffer desactiv pour plus de vitesse)
activation du blending additif
pour chaque lumiere visible
    pour chaque face visible
        si la face est atteinte par la lumiere (simple a calculer pour les lumieres spheriques)
            on affiche la face (eclairage calculer par un fragment program)
        fsi
    fpour
fpour


```

```

----------


## djo.mos

a devient intressant.
Une question cependant : T'as dit :



> eclairage calculer par un fragment program


Tu en est sur ? car j'ai jou  DOOM III sur ma Radeon 9200, et jusqu' maintenat, j'etais sur que les ATI d'avant 9500 ne graient pas le fragment shader ou programs !

----------


## bafman

en fait selon la carte graphique l'eclairage n'est pas calcul avec la mme methode : sur GeForce2,3,4 c'est du DOT 3  + combiner NV, sur radeon < 9500 c'est pareil mais avec l'equivalent des combiner NV chez ATI, et sur le reste des cartes, c'est du fragment program

----------


## djo.mos

Donc y'a pas moyen d'echapper aux extensions spcifiques !
 juste par curiosit, et come je suis sur une Radeon 9200, c'est quoi l'quivalent des combiners NV sur les ATI ?

----------


## shenron666

> Donc y'a pas moyen d'echapper aux extensions spcifiques !


Je ne suis pas d'accord, c'est "juste" une volont de Carmack de vouloir optimiser  fond pour toutes les cartes possibles.
Il existe un CodePath plus lent utilisant uniquement le "multi-texturing" et le "multipass rendering", utiliser les extensions spcifiques est purement de l'optimisation.
Qu'en est-il des cartes autres que ATI ou NVIDIA qui n'ont pas accs aux extensions ? elles utilisent les extensions "officielles"

----------


## djo.mos

Oui mais produire du code compatible avec toutes les cartes mais qui est super lent ne va pas arranger les choses, non ? dans mon cas, c'est clair qu'il faut optimiser  fond mon code car les performances sont trs basses, surtout qu'on est dans le cas d'un moteur 2D pas assez gourmand.

 inon, s'il y' a un autre alternative pour l'clairage, je suis toujours preneur !

----------


## bafman

et attention, selon les code path de Doom 3, il y a des effets qui ne sont pas activable, par exemple l'effet de heat haze n'est accessible que pour le code path ARB2 (vertex + fragment program ARB), et le code path ARB (celui de base prevu pour GeForce 2 au depart) ne permet pas d'avoir l'eclairage speculaire... par contre l'utilisation des extention lui permet de faire d'autres effets qui n'aurait pas t possible en mode ARB (par exemple l'eclairage speculaire sur GeForce 4 realis grace au combiner...)

bref les extention c'est bien pour faire pleins d'effets de fou a la sortie de la carte mais apres c'est preferable d'utiliser du EXT ou de l'ARB...

----------


## djo.mos

Bonjour, et merci bafman : tes posts sont un vrai rgal.
Pour l'eclairage, j'ai pu bricoler les composantes diffuses et ambiantes, mais en ce qui concerne la composante spculaire, je suis un peu dans  l'obscurit. quelqu'un aurait des tuyaux ?

----------


## Heptaeon

C'est vrai qu'on sent que bafman a du deja coder un moteur 3D. Bafman on peu avoir un screenshot de ton moteur lol ?

----------


## bafman

pour l'eclairage speculaire le principe est simple : c'est exactement la mme chose que le bump Dot 3 en fait.

en gros l'eclairage speculaire consiste a prendre le demi angle entre le vecteur pixel->vue et pixel->lumiere... facile a dire mais comment le faire ? tout simplement en placant la lumiere (la cube map de normalisation en fait) a mi chemin entre la position de la camera et la lumiere relle... et voila on a notre demi angle, il ne reste plus qu'a effectuer le mme calcule que pour le Bump et a l'ajouter (blending additif ou addition dans un fragment program)  la scene... Mais le probleme c'est qu'on a du coup une lumiere speculaire tres (trop) forte, il faut la mettre a une puissance, et c'est justement la le probleme, car pour le mettre a une puissance il n'existe pas 36 solution : fragment program ou combiner...

en fait il existe bien une solution qui consiste a effectuer 2 fois le calcule de speculaire et a multiplier le resultat, mais ca double le calcule et ne mette le resultat qu'a la puissance 2 alors que le speculaire est generalement a une puissance de 8 ou de 16...

enfin bref, pour faire simple, le speculaire c'est :
 - trouver le demi angle en placant la cube map de normalisation entre la position de la camera et de la lumiere
 - effectuer le mme calcule que pour le bump avec le demi angle
 - mettre le resultat du calcule a une puissance donne
 - ajouter le tout a la scene...

----------


## deverdeb

> C'est vrai qu'on sent que bafman a du deja coder un moteur 3D. Bafman on peu avoir un screenshot de ton moteur lol ?


Moi je l'ai dj vu  ::D: 

Sinon, ce cher Bafman nous offre mme les sources d'un de ces premiers essais de moteur sur son site : http://michel.deverdelhan.free.fr/  (il faut aller voir poutrage de loutres   ::lol::  )

----------


## sebh

Hey bonjour Les gens!!!!
(pour info je suis le deuxime codeur qui travalle avec Bafman)

Trs interessant se topic!!!! Sa m'a donner envie de post(sa fesait trop longtemp).

bientot il y aura des screens de notre dernier moteur sur mon site ki devrait arriv dans 2~3semaine(pr info, j'ai mon cran a pt donc jpeu pas le continu pour l'instant).

Notre dernier moteur est assez exitant, surtout quand on pense a ce qu'on peut faire avec!!!!

Petit complment sur le spculaire : Bafman a dcrit ici la mthode de Blinn qui utilise le halfAngle qui est beaucoup plus facil pour faire du spculaire sur des carte ne supportant pas les FP. Sinon, il existe le mthode Phong qui utilise le vecteur reflchit pour le calul du DOT3 avant le mise a la puissance.

Voili voilou!

----------


## Heptaeon

Lol les louttres sont des annimaux protg ici  ::D: .

Sinon pour la question de bases, Un bon moteur doit pouvoir utiliser le bon algo au bon moment ^^. Comme tout bon programme en faite ^^.

Vouloir trouver l'unique Algo universel pour tout les cas de scene 3D, je pense, pour ma part, que c'est une utopie ^^.

----------


## bafman

exactement, surtout que tout algo a besoin de reposer sur une structure de donne, et que la structure de donne ultime n'existe pas   ::wink::

----------


## Heptaeon

VRML ??? Lol bon j'arrete mes blagues foireuses 
*Est mchant avec le VRML*

----------


## djo.mos

Bonjout tout le monde et dsol pour ce retard.

Ces derniers jours, j'ai pu cravacher comme un malade sur mon moteur (2D pour l'instant) et j'ai fait d'normes avances, je prvois la premire version comltement fonctionnlle dans 2, 3 semaines.
 Et pour y arriver, j'ai du procder en marche arrire : d j'ai dfini mes classes et leurs intrfaces, j'ai tout fix quoi, et ensuite, j'ai commenc  coder la chose, et la ca a march.

 Je confirme, c'est trs difficile de developper un moteur gneraliste, qui rsout le conflit isralo-palstinien, le conflit irakien, les ouragons, les tremblements de terre et la famine ... si c'est pas pour un jeu, il faut poser ce qu'on va faire et ce qu'on ne va pas faire dans le moteur pour pouvoir le terminer.

----------


## djo.mos

Et pour rsumer ce qu'on a dit sur l'clairage, je dirais que le mieux serait d'utiliser des lightmaps, qui sont calculs par des vertex et fragment shaders en plusieures passes. C'est bien a ? dommage que j'ai pas de fragment shader sur ma carte, je devrais le faire sur le CPU.

----------


## deverdeb

> Et pour y arriver, j'ai du procder en marche arrire : d j'ai dfini mes classes et leurs intrfaces, j'ai tout fix quoi, et ensuite, j'ai commenc  coder la chose, et la ca a march.


Heu... On ne doit pas avoir la mme vision du dveloppement   ::?:  
Pour moi, tu as plutt procd en "marche avant".
Dfinir les classes et interfaces avec de commencer  coder, c'est pour moi une obligation (au moins pour les classes principales).

----------


## shenron666

Je pense qu'il voulait dire qu'il avait du revenir en arrire pour dfinir ses classes et interfaces, enfin je pense  ::roll::

----------


## bafman

tu peut tres bien faire de l'eclairage par pixel sans fragment program sur le GPU, c'est d'ailleur pour ca qu'a t invent l'extension  DOT3... par contre tu sera plus limit dans les possibilit de cre de l'eclairage speculaire et autre mais ce n'est pas non plus impossible... en utilisant quelques feintes de sioux (attenuation + "cube map de normales" dans une seule texture 3D ou autre) on peut atteindre des resultats impressionnant mme avec du vieux materiel genre GF4   ::wink::

----------


## sebh

En effet, notre moteur permet de rendre des lumire omni directionnel avec diffrent rayon sur l'axe X,Y ou Z et orientable ; des spot light avec angle d'ouverture rglable et des cube light. Tout ces lumire on un couleur et sont correctement attnuer.

Sur GF4, j'utilise les combiner et je rend tout ces lumire en 2passes par lumire : 1 pour la composante diffuse et une autre pour la composante missive et le tout bumpMapp grace au DOT3.

La texture3D est une trs bonne ide d'optimisation pour l'attnuation(1 texture au lieu de 2) et permet de simplifier les calcul de lumire oval grace au matrice. Par contre l'optimisation que j'ai utilis qui consiste a mettre les normal dans la composante RGB de la texture3D a aussi certaine limite : problme de la normal au centre indfini  :8O:   (mais il faut que la lumire se confond presque avec la surface et qu'elle soit gantre pour que le problme se voit) et  cause de problme de prcision(et une  petit feinte de ma part pour rendre le cubelight et spotlight speculaire en 1 pass) dans le vertex_program, le spculaire semble tir vers la camra.
Pas pour les omnilight qui n'utilise pas cette feinte.

PS : bientot des screen  ::!::

----------


## bafman

sebh ou comment parler pour que personne ne nous comprennent   ::lol::

----------


## djo.mos

Binjour.
Ce que je voulais dire par marcher arrire, c'est que j'avais  fix les prototypes des fonctions finales que va utiliser le client final, pour ce faire, j'ai fais le brouillon d'un programme final qui utilise le moteur.
 Ce n'est qu' la fin que j'ai commenc  implementer ces interfaces.

 Je ne sais pas pour vous, mais d'habitude, je ne fais pas a, je commence  rsoudre des petits problmes, sans avoir une vision d'ensemble sur le projet, et je peaufine l'interface finale au fur et  mesur, mais ca c'est aver catastrophique dans un grand projet.

----------


## bafman

ha... donc en fait c'est avant que tu marchais  l'envers...

generalement dans tout projet autre que de la bidouille on commence toujours par fixer l'interface (au sens programmation pas GUI   ::wink::  ), et une fois qu'on a des beau diagramme avec juste des signature de methode (on parle mme parfois juste de service pour bien montrer qu'on ne sait pas ce qu'il y a derniere), on implemente. ainsi on peut utiliser sans probleme dans du code des methode qui n'on pas encore t implemente...

----------


## djo.mos

Oui, et je l'ai appris  la dure.
Sinon, pour revenir  l'clairage, tu as parl d'utiliser le DOT3, mais il faut comme mme calculer la texture d'clairage  chaque frame pour avoir un clairage dynamique, et sans fragment shader, je ne vois pas comment calculer cette (maudite) texture sur le GPU pour plus de performances.

----------


## bafman

qu'est ce que tu appel texture d'eclairage ? la texture d'attenuation ? si c'est ca, une bete texture 3D en forme de sphere fait tres bien l'affaire...

----------


## djo.mos

Je ne suis pas sur de bien comprendre.
Si ce n'est pas trop demander, pourrais tu eclaircir un peu STP ? un lien vers un tuoriel traitant de ce sujet peut tre ...

----------


## bafman

en gros pour ton eclairage tu a besoin de pouvoir dire
ce pixel la est eclair, celui la l'est moins (car plus loins de la lumiere) et celui la est completement noir car trop loins de la lumiere. c'est cela l'attenuation, plus un pixel est loins de la lumiere, moins il est eclair, et pour cela on utilise une texture 3D en niveau de gris dont le centre vaut 1 et les bordure vallent 0, ce qui permet de dire "plus je suis proche du centre de la lumiere, plus je suis eclair".

----------


## djo.mos

oui, merci, je le sais a, c'est une sorte de lightmap, mais je n'arrive pas   comprendre la notion d'une texture 3D ... comment la stocker dans un fichier par exemple, sous forme de plusieures couches ?

----------


## bafman

ca c'est un autre probleme   ::lol::  
on peut en effet la stocker en plusieurs textures, mais il faut que celles ci soit toutes de la mme taille...
en fait la texture 3D est plus un outils qu'on utilise en interne d'un moteur et dont les artiste n'on pas  se preoccuper. En effet generalement les textures 3D sont cre directement dans le programme avec une petite fonction qui va bien et non pas stocker dans des fichier.

a part quelques demo de Nvidia, je n'ai jamais vu de moteur 3D qui chargeait une texture 3D depuis des fichier, tout simplement parcequ'il n'existe pas de format officiel pour les stocker et parcequ'il n'existe pas d'outils pour les cre  8) bref les Texture 3D c'est encore un truc de developpeurs   ::lol::

----------


## djo.mos

OK, toujours merci bafman.
Sinon, comment faire en OpenGL pour mettre  pied cette solution ? je veux dire calculer l'attenuation que subit chaque face ? un bout de code serait le bien venu !

----------


## bafman

un bout de code est difficile a placer la mais en gros il suffit de calculer des coordonne de textures relative au centre de la lumiere. ca donne quelque chose du genre

coordonneTexture = vertexPosition - centreLumiere

et voila tu a tes coordonne de texture pour la texture 3D d'attenuation... c'est vraiment tout bte en fait   ::wink::  
bien entendu il faut moduler le tout par le rayon de la lumiere mais le principe de base est la

----------


## sebh

Voici mon site pour ceux qui veulent voir notre dernier moteur 3D (comme promit).


PS : j'ai remarqu qu'il restait des fautes d'orthographe... Elle seront bientt corrig.

----------


## shenron666

> Voici mon site pour ceux qui veulent voir notre dernier moteur 3D.


O a o a    ::?:

----------


## bafman

mhouahahahahahaha mais qu'il est fort.... bon je vais peut etre lui signaler quand mme   ::lol::

----------


## bafman

bon aller comme je suis gentil je donne l'adresse avant qu'il ne se rende compte de son erreure   ::lol::  
http://sebastien.hillaire.free.fr/
 ::lol::

----------


## shenron666

Merci Bafman   ::wink::  

Note: Ca m'est dj arriv d'envoyer un mail en disant qu'il y a une pice jointe et de l'oublier, l'erreur est humaine  ::roll::

----------


## sebh

::boulet::  
H oui, le truc de la piece jointe sa  m'tait dj arriv aussi...

Enfin l'erreur est rparer.  ::):

----------


## shenron666

Merci et bravo pour ce moteur qui semble dj bien avanc
Manque quelques models sur les screens, vivement qu'ils soient implments  ::wink::  

Sinon, une gestion des extrieurs prvue ?
J'aime bien les grandes tendues moi  ::roll::

----------


## bafman

pour les exterieurs c'est clairement non... on a voulu faire un moteur purement interieur et pour les models c'est en cours de realisation, on peut d'ailleurs en voir... les caisses (oui bon on a aucun talent de modeleurs, des cubes c'est deja pas mal non et puis passer d'un cube a un autre model ne pose pas de problemes...)

----------


## shenron666

Snif pour les extrieurs, en tout cas je trouve que le moteur donne dj d'excellents rsultats concernant les intrieurs

pour les models les caisses sont destructibles ? nan jdconne, mais par contre  ce sujet vous tes sur quel format ?
mme format pour les models statiques (caisses, bidons) et anims (personnage, vlo, monstre  34 pattes 17 bras 14 yeux) ?

ps: me demande pas ce que foutrait un vlo ici j'avais pas d'autre ide en tte

----------


## bafman

pour les models statiques on utilise des betes .obj et pour les dynamiques (pas encore fait) des MD2

----------


## sebh

Les caisse ne sont pas destructible mais elle sont dyanmique : gr avec le moteur physique novodex. On peut les lanc et ya de jolie collision.  ::wink::  

sa donne de belle ombre qui bouge dans tout les sens.

----------


## hansaplast

passionnat votre topic ^^
meme pour un sous newb's ^^

----------


## Edouard Kaiser

Modjo, tu comptes rendre public tes sources ? J'avoue que je suis trs curieux de voir la faon dont les gens structurent leur programmation surtout concernant ce sujet  ::):

----------


## BadFox

oui, moi aussi, tant sur un projet similaire.
Modjo, tu pourras mettre un screenshot ? je suis curieux de voir au moins un rendu.

clin d'oeil Zoso_ (entre EPSIens)

----------


## djo.mos

Bonjour, I'm back again !
Merci de vous interesser toujours  ce topic.

 La rponse  votre question est OUI, je compte bien rendre les sources publiques, je compte mme rendre le projet public, c'est justement pour a que j'ai voulu peaufiner une "belle" architecture ! Mon but etait de crer une sorte de base, de socle et de tout mettre au net, comme ca tout le monde peut y apporter sa contribution. C'etait mon but, mais maintenant, je galre comme un malade dans mes tudes, on nous donne normement de travail et j'ai plus le temps de travailler sur mes 2 moteurs (toodee et Quad3D). Esprons que a va s'amliorer aprs les exams car j'ai pas pu toucher   ce travail depuis plus d'un mois.

En tout cas, je vous tiens au courant !

----------


## Edouard Kaiser

Niquel, merci beaucoup  :;):

----------


## djo.mos

Bonjour.
De retour aprs une longue abscence.
Je vois que le topic vient d'etre dplac dans un nouveau forum.
En definitive, je pense que c'est plus adapt.

----------


## djo.mos

Bonjour tout le monde.

Pendant ce long abscence, j'ai pas mal boss sur mon moteur, plus exactement sur des questions architecturales, et voici la synthse princpale de mes travaux :
* Faire sortir tout ce qui est artistique du moteur et l'exposer aux artistes via un langage de script.*

Ca m'a caus pas mal d'ennuies : Je me suis trouv dans l'obligation de crer une bibliothque pour grer les scripts, et ca n'a pas t facile. Mais les resultats sont concluants : Sans la moindre ligne de programmation, on peut crer une myriade d'effets epoustouflants ! J'en suis vraiment fier.

Pour tre tout a fait honnte, j'avoue que je me suis fortement inspir des shaders de Quake III pour crer mes propres shaders, Merci Carmack !

Qu'en pensez vous ?

----------


## Laurent Gomila

Ca a l'air trs sympa, un petit exemple peut-tre ?  ::):

----------


## djo.mos

D'accord. Voici deux exemples : un mesh et un shader :
exemple 1:


```

```

On enregistre ce script dans un fichier .mesh.
Le mesh est subdivis en elements, chaque element a son propre gizmo, c'est  dire qu'on peut le positionner et le redimensionner et le tourner librement. de plus, chaque element peut avoir son propre shader.

Maintenenat, voici un shader :


```

```

Le principe des shaders est le suivant : on applique plusieures passes sur l'objet  dessiner, autant de passes que de sections _pass_ dans le shader. les paramtres sont, pour la plupart controlables via des fonctions comme le sin, le cos ...

Ceci est loin d'tre une explication complte, je le sais, et c'est pourquoi je suis en train de dvelopper une rference pour les shaders et les mesh, pour pouvoir les publier plus tard, quand j'arriverais enfin  :
1- arriver  une version de base de toodee qui marche et qui trace les grands lignes  suivre
2- arriver  crer un site fonctionnel pour pouvoir partager mon experience avec tout le monde, et avoir de l'aide, car franchement, je suis en train de couler sous la quantit immense de travail ncessaire !

En attendant, je suis ouvert  toutes vos suggestions, alors n'hsitez pas  en donner !

----------


## bigquick

Ca  l'air vraiment sympa !

Mais juste une question qui me vient  l'esprit, pourquoi ne pas avoir utilis du XML pour formatter ton langage de script (en tout cas pour la partie mesh / shaders) ? Ca serait plus "ouvert" vers l'exterieur, par exemple si tu veux que des personnes contribuent en crivant des scripts d'export, ou des tools pour ton moteur.

Mais ce n'est qu'une suggestion comme a  :;):  En tout cas je suis vraiment impressionn par la qualit de ton travail, toutes mes flicitation, rien que pour avoir eu le courage de pousser ton moteur jusque l malgr tout ce que a a du demander !

----------


## djo.mos

Merci beaucoup. C'est vrai que je galre comme un fou et ce n'est pas du tout evident de trouver le temps pour mon sport favorie : la programmation.

Concernant la partie concernant XML, j'y avais pens au dbut, et je comptais l'utiliser, mais a m'a eu l'air trop lourd et trop gneraliste pour mes besoins, de plus, j'essai de limiter les dependances de mon moteur  l'exterieur au strict minimum : si je peux raliser un truc, et qu'il y'a une biblio qui ralise le mme truc, je prefre la raliser moi mme. C'est un peu bte, mais ca aide bcp  apprendre.

De plus, le BOSL (le langage de script que j'ai dvelopp) n'est pas si difficile que a, et on peut facilement l'apprendre et l'utiliser.

----------


## djo.mos

Et tant que j'y pense, il est tout  fait possible de rendre le moteur indpendant du langage de scripting, en passant comme paramtre supplementaire  toute fonction qui est charg de charger un fichier un objet loader en plus du nom du script ! ce serait un peu merdique  coder mais a reste possible !

----------


## Matthieu Brucher

> Merci beaucoup. C'est vrai que je galre comme un fou et ce n'est pas du tout evident de trouver le temps pour mon sport favorie : la programmation.
> 
> Concernant la partie concernant XML, j'y avais pens au dbut, et je comptais l'utiliser, mais a m'a eu l'air trop lourd et trop gneraliste pour mes besoins, de plus, j'essai de limiter les dependances de mon moteur  l'exterieur au strict minimum : si je peux raliser un truc, et qu'il y'a une biblio qui ralise le mme truc, je prefre la raliser moi mme. C'est un peu bte, mais ca aide bcp  apprendre.
> 
> De plus, le BOSL (le langage de script que j'ai dvelopp) n'est pas si difficile que a, et on peut facilement l'apprendre et l'utiliser.


Rinventer la roue, c'est super gnial  :;): 

Le plus simple, template avec un paramtre par dfaut contenant le loader DOSL ou XML ?

----------


## djo.mos

Mauvais nouvelle pour les C++iens ! Le projet est entirement dvelopp sur Delphi ! Il s'agit d'une DLL qui exporte des interfaces, donc, normalement, ca devrait tre possible de l'utiliser  partir du C++ par exemple, mais je n'en suis pas sur.

Sinon, une premire version completement fonctionnele de toodee est enfin disponible, et je suis en train d'effectuer des tests la dessus et de la peaufiner.

Il me reste de trouver un hbergeur gratuit et de raliser un site. Mais le plus difficile est dja fait !

----------


## h0bby1

salu modjo tu m'as l'air de bien te prendre la tete =) en gros pour les eclairage on peut dire qu'il ya deux facon principale de les calculer soit calculer les couleur 
1. soit calculer une couleur pour chaque polygone ou vertex en utilisant sa normale et en faisant des dot product avec le vecteur lumiere/vertex et la normale et en prennant en compte les parametre des materiaux le dot product a la particularit de donner zero en cas de face perpendiculaire et 1 en cas de vecteur normalis opos ce qui donne que les face/vertex ayant une normale face a la lumiere auront la couleur diffuse du material + ambient et ceux qui ont une normale perpendiculaire auront uniquement la couleur ambient. le speculaire sert ensuite a faire un effet de brillance la valeur du specular est plus forte qd le vecteur reflechi lumiere/eye est proche de la normale et le parametre SHININESS de materiaux sert a calculer l'exposant de cette valeur et ca permet d'avoir une tache de lumiere plus ou moins petite a certain endroit
2. soit on peu aussi utiliser une texture pour avoir les pixel qui sont entre les vertex soient en utilisant l'envmap ou autre 

le tout etant d'avoir une variation de la couleur des pixel selon l'orientation des faces par raport a la/les lumiere

pour l'architecture general je pense le mieux est d'abbor d'avoir une librairie de math vecteur/matrice assez solide etant donn que la plupart des effets ne sont en fait que des math et physics vectoriels pour calculer des couleur ou uv que ce soit pour de la refraction/reflection/lumiere et des bonnes classes de vecteur/uv qu'on peut utiliser pour avoir des uv, ou des couleur en fonction d'autre vecteur c'est ce qu'il faut pour reussir la plupart des effet et avoir des rendu 'realistes'  ::):  

et au fait les dll ne ralentisse pas l'execution le code des dll etant charg dans l'espace du process qd l'exe est charg ca peut ralentir un poil le lancement parce qu'il faut charger les dll en memoire et resoudre les symbole de l'exe principale mais une fois ceci fait l'execution n'est pas plus lente sauf peut etre si on prend en compte le cache du cpu qui ne doit pas etre optimis bien parcque les differentes fonction on plus de chances d'etre eloignes en memoire =)

----------


## h0bby1

j'ajouterai aussi a cela que ce qui bride bien souvent la vitesse du rendu est effectivement la vitesse des bus pci/agp et pour avoir les meilleur performance il vaut mieux eviter un maxium les transfer entre la ram et la carte graphique et aligner un maximum les donne envoye et utiliser de preference des vertex buffer pour stocker les vertex dans la carte graphique une seule fois et sinon utiliser des pointer align sur 32/64bit pour transfer des donne via glVertex*v(); ou utiliser des array et drawelement ca diminue le nombre de requete envoye a la carte et augmente donc la bande passante disponible pour les vertex et autre donne

----------


## djo.mos

Merci les gars de vous interresser toujours  ce topic malgr son age et la frequence mdiocre de mes rponses.

Pour ce qui est des transferts RAM<-->GPU, notamment pour la gometrie, je me suis en effet pench ladessus, et j'ai remplac les pauvres glVertex3f par des glVertexPointer etc..., mais sans utiliser les VBO : Je ne sais pas pourquoi, mais sur ma carte ATI Radeon 9200 les VBO font chuter les performances d'une faon drastique, allez donc comprendre pourquoi !

Pour ce qui est de l'clairage, je l'ai enfin implant dans mon moteur. Bon, je vais essayer d'en expliquer le principe. Mais avant a, je vais revenir un peu sur les meshes et les shaders dans toodee.

Un mesh est une classe qui permet de stocker la gometrie des objets.

Les shaders servent  controler la manire dont une surface est remplie.

un objet dans toodee est un couple (mesh, shader) complt par un gizmo qui sert  controler sa position, sa rotation, etc ...

 part les mesh, tout est dynamique dans toodee, par exemple une couleur dans un shader peut varier en sinus au cours du temps, de mme, la position x par exemple peut varier selon une autre fonction, bref, presque tout est dynamique.

J'ai trouv que la manire la plus simple et legante d'integrer l'clairage dans mon moteur est d'utiliser la puissance des meshs et des shaders.

Une lumire est don similaire  un objet, sauf pour ce qui est de l'utilisation.

Le rendu d'une image se droule comme ceci :
- on part d'une scne vide dont la couleur est la lumire ambiante (Ra, Ga, Ba)

- on dessine les lumires (dessiner le mesh en le remplissant avec son shader associ) avec un blend activ GL_ONE, GL_ONE pour additionner les contributions des lumires.

- effectuer un glReadPixels vers une texture LMAP (c'est juste un nom, pas un terme technique ;-) )

- commencer une nouvelle scene avec une couleur de fond.

- dessiner les objets(comme les lights)

- appliquer la texture LMAP sur la nouvelle scne avec un blend GL_ZERO, GL_SRC_COLOR

- c'est tout !


Et les rsultats sont tout simplement magnifiques ! poustouflantes ! 

Bon,  trve de vanit.

C'est vrai que ca peut avoir l'air leger et non raliste, vu que l'intensit ne depend pas de al gomtrie, mais c'est un moteur 2D ! une simple texture en niveaux de gris multipli par une couleur dynamique donne des rsultats trs probantes ! Dommage que je ne peux pas vous montrer des screenshots ! (Si quelqu'un peut m'aider ...) !
De plus, c'est trs performant, avec une scne de 12000 faces et plus de 100 lumires (oui, c'est bien un cent), je suis dans les 180fps, et c'est du vrai clairage dynamique !

des suggestions ? des remarques ?

----------


## fearyourself

> Et les rsultats sont tout simplement magnifiques ! poustouflantes ! 
> 
> Bon,  trve de vanit.
> 
> C'est vrai que ca peut avoir l'air leger et non raliste, vu que l'intensit ne depend pas de al gomtrie, mais c'est un moteur 2D ! une simple texture en niveaux de gris multipli par une couleur dynamique donne des rsultats trs probantes ! Dommage que je ne peux pas vous montrer des screenshots ! (Si quelqu'un peut m'aider ...) !
> De plus, c'est trs performant, avec une scne de 12000 faces et plus de 100 lumires (oui, c'est bien un cent), je suis dans les 180fps, et c'est du vrai clairage dynamique !
> 
> des suggestions ? des remarques ?


Quelques screenshots seraient bien, je vois que tu dis que tu ne peux pas, comment cela se fait? N'as-tu pas un endroit sur le net pour les crer? Il y forcment quelque part o tu peux les mettre, mme un hbergeur gratuit...

Jc

----------


## djo.mos

Oups ! quel lapsus, je corrige :
 JE NE PEUX PAS, c'est pas je ne VEUX pas ! 

Dsol!

----------


## fearyourself

> Oups ! quel lapsus, je corrige :
>  JE NE PEUX PAS, c'est pas je ne VEUX pas ! 
> 
> Dsol!


Moi j'ai lu *peux*, mais alors pour quelle raison? Parce que tu n'as nul part o les mettre?

----------


## djo.mos

Exactement.

----------


## fearyourself

> Exactement.


http://weblogs.about.com/gi/dynamic/...ageshack.us%2F

Mets ta photo, click host it! et ils te donneront un lien... Je ne sais pas combien de temps cela restera l mais ce sera dj a...

Jc

----------


## djo.mos

Merci. Je vais essayer la prochaine fois. Et si a marche ... ce serait vraiment cool !

PS : Je me connecte pas depuis mon PC, en fait il s'agit d'un PC  ma fac, donc, ca peut prendre du temps ...

----------


## Laurent Gomila

> http://weblogs.about.com/gi/dynamic/offsite.htm?zi=1/XJ&sdn=weblogs&zu=http%3A%2F%2Fwww.imageshack.us%2F


Le mme en plus direct : http://imageshack.us/

Et sinon, tu n'as pas une petite dmo ?  ::wink::

----------


## djo.mos

Enfin,un premier shot :


[/url]

----------


## djo.mos

Bon,c'est pas trs clair,mais a presente quelque uns des capabilits de toodee : la console au dessus est un plugin.

En bas  droite, un cran radar qui est possible grace au rendu vers une texture.

Enfin, Il y'a l'eclairage dynamique et les animations des objets, mais il faut une dmo pour les voir !

----------


## fearyourself

Ahhh, maintenant on voit de quoi tu parles =>

Faudrait peut-tre rendre le jeu plus clair comme tu le dis mais cela fait aussi un look nocturne...

Pas mal pas mal!

Jc

----------


## djo.mos

Voici une autre image plus claire mais aussi plus ancienne.

----------


## loka

vraiment pas mal du tout, tu ne pourrais pas fournir la petite demo pour qu'on puisse mieux l'apprecier ?
Si tu le souhaites je peux l'heberger pour que les autres puissent la telecherger si tu ne peux pas  :;):

----------


## djo.mos

Ce serait vraiment tres gentil de ta part.

Des que je realise une demo, je te contacte par MP, ca te va ?

----------


## loka

a me va  ::):

----------


## bafman

ha oui... effectivement ca rend super bien... beau boulot   ::wink::

----------


## djo.mos

Merci loka et bafman.
Voici un autre shot :


Merci tout le monde de vous interresser toujours  ce topic, namoins, il faut noter que l'on s'est loign du sujet, et ce topic est devenu une sorte de page d'actualit : je viens de faire ceci, j'ai ajout cela, etc... Don, n'abusons pas de ce forum et recentrons la discussion.

(Avant de passer  autre chose, je vous demande votre clmence pour juger les shots, je ne suis pas un artiste ;-) !

Quand je me suis lanc dans cette tache (titanesque), tout le monde n'arretait pas de me dire : Tu n'y arriveras jamais, et mme si tu y arrives, ca ne pourra pas concurrencer des produits dja existants telque OGRE etc... : Je leurs reponds que ce n'est pas mon but, mon etait de :
1- mettre au point une architecture extensible, intuitive et puissante.
2- approfondir mes connaissance dans le domaine de 3D, notamment en OpenGL.

J'ai pas mal boss la dessus, et sur quelques points, je crois que j'ai pleinement russi, surtout sur des points architectureaux, quand  ce qui concerne l'API 3D (OpenGL), je n'y ai pas consacr beaucoup d'effort, ca peut venir ensuite.

Je vais maintenant presenter en gros l'architecture de toodee (mon moteur).

Les objets de base sont :
- Mesh : stocke la gometrie d'un objet.
- Shader : Dfinit la faon dont on remplit une surface.
- PrimaryController : un objet qui permet de faire des translations, rotations et des scales via une interface intuitive (mthode translate, rotate...)
- SecondaryController : un objet qui permet de faire des translations, rotations et des scales mais pas directement, je veux dire pas via des mthodes, mais via des controlleurs comme le SinController. Pour expliquer, il s'agit d'une liste de Point3Controller, ce dernier est compose de 3 FloatController : X, Y, Z. Il y'a quelques FloatControllers prdfinis comme le Sin, Cos, Triangle, Sawtooth, Noise, ..., et vous pouvez en ajouter de nouveaux. Grace  ce systme qui a l'air trs compliqu, on peut automatiser une animation complexe, par exemple un objet qui tourne continuellement et qui vibre etc...

- Gizmo : compos d'un PrimaryController et d'un SecondaryController.

- Object : Un objet en toodee est une liste de couples (Mesh, Shader) coupl avec un Gizmo pour le positionner. En fait il ne stocke pas le mesh et le shader, seulement leurs indices dans une liste globale.

- Font : Permet d'afficher du texte.

- Scene : une collection d'indices d'objets
- Camera : !!!!!!!!!!!!!!!
- World : une collection de scenes, de shaders, de meshes, de cameras, d'objets.
- Engine : le moteur, il contient tout.

 On revient mnt  cette histoire d'indices : voici un exemple en pseudo code pour clarifier ce bordel :




```

```

J'espre que j'arrive  expliquer le principe. En procdant comme ceci, il n'y a pas de redondance. Un meme mesh ou shader peut tre utilis dans plusieurs objets. De plus, on peut crer plusieures scenes, et plusieures cameras, et choisir  tout instant quel scene dessiner et avec quelle camera. De plus, un mme objet peut appartenir  plusieures scenes.

C'est un peu compliqu, mais c'est robuste et trs puissant.
Bon, j'ai une crampe aux mains, donc je vais arreter, et continuer plus tard pour expliquer plusieures autres aspects de toodee.
J'attends vos avis. Merci d'avance.

----------


## Matthieu Brucher

C'est beau  ::): 
Continue comme a !

----------


## Baptiste Wicht

Ouais c'est joli   ::D:  Continue comme ca, bon courage   ::!::

----------


## loka

encore trs joli  ::D: 

Je comprend plutot bien le principe de ton moteur, ton explication (surtout la source) explique parfaitement comment l'utiliser et parait assez simple.

----------


## djo.mos

Bonjour tout le monde.

Ca y est ! La crampe des mains est partie ! Je vais donc pouvoir continuer de presenter les ides et les mthodes que j'ai utilis dans toodee.


**************  Les transformations das toodee ************

En re-lisant mon dernier post, J'ai vu que la partie concernant les controleurs (SecondaryController, FloatController, Point3Controller ...) etait du charabia, je vais donc re-expliquer la chose.
Je commence par le floatController.
C'est une classe dont voici l'entte :


```

```

C'est une classe abstraite, plus precisement c'est une interface (je bosse sur Delphi).
la mthode setPAram permet de configurer le controlleur, et transform retourne une valeur selon la valeur de t (le temps) et des paramtres.

Par exemple, on peut dfinir une classe SinController qui implemente FloatController comme ceci :


```

```

Cette classe retourne une valeur qqui varie sinusoidalement selon t et dans l'intervalle [min..max]. Ce n'est qu'une possibilit, et je pense que via cette interface, les possiblites sont infinies.
Dans mon case, j'ai ralis :
- Id controller : 			 
	Configuration:
		 target= 0   : la valeur (val).		 

	fonctionnement:
		 Une fonction constante qui retourne val qlq soit t. (Waw ! Trs ingnieux !)

- Sin controller : 			 
	Configuration:
		 target= 0   : la priode (period).
		 target= 1   : le decalage (dec).
		 target= 2   : la borne inf (min).
		 target= 3   : la borne sup (max).

	fonctionnement:
		 Une sinusoide de periode period retard dans l'axe du temps de dec et borne par min et max.

- Cos controller : 			 
	Configuration:
		 La mme que SinController

	fonctionnement:
		 Une fonction cosinus de periode period retard dans l'axe du temps de dec et borne par min et max.

- Triangle controller : 			 
	Configuration:
		 La mme que SinController

	fonctionnement:
		 Une fonction qui varie en triangle de periode period retard dans l'axe du temps de dec et borne par min et max.        

- Square controller : 			 
	Configuration:
		 La mme que SinController

	fonctionnement:
		 Une fonction qui varie en carre de periode period retard dans l'axe du temps de dec et borne par min et max.

- Sawtooth controller : 			 
	Configuration:
		 La mme que SinController

	fonctionnement:
		 Une fonction qui varie en dents de scie de periode period retard dans l'axe du temps de dec et borne par min et max.

- Noise controller : 			 
	Configuration:
		 target= 0   : le seed
		 target= 1   : la borne inf (min).
		 target= 2   : la borne sup (max).

	fonctionnement:
		 retourne des valeurs alatoires selon le seed et qui sont bornes par min et max.



On passe maintenant au choses srieuses.

Une premire classe qui utilise tout ce bordel mathmatique est le Color4Controller. Elle est constitu de 4 FloatController et qui sont R, G, B et A.
Toute couleur dans toodee est en fait une instance de cette classe : La couleur d'arrire plan, les couleurs des vertices, etc...
De cette faon, et malgr la complexit avec la quelle se manipule les couleurs, on peut facilement crer des effets complexes et completement automatiss.
Vous n'avez pas  vous en soucier  chaque frame, en mettant  jour des variables ou  calculer de nouvelles valeurs ! Il faut juste tout initialiser et configurer au dpart, et laisser le moteur s'en occuper pour la suite !


Une deuxime classe qui utilise ce qui precde est le Point3Controller.	Elle est constitu de 3 FloatController et qui sont X, Y, Z. coupl  un champs type qui controlle quelle genre de modif cette classe effectue.
Le champs type est soit translate, rotate ou scale. Elle aussi permet de raliser et d'automatiser beaucoup d'animations.
Un exemple : disons qu'on a une roue qui tourne autour de l'axe Z et qui se dplace sur l'axe des X.



On peut raliser ce genre d'animations comme ceci : On associ   la roue 2 Point3Controllers : un pour la rotation, et un pour la translation.
-Pour le premier controleur (celui de la translation):
  -On instancie le champs X (FloatController) par un SawTooth Controller (il a une une crte ascendante qui est linaire), on
  le configure comme ceci : une periode de 20s, un decalage de 0s, la valeur minimale est la position initiale de la roue et la valeur maximale est la position finale de la roue.
  -On instancie les champs Y et Z (FloatController) par un IdController car La position Y et Z ne changent pas.
  -On met le champs type  translate.

-Pour le second controleur (celui de la rotation):
  -On instancie le champs Z (FloatController) par un SawTooth Controller (il a une crte ascendante qui est linaire), on
  le configure comme ceci : une periode de 5s, un decalage de 0s, une valeur minimale de 0 et une valeur maximale de 360.
  -On instancie les champs X et Y (FloatController) par un IdController car Les angles X et Y ne changent pas.
  -On met le champs type  rotate.

Et on lance le rendering : La roue se dplace en tournat, et ce sans la moindre intervention de votre part !

Et puisque en gneral on aura besoin plus que d'un seul Point3Controller par objet, j'ai ajout une nouvelle classe, Point3ControllerList qui permet de grer une collection de Point3Controller !
C'est le SecondaryController.

RQ : L'effet du Point3Controller est relatif, pour que l'apport de chaque Point3Controller soit accumul.

Malgr sa puissance, le SecondaryController reste difficile  manier, donc, pour simplifier la tache, j'ai ajout une nouvelle classe : PrimaryController qui permet de positionner plus simplement les objets.
En gros, Elle contient les fonctions suivantes :

  -TranslateTo(x, y, z)
  -TranslateBy(mode, x, y, z) : mode est soit local soit global.

  -RotateTo(x, y, z)
  -RotateBy(mode, x, y, z) : mode est soit local soit global.

  -ScaleTo(x, y, z)
  -ScaleBy(x, y, z) : pas de mode encore (ca fonctionne en local, en global a donne le shearing je pense).

Et enfin j'ai ajout la classe Gizmo, qui est un couple (PrimaryController, SecondaryController).

Dans toodee, chaque objet, chaque texture, chaque Font, chaque Camera et  chaque Light a son propre Gizmo. Je vous laiise imaginer ce qu'on peut raliser avec tout ce bazar !

RQ  : Les transformations sont appliqus dans cet ordre 1-Primary, 2-Secondary.
RQ2 : Je ne pretends pas avoir invent tout cela, je me suis fortement inspir de deux sources : 3D Studio Max et Quake III. Mais j'ai pas mal boss ladessus quand mme ;-)

----------


## djo.mos

**************  Les shaders dans toodee ************

Je vous avertis tout de suite : Ne vous attendez pas  des prouesses du systme de shading que j'ai dvelopp ! Je suis un dbutant dans le domaine, ma p****n de Radeon 9200 ne prend pas en charge les nouvelles technologie dans ce domaine.

Mais, on peut toujours raliser de beaux effets avec !

Je vais commencer par presenter quelques classes intermdiaires avant d'attaquer les shaders.
J'ai ralis une classes Texture qui permet de stocker et de manipuler une texture. En gros, il s'agit d'un wrapper des fonctions d'OpenGL.
Des mthodes pour charger une texture, pour changer le envmode, le wrap, bla bla bla ...
De plus, j'y ai ajout :
1- La possibilit de stocker plusieures textures pour pouvoir raliser des textures animes, donc tout le bazar des fonctions pour ajouter une nouvelle texture, passer d'une texture  l'autre quoi que a peut se faire automatiquement.
J'explique : J'ai ajout un champs Frequency, qui represente le temps au dela duquel on passe  l'image suivante. Mais si ce champs est  0, le passage devient manuel et est  la charge du programmeur.
2- Un Gizmo : Pour pouvoir raliser pleint d'effets sympas en jouant sur la matrice GL_TEXTURE.

Il y'a ensuite la classe ShaderPass, qui represente une passe lors du dessing d'un polygone.
Elle contient une Texture, Un Color4Controller pour pouvoir jouer un peu sur la couleur de la face ou modifier la couleur de la texture (dynamiquement).
Il y a aussi des fonctions pour controler le blending (toujours une abstaraction d'OpenGL) et enfin des fonctions pour controller l'etat de la passe (Marche/Arret).

Et enfin le shader, qui n'est autre qu'une collection de ShaderPass, pour pouvoir raliser des effets plus complexes.

En fait, je pense que la puissance de ce systme provient uniquement du gizmo de la texture et du Color4Controller de chaque ShaderPass, car ils permettent de raliser des animations complexes et dynamiques avec un minimum d'efforts.

Comme je l'ai mentionn avant, je pense qu'il faut faire exposer tout ce qui est artistique aux artistes, et ce d'une manire simple.
Un artiste n'a pas  connaitre le langage de programmation surlequel on bosse, ni de connaitre les mthodes et les paramtres des classes du moteur.
Il faut donc trouver un moyen pour simplifier la tache aux artistes, et d'aprs ma connaissance, il y a 2 mthode pour ceci :
1- Soit dvelopper un diteur graphique de shaders, avec interface ergonomique, prvisualisation, etc... Mais c'est beaucoup de travail aux dveloppeurs de raliser un tel diteur.
2- Soit dvelopper un systme de scripting qui permet de controler compltement un shader avec une syntaxe simple.

Je vous laisse deviner quelle option j'ai choisi !

J'ai donc ralis une petite bibliothque de scripting, qui permet de parser un script dans un langage que j'ai nomm BOSL pour Block Organized Scripting Language.
Dans ce langage, il y a deux structures :
- Une dfinition : dont voici la syntaxe 


```
VARIABLE VALEUR &#91; VALEUR2 VALEUR3 ...&#93; ;
```

VARIABLE et VALEUR* sont une sequence qlq de caractres sans spaces, car l'espace est utilis comme sparatuer.
  Une dfinition se termine par un point virgule : ( :;): 

- Un noeud : dont voici la syntaxe


```

```


   NOM est une sequence qlq de caractres sans spaces.
   Un noeud peut  son tour contenir un nombre quelquonque de dfinitions et d'autres noeuds. Pas d'ordre particulier.


Enfin, le fichier script est un fichier qui contient un seul noeud.(un peu comme XML).
RQ : Le BOSL accepte les commentaire sur une seule ligne du style C : //commentaire

exemple :


```

```

Revenons maintenant aux shaders.
Un script shader est un svript BOSL dont le neoud pricipal se nomme shader.
Dans ce noeud, il ne peut y avoir que des noeuds pass, qui representent un ShaderPass.

exemple :



```

```

C'est un shader simple qui se contente de remplir une surface avec le rouge.


```

```

Cette fois, ce shader remplit une surface avec une texture combine  une couleur.
Le paramtre default indique au moteur d'utiliser son chargeur de texture par dfaut. Il s'agit d'un wrapper autour de DEVIL. Merci les mecs !


Jusque la, les couleurs sont statiques. Utilisons les FloatControllers :


```

```

maintenant, la composante r de la couleur varie en sinus.
le paramtre default indique que le controleur qu'on va spcifier (le sin) est un des controleurs fournies avec toodee.
ensuite le nom du controleur : sin, et la liste des paramtres pour configurer le controleur ( si vous ne suivez plus, revenez au post prcedent sur les controleurs).

Voici maintenant un shader avec du blending et une texture anime :


```

```

maintenant, on va pouvoir jouer sur le gizmo de la texture :


```

```

on specifie le type de la transformation comme un neoud, et  l'interieur, on specifie les floatController pour chaque composante.
Si une composante est omise, son controlleur va toujours retouner 0, donc attention lors du scaling !

Un autre shader multipass


```

```

et ainsi de suite, la crativit est la seule limite !

Comme je le dis toujours, je ne pretends pas avoir invent tout ceci ! je me suis fortement inspir du dieu-le-tout-puissant John Carmack et de shaders de Quake III.

----------


## djo.mos

Une dernire chose, je pars en vacances demain, et je serais absent du forum pour au moins 2 semaines. Je m'excuse d'avance. D'ici l, j'espre que quelqu'un aurait pu lire mes deux precedants romans, je veux dire posts   ::lol::  .

----------


## loka

t'as pas a t'excuser parce que tu pars en vacance   ::lol::  

Bon j'ai pas encore lu tout a mais demain j'ai un peu de temp libre entre 2 cours. 
surtout que j'ai vu le nom de John Carmack   ::D:

----------


## h0bby1

un exe !! un exe !! =)

----------


## djo.mos

Bon, je crois que ce topic est un peu mort l : il a assez vcu.
Mauvaise nouvelle : Je laisse tout omber ! Vu que Borland a lach Delphi et que j'ai jur de ne plus l'utiliser pour punir Borland, j'arrete tous mes projets : Quad3D et toodee.
Je suis actuellemnt en pleine transition vers C#, et une fois que je l'aurais bien maitris, je pense que je ramorcerais ces projets.

Je marque ce topic comme rsolu pour laisser la place  d'autres.

En attendant, et pour finir, merci  tous ceux qui ont particip  ce topic, vos rponses et avis m'ont beaucoup aid.

----------


## fearyourself

Bonne chance, porter un code vers un autre langage n'est pas une mince affaire!

Reste calme et zen  ::wink:: 
Jc

----------


## djo.mos

Merci, et c'est vrai ce que tu dis, c'est trop dcourageant, surtout avec les dizaines de milliers de lignes de code que j'ai dja pondue !

----------


## fearyourself

> Merci, et c'est vrai ce que tu dis, c'est trop dcourageant, surtout avec les dizaines de milliers de lignes de code que j'ai dja pondue !


Oui je connais le problme... Tu perdras moins de temps  rassembler les grandes lignes de ton moteur courant et recoder tout  zro.

Tu viteras les grandes erreurs et tu seras srement capable d'amliorer le tout...

Jc

----------

