Quelques précisions sur les remarques de Lightness1024 :
1) Je ne sais pas si l´octree est aussi bon pour la détéection de collsion, en tout cas les BSP semblent l´être (enfin d´après ce que j´en ai lu). Si j´ai bien compris le principe des BSP (je dis peut-être carrément n´importe quoi), c´est dichotomique. Tu coupes ta scène en deux avec un plan, puis les deux autres morceaux restant encore en deux etc etc... Et après, tu testes ta caméra par rapport au plan, et tu sais ce qu´elle voit (idem pour la détection, par dichotomie on arrive rapidement à savoir où on est dans la scène).
Les CSG c´est plutot pour les modeleurs, dans un moteur 3d, c´est pas la bonne solution pour enleveer des polys (au contraire).
Le ZBuffer est maintenant cablé en hard, et oui, il est très important, il permet notamment pour nous autres feignasses d´éviter de devoir trier les polygones par ordre de profondeur (a par bien sur les polygones transparent utilisant un blending autre qu´additif).
Les portals sont un pou chiant à comprendre, mais ça a l´air assez puissant quand même.
2)Ben un moteur ça s´optimise, masi faut bien dire que le but du jeu, c´est de pouvoir avoir les scènes les plus immenses possibles, tout en gardant une rapidité correcte. Et là, y´a pas de secret : faut rendersier que ce que l´on voit, pas plus, pas moins. Le seul problème, c´est qu´a force de voiloir faire la chasse aux polygones invisibles, on finit par tomber dans l´excès, et on perd finalement plus de temps à faire les occlusions qu´aà renderiser, ce qui est somme toute assez ridicule. Donc il faut savoir faie la part des choses, et si 500 ou 1000 polygones passent à travers les mailles du filet, c´est pas forcément la catastrophe.
Et autres astuces : toujours sauvegarder l´état du moteur entre chaque frame. Par ex, si un objet n´était pas visible, et si depuis, la caméra n´a pas bouger et l´objet non plus, alors il est toujours invisible. Donc pas besoin de recalculer ça. Enfin vous voyez le principe.
3) Les highliths dynamiques tout le temps, non, c´est pas une bonne idée, et puis pkoi se servir d´une light dynamique si pour simuler une lampe qui ne bouge pas et qui éclaire des objets qui ne bouge pas non plus ?
Maintenant attention, Doom 3 c´est pas du moteur de tafiole, et il utilise (enfin d´après les screenshot que j´ai vu), le per-pixel lighting. J´ai un peu la femme de vous expliquer le principe, mais au lieu de calculer une intensité lumineuse par vertex, on le fait par pixel. Tout ça passe par des modes de texturages (comme les textures Dot3 quu permettent de faire un produit scalaire par pixel, utile pour le bump map par exemple). J´ai vu des exemples tourenr chez moi, c´set très joli, et oui, ça fout une claque dans la gueule quand on voit un objet éclairé comme ça.
4) Euh y´a DevIL (www.imagelib.org), pour charger/sauver tous les formats d´image les plus usités, super pratoche et simple d´accès (avec les source en prime).
5) Ca je sais pas, je fais pas de jeu moi : )
6) Oui, un petit moteur 3d avec rendu en cel-shading (qui est un peu en pause pour le moment, mais ça c´est ma flemme légendaire : )
--------------------------------------------------
En tout cas, faut pas se leurrer, faire un (vrai) moteur 3d bien balèze, c´est pas simple. Personnellement, j´en ai marre de voir des moteur 3d aseptisés, sans gouts, qui renderisent tous pareils, avec tous les mêmes trucs et qui se targuent de jolis screenshots. Il faudrait que les gens codent des moteurs 3d pour renderiser ce qu´ils veulent, et non pas qu´ils fassent des scènes pour renderiser ce qu´ils peuvent...
J´ai vu des démos assez sympatoches (voire franchement terrible), avec des moteurs 3d minimalistes. Tout est une question de gouts après, et de design
