Discussion :

[5:35pm]

Bonjour,
Il est habituel de choisir une architecture abstraite pour la creation d'un moteur 3d multi API.
Ce qui implique donc des classes Virtuelle pures pour avoir une interface commune, pour toutes les API graphique, comme ceci:

(Excusez mes erreurs, cela fait un bail que j'ai plus fais de c++)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
class Renderer
{
public:
//Interface commune
  virtual void DrawScene() = 0;
}
 
class DXRenderer : public Renderer
{
//definition de la methode virtuelle pour directX
public:
void DrawScene()
  {
    //Instructions DirectX
  }
}
 
class OGLRenderer : public Renderer
{
//definition de la methode virtuelle pour openGl
public:
void DrawScene()
  {
    //Instructions OpenGl
  }
}

Cependant, le cout d'appel d'une methode virtuelle est superieur au cout d'un methode "normale", et comme un moteur 3d se doit d'etre rapide et efficasse, j'ai pense a une autre maniere de concevoir la chose. la methode utiliserait les preprocesseurs mais est certainement plus "risquee" et moins elegante que l'abstraction:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
 
 
//definition directX
 
#ifdef DX
 
class Renderer
{
public:
 
  void DrawScene()
   {
     //Instruction directX
   }
}
 
#endif
 
 
 
//definition OpenGl
 
#ifdef GL
 
class Renderer
{
public:
 
  void DrawScene()
  {
     //Instruction OpenGl
  }
}
 
#endif

donc l'idee est de se priver d'abstraction, mais de garder la meme interface commune pour l'utilisation des deux api. au debut du programme, on definit via #define quel api utiliser.
contrairement a une architecture abstraite, la difference est qu'une compilation pour chaque API serait necessaire.
mais cette maniere, se debarrasse de la couche abstraite, ce devrait apporter un gain niveau performances...
qu'en pensez vous?

[Laurent Gomila]

donc l'idee est de se priver d'abstraction, mais de garder la meme interface commune pour l'utilisation des deux api. au debut du programme, on definit via #define quel api utiliser.

Là tu perds vraiment tous les avantages du système à base de classe abstraite. Si tu veux créer un nouveau renderer il faut toucher au moteur ; avec l'approche précédente n'importe qui peut le faire si un petit système de plugin est prévu. Ensuite pour changer le renderer que tu utilises il faut également recompiler le moteur ; avec l'approche précédente on peut par exemple simplement le passer en paramètre dans un fichier de config ou en ligne de commande, voire en changer pendant l'exécution.
Etc...

mais cette maniere, se debarrasse de la couche abstraite, ce devrait apporter un gain niveau performances...
qu'en pensez vous?

J'en pense que si les moteurs 3D étaient ralentis par les appels à des fonctions virtuelles, alors ce serait bien grave.
Optimisation nettement inutile vu les fonctionnalités dont il faudrait se priver, à mon avis. Mais bon si tu veux faire un truc qui ne soit pas modulaire et que tu te fiches un peu de pouvoir changer de renderer à la volée ou d'en écrire de nouveaux, alors pourquoi pas.

[5:35pm]

J'en pense que si les moteurs 3D étaient ralentis par les appels à des fonctions virtuelles, alors ce serait bien grave.
Optimisation nettement inutile vu les fonctionnalités dont il faudrait se priver, à mon avis. Mais bon si tu veux faire un truc qui ne soit pas modulaire et que tu te fiches un peu de pouvoir changer de renderer à la volée ou d'en écrire de nouveaux, alors pourquoi pas.

Bjarne Stroustrup l'a ecris dans son livre, le coup d'un appel d'une methode virtuelle demande plus de ressources que celui d'une methode de base.
Donc, oui, ca ralentit le moteur
Je ne vois vraiment pas l'interet de changer de renderer a la volee, ca n'arrive jamais dans le monde des jeux video.
sinon pour la modularite, je dirais que ca reste "statiquement modulaire".
Enfin, rien n'empeche d'ajouter un nouvel API, du moment qu'on dispose du code source c'est vrai.

ps: Laurent, j'ai lu tes articles, respect

[Laurent Gomila]

Bjarne Stroustrup l'a ecris dans son livre, le coup d'un appel d'une methode virtuelle demande plus de ressources que celui d'une methode de base

Ca je n'ai pas dit le contraire. Simplement un appel de fonction virtuelle ce n'est qu'une indirection de plus ; Comparé au parcours du graphe de scène, au tri des polygones transparents, à la mise à jour de ta structure de partitionnement dynamique, à la détection de collisions pour la physique en temps réel, à l'IA qui réflechit bien plus qu'elle ne devrait, au temps perdu par manque de synchro CPU / GPU, au temps d'exécution de ton shader 3.0 non optimisé, ... C'est du pipi de chat. Et encore...

Donc, oui, ca ralentit le moteur

Tu l'as mesuré ?

Avant de brider des fonctionnalités aussi essentielles, construis ton moteur 3D, fais des benchs, optimise les algorithmes de rendu, les structures de données, les renderpaths pour chaque CG, ... Et là tu seras bien loin de vouloir optimiser les liaisons dynamiques, crois moi.

Je ne vois vraiment pas l'interet de changer de renderer a la volee, ca n'arrive jamais dans le monde des jeux video

A la volée non, mais entre deux exécutions oui.

sinon pour la modularite, je dirais que ca reste "statiquement modulaire"

Appelle ça comme tu veux, le fait est que ça n'est plus modulaire

Enfin, rien n'empeche d'ajouter un nouvel API, du moment qu'on dispose du code source c'est vrai.

Si l'on dispose d'un code source on peut ajouter ce que l'on veut. L'intérêt est justement de pouvoir ajouter des choses sans toucher au moteur.

[5:35pm]

ok, tu m'as convaincu lol
moi qui croyais avoir l'idee du siecle
bon alors dans ce cas la, autant continuer sur Ogre

[Laurent Gomila]

J'ai remplacé "délestage" par "résolu", le sujet pourrait aider ceux qui se posent le même genre de questions

[5:35pm]

mouais, a mon avis y a pas beaucoup de gens qui se la pose! lol
sinon, as tu des bouquins a me conseiller pour faire un moteur de jeu?
la je n'ai que le red book d'open Gl
Que ca concerne la 3d, l'IA, la physique...
je sais bien qu'il y a une tonne de moteur, mais c'est pour etudier.

[Matthieu Brucher]

En anglais, il y a game engine architecture d'un allemand. C'est plutôt orienté windows au niveau conception, mais c'est bien.

[ash.ice.loky]

En effet j'ai feuilleté ce livre qui m'avais semblé interressant.
Il y avait aussi du meme auteur "3D game engine design" mais toujours en anglais.

dans le dernier game engine architecture je m'etait alors interressé au diverse classes, tel que Smart Pointer, Maths, Vector, Exceptions, ..., et la on se rend compte qu'il y a tout un tas de choses a preparer avant meme de taper la premiere ligne OpenGL.

Sinon le code etait en effet pour WIN avec le couple OpenGL/Win32 (..!)

Je peut pas t'en dire beaucoup plus car je l'ai eu que quelques heures entre les mains.

Quand a l'autre juste quelques minute, 3D game engine design, il m'avais semblé etre beaucoup plus theorique.

[mat.M]

qu'en pensez vous?

L'intérêt de déclarer une classe de base Renderer et des classes qui en héritent c'est un peu limité...enfin c'est mon point de vue.
Ok pour des entités comme les persos du moteur de jeu mais de là à rajouter du code pour gérer la gestion du rendu...

[Matthieu Brucher]

En fat, c'était le 3D Game que j'ai aperçu

[5:35pm]

je crois avoir trouve les livres qu'il faut, je les ai deja commande
http://www.amazon.com/gp/product/073...630531?ie=UTF8
http://www.amazon.com/gp/product/158...630531?ie=UTF8
http://www.amazon.com/gp/product/155...e=UTF8&s=books

[Matthieu Brucher]

J'ai pas lu le premier, mais les 2 derniers sont bons - mais pas pour les moteurs de jeu, plus sur les détails -

[5:35pm]

je viens d'annuler le premier, parce que je me rend compte que ca traite plus d'organisation dans l'entreprise que de code.
voila mon choix http://www.amazon.com/gp/product/012...630531?ie=UTF8
celui la a de bonne critiques

[Sixissor]

N'oublie pas d'aller aussi sur GameDev.net dans la section "books" pour voir leurs choix. Sans oublier les lectures et les bonnes critiques de Miles disponibles sur developpez.com sur pas mal de bouquins concernant le "game programming"

Concernant ce bouquin sur l'architecture d'un game engine, m'y étant aussi intéressé, je n'en ai pas vu de meilleurs...
Il m'a l'air bon seulement j'ai un lu un petit extrait (je ne sais plus où... en PDF) et ça m'a l'air pas mal du tout.

Voici quelques extraits du livres ici (tables des matières, tout ça...): 3D Game Engine Architecture: Engineering Real-Time Applications with Wild Magic

Seulement je me pose une question assez importante... parce que je vais bientôt en faire une indigestion...
POURQUOI dans le space partitionning ils utilisent tous soit le BSP, soit un octree obligatoirement et des fois des portals ou d'autres méthodes dans ce genre ?
Je veux dire par là: mais où est passé l'ingéniosité de l'être humain et pourquoi tout le monde utilise toujours les MEMES techniques... Ca devient lassant à la fin... C'est usant !!! N'y a-t-il vraiment personne pour réfléchir à une autre méthode ou ils se contentent tous de respecter le planning et coder sans réfléchir un truc des vieux de la vieille qui marche déjà ?
Parce que juste pour info... Le BSP a été utilisé pour le jeu DOOM... Et pas Doom 3 mais DOOM, premier du nom, donc c'est Relativement vieux.


Personellement, j'ai déjà essayé quelques techniques "home made" mais sans grand succès... Je n'ai aucune prétention mais j'essaye juste de réfléchir par moi-même à une solution. Il m'est déjà arriver par 2 fois déjà d'avoir "découvert" une méthode mais après diverses recherches, je me suis aperçu qu'elle existait déjà... Un peu déçu mais bon, qui ne tente rien n'a rien
Et c'est ça la problématique: qu'est-ce qui différencie 2 moteurs graphiques qui offrent presque la même qualité de rendu ? C'est sa conception, sa philosophie et surtout les algorithmes qui sont utilisés derrière et qui permettent de le rendre plus performant, parce qu'on peut avoir la même qualité de rendu à 60 et à 200 fps...
Et c'est là que tous les moteurs graphiques commerciaux débarquent à la pelle, avec leur "shader 42.0", leur "binary space partitionning of the mega death", leur 42 formats de modèles 3D et de textures qu'ils peuvent charger et plein de choses encores. Et honnêtement, lequel se démarque VRAIMENT des autres ? Non je ne parle pas des moteurs comme l'Unreal Engine 3.0 qui doivent tourner sur un Pentium 42 avec 42 Go de Ram et qui "parait" plus beau que les autres, mais je parle du niveau algorithmique ! Lequel n'utilise pas au moins les arbres BSP ou les octrees et ne bourrine pas sur l'assembleur ?
Sommes-nous arriver à une limite au niveau optimisation de l'espace et algorithmique en général concernant les jeux vidéos ?

Vous vous faites comment ? Vous vous lancez cash dans un BSP ou un Octree sans réfléchir ou vous essayez aussi de penser à une nouvelle méthode ?

PS: je signale qu'aucun nombre 42 n'a été agressé durant son utilisation pendant mon ennuyant discours.
PS2: les claviers QWERTY c'est MAL.

[ash.ice.loky]

Seulement je me pose une question assez importante... parce que je vais bientôt en faire une indigestion...
POURQUOI dans le space partitionning ils utilisent tous soit le BSP, soit un octree obligatoirement et des fois des portals ou d'autres méthodes dans ce genre ?
Je veux dire par là: mais où est passé l'ingéniosité de l'être humain et pourquoi tout le monde utilise toujours les MEMES techniques... Ca devient lassant à la fin... C'est usant !!! N'y a-t-il vraiment personne pour réfléchir à une autre méthode ou ils se contentent tous de respecter le planning et coder sans réfléchir un truc des vieux de la vieille qui marche déjà ?
Parce que juste pour info... Le BSP a été utilisé pour le jeu DOOM... Et pas Doom 3 mais DOOM, premier du nom, donc c'est Relativement vieux.


Personellement, j'ai déjà essayé quelques techniques "home made" mais sans grand succès... Je n'ai aucune prétention mais j'essaye juste de réfléchir par moi-même à une solution. Il m'est déjà arriver par 2 fois déjà d'avoir "découvert" une méthode mais après diverses recherches, je me suis aperçu qu'elle existait déjà... Un peu déçu mais bon, qui ne tente rien n'a rien
Et c'est ça la problématique: qu'est-ce qui différencie 2 moteurs graphiques qui offrent presque la même qualité de rendu ? C'est sa conception, sa philosophie et surtout les algorithmes qui sont utilisés derrière et qui permettent de le rendre plus performant, parce qu'on peut avoir la même qualité de rendu à 60 et à 200 fps...
Et c'est là que tous les moteurs graphiques commerciaux débarquent à la pelle, avec leur "shader 42.0", leur "binary space partitionning of the mega death", leur 42 formats de modèles 3D et de textures qu'ils peuvent charger et plein de choses encores. Et honnêtement, lequel se démarque VRAIMENT des autres ? Non je ne parle pas des moteurs comme l'Unreal Engine 3.0 qui doivent tourner sur un Pentium 42 avec 42 Go de Ram et qui "parait" plus beau que les autres, mais je parle du niveau algorithmique ! Lequel n'utilise pas au moins les arbres BSP ou les octrees et ne bourrine pas sur l'assembleur ?
Sommes-nous arriver à une limite au niveau optimisation de l'espace et algorithmique en général concernant les jeux vidéos ?

Voila un raisonnement de chercheur, bosse dans un labo
plus serieusement, dans les entreprises d'aujourdh'ui on a plus le temps d'optimiser.
Qu'elle boite voudrai passer plusieurs mois de recherche sur des sujet qui profiterais au concurrent et dont l'apport est minime au vue de l'evolution du matos ?
Aucune, le pb est la.

>> 5:35pm

ce livre est celui dontje te parlais. Le peu que j'en avais lu m'avais mi l'eau a la bouche. N'hesite pas si tu le termine a venir en faire une critique

[5:35pm]

Sixissor: j'ai l'ai pas choisis le clavier qwerty!

ca me fais plaisir que tout le monde soit unanime sur ce livre, j'ecrirais une critique avec plaisir, j'ai egalement pas mal de bons livres sur c++ que je critiquerais avec plaisir, mais ils sont tous en anglais.

[bafman]

POURQUOI dans le space partitionning ils utilisent tous soit le BSP, soit un octree obligatoirement et des fois des portals ou d'autres méthodes dans ce genre ?

tout simplement car ce sont les structures de données les plus adaptée au problemes posé. Le BSP a l'aventage d'etre relativement generique, l'octree/quadtree s'adapte très bien au rendu de terrain et les portals au rendu de scènes en interieur. d'ailleur, tu ne parle pas des PVS inventé par camack pour Quake1 qui se basent sur les BPS et sont très efficaces... (et très utilisé aussi)

Je veux dire par là: mais où est passé l'ingéniosité de l'être humain et pourquoi tout le monde utilise toujours les MEMES techniques... Ca devient lassant à la fin... C'est usant !!! N'y a-t-il vraiment personne pour réfléchir à une autre méthode ou ils se contentent tous de respecter le planning et coder sans réfléchir un truc des vieux de la vieille qui marche déjà ?

tout simplement parceque ces méthodes on fait l'objet de recherches approfondi et d'année d'affinage qui leur permet d'etre très efficaces dans leur domaine d'application. Apres, tu peut toujours charcher une methode spécialement adapté à un type de rendu, mais ca reste l'eternel combat optimisation vs généricité, et les techniques citée plus haut on justement l'aventage d'avoir un très bon rapport rapidité/généricité.

Parce que juste pour info... Le BSP a été utilisé pour le jeu DOOM... Et pas Doom 3 mais DOOM, premier du nom, donc c'est Relativement vieux.

houla, ca date meme de bien avant doom, et pour info, doom 3 utilise aussi un arbre BSP...

Et c'est ça la problématique: qu'est-ce qui différencie 2 moteurs graphiques qui offrent presque la même qualité de rendu ? C'est sa conception, sa philosophie et surtout les algorithmes qui sont utilisés derrière et qui permettent de le rendre plus performant, parce qu'on peut avoir la même qualité de rendu à 60 et à 200 fps...

je dirais meme ca de façon encore plus simple :
qu'est ce qui differencie un bon moteur d'un mauvais : l'efficaticé des algorithmes de partitionnemet.

Et c'est là que tous les moteurs graphiques commerciaux débarquent à la pelle, avec leur "shader 42.0", leur "binary space partitionning of the mega death", leur 42 formats de modèles 3D et de textures qu'ils peuvent charger et plein de choses encores.

regarde le code du renderer de quake3 (bon OK il commence à etre un peut vieux mais ca rest un bon exemple), il est ridiculement petit, gere trois pauvre formats d'images et de models. et pourtant ca a été un succes commercial tout simplement parce que ce qu'il fait, il le fait bien, un point c'est tout.

Et honnêtement, lequel se démarque VRAIMENT des autres ? Non je ne parle pas des moteurs comme l'Unreal Engine 3.0 qui doivent tourner sur un Pentium 42 avec 42 Go de Ram et qui "parait" plus beau que les autres, mais je parle du niveau algorithmique ! Lequel n'utilise pas au moins les arbres BSP ou les octrees et ne bourrine pas sur l'assembleur ?

entierement d'accord avec toi, je n'aime pas les unreal engine, il se pretendent trop generalistes et se basent generalement sur une utilisation massive de texture super haute resolution pour parraitre joli...
sinon, pour les autres moteurs non commerciaux, il faut voir un "truc" super important que n'ont pas ces moteurs : les outils de developpement. Sans outils pour pouvoir créer ses niveaux de jeux, on se retouve obligé d'utiliser les resultat des outils deja present sur le marché (gktRadiant et autre), et donc, on se retrouve aussi obliger d'utiliser leurs algorithmes en quelque sorte...

PS: je signale qu'aucun nombre 42 n'a été agressé durant son utilisation pendant mon ennuyant discours.

42 ? tu avais donc raison
http://fr.wikipedia.org/wiki/La_Gran...rs_et_le_Reste

[Sixissor]

Je suis content de voir que ça provoque des réactions

plus serieusement, dans les entreprises d'aujourdh'ui on a plus le temps d'optimiser.
Qu'elle boite voudrai passer plusieurs mois de recherche sur des sujet qui profiterais au concurrent et dont l'apport est minime au vue de l'evolution du matos ?
Aucune, le pb est la.

Pour la beauté de la recherche et de l'évolution des techniques. Oui je crois en un monde meilleur où tout le monde partage ses connaissances (même si je sais pertinament que j'ai une vision utopique des choses...)

Le problème c'est que DOOM existe depuis 1993 et les BSP aussi donc il serait peut-être temps de bouger car il est étonnant de voir ça dans le monde du jeu vidéo. En théorie il s'agit d'un monde qui est toujours en constante évolution et à la pointe de la technologie et des techniques de rendu avancées, etc. Pourtant voir que les BSP sont utilisés depuis 13 ans produit un contraste avec l'esprit "novateur" dans ce secteur de l'informatique. Ca fait bizarre de voir qu'il n'y a rien de nouveau... Mais peut-être que ça va rester pour toujours et que Carmack est vraiment un visionnaire et un génie.

Sixissor: j'ai l'ai pas choisis le clavier qwerty!

OK j'avais pas vu ta localisation... Dsl

ca me fais plaisir que tout le monde soit unanime sur ce livre, j'ecrirais une critique avec plaisir, j'ai egalement pas mal de bons livres sur c++ que je critiquerais avec plaisir, mais ils sont tous en anglais.

Avec plaisir

houla, ca date meme de bien avant doom

Hum... J'ai cru lire ici que Doom était le premier jeu à utiliser les BSP : http://en.wikipedia.org/wiki/Binary_Space_Partition (dans Overview)

Mais vous avez toujours pas répondu à une de mes questions:

Vous vous faites comment ? Vous vous lancez cash dans un BSP ou un Octree sans réfléchir ou vous essayez aussi de penser à une nouvelle méthode ?

[bafman]

ce n'est pas parceque doom est le premier JEU à utiliser les BSP que le principe du BSP n'a pas été inventé avant... tout comme l'eclairage par pixel, bump mapping tampon stencil et pleins d'autres...