Pour ceux qui suivent l'histoire (cf les articles précédents), vous savez que j'ai commencé à modifier FSrad pour générer des lightmaps calculées par radiosité pour Raydium. Ce programme est à la fois génial et mauvais. D'un coté, les algos sont d'une complexité incroyable, le programme cherchant même à modifier le modèle 3D qu'on lui donne pour l'optimiser pour ses propres besoin, et d'un autre coté, l'interface et le code sont à vomir et sa "mini-intelligence" pète un plomb régulièrement. Mais je commence à dompter la bête, petit à petit, et j'ai pu profiter de machines au boulot pour lancer les premiers calculs pour des objets un peu conséquents (autre que la classique boite avec 2 cubes dedans [Cornell Box]).
Après plusieurs heures de rendu, j'ai découvert ce soir un résultat extrêmement encourageant !
Mais avant, faut que je vous montre certaines choses.

J'ai utilisé pour ce test un de nos modèles, qui sans être incroyablement détaillé, possède déjà 30 000 points. Pour vous donner un odre d'idée de l'importance de l'éclairage, voilà une capture de ce terrain SANS la moindre lumière :

C'est pas sexy, hein ?

Notez que même si c'est pas l'objet ici, une "simple" texture offre déjà quelque chose de plus "lisible" par l'oeil :


Retour sur nos lumières : on enlève la texture (idem capture n°1, donc), mais on active l'éclaire actuel de Raydium, basé sur le modèle OpenGL (un vertex lightning, en somme) :

La compression JPG en moins, on distingue déjà beaucoup mieux ce que représente la scène, sans compter que la lumière (et 7 autres éventuelles) est dynamique. Notez en revanche qu'il n'y a aucune ombre dans cette scène.

Pour info, si on active la texture + l'éclairage, voilà le résultat (qui représente le rendu "normal" actuel de Raydium) :


Et j'en arrive à ma conclusion : les lightmaps avec radiosité. Attention, c'est sombre (faizez péter le gamma), ca ne supporte pas encore le texturage, mais bordel, c'est beau (je ne bien sûr suis pas complétement objectif, hum) :


Ca représente 8 textures en 128x128, pour un total de même pas 600 Ko. J'ai interrompu le calcul après 3h30 environ, il devait encore en rester pour 2h en gros. Il faut encore apprendre à ajuster encore plus finement les réglages, ajouter le support des textures, "trianguliser" les faces transformées par FSrad, mais c'est un énorme pas en avant pour l'éclairage sous Raydium !

Je me rend compte que j'ai aucune idée de ce que ça rend pour quelqu'un d'extérieur au projet, mais ici ca représente vraiment beaucoup de boulot "rentabilisé". Au cas ou, je vous en repasse une couche sous d'autres angles :







Merci d'avoir sacrifié vos yeux :)

Grmphf. Raydium ne sait faire que de l'éclairage "dynamique", au travers des capacités "de base" (lire : hors shaders) d'OpenGL. Ca à l'avantage d'être furieusement rapide, et de donner un effet bluffant dans la majorité des cas si on se débrouille bien. Mais il est évident que les lightmaps, même si j'ai beaucoup cherché à les éviter au début, deviennent de plus en plus intéressantes pour donner un cachet réaliste à une scène.
Pour rappel, une lightmap est une "carte d'éclairage", en général précalculée, que l'on applique pour moduler l'intensité lumineuse des textures de la scène. Pour réaliser ça à une vitesse intérressante, une carte vidéo doit disposer de plusieurs unités de texturage, qu'elle va utiliser en parallèle (multitexturing). Le principe est utilisé par la quasi totalité des moteurs 3D, même si ces lightmaps peuvent êtres complémentaires d'une autre technologie pour l'éclairage et la gestion des ombres (en particulier pour tout ce qui concerne l'éclairage dynamique).

Et justment, Raydium à toujours cherché à offrir un éclairage "puissant" (donc dynamique) que je n'ai jamais réussi à obtenir avec d'autres techniques (notez que je parle de mes capacités, et non de celles des autres techniques en question ;).
Ouais mais voilà, les techniques de génération de lightmaps par "Global Illumination" (principe qui consite à prendre en compte l'éclairage au sens large de la scène, en gros) commencent à donner des résultats franchement bluffants.. et c'est pour ça que je me suis penché sur un des ces algo : la radiosité.
Les résultats me scient : c'est magnifique ! Pour faire court, la radiosité consiste donc à générer des lightmaps "en placant la caméra sur chaque pixel de chaque triangle de la scène", pour compter la quantité de lumière reçue par ce point. Là ou ca tourne au génie, c'est que par défaut, tout est plongé dans le noir, sauf la (ou les) source de lumière, comme un simple point, par exemple. Seuls les "pixels" qui sont orientés vers ce point vont êtres lumineux, en fonction de l'éloignement et de l'angle. Sauf que la radiosité est récursive : on refait tout une seconde fois, en utilisant la lightmap générée à l'étape précédente ... résultat, un mur qui est dos à la lumière (complétement noir après la première passe, donc) va du coup "voir" la luminosité du mur qui est face à lui, ce dernier ayant recu de la lumière à la première passe. Ce mur, qui resterait noir avec une lightmaps "classique" va donc maintenant être légérement éclairé par la lumière ambiante qu'il percoit ... et on recommence comme ça des centaines de fois.

(image tirée de cette excellente documentation, à lire absolument : http://freespace.virgin.net/hugo.elias/radiosity/radiosity.htm)
Regardez bien ces ombres, douces, réalistes, ...

Je vous rassure tout de suite, la méthode que j'ai décrite un peu plus haut était volontairement fausse, il est bien sûr impossible de réaliser ce calcul pour chaque point de chaque triangle... des algos sont là pour aider à cette tâche (même si elle reste très lourde à réaliser).
Précisons au passage que c'est la méthode d'éclairage principale utilisée par Half-Life 2, qui reste à mon sens une des références du moment pour le réalisme de ses éclairages.

Bref, ça fait pas mal de temps que je louche sur ce principe de radiosité. Sauf que des documents comme celui ci (http://www.owlnet.rice.edu/~comp360/lectures/RadiosityText.pdf), même s'ils sont intéressants, dépassent de beaucoup les moyens de développement dont dispose Raydium !
Je me suis donc lancé à la recherche du Graal : le code opensource d'un algo compétent et viable de génération de lightmaps par radiosité... ca a duré des dizaines d'heures, mais je l'ai eu : http://www.fluidstudios.com/rad/

C'est une énorme application, en C++, pour Windows uniquement (et du vrai ... MFC, code dégeulasse style Visual C++, ..), qui ne sait travailler que sur ses formats de fichiers à elle.
Ouais, ça semble pas une bonne affaire au premier coup d'oeil, et c'est bien pour ça que je suis passé à coté au moins une dizaine de fois. Mais après 5 heures de recherches sous Google vendredi soir, je me suis résigné : c'est le seul morceau de code valable qui existe sur le net :)

Je vous passe les détails, mais après une lutte sans fin (la nuit de samedi à dimanche y est passée), j'ai réussi à compiler et linker l'application, et à la dompter petit à petit pour y intégrer nos propres formats de fichiers... c'est le tout début, mais les premières lightmaps de l'histoire de Raydium vont arriver sous peu, et avec la radiosité, monsieur !
Alors oui, vous allez surement trouver ça laid, mais faut pas oublier que c'est le tout début, que ca bug encore de partout, et qu'il va y'avoir des textures par dessus, et qu'une fois l'appli bien modifiée, les lightmaps vont passer de 128x128 à 512x512.
Ca donne ca, donc :


Avec encore un peu de boulot, on risque d'arriver à des choses très très sympas d'ici quelque temps.

Changement total de sujet pour aborder rapidement 2 points :

- BomberFrag : le projet avance, nous avons 2 modèles 3D de Seldaek (cf son blog), je dois envoyer une liste des sons dont nous avons besoin à G_T_O pour qu'il abuse de son talent, et j'ai enfin des idées neuves pour les problèmes (tout à fait normaux, je vous rassure) que je rencontre avec le code de l'appli : la physique du déplacement du perso, et la gestion des parties desctrucibles des niveaux au travers du réseau. Sachez aussi que Seldaek à disposé d'une version d'alpha preview 0.00001 très privée pour évaluer son boulot "ingame", et par un énorme hasard, nous a permis de découvir un sombre bug pour les version windows des applications Raydium sur certains P4 (détails ici :
http://memak.cqfd-corp.org/viewtopic.php?t=190 ).
Joignez vous.

- J'ai décidé d'implémenter dans Raydium une sorte de "capture d'écran 3D". Le principe consiste à faire une capture de la scène à un instant donné. Au lieu d'avoir un .JPG, le joueur (ou le développeur en phase de debug) disposera d'un modèle 3D de toute la scène à ce moment là (joueurs, balles, explosions, ...). J'y vois un bon argument marketing en faveur de Raydium, des possibilités pour faciliter le développement des applications Raydium, et surtout une feature assez fun pour le joueur !

Désolé pour les fautes ou les explications floues, la relecture va trainer un peu, le manque de sommeil se fait sentir :)

Peu d'avancées ce jour (en tout cas par rapport à ce que j'avais prévu de faire), mais des choses intéressantes :

- Le programme affiche quelque chose (c'est tout bête, mais hier il ne faisait que générer un niveau, souvenez vous).

- J'ai implémenté un début de joueur, mais je suis pas satisfait de la manière dont il se comporte (légers rebonds contre les murs, tendance à accrocher les angles, ...) ... il va falloir tweaker les paramètres de la physique pour avoir quelque chose de mieux (première idée : utiliser un cube au lieu d'une sphére pour représenter le perso). Pour représenter graphiquement le perso, étant donné que je n'ai pas de modèle 3D des protagonistes prévus (ceci est un message caché), j'ai utilisé notre bon vieux lego (tm, (r), copyrights samère) qui a déjà vécu pas mal de trucs (balles, roquettes, explosions, chutes, écrasements, ...) mais qui n'est pas tout à fait à l'échelle.

- L'implémentation des blocs destructibles au sein du niveau, modifiée (l'implémentation) par la suite pour utiliser la physique (pour la détection de collisions seulement, bien sur, faudrait pas que les blocs se mettent à bouger sous l'action des joueurs ou des explosions).

- La caméra, comme prévue : top-down, légérement décalée en -Y, avec un petit lag très artistique sur les déplacements du joueur.

- De la correction de bugs (déjà) : je me suis, par exemple, rendu compte que le parser lisait le niveau à l'envers sur l'axe Y (la hauteur, quoi ... logique : on lit du texte de haut en bas, et donc le fichier est parsé de cette manière là. Par contre, en géométrie, l'axe Y+ est souvent représenté vers le haut... d'ou ma bourde).
En fait, je crois que c'était le seul.

- Dans ma grande incompétance graphique, j'ai tenté de produire une bombe un peu cartoon ... :



J'avais prévenu ... :) Dans un premier temps, c'est suffisant pour faire mes premiers tests, et de haut, dans l'action, en ajoutant un générateur de particules sur la mèche, ca va ptet même être regardable.

Pour résumer ce qui se passe sur la partie code du projet, pour un truc écrit en quelques heures (10 ?), on peut commencer à imaginer ce que ca donnera. Certes, pour l'instant spa très joli (les modèles et textures sont de moi, donc ...), spa très fun (on ne peut pas jouer), yapa d'ambiance (pas de son, pas de mouvements, ...) ... mais si on arrive à ajouter tout ca au fur et à mesure, il y'a moyen d'arriver à quelque chose.

Que je vous montre (un jour je vous releaserais même des versions de développement sous windows, juré !) quand même ce que ça donne :



(et toujours le code dispo ici)

Les premières lignes de code sont lancées, et le programme possède une partie de son squelette, et le générateur de niveau est en place. Ce générateur utilise un fichier de description (texte, cf commentaires du blog précédent) et produit un modèle 3D depuis ce fichier. Les autres informations sont aussi lues (description, point de spawn, blocs destructibles, textures, ...) et stockées.

Voilà ce que ca donne :
- tout premier niveau créé :


- second niveau un peu plus conséquent :


Le tout est effectué à la volée par le jeu (pas de compilation ou d'étape intermédiaire).

Autre sujet : Seldaek, l'homme qui a osé franchir le pas et dire "oui !" à l'appel des artistes 3D (il nous en faut d'autres, au fait :) m'a fait parvenir une des ses créations pour vérifier la "compatibilité" des ses modèles avec Raydium : réussite totale (screenshot dans le moteur lui même) :



A suivre dans l'implémentation du projet : les blocs destructibles, les persos, les bombes.

(Pour les plus malades, le code source est dispo ici)

Contrairement à mes habitudes, je vais faire court : il y'a deux choses qui commencent à urger :
- trouver un nom pour le jeu
- trouver un autre endroit que ce blog pour le projet (ca empêche pas de donner des nouvelles de temps en temps ici).

J'en profite pour lancer un appel aux artistes 3D intéressés : il nous faut des modèles 3D (non animés) lowpoly pour quelques persos (cf cette image et le contraintes exprimées ici).

Résumé des épisodes précédents :

On a :
1) un début de troupe motivée
2) 6 joueurs : fidel, popestar, pronstar, saddam, supernazi et uncle (voir plus bas)
3) une vue de haut (probablement "dynamique")
4) des bonus : jet de bombes, saut, cocaïne (perso + rapide), endurance, plus de bombes, bombes plus fortes, passe muraille (sauf blocs non destuctibles), super vitesse, une roquette ? (tue persos & explose les bombes)
5) des malus : kamikaze (ou diarrhée, les bombes se posent automatiquement), lenteur, alcool (directions inversées)
6) des règles pour les bonus/malus:
- Il y'a des bonus permanents, les autres sont basés sur la jauge
- On ne peut avoir qu'un malus/bonus à la fois
- Ramasser un nouveau bonus/malus remplace l'ancien (sauf les bonus permanents, qui s'accumulent sur toute la partie)
- La jauge qui baisse petit à petit (bonus temporaire ou malus)
- Quand on ramasse un bonus/malus, il s'active automatiquement et sa jauge est à 100%
- 2 joueurs qui se touchent font passer leur(s) malus de l'un à l'autre
7) des niveaux autogénérés depuis des fichiers de description, et non des modèles 3D "issus d'artistes" (point encore à débatre, probablement)


Il nous manque :
1) il nous manque un nom (NoBomber ? BombDaWorld ? "eh mec, elle ou ma bombe ?", ...)
2) des précisions sur certaines règles : interactions joueur/bombe, par exemple (joueur pousse bombe ? bombe explose si joueur touche ? seulement si elle est à lui ? etc.)
3) il nous manque les icones pour les bonus et malus
4) il nous manque la modélisation 3D pour tout ce petit monde (persos, bonus, malus)
5) il nous manque les textures pour les niveaux (quelles ambiance(s) ?)
6) il nous manque les sons (quid d'avoir des prout pouet ping pang paf boum bing burp grrr à la place de sons pseudos réalistes ? - cf Big Red Racing)
7) il nous manque une/des musique(s). S'il y'a des motivés, faites signe (reste à définir le style), sinon des sites style http://www.magnatune.com/ peuvent nous aider.


Pour les contraintes :
- sons en WAV non compressés
- musique en .ogg
- modèles 3D en .3DS, en .blend, ... ou mieux que tout, en fichier DirectX texte (me contacter pour plus d'infos sur ce point si nécessaire). Les modèles doivent avoir 3 points par face, pour un total du coté des 1000 faces (style lowpoly)
- textures en TGA non compressées, tailles x et y limitées aux puissances de 2.
- les modèles des bonus/malus doivent êtres très reconnaissables (c'est pas un Jungle Speed).

Pour motiver les troupes, voilà 3 images qui montrent que ça avance :




Et les premiers greetz :
- CaptNCook, Dr.Loser, Seldaek.

Parmis les propositions précédentes, Bomberman sort vainqueur : reste donc à déterminer un certain nombre de choses :
- gameplay : clone total, ou on exploite les nouveautés (3D et moteur physique)
- nom du jeu
- avatars (liste, nom et "type", icones représentatifs)
- idée pour un premier niveau (dépendant du gameplay)

Il manque pas mal de choses, mais ca nous fait une bonne base juste avant d'attaquer les premiers modèles 3D et le code.

Les caractéristiques des modèles 3D seront elles aussi dépendantes du gameplay : si la caméra est plutôt éloignée de l'action, on peut se permettre des modèles beaucoup moins détaillés (nombre de faces et résolution des textures). Reste aussi le problème de l'animation.

Edit: pour les icones des joueurs, une TGA en 32x32 est l'idéal. Il nous faudrait aussi des icones pour les bonus (idem).
Edit de l'edit : pourquoi pas du 64x64 (ca fait à peine 25 ko en RAM vidéo)

Je vous 'espique :
Si vous suivez le blog, vous avez probablement compris que ca parle d'un moteur de jeu/3D. Vous avez peut être aussi lu l'incroyable et touchante histoire du netcode, enfin complet.
En conséquence, nous sommes (les-gens-qui-contribuent-à-Raydium) en train d'imaginer quel mini-jeu nous pourrions écrire pour tester ce nouveau netcode.

Si je parle de mini-jeu, c'est parce qu'il n'est pas question ici de ré-écrire une application complète et complexe, avec plusieurs mois de boulot, etc. Il s'agit ici d'étaler le projet sur quelques semaines (code, graphs 2D et 3D, sons et musique) au maximum et avec une équipe réduite.

Le but est donc (et je vous propose donc de participer à ceci au travers des commentaires) d'exprimer des idées de mini-jeux "efficaces", quel que soit le type (FPS, jeu de voiture, réflexion, ...). Les idées doivent si possible êtres très précises, avec les règles du jeu ("gameplay" si on veut), les grands axes graphiques, etc.

Ne pas perdre de vue :
- Qu'on a pas franchement le moteur 3D de Doom3, le CryEngine ou le Source Engine (regardez les dernières [en bas] captures d'écran pour faire une idée, ou les vidéos)
- Qu'il n'y a pas une équipe de 30 personnes à temps plein sur le projet
- Qu'il doit bien s'agir d'un mini jeu
- Qu'il doit être multijoueur (pour tester le netcode, c'est plus pratique)
- Qu'on dispose d'un moteur physique (eh, c'est pas rien :)

Je ne sais pas si ca va intéresser quelqu'un ici, mais j'aurais essayé ;)
Si au contraire il y'a une certaine motivation, pourquoi ne pas impliquer les gens concernés dans la création de modèles 3D, de sons, textures, ou même dans le code.

Juste une saute d'humeur : Le Wiki(*) du projet a été "attaqué" par un bot, et une partie du contenu a été remplacé par de la pub pour un site (planqué au fond du Japon, bien sur). Ca devait arriver, c'est le lot de tout les Wiki référencés par Google, mais c'est lourd.
Merci aux petites mains (Mildred, PRoSPeRe, Jean-Fran) qui ont remis tout ça debout très rapidement, mais c'est quand même très énervant d'imaginer le mec écrire ce bot et se dire que sa pub vaut plus que le contenu du Wiki (qui est le résultat de plusieurs semaines de boulot, soit dit en passant).

Cet article n'est pas très instructif, mais ça défoule.


* Wiki : site web que tout le monde peut éditer, ce qui l'ultra-idéal pour un projet "communautaire" pour héberger la FAQ, la doc du projet, ...