Présentation :

FsRadRay est une version modifiée de FsRad?, un logiciel open source de calcul de LightMaps par radiosité, développé par la société Fluid Studios ( http://www.fluidstudios.com/ ).
Cette application n'est disponible que sous windows, mais fonctionne sous Wine (testée sous la version 20040213-3mdk. Toute personne mentalement assez robuste pour tenter un portage Linux natif est la bienvenue).
Le but de cette application est donc de générer des cartes statiques d'éclairage, dans le but de rendre une scène (en général il s'agit d'un objet représentant le "sol") beaucoup plus réaliste.
Plus parlant que des mots, voilà un montage qui démontre l'intérêt des LightMaps :

Cette première image représente une scène, rendue dans Raydium (willou.c), sans éclairage :



Comme c'est systèmatiquement le cas dans les applications Raydium, activons l'éclairage matériel. Pour rappel, il s'agit ici de ce que l'on nomme souvent "Vertex Lighting", procédé de rendu approximatif mais rapide de l'éclairage :



On constate sur la précédente capture que l'éclairage n'est pas du tout adpaté à ce genre de scène, basée sur un environnement intérieur. Le rendu semble confu, sombre et surtout ne présente aucune ombre.
L'exemple qui va accompagner cette documentation va nous permettre de calculer des textures supplémentaires du genre de celle-ci :



Ces textures, une fois "mélangées" aux textures déjà présentes dans l'objet vont nous permettre un rendu beaucoup plus photoréaliste que les captures précédentes :



Avec une compression plus faible :

Mise en place de l'exemple :

Pour cet exemple, vous allez avoir besoin de plusieurs choses :

• RaydiumModler
• FsRadRay (disponible ici : http://raydium.cqfd-corp.org/data/bin_tools_win32/FSRad.exe )
• output_org.tri (utilisez RaydiumModler pour le télécharger : "/load output_org.tri" dans la console)

Principe de la radiosité :

Pour faire court, la radiosité consiste à 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.
Par défaut, tout est plongé dans le noir, sauf la (ou les) source de lumière, (un simple point blanc).
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. Chacun de ces calculs est nommé "itération", ou "bounce".

Présentation de l'interface et première configuration :

L'interface de FsRadRay est un peu brusque, mais bien organisée. La fonctionnalité principale est le gros bouton "Go", le reste de l'interface est dédiée à la configuration du calcul. Toute modification de cette configuration est automatiquement sauvegardée pour les futurs lancements de l'application.
Avant de lancer notre premier calcul, nous devons configurer l'application pour l'adapter à Raydium.

Dans les images suivante, les réglages propres à Raydium sont colorés en surbrillance.



Dans ce premier onglet, vérifiez que "l'adaptative degradation" est cochée (même si l'impact réel n'a pas encore été mesuré), et que les différentes cases à cocher du cadre le plus en bas sont bien cochées. La case "Enable the use of the ambient term for estimation of unshot energy" est décochée car elle est connue pour engendrer des problèmes sous Wine (vous pouvez donc la laisser cochée sous windows).
Direct light only et Limit total iterations seront expliquées dans le prochain chapitre.

Aucune configuration particulière n'est a appliquer pour le second onglet.



Dans le 3ème onglet, le réglage important (et imposé) est la taille des LightMaps (exprimée en pixels). Raydium est tout à fait capable de manipuler des textures de 512x512, et ce réglage est préférable pour des questions de performance (dans Raydium) et va limiter le nombre de fichiers générés par FsRadRay.



Dans le dernier onglet, utilisez le filtre de clamping "Saturate to 0/255 (retain color ratio)" pour éviter les erreurs engendrées par des éclairages trop puissants.

Ces réglages sont donc en théorie définitifs.

Configurer un calcul :

Génération des lampes :

Pour générer un éclairage dit "photoréaliste", il faut bien sûr placer des lumières à des endroits réalistes.
Pour notre fichier output_org.tri, FsRadRay va s'attendre à trouver un fichier output_org.tri.lamp. Ce fichier, assez proche de la syntaxe des fichiers .tri se présente de la manière suivante :



Créez le fichier output_org.tri.lamp à partir de ce contenu pour la suite de cette exemple.
Le format est assez simple (l'écriture "à la main" est tout à fait envisageable), avec les champs :
Pour chaque ligne (lire : pour chaque lampe)

• position (3 valeurs)
• orientation (vecteur, 3 valeurs)
• couleur (RGB, interval 0-1, 3 valeurs)
• facteur d'intensité (1 valeur)

La première ligne donne le numéro de version du fichier (version 0 imposée).

Il est possible de générer ces valeurs depuis Blender. Chargez votre modèle .tri dans Blender (cf TriVersBlender) et posez vos différentes lampes (type "Area" uniquement !).
Méthode : touche "espace" dans une vue, Add -> Lamp -> Area
Ces lampes sont directionnelles, vous pouvez donc les orienter (touche "r"), et elles n'émettent de la lumière que d'un seul coté ! (il vous est possible de placer 2 sources dos-à-dos pour simuler une source non directionnelle).



La taille des sources n'a pas d'importance, contrairement aux paramètres que vous trouverez ici :



Seuls energy, R, G et B sont utilisés.
Une fois vos réglages effectués, utilisez le script LampEXP?* disponible ici : http://wvs.cqfd-corp.org/browse.php?dir=/import/blender/ (cf BlenderChargerScript pour une aide rapide à l'utilisation des scripts dans Blender). Ce script génère un fichier output.tri.lamp que vous devrez renommer.

Vous disposez maintenant des deux fichiers nécessaires à la génération des LightMaps (.tri et .tri.lamp), vous pouvez configurer l'onglet Database de FsRadRay :



Le résultat va être ici un fichier output.tri et des fichiers du genre output.tri.*.tga pour les LightMaps.

Ajustements :

La première étape pour générer nos lightmaps va consister à régler la résolution des texels. Les texels sont des "mini-cubes" qui découpent l'espace 3D de votre objet. Le but est de trouver une taille qui permette une certaine précision dans le rendu (ombres pas trop floues), mais qui ne génère pas trop de données (chaque LightMap pèse plus d'1 Mo dans la carte vidéo).
D'après mon expérience, il semble que la formule suivante donne a peu près la taille d'une LightMap :
t / 512 * 4 ou t est la plus grande "largeur" de votre modèle (aidez vous d'un "/size" dans RaydiumModler).
Pour notre "output_org.tri", RaydiumModler donne :
-6.603604 < x < 6.603604, diff= 13.207208
-6.406655 < y < 6.406655, diff= 12.813310
-0.758080 < z < 0.758080, diff= 1.516160
13 est la plus grande valeur de "diff", donc :
13 /512 * 4 = 0.1015625 que l'on va tronquer à 0.1 sans problème (n'oubliez pas que le calcul lui même est une grosse approximation).
Un texel doit donc avoir une taille de 0.1 pour que l'ensemble du niveau "rentre" dans une LighMap?. Imaginons maintenant que je souhaite me permettre 2 LightMaps pour ce modèle pour un meilleur rendu : un texel peut maintenant être deux fois plus petit, soit 0.05 unités.
Il donc maintenant possible de rentrer cette valeur dans l'onglet Lightmaps du logiciel, en entrant la même valeur pour U et V, comme le recommande le texte à gauche des champs.

Le but va être maintenant de vérifier que cette valeur est correcte. Pour se faire une idée assez rapide du résultat du calcul, il est possible de cocher la case Direct light only dans l'onglet General de FsRadRay. Cette option ne va faire qu'une itération du cycle de calcul de lumière (pas de lumière diffusée, donc), pour un rendu souvent effectué en moins d'une minute. Une fois ce rendu terminé, regardez vos LightMaps, soit avec un logiciel de visualisation d'image, soit directement en regardant votre modèle avec RaydiumModler, willou.c, ...
Vérifiez que le rendu est correct, et que vous n'avez pas généré trop de LightMaps par rapport à la taille de votre modèle, et modifiez la taille des texels en conséquence si nécessaire.

Attention : Dans certaines conditions (valeurs de textels très faibles, par exemple) FsRadRay se trouve obligé de remanier le modèle 3D, en particulier en "découpant" certains triangles. Pour l'heure, FsRadRay ne SAIT PAS exporter ces modifications dans le fichier .tri de résultat, et va générer une (et même "des") erreur en conséquence. Si vous n'arrivez pas à contourner le problème en modifiant les valeurs U et V, contactez moi (XfenneC) pour que je me bouge pour écrire cette partie de l'application.

Calcul final :

Une fois vos valeurs de taille de texels configurées et vos lumières placées comme vous le souhaitez, vous pouvez décocher la casse Direct light only de l'onglet General. Vérifiez que la case Limit total itérations est elle aussi décochée, et lancez votre calcul.
En fonction de la taille (nombre de triangles) de votre modèle, ce calcul risque de durer plusieurs heures, voire plusieurs jours. Il est inutile de laisser le calcul s'affiner trop longtemps, les nuances devenants trop faibles pour l'oeil assez vite, d'autant que FsRadRay est capable de sauvegarder un calcul non terminé (cliquez sur stop, puis répondez "yes" aux deux questions posées).
Sur les modèles sur lesquels j'ai travaillé, je n'ai jamais eu à dépasser 30 minutes de calcul (et avec une certaine marge, puisque je n'ai en général pas réussi à faire la différence à l'oeil avec un calcul de 5 minutes).
Méfiez vous tout de même sur de gros modèles (plus de 50 000 points) ou les calculs deviennent réellement plus lourds. N'essayez pas de jouer sur la Limit total itérations, qui semble ne pas être très cohérente.

N'hésitez pas à compléter, corriger, commenter cette documentation.

---