# Applications > Dveloppement 2D, 3D et Jeux > Moteurs 3D >  [Moteur 3d Architecture] juste une idee, pour la performance

## 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++)




```

```

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:



```

```

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 systme  base de classe abstraite. Si tu veux crer un nouveau renderer il faut toucher au moteur ; avec l'approche prcdente n'importe qui peut le faire si un petit systme de plugin est prvu. Ensuite pour changer le renderer que tu utilises il faut galement recompiler le moteur ; avec l'approche prcdente on peut par exemple simplement le passer en paramtre dans un fichier de config ou en ligne de commande, voire en changer pendant l'excution.
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 fonctionnalits 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 vole 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 fonctionnalits 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 vole 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  ::D:

----------


## 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 scne, au tri des polygones transparents,  la mise  jour de ta structure de partitionnement dynamique,  la dtection de collisions pour la physique en temps rel,  l'IA qui rflechit bien plus qu'elle ne devrait, au temps perdu par manque de synchro CPU / GPU, au temps d'excution 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 fonctionnalits aussi essentielles, construis ton moteur 3D, fais des benchs, optimise les algorithmes de rendu, les structures de donnes, 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 vole non, mais entre deux excutions 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'intrt 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 "dlestage" par "rsolu", le sujet pourrait aider ceux qui se posent le mme 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 plutt 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

::roll::  


> qu'en pensez vous?


L'intrt de dclarer une classe de base Renderer et des classes qui en hritent c'est un peu limit...enfin c'est mon point de vue.
Ok pour des entits comme les persos du moteur de jeu mais de l  rajouter du code pour grer la gestion du rendu...

----------


## Matthieu Brucher

En fat, c'tait le 3D Game que j'ai aperu  :;):

----------


## 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  ::D:  - mais pas pour les moteurs de jeu, plus sur les dtails -

----------


## 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 intress, 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 matires, 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 bientt 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 mthodes dans ce genre ?
Je veux dire par l: mais o est pass l'ingniosit 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 rflchir  une autre mthode ou ils se contentent tous de respecter le planning et coder sans rflchir un truc des vieux de la vieille qui marche dj ?
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 dj essay quelques techniques "home made" mais sans grand succs... Je n'ai aucune prtention mais j'essaye juste de rflchir par moi-mme  une solution. Il m'est dj arriver par 2 fois dj d'avoir "dcouvert" une mthode mais aprs diverses recherches, je me suis aperu qu'elle existait dj... Un peu du mais bon, qui ne tente rien n'a rien  ::): 
Et c'est a la problmatique: qu'est-ce qui diffrencie 2 moteurs graphiques qui offrent presque la mme qualit de rendu ? C'est sa conception, sa philosophie et surtout les algorithmes qui sont utiliss derrire et qui permettent de le rendre plus performant, parce qu'on peut avoir la mme qualit de rendu  60 et  200 fps...
Et c'est l que tous les moteurs graphiques commerciaux dbarquent  la pelle, avec leur "shader 42.0", leur "binary space partitionning of the mega death", leur 42 formats de modles 3D et de textures qu'ils peuvent charger et plein de choses encores. Et honntement, lequel se dmarque 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 gnral concernant les jeux vidos ?

Vous vous faites comment ? Vous vous lancez cash dans un BSP ou un Octree sans rflchir ou vous essayez aussi de penser  une nouvelle mthode ?

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 bientt 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 mthodes dans ce genre ?
> Je veux dire par l: mais o est pass l'ingniosit 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 rflchir  une autre mthode ou ils se contentent tous de respecter le planning et coder sans rflchir un truc des vieux de la vieille qui marche dj ?
> 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 dj essay quelques techniques "home made" mais sans grand succs... Je n'ai aucune prtention mais j'essaye juste de rflchir par moi-mme  une solution. Il m'est dj arriver par 2 fois dj d'avoir "dcouvert" une mthode mais aprs diverses recherches, je me suis aperu qu'elle existait dj... Un peu du mais bon, qui ne tente rien n'a rien 
> Et c'est a la problmatique: qu'est-ce qui diffrencie 2 moteurs graphiques qui offrent presque la mme qualit de rendu ? C'est sa conception, sa philosophie et surtout les algorithmes qui sont utiliss derrire et qui permettent de le rendre plus performant, parce qu'on peut avoir la mme qualit de rendu  60 et  200 fps...
> Et c'est l que tous les moteurs graphiques commerciaux dbarquent  la pelle, avec leur "shader 42.0", leur "binary space partitionning of the mega death", leur 42 formats de modles 3D et de textures qu'ils peuvent charger et plein de choses encores. Et honntement, lequel se dmarque 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 gnral concernant les jeux vidos ?


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 mthodes dans ce genre ?


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



> Je veux dire par l: mais o est pass l'ingniosit 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 rflchir  une autre mthode ou ils se contentent tous de respecter le planning et coder sans rflchir un truc des vieux de la vieille qui marche dj ?


 tout simplement parceque ces mthodes on fait l'objet de recherches approfondi et d'anne d'affinage qui leur permet d'etre trs efficaces dans leur domaine d'application. Apres, tu peut toujours charcher une methode spcialement adapt  un type de rendu, mais ca reste l'eternel combat optimisation vs gnricit, et les techniques cite plus haut on justement l'aventage d'avoir un trs bon rapport rapidit/gnricit.



> 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 problmatique: qu'est-ce qui diffrencie 2 moteurs graphiques qui offrent presque la mme qualit de rendu ? C'est sa conception, sa philosophie et surtout les algorithmes qui sont utiliss derrire et qui permettent de le rendre plus performant, parce qu'on peut avoir la mme qualit de rendu  60 et  200 fps...


 je dirais meme ca de faon 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 dbarquent  la pelle, avec leur "shader 42.0", leur "binary space partitionning of the mega death", leur 42 formats de modles 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 honntement, lequel se dmarque 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 crer 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
 ::lol::

----------


## Sixissor

Je suis content de voir que a provoque des ractions  ::): 




> 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  ::mouarf::   (mme si je sais pertinament que j'ai une vision utopique des choses...)

Le problme 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 vido. En thorie il s'agit d'un monde qui est toujours en constante volution et  la pointe de la technologie et des techniques de rendu avances, etc. Pourtant voir que les BSP sont utiliss 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 gnie.




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


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




> 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 rpondu  une de mes questions: 



> Vous vous faites comment ? Vous vous lancez cash dans un BSP ou un Octree sans rflchir ou vous essayez aussi de penser  une nouvelle mthode ?

----------


## 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...

----------


## Sixissor

> ce n'est pas parceque doom est le premier JEU  utiliser les BSP que le principe du BSP n'a pas t invent avant...


On est d'accord, et a amplifie d'autant plus l'ge de cette technologie.

----------


## LapinGarou

Il me semble que chez ID, ils font aussi de la recherche et dveloppement (d'ailleurs en ce moment mme ils ne savent pas trop quoi faire de leur nouveau moteur 3D : fps, rts...) avant de sortir un nouveau moteur 3D, tous comme chez Crytek, il suffit de voir les vidos de Crysis pour se rendre compte qu'ils ne se sont pas contents de reprendre des algorithmes tout faits. Mais c'est sr que tant que a marche, beaucoup comptent gagner du temps de dveloppement sur les choses dj maitrises et qui ont fait leur preuves  ::?:

----------


## xterminhate

La diffrence entre deux moteurs est aussi du cot :
- du support et la documentation,
- des outils (diteurs,etc),
- du prix (licence,royalties,etc).

(Histoire de troller un peu)

Amicalement,
Xter.

----------


## 5:35pm

il n'y a vraiment pas a remettre en question le rendu via BSP, c'est la technique la plus rapide.
Puisque le topic est  "juste une idee, pour la performance", voici une autre idee:

Un moteur rachaichis chaque element de la scene a chaque frame.
si la camera se trouve par exemple dans une grande foret toute en 3d, la quantite de polygones visible devient enorme, donc voila l'idee:
a une distance proche de la camera, le rendu de chaque polygones se doit d'etre rafraichis a chaque frame. L'idee est tout simplement que les objet eloigne de la camera, ne soient pas rachaichis, et donc qu'a partir d'une certaine distance, on transforme l'objet 3d en billboard, que l'on ne rafraichira pas tant que la camera ne change pas significativement son angle par rapport a l'objet eloignee.

Cela reviendrais a avoir un champ de billboards loin de la camera, et plus de ressources pour detailler les objets proche.

voila l'idee  :;):

----------


## LapinGarou

C'est la technique utilise dans FarCry : au loin ce sont des sprites, puis plus on se raproche, plus l'objet "prend de la 3D".

----------


## 5:35pm

rhoo, ils y ont pense avant moi  ::?:   vraiment dommage... 
"plus l'objet prend de la 3D" tu veux dire que les vertices et textures sont generes progressivement?

Une autre idee, mais vu mon manque de connaissances, je sais pas si c'est automatiquement gere par l'Api graphique:

l'idee est de regrouper les vertices d'une mesh statique en 8 groupes.
a partir de l'axe y (la hauteur) du repere 3d de l'objet, on decoupe ce repere en 8 (donc, on groupe ces vertices selon quel angle de 1/4 pi radiant (soit 45 degres) il appartient.
Au final ca permet de directement savoir quel groupes de vertices seront affiches selon quel angle est vu l'objet.
le groupement eviterai de verifier si chaque face est visible, on verifie juste qu'el groupe est visible.
ca marcherais que pour les objets statique, et plus ou moins cilindrique.
j'espere m'etre fait comprendre; l'idee a besoin d'etre affinee, travaillee voire repensee, mais le concept est la...

----------


## Sixissor

Ok mais y'a quelques dfauts comme par exemple une colline devant toi. Avec ta mthode tu affiches aussi ce qu'il y a derrire la colline et que tu vois pas donc...

Et comment tu mets  jour les angles quand le personnage bouge par exemple ?

Non ta mthode ne m'a pas l'air au point...
Les octrees pour l'instant sont les meilleurs.

----------


## 5:35pm

il y a des defauts je sais bien, mais c'est juste une idee a creuser...
sinon... bah je n'ai aucune idee de ce qu'est la methode octree lol

----------


## xterminhate

Cf FAQ Developpez.com. Comrpendre les techniques actuelles me parait indispensable pour les amliorer ou en proposer de nouvelles.

----------


## Sixissor

> Comrpendre les techniques actuelles me parait indispensable pour les amliorer ou en proposer de nouvelles.


Pour les amliorer, entirement d'accord, mais pour en proposer de nouvelles, au contraire. Il faut plutt commencer de rien et "recrer la roue".
En tout cas a c'est ma mthode et elle a march  plusieurs reprises  :;):

----------


## Sixissor

> voila l'idee:
> a une distance proche de la camera, le rendu de chaque polygones se doit d'etre rafraichis a chaque frame. L'idee est tout simplement que les objet eloigne de la camera, ne soient pas rachaichis, et donc qu'a partir d'une certaine distance, on transforme l'objet 3d en billboard, que l'on ne rafraichira pas tant que la camera ne change pas significativement son angle par rapport a l'objet eloignee.
> 
> Cela reviendrais a avoir un champ de billboards loin de la camera, et plus de ressources pour detailler les objets proche.





> C'est la technique utilise dans FarCry : au loin ce sont des sprites, puis plus on se raproche, plus l'objet "prend de la 3D".


C'est une des mthodes que j'avais trouv aussi, mais tant donner que je veux rendre des environnements trs dynamiques, j'ai laiss tomber.
Nanmoins a reste une bonne ide, et le plus important c'est que a marche !

----------


## bafman

juste pour info : carmack y avais deja pens pour quake 1  ::lol:: 
finalement il ne l'a pas fait car  l'epoque il avait des problmes avec l'eclairage...

----------


## 5:35pm

Je viens de recevoir "3d game engine Architecture", j'ai survolle les chapitres et ca m'a l'air d'etre de la balle les gars!
bien que complique pour moi, ce bloc de 740 pages expose un moteur de jeu batise "Wild Magic", utilisant OpenGl dans le livre, mais les sources du cd fournit egalement les parties en DirectX.

On rentre dans le code des l'introduction, avec le rendu d'un premier triangle auquel on applique une rotation, c'est d'ailleurs ce qui m'as beaucoup plus, on rentre des le depart dans le vif du sujet.
Ce livre est generaliste, il va traiter de chaque parties d'un moteur complet,  comme le rendu des mesh,  l'application de textures, les shaders, l'animation, les particules, la physique...
ce livre etant generaliste traite de tout mais ne traite pas tout a fond, mais le tout reste tres bien detaille.

voila pour mes premieres impressions, je vais l'etudier, et eventuellement soumettre une critique, mais je crois bien que je suis devant une mine d'or  ::D:

----------


## scepticimus

Bonjour tout le monde,

Existe-t-il un bench qui compare tous les moteurs 3D GNU ? Du genre:
Telle scne contenant 80.000 polygones ou vertices ou faces peuvent tre raffraichies  50 img/sec avec une rsolution de 1024x768 ? Je parle de perfs pures sans chichis :-))

PS: euh ... c'est le bon endroit pour ma question ?

----------


## 5:35pm

j'ai pas vu de comparatif, mais tout le monde te dira que Ogre est le meilleur  ::):

----------


## LeGreg

> mais cette maniere, se debarrasse de la couche abstraite, ce devrait apporter un gain niveau performances...


Et ton drawScene() il est magique ?

ou il fait lui aussi appel  des parties abstraites ?

(Aussi, la plus grosse partie du cot de l'abstraction n'est pas dans les appels aux fonctions virtuelles mais dans l'abstraction elle-meme)

LeGreg
ps : tap sur clavier Qwerty avec la bonne config (US-international sous windows xp).

----------


## Matthieu Brucher

> j'ai pas vu de comparatif, mais tout le monde te dira que Ogre est le meilleur


Ce qui est dbile sans preuve, a dpend de plusieurs facteurs tout de mme, dont la manire de programmer.

----------


## 5:35pm

> Et ton drawScene() il est magique ?
> 
> ou il fait lui aussi appel  des parties abstraites ?
> 
> (Aussi, la plus grosse partie du cot de l'abstraction n'est pas dans les appels aux fonctions virtuelles mais dans l'abstraction elle-meme)
> 
> LeGreg
> ps : tap sur clavier Qwerty avec la bonne config (US-international sous windows xp).


drawScene() n'est pas magique, juste une maniere d'illustrer le processus du rendu, pour exprimer l'idee.
S'Il y a une chose de certain, c'est que programmer un moteur 3d est toujours fait de difficiles compromis, c'est l'eternel "genericite VS specificite". et le mecanisme de l'abstraction permet la genericite, avec un certain cout.
voila une reponse respectueuse, LeGreg, malgres ton sarcasme.

Miles, c'est debile sans preuve c'est certain.
Les deux plus gros moteurs open sources sont Irrlich et Ogre.
Je ne juge pas seulement en fonction des perfomances, mais egalement en terme de facilite d'utilisation, des "features", de l'activite de la communaute...
et Ogre est loin devant. Ce moteur est aussi le seul open source qui fait aboutir des jeux commerciaux.
Je me souviens il y avait un debat sur le forum d'ogre "Irrilich vs Ogre".
quelqu'un a demontre qu'irrlich offre de meilleures performance en affichant un grand nombre de mesh low-polys. La conclusion etait qu'Ogre prefere afficher moins de mesh High-poly que plusieurs centaines de mesh low-poly.

----------


## LeGreg

> drawScene() n'est pas magique, juste une maniere d'illustrer le processus du rendu, pour exprimer l'idee.
> S'Il y a une chose de certain, c'est que programmer un moteur 3d est toujours fait de difficiles compromis, c'est l'eternel "genericite VS specificite". et le mecanisme de l'abstraction permet la genericite, avec un certain cout.
> voila une reponse respectueuse, LeGreg, malgres ton sarcasme.


Dsol il ne s'agissait pas d'un sarcasme mais d'une question sur comment tu voyais l'intrieur de la fonction drawScene(), qui serait l'quivalent de la fonction "runGame()" pour un jeu vido. C'est  dire que si ton abstraction est  ce niveau l, il n'y a pas beaucoup d'conomie. Comme tu le sais dj, les appels aux fonctions virtuels ont un cot,  ne pas ngliger, mais si c'est pour conomiser l'appel  une fonction, une fois par scne, ce n'est pas trs intressant.

De plus j'avais juste l'impression que dans ton esprit le cot de la "gnricit" et l'"abstraction" sont les appels virtuels. Comme je disais la majeure partie du cout d'une abstraction est dans l'abstraction elle-meme, plutot que dans les appels virtuels (tant que ceux-ci ne sont pas "out of control" bien sr). 

Quant  ton "optimisation", c'en est une, et qui marche bien si tu sais  l'avance sur quelle plateforme vas tourner ton executable, ce qui est souvent le cas, heureusement. On utilisait un systme similaire sur l'un de nos produits qui devait tourner  l'identique sur xbox, ps2, pc et gamecube (objet engine "abstrait", avec tous les membres encapsuls et remplac  la compilation par la version spcifique).

Joyeuses ftes !
LeGreg

----------


## 5:35pm

Donc on est bien d'accord.
 pour etre plus clair, ce que j'appelle, drawScene(), serait plutot RenderOneFrame(), (qui change en fontion de l'Api graphique), et est appelle a chaque frame.
Je vois pas a quel autre niveau l'abstraction pourrait avoir lieu, puisque cette methode ferait parti la classe s'occupe du rendu.




> De plus j'avais juste l'impression que dans ton esprit le cot de la "gnricit" et l'"abstraction" sont les appels virtuels. Comme je disais la majeure partie du cout d'une abstraction est dans l'abstraction elle-meme, plutot que dans les appels virtuels (tant que ceux-ci ne sont pas "out of control" bien sr).


J'avais pas compris sur le coup, et la ca y es c'est bon, merci pour l'info =)

----------


## scepticimus

reBonjour,
J'ai vu que le moteur Raydium (http://raydium.org) dit pouvoir afficher 80.000 vertices (=160.000 faces c'est a ?)  un frame rate correct (25 img/sec mini ??). Je trouve que c'est beaucoup. Dites-moi, je n'ai de connaissance que le rendu de 3ds MAX, je veux dire, le rendu Direct3D qui permet de manipuler les scnes et pour lui, 100.000 faces s'affiche correctement  30 ou 30 img/sec en 1600x1200 sur une ATI 8800.
J'image que la perf pure dont je parle doit tre sans texture, shaders et autres artefacts !

----------


## bafman

oula, ca fait un moment que les gens serieux ne parlent plus en nombre de polygones affich  ::mouarf::  
en fait ca depend de beaucoup trops de paramtres pour pouvoir indiquer quelque chose... pour augmenter la vitesse d'affichage, il suffit de desactiver tout shader/eclairage/textures/blending et autre, et d'afficher tout les polygones de faon qu'il ne fassent que quelques pixels, tout en affichant le plus proche en premier pour profiter de l'effet early zBuffer culling (voir mme mieux : desactiver le zBuffer  ::mouarf::  )

----------


## scepticimus

Et si je prennais ma question  l'envers:

Dans les scnes de jeux actuels, combien sont grs de polygones (avec un rendu correcte en 50 img/sec sur une carte moyenne du march et une rsolution moyenne) ? Cette question doit juste me permettre de savoir  peu prs quelle taille doit avoir un objet  peu prs.

----------


## LeGreg

> Dans les scnes de jeux actuels, combien sont grs de polygones (avec un rendu correcte en 50 img/sec sur une carte moyenne du march et une rsolution moyenne) ? Cette question doit juste me permettre de savoir  peu prs quelle taille doit avoir un objet  peu prs.


Tout ce que tu peux savoir sans faire d'exprimentation par toi-meme (benchmarker ton propre jeu sur une scne typique), c'est quels sont les pics de performance thoriques ("vitesse de la lumire") pour un traitement donn d'un systme donn. Un pic de performance c'est quelque chose qui n'est atteint que dans des conditions trs prcises. Avec de l'exprience tu peux  peu prs savoir quels sont les pics de performance qui sont les plus significatifs et quels sont ceux qui vont dfinir la vitesse de ton application (les facteurs limitants).

Imagine par exemple que tu aies une machine qui ait huit units de vertex shading distinctes, qui est donc capable de travailler en parallle sur huit sommets  la fois. Ces units sont trs simples et ne peuvent faire qu'une seule opration en virgule flottante sur des array de quatre flottants (un registre vectoriel typique) par cycle d'horloge. Le cycle d'horloge est dfini par unit et pour les vertex shader il est de 500Mhz soit, 500 millions de cycles  la secondes. Si ton sommet n'est constitu que de la position X,Y,Z et que la seule opration est une multiplication de ta position par une matrice de projection combine (M4x4), alors le vertex shader en question devrait prendre quatre oprations par sommet (des produits scalaires), soit quatre cycles d'horloge par sommet. Comme il y a 8 units qui travaillent  500Mhz, alors tes units de shading ne peuvent transformer que 1 milliards de sommets  la seconde. Autrement dit si tu dsires tourner  50 images par secondes, 20 millions de sommets par image. Combien de triangles cela fait-il ? Cela dpend du type de gomtrie,  si c'est une liste de triangles non indice donc sans rutilisation du cache, cela fait  6 millions 666 mille 666 triangles par image (cas 1). Si c'est un mesh indic avec un taux de rutilisation de 4 triangles par sommets en moyenne cela fait 26 millions 666 mille 666 triangles par image (cas 2). On est loin des 80000 donns ci dessus, hein !

Mais minute. Il y a une autre unit qui s'appelle le "chargeur d'attribut". Ce chargeur d'attribut lit les donnes de position en mmoire et les place dans les registres des units de vertex shader. Ce chargeur d'attribut est unique et ne travaille pas en parallle. Il n'est donc capable de fournir un seul registre vectoriel au vertex shader par cycle d'horloge (c'est son pic). Pour des raisons de simplicit, le cycle d'horloge du chargeur est le meme que celui du vertex shader. Pour chaque sommet trait, le chargeur va donc lire la totalit des attributs en entre par groupe de quatre flottants. Si ton sommet ne contient comme unique donne que la position X,Y,Z, alors on arrondit aux quatre flottants suprieurs et donc le chargeur ne peut charger que 500 millions de position par secondes. 500 millions de position par seconde, a veut dire que ton vertex shader va devoir se tourner les pouces pendant un certain temps et ne pourra traiter que 500 millions de sommets par seconde le reste du temps. Dans le cas 1, cela fait donc 3 millions 333 mille 333 triangles par image, dans le cas 2, 13 millions 333 mille 333 triangles.

Mais minute. Les positions se trouvent en mmoire vido. La mmoire vido est relie  la carte graphique par un bus qui travaille par rafale (burst rate) et compte sur un petit cache de niveau 1 pour absorber la latence des requetes non "burst". Si les accs  la mmoire vido sont prvisibles par le cache, on bnficie donc d'un taux de transfert optimal de 32 milliards d'octets par secondes (en supposant que le buffer est correctement entrelac dans quatre modules de DRAM 64 bits  1 Ghz chacune). On suppose qu'il est optimal de lire trois flottants autant que quatre pour simplifier le problme. Dans ces conditions optimale le cache fait son effet et on peut atteindre le dbit thorique de 32 milliards d'octets  la seconde, soit 2 milliards 666 mille 666 vecteur position  la seconde, aucune chance que cela limite le reste du processeur dans ce cas. Imaginons au contraire que les donnes dans le vertex buffer soit mal arranges et qu'entre chaque lecture d'une position il y a ait un conflit au niveau du cache, forant une relecture des donnes. Supposant que dans ce mode non optimal, les performances de la lecture en mmoire sont divises par 20. Dans ce cas on sera limit par la vitesse d'accs l mmoire et on ne pourra pas fournir plus de 888 888 (cas 1 -> cas 3) ou 3 millions 555 mille 555 (cas 2 -> cas 4) .

Mais minute. Aprs avoir t transform dans le vertex shader, le triangle doit etre projet et prpar pour la rasterization (phase de setup). Supposons que la partie qui fait le setup pour des raisons de simplicit et de cout ne peut traiter que un triangle tous les trois cycles d'horloge (toujours  500 Mhz). On se retrouve donc avec une limite dure de 3 millions 333 mille 333 triangle par image ( 50 images par secondes) dans tous les cas (cas 1,2,4 -> cas 5) sauf dans le cas 3 o l'on tait dj limit  888 888.

Que faut-il retenir ?
Que la carte graphique est une boite noire qui possde des leviers sur lesquels il faut peser pour obtenir la performance voulue. Que un chiffre donn tout seul ne signifie rien (donc a ne sert  rien que l'on te dise "mon moteur affiche 80000 triangles par scene".. cpu limited ? gpu limited ? sur quelle config ? avec quels calculs ?). 
Que les exemples donns ci dessus sont pour une carte imaginaire plutot haut de gamme. Que les ratios entre les units diffrent normment d'une carte  l'autre (y compris  l'intrieur de la gamme d'un meme constructeur).  Que la gomtrie traite par un jeu contient gnralement plus qu'une simple position (coordonnes de texture et couleur et traitement de la lumire). Et que le traitement de la gomtrie n'est que le quart de ce que constitue le pipeline graphique (donc gnralement pas limit par le traitement gomtrique mais plutot par le CPU ou par les pixel shader, ou la bande passante mmoire). Et que le triangle le moins cher est celui qui n'est pas envoy  la carte graphique  ::): .

Conclusion : lis le plus de docs que tu peux, pose les bonnes questions et fait tes propres benchmarks (en les comparant avec la thorie). 

LeGreg

----------


## mawww

Juste un petit message pour sixissor, qui s'insurge contre l'utilisation de BSP 13 ans apres DOOM...
Je voulais juste rappeler que les shadow volumes (gestion des ombres dans Doom3) ont t dcrit par Crow dans les annes 70, et on continue a les amliorer aujourd'hui, mais le boulot des dveloppeur de jeux ce n'est pas de developper de nouveaux algo, Ils les adaptent au materiel sur lequel ils veulent le faire tourner (ce qui est dja un boulot consequent, dcrire un algorithme et trouver un moyen de faire tourner rapidement sur la technologie actuel ca n'est pas le meme travail), il les optimisent (encore du gros boulot, john carmack par exemple a amlior l'implementation standard des shadow volumes en inversant le test stencil), mais resortir un tout nouvel algorithme pour faire un boulot qui est dja trs bien ger par un algo prouv, c'est un boulot de chercheur, pas de dveloppeur.

----------


## Invit

> 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.


hihi, je dirais que je partage ta philosophie!! J'avais exactement la mme ide et l'ide de changer de renderer dynamiquement ne m'allumait pas vraiment. 

 ::roll::

----------


## Sixissor

> resortir un tout nouvel algorithme pour faire un boulot qui est dja trs bien ger par un algo prouv, c'est un boulot de chercheur, pas de dveloppeur.


Aprs c'est comme le dilemne du soldat: obir aux ordres ou essayer de rflchir.

Il est tout  fait normal d'utiliser une technique dj prouve et efficace mais rien n'empche d'y rflchir. Aprs je reconnais que c'est plus le boulot d'une quipe de chercheurs plutt qu' des dveloppeurs qui doivent remplir des objectifs dans un temps limit.

Mais... Carmack n'tait-il pas un simple dveloppeur quand il a dcouvert de nouvelles techniques qui lui ont valu sa clbrit ?
Pourtant  la base il n'tait que dveloppeur, pas chercheur  ::): 
Et chercheur (dans ce cas)... N'est-ce pas un dveloppeur  la base ?

----------


## LapinGarou

+1 pour Sixissor, rien n'empche le dveloppeur de chercher, sinon en serait encore  pong. 
Les dveloppeurs ne font pas que mises  jour pour utiliser un algo sur le nouveau matriel, mais ils rpondent  une demande: ils traduisent une "intention" (comme un client qui demande un soft pour grer une base de clients) en langage machine, analysent tous les petits mcanismes ncessaires pour raliser la demande. 
Un algo peut tre cod de plusieurs faons diffrentes, et du coup tous les dveloppeurs ne sont-ils pas un peu "chercheurs" ? Et les chercheurs des dveloppeurs ?  ::D:

----------


## 5:35pm

mais alors... si on est aussi des chercheurs... ca veut dire qu'on a droit a une augmentation?  ::D:  
 ::dehors::

----------


## Matthieu Brucher

> mais alors... si on est aussi des chercheurs... ca veut dire qu'on a droit a une augmentation?


Vous tes mieux pays que des chercheurs dans le public, soyez content  ::aie::

----------


## shams

Etant en thse en imagerie numrique, je rejoint un peu ce qui a t dit prcedement, dans le sens o certains dveloppeurs cherchent et certains chercheurs dveloppent. Dans le cadre de la recherche, je vois pas trop l'intret de faire avancer le schmilblik si c'est pour pas que ca soit utiliser. Je fais ma thse pour une boite, donc les travaux seront bien mis en valeur. 

de plus, je crois que beaucoup de personnes qui utilisent un moteur se foutent de savoir comment il fonctionne, du moment que ca fait ce qu'ils ont demand. Et c'est dommage, parce que du coup, on peut passer  cot de pleins de trucs. 

En meme temps, j'ai l'impression que beaucoup de boite devraient parier un peu sur la recherche, c'est  dire laisser un gars avancer AVEC les developpeurs, sans (trop) se dire qu'il faut des resultats tout de suite. 

Les comptences de chacun sont complmentaires, non?!

PS: c'etait l'avis d'un jeune padawan de la recherche, et qui veut pas se retrouver uniquement developpeur  la fin de sa thse !!  :;): 

EDIT: on rejoint un peu mon post dans le concept...

----------

