2.4.2 Les choses qui ne fonctionnent pas comme prévu
"Comment activer l'animation ? J'ai utilisé la variable clock dans ma scène, mais POV-Ray ne calcule toujours qu'une page."
La méthode facile est de spécifier le paramètre de ligne de commande approprié sur la ligne de commande ou dans la ligne de commande des paramètres de rendu (dans la version de Windows). Par exemple, si vous voulez créer 20 pages, tapez ceci : +kff20.
Cela créera 20 pages avec la variable clock allant de 0 à 1. Les autres paramètres de la ligne de commande seront trouvés dans la documentation de POV-Ray.
Ken Tyler a aussi une bonne solution pour cela :
Dans le répertoire où vous avez installé POV-Ray vous trouverez un dossier appelé scenes puis un dossier appelé animate. Vous trouverez de nombreux fichiers exemples vous montrant comment écrire une scène en utilisant la variable horloge. Vous devrez toujours activer la caractéristique animation de POV-Ray en utilisant un fichier .ini avec l'information correcte ou les paramètres de ligne de commande. Je préfère, personnellement, utiliser le fichier ini. Si vous essayez ceci, ouvrez le fichier maître povray.ini depuis le menu des outils et ajoutez les lignes suivantes :
;clock=1
;Initial_Frame=1
;Final_Frame=20
;Cyclic_Animation = on
;Subset_Start_Frame=6
;Subset_End_Frame=9
Sauvez le fichier et fermez-le. Quand vous avez besoin d'utiliser la caractéristique animation, éditez simplement le fichier povray.ini et enlevez les commentaires des fonctions que vous voulez utiliser. Au minimum vous aurez besoin des options Initial_Frame et Final_Frame pour que ça fonctionne. Une fois que vous avez fini votre série de pages, assurez-vous de commenter les variables horloges dans le fichier ini. Après avoir rendu une série de pages, vous aurez besoin de les compiler dans un format d'animation voulu comme AVI ou MPEG. Voir mes pages de liens ou mes programmes pour vous aider à cela. POV-Ray n'a pas de possibilité interne pour faire cela, sauf sur la plate-forme Macintosh.
La version Mac n'utilise pas normalement les fichiers .ini at saute toute commande en ligne, mais utilise plutôt une interface complètement graphique. Pour activer l'animation, choisissez l'élément des paramètres de rendu dans le menu 'Edit' (juste en-dessous de "Preferences", il est titré "FILENAME Settings",
où FILENAME est le nom de votre fichier), cliquez sur l'élément 'Animation', et entrez l'information nécessaire dans les boîtes de texte.
Réponse courte : La seule façon de faire tourner POV-Ray sur de multiples processeurs est de lancer plusieurs copies de POV-Ray.
Réponse longue :
Faire un programme qui utilise de multiples flux n'est pas si facile. Voici quelques raisons qui font que c'est assez difficile avec POV-Ray:
Un excellent article sur ce sujet peut être trouvé à http://www.acm.org/tog/resources/RTNews/html/rtnv12n2.html#art3.
Voici une réponse de John M. Dlugosz avec des trucs utiles :
Le moteur de rendu de POV-Ray est un traitement monotâche, donc quand il est lancé sur un double Pentium Pro (éxecutant NT4) l'indicateur CPU ne va que jusqu'à 50%. POV n'utilise pas plus de la moitié de la puissance de la machine.
C'est le résultat de base, mais ce n'est pas exactement vrai : le moteur de rendu occupe un seul CPU, mais l'éditeur tourne sur son propre flux, et les fonctions du système d'exploitation (écriture dans le fichier, mise à jour de l'affichage, activité du réseau, tâches de fond) tournent sur différents flux. Cela donne un léger bonus, et le système utilise jusqu'à 54% des MIPS disponibles quand on le vérifie. Plus important, la machine a toujours un excellent taux de réponse, et l'édition ou d'autres applications continuent sans gène.
Mais pour un long rendu, il est dommage d'avoir un CPU ignoré. Que faire pour diviser le temps en deux (passer de 20 heures à 10, par exemple)?
La chose la plus simple est de faire tourner deux copies de POV sur la machine. Une copie rend la moitié haute, et l'autre s'occupe du bas. Puis faire passer les deux moitiés dans votre éditeur d'image.
Une chose à vérifier : ne lancez pas seulement les deux copies en les faisant pointer sur le même fichier ini et la même image. Ils s'écraseront mutuellement. Vous devez vous assurer qu'ils travaillent sur des fichiers différents.
Pour les rendus modérés, vous devez laisser une copie s'occuper du long rendu, et utiliser l'autre pour continuer le développement dans POV.
"Y a-t-il un moyen de générer une sortie en fil-de-fer depuis un fichier de scène POV ?"
Réponse courte : Non.
Réponse longue :
Vous devez comprendre la différence entre un modeleur comme 3D-Studio et POV-Ray dans la façon dont ils gèrent les objets. Ces modeleurs utilisent toujours des maillages de triangles (et quelques modeleurs utilisent des NURBS qui peuvent être très aisément convertis en triangles). Les maillages de triangles sont extrèmement simples pour représenter un format en fil-de-fer : seulement dessiner une ligne pour chaque côté de triangle.
Toutefois, POV-Ray gère la plupart des objets comme des entités mathématiques, pas comme des maillages de triangles. Quand vous dites à POV-Ray de créer une sphère, il ne la gère que comme un point et un rayon, rien de plus (à côté d'une possible matrice de transformation qui lui est appliquée). POV-Ray a seulement une notion de la forme de l'objet comme une formule mathématique (il peut calculer l'intersection d'une ligne et d'une sphère).
Pour des sorties fil-de-fer il faut un moyen de convertir cette représentation mathématique en triangles. C'est appelé la tesselation.
Pour quelques objets mathématiques, comme la sphère, la boîte, etc, la tesselation est quelque peu triviale. Pour d'autres éléments, comme la différence CSG, l'intersection, etc, c'est plus difficile (bien que non impossible). Pour d'autres éléments, c'est complètement impossible : surfaces non plates infinies comme les paraboloïdes et hyperboloïdes (bien, actuellement c'est possible si vous limitez la taille de la surface à une forme finie; bien que le nombre de triangles nécessaires puisse être extrèmement haut).
Il y a eu de nombreuses discussions sur l'incorporation de la tesselation dans POV-Ray. Mais puisque POV-Ray est seulement un moteur de rendu, pas un modeleur, cela ne justifie pas les efforts (l'ajour de la tesselation à toutes les primitives et CSG serait un travail lourd).
(Bien sûr, la tesselation peut donner d'autres avantages, comme la possibilité de simuler des transformations non uniformes aux objets comme le font de nombreux modeleurs...)
Si vous voulez seulement de rapides prévisualisations de votre image, vous pouvez essayer d'utiliser le paramètre de qualité de POV-Ray. Par exemple, fixer la qualité à 0 (+q0) peut donner un très rapide rendu. Voir aussi la question sur la vitesse de rendu.
"Puis-je spécifier un IOR variable pour un objet ? Y e-t-il un ajout qui peut le faire ? Est-ce possible ?"
Réponse courte : Non.
Réponse longue :
Il y a deux façons de définir une IOR variable pour un objet : le changement d'IOR sur la surface de l'objet et le changement d'IOR à travers l'intérieur de l'objet.
La première est physiquement incorrecte. Pour un IOR uniforme, il simule l'IOR physique assez précisemment puisque pour les objets avec une densité uniforme, la lumière se courbe à la surface et nulle part ailleurs. Toutefois, si la densité de l'objet n'est pas uniforme mais change à travers le volume, la lumière se courbera dans l'objet, pendant son trajet, pas seulement sur la surface de l'objet.
Voilà pourquoi une IOR variable sur la surface est incorrecte et que cette possibilité a été otée de POV-Ray 3.1.
De là nous pouvons déduire qu'un IOR constant est une sorte de propriété de surface de l'objet tandis qu'un IOR variable est une propriété de l'intérieur de l'objet (comme le média de POV-Ray). Bien sûr l'interprétation physique correcte de ce phénomène est que l'IOR est toujours une propriété de la totalité de l'objet (c.a.d. de l'intérieur), pas seulement de la surface (et c'est pour cela que l'IOR est maintenant une propriété de l'intérieur des objets dans POV-Ray); toutefois, l'effet d'un IOR constant n'a de conséquence qu'à la surface de l'objet et c'est ce que fait POV-Ray quand il courbe les rayons.
La simulation correcte pour un IOR variable, donc, serait de courber le rayon dans l'objet selon la densité de l'intérieur à chaque point.
C'est plus difficile qu'on ne le pense. Les raisons sont similaires à celles qui font que les tranformations non linéaires sont trop difficiles à calculer raisonnablement (autant que je sache, il n'existe aucun moteur de rendu qui calcule de vrais transformations non uniformes; les modeleurs de maillage déplacent seulement les sommets, ils ne transforment pas les objets; une vraie transformation non uniforme tordrait les triangles). De plus, les transformations non uniformes peuvent être simulées si l'objet est fait de plusieurs polygones (vous pouvez déplacer les sommets comme la plupart des modeleurs le font), mais vous ne pouvez pas simuler un IOR variable de cette manière.
L'IOR variable est (souvent) impossible à calculer analytiquement (c.a.d. selon une voie mathématique exacte) au moins en un temps raisonnable. La seule façon serait de la calculer numériquement (habituellement par super échantillonnage).
Le média dans POV-Ray fonctionne de cette manière. Il ne cherche jamais à résoudre analytiquement la couleur du média, mais il suréchantillonne le média le long du rayon et fait une moyenne des résultats. Cela peut être assez imprécis comme vous pouvez le voir avec la méthode 1 du média (la seule supportée par POV-Ray 3.1). Toutefois, quelques astuces peuvent être utilisées pour gagner en précision sans dépenser trop de temps, par exemple l'anti-crénelage (qui est utilisé par la méthode 3 du média). C'est un calcul facile parce que le rayon est droit, POV-Ray connait les points de début et de fin du rayon et il sait qu'il n'est en intersection avec rien le long du rayon (ainsi il n'a pas à faire des calculs d'intersections rayon-objet pendant le suréchantillonnage).
L'IOR variable est, toutefois, une histoire complètement différente. Ici, le programme aura à tirer de nombreux rayons le long du trajet du rayon courbé. Pour chaque rayon, il devra faire tous les calculs normaux d'intersection rayon-objet. C'est comme avoir des centaines de milliers d'objets transparents les uns dans les autres (avec max_trace_level placé suffisamment haut pour que le rayon les traverse tous). Vous pouvez facilement tester la lenteur de ceci. C'est TRES long.
Certains pourraient penser "pourquoi ne pas tirer une dizaine de rayons et utiliser une sorte d'anti-crénelage pour avoir les détails finaux, comme dans le méthode 3 du média".
Bien, cela peut fonctionner (je ne l'ai jamais vu testé), mais je ne pense pas que cela aide beaucoup. Le problème est l'inexactitude du suréchantillonnage (même en utilisant l'anti-crénelage). Dans le média, ce n'est pas un gros problème; si une très petite aire ombrée du média n'est pas détectée par le suréchantillonnage, le résultat ne diffèrera pas beaucoup de l'exact (puisque l'aire ombrée était si petite qu'elle a diminué la brillance de ce rayon mais pas beaucoup) et il paraîtra probablement toujours bon.
Avec l'IOR cela n'est plus vrai. Avec l'IOR même de très très petites aires peuvent avoir de très grands effets sur le résultat final, puisque l'IOR peut radicalement changer la direction du rayon, donnant un résultat complètement différent (même de très petits changements peuvent avoir de grands effets si l'objet derrière l'objet réfractant actuel est éloigné).
Cela peut avoir des effets désastreux. L'ior peut changer drastiquement d'un pixel à l'autre aléatoirement, sans parler d'une page à l'autre dans une animation.
Pour avoir un résultat plus ou moins précis, de nombreux rayons sont nécessaires; quelques rayons ne sont pas suffisants. Et tirer de nombreux rayons est extrèmement lent.
L'application photon utilise du raytracing par avance (c.a.d. envoyer des rayon depuis les sources de lumières), calcul la lumière de réflexion et de réfraction (caustiques).
Ce qui suit vient du site du développeur (Nathan Kopp):
"Ma dernière addition à POV est l'application photon. Le but de cet ajout est de rendre de vrais caustiques de réflexion et de réfraction. L'application photon a été d'abord introduite par Henrik Wann Jensen. C'est une façon de stocker l'information lumineuse récoltée d'un rendu en arrière-plan [sic] selon une structure de données indépendante de la géométrie de la scène."
C'est surprenant de rapidité et d'éfficience. Comment est-ce possible quand le raytracing par avance est si inéfficace ? Pour plusieurs raisons :
Comme vous l'avez vu, pour que l'application photon fonctionne de manière acceptable, vous devez dire au programme quels sont les objets pour lesquels vous voulez de la lumière réfléchie/réfractée ou non. De cette manière vous pouvez optimiser un peu la phase d'application photon.
Complément sur la question de la vitesse de rendu
| 2.4.2 Les choses qui ne fonctionnent pas comme prévu |
2.4.4 Les formats de fichier |