Suivant les traces du Zythum project et de Serhum, je viens de m´atteller à la réalisation de mon propre moteur graphique grâce à l´API OpenGL
Le projet n´es pas encore très avancé mais il y a déjà quelques screen.
Plus d´infos ici :

http://perso.wanadoo.fr/thomasc/

C´est sympa.

Beaucoup de boulot en perspective.

Dommage que ce soit si eloignée de la conception de jeu ( mais bon un programmeur commence toujours par le bas niveau pour finir au haut niveau, tel est le chemin )

C´est pas très éloigné de la conception de jeu, vu que beaucoup de jeu ( d´équipe de création) dévelloppe leur propre moteur pour faire leur jeu.

Bonne chance alors Lag-it et tiens nous au courant.

Oh peut être pas si éloigné du domaine de la conception d´un jeu que ça
Et il est vrai qu´il y a pas mal de boulot à fournir, mais c´est très intéressant

Merci dnob700, les niouzes sont la pour ca

La vision d´un debutant est toujours la meme. Quand il regarde un jeu, il voit surtout un moteur 3D.

Or avec l´experience, on se rends compte que c´est deux choses distinctes. Et plus on a d´experience et plus on se rends compte que c´est vraiment distinct.

Un programmeur genial en 3D peut etre archi nul en conception de jeu et un maitre du game play, peut ne rien connaitre en 3D.

Avec mon recul, je considere ca vraiment comme deux choses completement separé. J´ai fait de l´affichage et du bas niveau quand j´etais jeune, mais je me suis rendu compte que c´etait pas du tout ca que de faire un jeu. Maintenant je fais l´inverse, j´utilise des moteur de jeu pour me concentrer sur le jeu en lui meme.

Mais bon faut passer par ces etapes la, c´est normal je le concois ( mais c´est loinnn de la creation de jeu )

Et même si c´est vraie,
Le moteur 3D d´un jeu est quand même l´une des pièce maitresse pour certain type de jeu.

Donc même si ce n´est pas la m^me chose que faire un jeu, si l´on veut faire un jeu il faut aussi faire un moteur ( a moins d´en utilisé un), c´est ce que je voulais dire dans mon précédent poste : il ne s´agit pas du tout, mais d´une étape quand même.

Je suis pas trop d´accord, un moteur 3D c´est pas la partie importante. C´est simplement la representation du jeu.

Tu peux avoir un moteur 3D de tueur et un jeu de merde. Un bon moteur 3D ne fait pas un bon jeu.

Alors qu´un bon jeu peut avoir une representation miteuse... ( 3D, fil de fer, gros pixels . ..)

La representation etant la chose qui se voit le plus, c´est ce qui a toujours interresser les programmeur en premier. Car on voit ce qu´on programme. C´est normal.

mais si tu prend des jeux comme farcry ou le futur HL2, il ne se vende que grace a leurs moteurs graphiques, qui sont excellent d´ailleurs.

Je ne dit pas que c´est bien, mais de temps en temps, ça devient quand même très important.

Un bon jeu aux graphisme de merde, malheureusement il va manquer quelquechose quand même, mais ca dépendra encore du type de jeu. ( on peut s´en conveincre avec des vieux jeu qui en leur temps était géniaux de par leur jouabilité et interet et qui maintenant ne sont plus que des " vieux jeux" sans interet)

Bon, je ne pense pas te conveincre, alors tant pis on restera sur nos positions ( c´est aussi de la diversité que nait la créativité).

Je dois avouer qu´ne réalité la conception de jeux m´intéresse moins que la programmation elle même, d´ou le projet
Ma is mes jeux préférés sont loin d´être ceux qui jouissent du meilleur moteur graphique

Note pour le screen concernant la lecture d´un fichier . map : les couleurs des faces sont générées aléatoirement lors de la conversion, car le moteur ne gère pas encore les textures

dnob700 > En effet tu ne me convaincra pas
Et ton exemple est mal chois car HL2 est certainement un des jeux qui sera le plus fouillé niveau scenario et interactions ( tout comme HL1). Le moteur graphique est a mon sens que la cerise sur le gateau. ( Pour FarCry, je sais pas, je connais pas trop).

Un bon jeu aux graphisme de merde

Si tu prends des " vieux" jeux comme Quake3 ou counterStrike qui sont encore ultra joués, pourtant ils ont des moteurs graphiques completement depassés. Les nouveaux jeux comme unreal tournament 2004 se jouent beaucoup aussi parcqu´ils en ont dans le ventre, pas parcqu´ils sont beaux.

Les gens etant assez betes, il faut qu´un jeu soit beau pour qu´il se vende. Du coup maintenant les jeux son " obligés" d´etre beaux, au detriment surement du jeu.

jeu qui en leur temps était
géniaux de par leur jouabilité

Tu peux essayer " Robotron" en arcade. C´est super vieux, super moche mais toujours aussi rigolo ( ca se joue avec deux manettes).

Mais bon cette parenthese est purement pour le fun. Lag it a dit qu´il etait interressé par la prog en elle meme, donc le mieux c´est faire du visuel. Tu as choisi le bon chemin Fonce !

c´est pas mal tout ça, je te souhaite plein de réussite, pas enore de textures ? dommage j´aurais pû écrire le loader, mais je suis trop occupé
long vie à lag-it

je t´encourage vivement ! !

tu te sers des techniques classiques ?
( définition des couleurs d´une face en multipliant la couleur vive par le produit scalaire du vecteur de vue par le vecteur normal afin d´obtenir une face un peu plus sombre quand elle est de coté)

vas tu faire un lissage de Gouraud ?
tu utilises quel algo de face caché ? Z-buffer ?
en hardware ou en software ?

Merci pour vos encouragements

Pour répondre aux détails techniques :
L´algorithme de faces cahé employé actuellement est celui d´OpenGL, il s´agit donc d´un Z-buffering en Hardware. Cependant à l´avenir, il sera remplacé par un système d´arbres BSP modifié, sur lequel je travaille actuellement, qui servira non seulement pour l´affichage des faces, mais aussi pour les test de collision.
Pour le lissage, je ne sais pas encore : cela dépendra de la rapidité du moteur lorsque que l´arbre et les textures seront implentées. POur le moment c´est du smooth.
Sinon pour le coloriage des faces : les couleurs de chaque triangles sont incluse dans mon format de fichier " .raw" et le moteur se contente de les rendre telle quelle, sans ombrages ou autres pour l´instant. L´objectif étant bien sûr d´utiliser les textures, lightmap ( et pourquoi pas bump maps, mais beaucoup plus tard ) . L´usage de Hammer ( ex. Worldcraft simplifiera la tache de créations des monde ) .
Pour l´instant, le convertisseur de fichiers . map en . raw génère aléatoirement une couleur pour chaque triangle, car ceux ci ne contiennent que des infos de texture, et rien sur la couleur.
Donc les objectif dans un futur proche :
- Finir le convertisseur . map en . raw ( pour obtenir toutes les faces et non pas une sur 2 )
- Récupérer les entrées utilisateur pour gérer le déplacement de la caméra.
- Support de textures.
- Système d´arbres BSP
- ET plus tard on verra.

Je précise que tout est fait par moi, avec l´aide de quelques tutos basiques et de beaucoup de docs sur les algorithmes.
Pour vous donner un appercu du rendu final, je compte arriver à celui de Half Life 1 ( attention : rendu, sans physiques, sons, netcodes dans un premier temps ) .
Une fois les textures, les entrées utilisateur gérées, une alpha devrait voir le jour, à moins que je ne la réserve pour les arbres BSP

" et pourquoi pas bump maps, mais beaucoup plus tard"

fais le en meme temps que tout le reste lié au texture, ça serait dommage de devoir apporter des modifs par la suite... Le plus chiant étant de calculer la map des binormales, et comme il me semble qu´OpenGL ne propose pas d´extension pour le faire, va voir dans les tools nvidia : y´a filtre pour photoshop sous forme de plugin. Tu save ta map de binormale, ensuite t´as plus qu´à blender avec un coef ou à écrire un petit shader et c´est tout bon. ( directx => 20 lignes...)

p-e que je me trompe mais on dirait sur ton screenshot que tu utilises des faces séparées ( inversion d´un vertex pour chaque face par rapport au rendu hammer) ; si c´est le cas, essaye de respecter les structures du fichier original ou de les retraiter par un algo pour maximiser les triangle strips, tu y gagneras en perfs et en mémoire.

pour le BSP, cf. le topic qui va bien, vive les versions " solid".

pour le rendu HL1, une fois des textures en place et un BSP, il te manquera juste qq trucs/effets, particules, eau, etc. mais le plus dur sera l´anim de persos ; sauf erreur de ma part, dans le jeu c´est fait à coup de vertex blending ( et on trouve plein de tuts expliquant comment faire ça avec un vertex shader)

bon courage...

Merci LGV

Concernant l´imprtation de fichier . map, j´y travaille : le problème vient du fait que dans ce format, le monde n´est pas représenté sous forme de triangles, mais de plans qui se coupent entre eux, ainsi un cube est représenté par 3(points)*6(plans) au lieu de 12(triangles)*3(points). La reconstitution du cube se fait en calculant les intersections avec les plans.
Le problème devrait être résolu bientôt...
Mais vaut il mieux que le moteur gère des triangles ou des plans comme dans les . map ? Le triangles sont plus rapides car ils delestent le processeur des calculs avant chaque affichage, c´est pour cela que je les utilise, mais si l´autre alternatives possède des points positifs, j´aimerai les connaitre.

Sinon concernant lightmap/bumpmap est autres, cela ne viendra qu´après la gestion des entrées utilisateurs et des textures ( je veux que cela ressemble d´abord à quelque chose ) et après l´implémentation du BSP ( qui constitue peut être la partie la plus complexe du projet ) .

" Mais vaut il mieux que le moteur gère des triangles ou des plans comme dans les . map ? "

les triangles ! ! y´a que ça de vrai ( enfin, avec l´archi des cartes actuelles). Sinon tu peux aussi gérer des formes implicites simples avec des patch 4x4 NURBS, et la tesselation se fait " à la volée", mais ça complique certains points ( => collisions notamment...). Bref, pas top pratique.
Autant que faire ce peu, gère des listes de triangles, groupes les par attributs communs ( textures notamment, pour éviter des changements d´états inutiles), sauvegarde à l´avance les transformations statiques éventuelles ( => display lists) et rends de grands blocs de vertices. Pour exemple, le perf killer majestueux, ce serait de tracer triangle par triangle en chargeant la texture associée à chaque fois.

" BSP qui constitue peut être la partie la plus complexe du projet"
avant que j´implemente un BSP, je trouvais ça super tordu aussi ; mais apres, on se dit que c´est quand meme bien foutu et assez " intuitif", c´est pourquoi le plus dur selon moi, sera la prise en charge de modèles animés ( si tu comptes en gérer)

J´ai zappé toute la partie technique du topic mais je tiens juste a dire quec´est excellent et que je suis pas pres de faire ca(enfin, pour de vrai, le screen je peux le reproduire sous paint LOOOOOL)

Moui je vais rester avec mes triangles, c´est le mieux
Je tâcherais de tenir compte de tes remarques concernant les performances pour le projet.
Et concernant les modèles animés, ce n´est vraient pas pour tout de suite
Je ne me suis as encore posé la question, mais j´ai entendu parler de quaternions pour de mouvements réalistes...