Raydium - Radiosité (56k warning)
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 128×128, 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 :)
Je suis pas sûr d’avoir bien compris > ça tourne bien en temps réel ton nouvel éclairage ? Si oui, bravo ça rend vraiment bien ! Bon courage pour ajouter la prise en charge des textures.
Le rendu est temps réel, bien sûr, mais la génération de la lightmap s’effectue en 3h, ce qui risquerait de faire chuter le framerate si on le faisait en temps réel ;)
Je ne fait "que" reproduire la technique utilisée dans des jeux que Half-Life 2, par exemple.. ce qui est déjà énorme pour le projet.
Je commente jamais tes articles mais je suit avec intérêts ton projet…
J’ai regardé ces images sur un écran CRT beaucoup plus sombre (trop ?), et on a du mal à distinguer les ombres.
Est-il utile que je corrige la luminosité des 4 images, ou c’est juste cet écran qui est toupouri ?
Ca manque de bombes FFS !!!
Je me demande ce que les gens peuvent bien trouver à ce type …
Comment ce fait-ce que pour le même genre de map un tool du style q3map2 mettrait moitié moins de temps à calculer les lightmaps ?
Si tu actives la radiosité, que tu pousses les bounces à fond, sur un espace ouvert avec une lumière placée aussi haut (situation dans laquelle les BSP sont quasis inutiles), j’en doute. Et c’est sans compter que FSrad est plus généraliste que les outils du style q3map2. Le seul truc qui m’intéresse très beaucoup dans les q3map, c’est la license, et le fait qu’ils compilent sous Linux, eux …
Heu, le bounce, osef un peu, et puis 1 passage de bounce, meme sur une grosse map, ca ne dure qu’une poignée de secondes. A partir de 8 passes, la différence n’est même plus remarquable à l’oeil.
Le fait que l’unique lumiere soit placée en hauteur ne joue pas autant en termes de perfs. D’autant plus que q3map2 propose des optimisations des lightmaps comme le filter, qui applique un flou gaussien sur le crénelage du lightmap, ce qui permet de calculer les ombres "grossières" (en augmentant la taille du sample) sans différence notable par rapport à une compile avec une taille de sample très basse, rendant des ombres très fines et sur lesquelles il est inutile d’appliquer un flou.D’où un gain de temps notable.
Exporte ton level au format .map et essaie voir…
Je ne te parle pas de la même catégorie de logiciels, channie. FSrad est avant tout un outil de rendu de radiosité. Pour te donner un odre d’idée, j’ai laissé un rendu tourner cette nuit au boulot, et il était bien partit pour dépasser les 5000 passes. Le jour ou q3map2 arrivera a rendre la Cornell à la quasi perfection, je serais le premier à essayer de bricoler avec. Note que je me fiche complétement que les calculs prennent des heures, je cherche simplement a avoir un rendu le plus configurable possible.
De plus, j’imagine mal le temps que prendrait la modification de q3map2 pour qu’il lise et surtout écrive dans nos formats de données. Ceci dit, si l’exercice t’intéresse ;)