Retrouvez cet article dans : Linux Magazine 89

Yafray est un moteur de rendu libre dont l’objectif est le photoréalisme. Bien que somme toute classique dans ses fonctionnalités, bien utilisé, il s’avère rapide et puissant, capable de résultats de très bonne tenue. Il en devient le compagnon de route de divers modeleurs, à l’image de Wings3D ou Blender lui-même.

A l’instar de Povray, Yafray repose sur un langage de description de scène (Scene Description Language ou SDL) pour l’instruire de ce qu’il faut rendre. Le fichier de description de scène est tout simplement un fichier XML formaté de façon spécifique. L’objectif de cette mini-série d’articles sur Yafray est d’apprendre à maîtriser son langage de description et l’utiliser de façon pertinente, en approfondissant notre connaissance de ses paramètres et rouages internes.

 

Yafray : le lancer de rayon pour les masses

1. Compilation et installation de Yafray

L’installation de Yafray devrait être triviale si vous utilisez les paquets pré-compilés proposés sur la page Downloads du projet (http://www.yafray.org/index.php?s=2). Malheureusement, ils ne fonctionnent pas à tous les coups ; par exemple, les paquets pré-compilés pour Debian Etch ne fonctionnent pas sur une Ubuntu. De plus, en tant que moteur de rendu, pour bénéficier des temps de calcul les plus courts possibles, optimiser le moteur de rendu en fonction de votre classe de processeur est une bonne idée. Compiler et installer soi-même Yafray est donc fortement conseillé, et ne devrait pas poser de souci majeur au lecteur " moyen " de GNU/Linux Magazine.

1.1 Outils et dépendances

Yafray est soumis à plusieurs dépendances qui nécessiteront donc l’installation de bibliothèques et outils variés pour permettre sa compilation. Les outils nécessaires comprennent bien évidemment le compilateur c++ gcc, ainsi que les scripts scons. L’installation de g++ est également absolument nécessaire, et est souvent oubliée par les apprentis linuxiens se lançant dans la compilation de Yafray sans trop lire la documentation. Les dépendances devant être résolues comprennent libc, libgcc et libstdc++, qui sont des dépendances courantes de gcc et g++. Leur installation risque donc d’être transparente pour vous. En revanche, vous devrez explicitement veiller à l’installation de libjpeg, libopenexr et zlib.

1.2 Compilation

Vous téléchargerez les sources de Yafray sur la page Downloads déjà citée du projet. Après avoir décompacté l’archive .tar.gz sur votre disque, vous vous rendrez dans le répertoire yafray ainsi créé et taperez :

 $ scons arch=athlon-xp

pour lancer la compilation. Bien sûr, vous adapterez la valeur de arch en fonction du processeur de votre machine. Les valeurs les plus courantes devraient être i686, pentium4 ou athlon-xp. La liste complète des possibilités se trouve ici http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options Si votre processeur ne se trouve vraiment pas dans la liste, lancez la compilation grâce à la commande scons seule.

1.3 Installation des fichiers

Pour l’étape suivante, vous aurez besoin des privilèges du super-utilisateur. Il vous faudra utiliser la commande suivante :

 $ scons arch=athlon-xp install

Pensez à bien spécifier la même architecture que précédemment, sinon scons recompilera à nouveau tous les fichiers, mais sans optimisation particulière, avant de les installer. Le répertoire d’installation par défaut est /usr/local. Les exécutables de Yafray seront donc localisés dans /usr/local/bin tandis que les librairies seront dans /usr/local/lib. Pour parfaire et conclure l’installation de Yafray, il vous faudra ajouter /usr/local/lib/ au fichier /etc/ld.so.conf et utiliser la commande ldconfig avec les privilèges du super-utilisateur.

2. Usage de Yafray à partir de Blender (et création de votre premier fichier XML)

Ce n’est pas l’objet de ces articles, mais quelques mots sur l’usage conjoint de Blender et Yafray peuvent vous aider dans votre apprentissage de ce dernier. Ouvrez une session de Blender. Allez dans le menu Scene (touche [F10]) et dans le panneau Render, sélectionnez YafRay à la place de Blender Internal. Deux nouveaux onglets se greffent au panneau Render.

Les principaux onglets relatifs au rendu avec Yafray depuis Blender

Jetez immédiatement un œil à l’onglet YafRay, et vérifiez que le bouton xml est activé. C’est grâce à lui qu’au moment du rendu seront créés les fichiers vous permettant de paramétrer finement Yafray. Faîtes le test avec la scène par défaut de Blender, en retournant dans l’onglet Render et en cliquant sur le bouton éponyme. La console de Blender nous renseigne sur les actions alors entreprises :

Starting scene conversion.
Scene conversion done.
No export directory set in user defaults!
Will try TEMP instead: /tmp
Yafray found at : /usr/local/bin/
COMMAND: /usr/local/bin/yafray -c 2 "/tmp/YBtest.xml"
Starting YafRay ...
Loading grammar ...
Starting parser ...
Parsing OK
Loading plugins from ‘/usr/local/lib/yafray’...
Registered arealight
Registered basicblocks
Registered basicshaders
Registered blendershaders
Registered globalphotonlight
Registered HDRI background
Registered hemilight
Registered mix block
Registered pathlight
Registered photonlight
Registered pointlight
Registered Shader Background
Registered softlight
Registered spherelight
Registered spotlight
Registered sss
Registered sunlight
Registered sunsky
found 18 plugins!
[Loader]: Added shader MAMaterial
starting build of kd-tree
=== kd-tree stats (0s) ===
primitives in tree: 12
interior nodes: 1 / leaf nodes: 2 (empty: 1 = 50%)
[Loader]: Added object OBCube
[Loader]: Added pointlight light LAMP1
[Loader]: Added constant background world_background
[Loader]: Added camera MAINCAM
Using a world resolution of 0.00114286 per unit
Rendering with 5 raydepth
2 anti-alias passes and 4 minimum samples per pass, 8 samples total.
Building bounding tree ... Object count= 1
OK
Light setup ...
Setting up lights ...
Finished setting up lights

Launching 2 threads

Render pass: [#############]
Saving Targa file as /tmp/YBtest.tga
OK
Yafray completed successfully

Vous noterez en particulier que le répertoire par défaut de Yafray est /tmp/, et que l’image de sortie est automatiquement enregistrée au format Targa sous le nom Ybtest.tga. La scène Blender, convertie au langage de description de scène propre à Yafray, a été enregistrée sous forme de fichier .xml dans ce même répertoire.

Le cube par défaut de Blender, rendu par Yafray : le début de la passion !

Ce fichier peut être ouvert et modifié à l’aide de n’importe quel éditeur de texte. Ce qui est particulièrement intéressant, c’est qu’il est parfaitement structuré, et donc relativement facile à parcourir. Nous insisterons sur le " relativement ". En effet, chaque maillage de la scène est décrit par une succession de points (décrivant les sommets du maillage) et de faces (décrivant les facettes du maillage). Pour les objets les plus simples, les fichiers .xml résultants resteront de taille modeste (quelques kilo-octets) ; pour d’autres scènes, il sera courant d’atteindre plusieurs méga-octets ! Il sera donc souvent plus facile de travailler sur la base d’un fichier .xml généré par un plugin ou un script d’export depuis Blender et/ou Wings3D (ou tout autre modeleur) vers Yafray, que de construire manuellement un fichier propre à Yafray, bien que cela soit bien sûr possible.

3. Structure d’un fichier XML de Yafray

Si vous jetez un œil sur le fichier .xml correspondant à la scène par défaut, vous risquez d’être impressionné par la quantité d’informations qui y figure. Cette sensation légitime ne durera qu’un court instant, car le fichier est clairement hiérarchisé et finalement facile à parcourir. En effet, la scène est décrite grâce à un système de balises qui ne sont pas sans rappeler celles du langage HTML ; il y a donc des balises ouvrantes et des balises fermantes, et entre celles-ci, des paramètres. Les balises et leur contenu forment un bloc, et chaque bloc instruit le moteur de rendu sur un élément de la scène. Le squelette d’une scène Yafray peut donc ressembler à quelque chose comme cela :

<scene>
     <shader>
     </shader>
     <transform>
          <object>
          </object>
     </transform>
     <light>
     </light>
     <camera>
     </camera>
     <filter>
     </filter>
     <background>
     </background>
     <render>
     </render>
</scene>

Le bloc scene est celui qui englobe tous les autres. Il permet de délimiter clairement la scène qui doit être rendue. Le bloc shader définit un matériau. Il peut bien évidemment y en avoir plusieurs (au moins un par objet présent dans la scène), mais chaque bloc shader doit être défini avant qu’il n’y soit fait appel, généralement par un bloc object. Généralement, un bloc shader contient un bloc attributes. Le bloc transform permet de définir la matrice de transformation de l’objet (localisation, rotations, échelle...). L’objet est ensuite défini dans un bloc qui lui est propre, mais contenu par le bloc transform. Le bloc object contient la géométrie de l’objet rendu. Il contient généralement un bloc mesh, lui-même contenant un bloc points et un bloc faces. Le bloc light définit une source de lumière. Le bloc background définit l’arrière-plan du rendu. Le bloc camera définit non seulement la position et la direction d’observation de la caméra de la scène, mais aussi la résolution de l’image rendue ou les paramètres de flou focal. Le bloc render permet de définir les paramètres de rendu, la qualité de celui-ci ainsi que, bien sûr, un fichier de sortie. La notion la plus importante à retenir est que le moteur de rendu va parcourir ce fichier du haut vers le bas, et que l’ordre d’occurrence des éléments a son importance. En effet, si un bloc fait appel à des éléments définis dans un autre bloc, ce bloc doit impérativement être défini avant, c’est-à-dire, se trouver en amont dans le fichier. C’est le plus souvent le cas avec les objets, qui font appel à un shader, celui-ci devant être défini avant que le moteur de rendu n’arrive au bloc propre de l’objet. C’est également le cas du bloc render, qui peut faire appel à un arrière-plan ; le bloc background correspondant devra donc être défini en amont du bloc render.

4. Quelques bases rapides et utiles

Plutôt que d’attaquer, bille en tête, la syntaxe particulière de Yafray, nous allons survoler quelques-uns des éléments les plus couramment utilisés. Ainsi, vous appréhenderez plus facilement les prochaines parties de cette mini-série. Pour cela, il va nous falloir un exemple concret, et quoi de mieux que le fichier XML de la scène par défaut de Blender ? Si vous avez suivi scrupuleusement les instructions de section 2 de cet article, vous devriez trouver un fichier nommé Ybtest.xml dans votre répertoire /tmp/. Ouvrez-le avec votre éditeur de texte préféré, et découvrez-en le contenu.

<scene>
<shader type="blendershader" name="MAMaterial" >
	<attributes>
	     <color r="0.800000" g="0.800000" b="0.800000" />
	     <specular_color r="1.000000" g="1.000000" b="1.000000" />
	     <mirror_color r="1.000000" g="1.000000" b="1.000000" />
	     <diffuse_reflect value="0.800000" />
	     <specular_amount value="0.500000" />
	     <alpha value="1.000000" />
	     <emit value="0.000000" />
	     <matmodes value="traceable shadow" />
	     <diffuse_brdf value="lambert" />
	     <specular_brdf value="blender_cooktorr" />
	     <hard value="50" />
	</attributes>
</shader>
<transform m00="1.000000" m01="0.000000" m02="0.000000" m03="0.000000"
           m10="0.000000" m11="1.000000" m12="0.000000" m13="0.000000"
           m20="0.000000" m21="0.000000" m22="1.000000" m23="0.000000"
           m30="0.000000" m31="0.000000" m32="0.000000" m33="1.000000">
<object name="OBCube" shadow="on"  shader_name="MAMaterial" >
	<attributes>
	</attributes>
	<mesh autosmooth="0.1" has_orco="on" >
		<points>
		<p x=”1.000000” y=”1.000000” z=”-1.000000” />
		<p x=”0.999999” y=”1.000000” z=”-1.000000” />
		<p x=”1.000000” y=”-1.000000” z=”-1.000000” />
		<p x=”0.999999” y=”-0.999999” z=”-1.000000” />
		<p x=”-1.000000” y=”-1.000000” z=”-1.000000” />
		<p x=”-1.000000” y=”-0.999999” z=”-1.000000” />
		<p x=”-0.999999” y=”1.000000” z=”-1.000000” />
		<p x=”-0.999999” y=”1.000000” z=”-1.000000” />
		<p x=”1.000000” y=”1.000000” z=”0.999999” />
		<p x=”1.000000” y=”0.999999” z=”1.000000” />
		<p x=”-1.000000” y=”1.000000” z=”1.000000” />
		<p x=”-1.000000” y=”1.000000” z=”1.000000” />
		<p x=”-1.000000” y=”-1.000000” z=”1.000000” />
		<p x=”-1.000000” y=”-0.999999” z=”1.000000” />
		<p x=”0.999999” y=”-1.000000” z=”1.000000” />
		<p x=”0.999999” y=”-1.000000” z=”1.000000” />
		</points>
	<faces>
		<f a="0" b="2" c="4" shader_name="MAMaterial" />
		<f a="4" b="6" c="0" shader_name="MAMaterial" />
		<f a="8" b="10" c="12" shader_name="MAMaterial" />
		<f a="12" b="14" c="8" shader_name="MAMaterial" />
		<f a="0" b="8" c="14" shader_name="MAMaterial" />
		<f a="14" b="2" c="0" shader_name="MAMaterial" />
		<f a="2" b="14" c="12" shader_name="MAMaterial" />
		<f a="12" b="4" c="2" shader_name="MAMaterial" />
		<f a="4" b="12" c="10" shader_name="MAMaterial" />
		<f a="10" b="6" c="4" shader_name="MAMaterial" />
		<f a="8" b="0" c="6" shader_name="MAMaterial" />
		<f a="6" b="10" c="8" shader_name="MAMaterial" />
		</faces>
	</mesh>
</object>
</transform>
<light type="pointlight" glow_intensity="0.000000" glow_offset="0.000000" glow_type="0" name="LAMP1" power="29.999983"
cast_shadows="on" >
	<from x="4.076245" y="1.005454" z="5.903862" />
	<color r="1.000000" g="1.000000" b="1.000000" />
</light>
<background type="constant" name="world_background" >
	<color r="0.056563" g="0.220815" b="0.400000" />
</background>
<camera name="MAINCAM" type="perspective" resx="800" resy="600"
	focal="1.093750" aspect_ratio="1.000000"
	dof_distance="0.000000" aperture="0.000000" use_qmc="on"
	bokeh_type="disk1" bokeh_bias="uniform" bokeh_rotation="0.000000" >
	<from x="7.481132" y="-6.507640" z="5.343665" />
	<to x="6.826270" y="-5.896974" z="4.898420" />
	<up x="7.163761" y="-6.195171" z="6.239008" />
</camera>
<render camera_name="MAINCAM"
	raydepth="5" gamma="1.000000" exposure="0.000000"
	AA_passes=”2” AA_minsamples=”4”
	AA_pixelwidth="1.5" AA_threshold="0.05" bias="0.001000" clamp_rgb="on"
	background_name="world_background"
 >
	<outfile value="/tmp/YBtest.tga" />
</render>
</scene>

Un bloc donné peut contenir différents paramètres, chacun compris entre un < ouvrant et un /> fermant. Par exemple, à l’intérieur du bloc camera se trouve le paramètre from suivant :

<from x="7.481132" y="-6.507640" z="5.343665" />

Le paramètre peut posséder plusieurs attributs (par exemple, ici : x=" ", y=" " et z=" "), chacun suivi d’un signe égal = et d’une valeur entre guillemets ". La balise du bloc peut elle-même comprendre divers attributs. Par exemple, le bloc suivant :

 <camera name="MAINCAM" type="perspective" resx="800" resy="600" />

permet de définir une caméra unique, en lui donnant un nom (name=" "), un type de rendu (type=" ") et une résolution de rendu (resx=" " et resy=" "). Il est en effet possible de définir plusieurs caméras (au travers de plusieurs blocs), chacune avec des attributs qui lui seront particuliers.

4.1 Le bloc transform

Il s’agit d’une matrice 4x4 de transformation " classique ". La portion 3x3 en haut à gauche correspond à la matrice de transformation (rotation, échelle, cisaillement) et le vecteur colonne (m03, m13, m23) représente la translation. La dernière ligne est " inutilisée " et reste toujours (0, 0, 0, 1). La diagonale (m00, m11, m22) représente l’échelle dans les directions (respectivement) x, y et z. Construire une matrice de transformation " à la main " est très difficile, car la simple rotation autour d’un axe va affecter plusieurs éléments de la matrice, chacun de ceux-ci étant une combinaison des sinus ou cosinus des angles de rotation. Par exemple, une simple rotation de 45° autour de l’axe z donne le bloc <transform> suivant, avec les autres rotations, localisation et échelle à leurs valeurs de base :

<transform m00="0.707107" m01="-0.707107" m02="0.000000" m03="0.000000"
           m10="0.707107" m11="0.707107" m12="0.000000" m13="0.000000"
           m20="0.000000" m21="0.000000" m22="1.000000" m23="0.000000"
           m30="0.000000" m31="0.000000" m32="0.000000" m33="1.000000">

En conséquence, la manipulation directe du bloc <transform> sera plutôt réservée à des mathématiciens enthousiastes ou avertis ; l’utilisateur moyen s’en remettra plutôt à l’exporteur XML (depuis l’application Blender ou Wings3d de son choix) pour la détermination de ces valeurs.

4.2 Le bloc camera

La syntaxe de ce bloc s’approche plus de ce que l’on peut voir dans des langages de description de scènes comme celui de Povray. Nous noterons en particulier les paramètres resx=" " et resy=" " qui définissent respectivement la résolution horizontale et verticale de l’image qui sera rendue. Le paramètre type=" " permet de déterminer le mode de la caméra : perspective et ortho sont deux classiques qui ne dépayseront pas les fans de Blender, mais il est également possible de compter sur les modes spherical (pour un rendu panoramique sur 360°) et lightprobe (pour obtenir l’affichage rond typique des light probes utilisés dans le cas d’illumination par images hdr). L’orientation de la caméra en elle-même est définie par trois points :

• from : dont les coordonnées x, y et z définissent le point-origine de la caméra ;
• to : dont les coordonnées x, y et z définissent le point visé par la caméra ;
• up : dont les coordonnées x, y et z définissent un point représentant le " haut " de la caméra ; la manipulation de cette coordonnée est très pratique pour faire " tourner " la caméra sur elle-même.

C’est également dans ce bloc que l’effet de flou focal est mis en place grâce aux paramètres dof_distance=" " et aperture=" ". Le flou est mis en place sur chaque pixel à l’aide d’une sous-géométrie qu’il est possible de déterminer. Il s’agit du bokeh, mais nous y reviendrons dans un futur proche.

4.3 Le bloc render

C’est ici que la qualité d’un rendu va se jouer. Tout d’abord, au niveau de la profondeur de récursivité des rayons lancés par le moteur, au travers du paramètre raydepth=" ". Plus sa valeur sera élevée, plus les inter-réflexions (objets réfléchissants, de type miroir) ou les réfractions (objets transparents, de type verre) seront rendues fidèlement. Traditionnellement, une image est rendue pixel par pixel, mais cette technique a tendance à produire des objets aux bords crénelés, très visibles et d’un impact désastreux sur le photoréalisme. L’anti-crénelage (ou anti-aliasing ou AA) est une technique qui consiste à sur-échantillonner les pixels rendus avec les couleurs des pixels voisins, ce qui a pour effet d’atténuer le crénelage et restituer des bords doux. Activer l’anti-crénelage nécessite de donner une valeur non nulle au paramètre AA_passes=" " ; bien sûr, plus cette valeur sera élevée, plus de fois l’anti-crénelage sera répété. À chaque passe, AA_minsamples=" " détermine le nombre de sur-échantillon appliqué au pixel. Vous noterez que c’est dans ce bloc qu’un chemin (ainsi qu’un nom) est attribué à l’image rendue par Yafray, grâce au paramètre outfile value=" ".

4.4 L’arrière-plan

L’arrière-plan est défini par un bloc de type background, mais est concrètement mis en place, dans le bloc camera actif, au travers d’un paramètre background_name=" " citant nommément l’arrière-plan à utiliser, parmi tous ceux potentiellement détaillés. Il existe plusieurs types d’arrière-plan, bien évidement mis en place par un paramètre type=" ". Parmi les possibilités, nous retrouvons l’image (nécessitant un attribut <filename value=" "/> indiquant le chemin vers l’image tga ou jpeg appropriée), l’arrière-plan constant (dont la couleur est déterminée par un attribut <color r=" " g=" " b=" "/>), l’image HDRI (nécessitant également un attribut <filename value=" "/> indiquant le chemin vers le fichier approprié ainsi qu’un paramètre mapping = "" indiquant un fichier de type probe ou spherical).

4.5 Le bloc light

Il existe différents types de lampes, mais les deux plus communes sont celles permettant de produire des ombres dures (type="pointlight") ou douces (type="spherelight"). Une fonctionnalité intéressante est la possibilité d’adjoindre à la source lumineuse une lueur (glow) grâce à la combinaison de paramètres glow_intensity=" " (qui détermine la puissance de l’effet), glow_offset=" " (qui gère la profondeur de couleur de la lueur) et glow_type=" " (qui décide du modèle de lueur à employer). Cette lueur permet à la lampe de devenir " visible " pour la caméra ainsi que pour les objets transparents. Toutefois, la lueur n’est pas visible sur un simple background (par exemple <background type="constant" name="world_background" >) : c’est une erreur courante des utilisateurs novices de Yafray, la parade étant simplement de disposer des objets (murs, plafonds et autres) en arrière-plan de la lampe.

4.6 Le bloc object

Yafray ne supporte que les maillages, aussi n’existe-t-il aucune primitive comme c’est par exemple le cas pour Povray. Il faudrait donc certainement être un brin masochiste pour essayer de décrire des figures complexes à partir d’un éditeur de texte directement dans le fichier XML : ce format, ainsi que le SDL de Yafray, n’ont pas été conçus pour cela. Yafray est et ne restera jamais rien d’autre qu’un moteur de rendu, un compagnon pour votre outil de modélisation préféré, quel qu’il soit. Directement dans la balise object, il est possible de spécifier si l’objet émet des ombres ou non (shadow=" ") ainsi que le nom du shader (qu’il conviendra d’avoir défini auparavant) qui lui sera attribué. Le maillage est lui-même décrit à l’intérieur du bloc object, entre deux balises <mesh> et </mesh>. Le paramètre autosmooth=" " est utile pour spécifier si les facettes de l’objet sont visibles, ou si le shading des facettes est lissé de façon à ce que l’ombrage de l’objet soit parfaitement continu. Enfin, le bloc mesh contient lui aussi deux blocs : un bloc points et un bloc faces, qui permettent de définir la géométrie du maillage. Il est important de noter que Yafray ne supporte que les triangles, mais aucunement les quadrangles. Lors de l’export du cube par défaut de Blender, par exemple, vous obtiendrez 12 facettes au lieu des 6 que vous seriez normalement en droit d’attendre pour un cube (2 triangles par facette) : pas d’inquiétude, c’est normal ! La première ligne précise les points à considérer pour la construction de la facette triangulaire, la seconde précise l’origine Orco pour la texture, la troisième, à nouveau les points de construction, et ainsi de suite. Enfin, pour chaque facette, il vous est possible de définir un shader à appliquer (shader_name=" ") ; comme précédemment, le shader en question devra avoir été défini au préalable au sein d’un bloc shader.

4.7 Le bloc shader

Ce bloc a une structure extrêmement simple, mais il fait partie de ceux qui sont les plus riches en paramètres et options. Outre les paramètres typiques (type=" " et name=" ") que l’on retrouve dans la balise ouvrante, le bloc shader contient un sous-bloc attributes, où les choses les plus intéressantes se jouent. C’est en effet ici que les différents paramètres du shader sont spécifiés, et l’utilisateur régulier de Blender n’aura pas grand mal à reconnaître et retenir les principales options. Les trois couleurs de base, color, specular_color et mirror_color, sont chacune définies par les classiques composantes r=" ", g=" " et b=" ". Le paramètre Ref de Blender trouve son équivalent dans l’attribut diffuse_reflect value=" ", tandis que le lien avec les autres attributs est souvent très facile : specular_amount value=" " pour Spec ; hard value=" " , alpha value=" " et emit value=" " pour les propriétés homonymes de Blender, etc. Les types de shaders, qu’ils soient de type diffus ou spéculaire, sont déterminés par les attributs diffuse_brdf=" " et specular_brdf=" ".

Conclusion

Nous n’avons bien sûr fait que survoler la syntaxe particulière de Yafray, mais nous en avons désormais une vision d’ensemble, et c’est là tout le but de cet article. Pour fonctionner, Yafray repose donc sur un SDL qui lui est propre. Mais contrairement au SDL de Povray, il n’est pas prévu pour composer des scènes entières avec seulement un éditeur de texte. Un modeleur solide, nanti de la possibilité d’exporter les objets au format XML de Yafray est donc d’une rigoureuse nécessité. L’éditeur de texte devra être robuste, également, car si l’on considère le nombre de lignes nécessaires à la description d’un simple cube, on peut imaginer le résultat sur une scène entière composée de plusieurs entités organiques ! Les fichiers XML risquent alors de prendre des proportions déraisonnables. Apprendre à naviguer dans de tels fichiers éléphantesques est alors une absolue nécessité si vous souhaitez tirer parti des capacités remarquables de Yafray, et c’est exactement ce qui a motivé l’étude du fichier XML correspondant à la (très simple !) scène par défaut de Blender : si vous avez saisi sa structure, vous serez armé pour vous attaquer à n’importe quelle scène, pratiquement quelle que soit sa taille ! A vos éditeurs de texte et à bientôt pour l’exploration des talents cachés de Yafray !!!  Liens :

• Le site de Yafray : www.yafray.org [en]
• Les forums consacrés à Yafray :www.yafray.org/forum/index.php [en]
• La documentation de Yafray : wiki.yafray.org/bin/view.pl/UserDoc/WebHome [en]
• La foire aux questions (FAQ) de Yafray : wiki.yafray.org/bin/view.pl/UserDoc/FaqEng [en]
• De l’aide en français ? Les forums de Linuxgraphic : www.linuxgraphic.org/forums/ [fr]
• Le site de Blender : www.blender.org [en]
• Le site de Wings3D : www.wings3d.com [en]

Retrouvez cet article dans : Linux Magazine 89