Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1587 connectés 

 


Dernière réponse
Sujet : Moteur 3D, D3D OpenGL et concepteurs
Arlo13

therier a écrit a écrit :

 
 
Merde un nouveau! je le connaissait pas celui là!  ;)  




 
:lol: :lol: :lol:
 
Si si c'est un effet de folie :)


Votre réponse
Nom d'utilisateur    Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !
Le ton de votre message                        
                       
Votre réponse


[b][i][u][strike][spoiler][fixed][cpp][url][email][img][*]   
 
   [quote]
 

Options

 
Vous avez perdu votre mot de passe ?


Vue Rapide de la discussion
Arlo13

therier a écrit a écrit :

 
 
Merde un nouveau! je le connaissait pas celui là!  ;)  




 
:lol: :lol: :lol:
 
Si si c'est un effet de folie :)

therier

youdontcare a écrit a écrit :

j'ai oublié 'virtual' mais personne ne corrige :D  




 
Ca semblait evident! ;)

youdontcare j'ai oublié 'virtual' mais personne ne corrige :D
therier

Arlo13 a écrit a écrit :

les effets visuels "moderns" comme le multitexturing, ou le bimp mapping



 
Merde un nouveau! je le connaissait pas celui là!  ;)

therier Tout comme youdontcare!
Il faut creer une couche intermediare d'abstraction pour t'abstraire:
1- de la lib graphique (DX, OGL, Glide, XWindow...)
2- de la platform OS+Machine (Sun, Linux PC, Windows PC, Mac)
 
comme ça celui qui utilise ton API a un effort minimal à faire pour le porter sur d'autres plateformes et library.
 
En résumé: Vive C++ et les Templates!  ;)
youdontcare pour compléter ce qui a été dit précédemment ... :)
 
en c++, tu créés une classe abstraite, de laquelle seront dérivées les classes spécifiques pour directx et opengl. une classe abstraite est en fait une classe de 'définition' que tu utiliseras dans ton code. tu ne peux pas l'instancier directement, tu ne peux instancier qu'une classe dérivée qui implémente les méthodes abstraites.  
 
par ex :
 
class renderer
{
   // la méthode abstraite de rendu d'un objet
   void DrawObject(myObject* obj) = 0;
}
 
class dxrenderer : public renderer
{
   // la méthode de rendu d'un objet pour directx
   void DrawObject(myObject* obj)
   {
     device->DrawPrimitive(obj->....);
   }
}
 
class glrenderer : public renderer
{
   // la méthode de rendu d'un objet pour opengl
   void DrawObject(myObject* obj)
   {
     glDrawElements(obj->...);
   }
}
 
dans ton code, tu n'utilises que la classe abstraite, par ex ta boucle d'affichage ressemblera à :
 
void Render(renderer* r)
{
  for (int i=0; i<numObjects; i++)
  {
    r->DrawObject(objects[i]);
  }
}
 
et d'où vient le renderer* ? c'est toi qui, suivant le choit de l'utilisateur, l'instancie :  
renderer* r = new glrenderer; // pour opengl
ou
renderer* r = new dxrenderer; // pour directx
 
voilà ... le mieux est d'abstraire le rendu à un certain niveau, et pas vertex par vertex. par ex, rendre un objet avec des shaders à la quake3 plutôt que gérer tous les renderstates à la main. tu verras que tu auras sûrement besoin d'abstraire l'objet 3d également : dans un cas stocker des vertex buffers (dx), dans l'autre des diplays lists (gl).
 
et pour une application pratique de la chose, regarde la sdk d'unreal tournament, y'a les sources des renderers.
tgrx Pour compléter ce que dit arlo13, pour faire un moteur 3D généraliste à la Unreal, il faut scinder ton boulot en deux entités :
* Un moteur dit géométrique, indépendant du matériel, qui s'occupe entre autres de choisir les faces à afficher (et c'est de loin la partie la plus difficile) et s'occupe des collisions.
* Des plug-ins OpenGL, Direct3D ou Glide qui viennent se greffer en aval du moteur géométrique et qui font exclusivement de l'affichage (pas de traitement à ce niveau, toute l'astuce est de faire le boulot avant). Cependant vu que les effets spéciaux dépendent généralement de l'API, ils doivent être traités à ce niveau. :hello:
Evadream -jbd- Ok merci bcp !
Arlo13 Ca n'a rien a voir avec le software...
 
Je code actuellement un moteur3D en OpenGL, DirectX, je suis donc bien placé pour en parler. Si tu fais les choses proprement, la transition DirectX/GL ou inversement n'est pas si compliqué. Ormis l'affichage, tous les algorithmes sont les même que ce soit pour le tri des faces, les collisions ou encore le son, etc ...
Il te suffit de faire des algos suffisament "aware" pour que tu n'es pas à te compliquer la tache trop longtemps! En gros, tu n'auras a recoder que les algos utilisant les routines d'affichages, par exemple notre fidèle glVertex3f(x,y,z) :)
 
Malheureusement avec l'apparition des extensions en tout genre, c'est plus compliqué pour gérer les effets visuels "moderns" comme le multitexturing, ou le bimp mapping pour ne citer qu'eux! Et dans ce cas, tu auras plus de boulot pour adapter ca sur les 2 ou 3 API que tu auras choisis!  
 
Voila j'espère que j'aurais répondu à tes questions !
Feyd_Rautha Tout ca c'est lié au software
Evadream -jbd- Je n'y connais rien en programmation et je voudrais faire Quake 5...  
 
Nannnn partez-pas, je rigolais !  
 
Bon, je n'ai aucune notion de programmation d'un moteur 3D, donc mes questions pourront sembler plus ou moins bêtes. Voilà : je me demande comment font les concepteurs de moteur3D pour proposer autant d'API différentes. Par exemple Unreal : d3d, openGL et glide. J'aimerais savoir comment ca se passe, si une fois qu'on a finalisé une api, passé à une autre n'est qu'une formalité ( relative... :p ) ou ca demande une refonte totale, une autre facon de penser certaines choses, ou certaines parties précises du code ?  
 
Est-ce le meme concepteur qui s'occupe de ca ou existe t'il des équipes qui s'occupe d'une API en particulier ?
 
Voilà, merci à ceux qui m'auront au moins lu :)
 
A+

Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR