2.4.6.1 Est-ce que POV-Ray rend plus vite avec une carte 3D ?

"POV-Ray rendra-t-il plus vite si j'achète la dernière et la plus rapide carte vidéo 3D ?"

Non.

Les cartes 3D ne sont pas faites pour le raytracing. Elles lisent les maillages de polygônes et les rendent. Cela n'a rien à voir, ou très peu, avec le raytracing. Les cartes 3D ne peuvent pas calculer les caractéristiques typiques du raytracing comme les réflexions, etc. Les algorythmes utilisés dans les cartes 3D n'ont rien à voir avec le raytracing.

Cela signifie que vous ne pouvez pas utiliser une carte 3D pour accélérer le rendu (même si vous le voulez). Le raytracing fait de nombreux calculs numériques, et c'est très vorace en FPU. Vous gagnerez plus de vitesse avec une FPU très rapide plutôt qu'avec une carte 3D.

Ce que fait le raytracing est : calculer 1 pixel de couleur et (optionnellement) le placer sur l'écran. Vous aurez très peu de bénéfice avec une carte vidéo rapide puisque seuls des pixels individuels sont affichés sur l'écran.

2.4.6.2 Comment augmenter la vitesse de rendu ?

Cette question peut être divisée en 2 questions :

1) Quelle sorte de matériel dois-je choisir pour augmenter la vitesse de rendu ?

(Réponse de Ken Tyler)

La vérité est que les calculs nécessaires pour rendre des images sont à la fois complexes et voraces en temps. C'est un des types de programme qui placera votre FPU au maximum d'utilisation.

Les choses qui amélioreront la vitesse, en gros dans l'ordre d'apparition, sont :

1. Vitesse CPU
2. Vitesse FPU
3. Vitesse du bus et mémoire cache de premier et second niveau - Le plus est le mieux. Plus le bus est rapide, plus le processeur peut échanger ses calculs entre les deux caches puis les ramener. La vitesse du bus peut avoir un large impact sur les temps de calcul de la FPU et du CPU. Plus vous avez de mémoire cache, plus les opérations sont rapides parce que le CPU n'a pas besoin de relayer sur la mémoire RAM plus lente pour stocker l'information.
4. La quantité de mémoire, le type et la vitesse. Plus et plus rapide est indubitablement mieux. Swapper vers le disque dur pour augmenter la mémoire doit être considéré comme la dernière option pour accroître la mémoire. La vitesse de lecture/écriture sur disque est comparable à la marche à pied quand on conduit une voiture. Ici encore c'est la vitesse du bus qui est le principal élément dans la vitesse du rendu.
5. Votre système d'exploitation et le nombre d'applications ouvertes. Fermer les applications ouvertes, en incluant les éléments d'arrière-plan comme le moniteur système, le planificateur de tâche, les connections internet, le contrôle du volume, et toute autre application que les gens cachent dans l'arrière-plan, peut augmenter grandement la vitesse de rendu en éliminant l'éparpillement des cycles cpu. Ouvrez le gestionnaire de tâches et regardez ce qui est ouvert, puis fermez tout ce qui n'est pas strictement nécessaire. D'autres OS multi-tâches ont d'autres méthodes pour déterminer les applications ouvertes et elles doivent être utilisées respectivement.
6. Et enfin votre carte graphique. Cela peut vous sembler absurde, mais c'est vrai. Si vous avez une simple carte graphique 16 bits, vos temps de rendu, comparés aux systèmes avec le même processeur et la même mémoire, mais avec une meilleure carte, seront égaux. Pas plus et pas moins. Si vous jouez à des jeux vidéos ou si vous regardez des films mpeg, cela demande une bonne carte graphique. Si c'est le rendu et le raytraçage que vous voulez, alors investissez dans un système plus rapide et dans son architecture. Les cartes graphiques avec accélération matérielle sont faites pour supporter le dessin rapide de polygônes simples, majoritaires dans les jeux de l'industrie, et n'offrent aucun apport à l'intense calcul numérique qui vient avec des programmes de rendu/raytracing comme Pov-Ray, Studio Max et Lightwave. Si votre programme de modelage utilise les méthodes OpenGL alors une carte graphique qui supporte l'OpenGL aidera à l'accroissement de la vitesse de mise à jour des fenêtres, mais quand c'est le moment du rendu, cet apport disparaît.

2) Comment puis-je faire des scènes POV-Ray qui se rendront aussi vite que possible ?

Voici certaines choses qui peuvent accélérer le rendu sans compromettre la qualité de la scène :

• Les boîtes englobantes : quelque fois, l'encapsulage automatique de POV-Ray n'est pas parfait et des gains de vitesse considérables peuvent être faits en faisant un encapsulage manuel. Ces types d'objets en cause sont, par exemple, les différences et les intersections CSG, les blobs et les objets poly. Voir aussi : Vitesse CSG.
• Le nombre de sources de lumière : chaque source de lumière ralentit le rendu. Si votre scène a de nombreuses sources de lumière, peut-être devriez vous vérifier si vous pouvez en enlever sans trop perdre en qualité. Remplacez aussi les sources ponctuelles avec des projecteurs, chaque fois que c'est possible. Si une source de lumière éclaire une partie de votre scènes, un projecteur est meilleur qu'une source ponctuelle, car la source ponctuelle est testée pour chaque pixel, alors que le projecteur n'est testé que si le pixel est dans le cône de la lumière.
• Les aires de lumières sont extrèmement lentes à calculer. Utilisez aussi peu d'aires lumineuses que possible. Utilisez toujours les aires adaptatives sauf si vous avez besoin d'une très grande précision. Utilisez les aires de projecteurs autant que possible.
• Quand vous avez de nombreux objets avec la même texture, réunissez-les et appliquez la texture une seule fois. Cela réduira le temps d'analyse et l'utilisation de la mémoire. (Bien sûr en supposant qu'il n'est pas important que la texture se déplace avec l'objet...)
• Choses à faire pour des tests de rendu rapides :
• Utiliser les paramètres de ligne de commande (ex. +Q).
• Commentez (ou enfermer dans des déclarations #if) la majorité des sources de lumières, et ne laissez que le strict nécessaire pour voir la scène.
• Remplacer (avec des déclarations #if) les objets lents (commes les superellipsoïdes) par de plus rapides (comme les boîtes).
• Remplacer les textures complexes avec de plus simples (comme les couleurs uniformes). Vous pouvez aussi utiliser la déclaration quick_color pour cela (elle fonctionnera quand votre qualité de rendu sera à 5 ou plus bas, ex. paramètre de ligne de commande +Q5).
• La réflexion et la réfraction : quand un objet réfléchit ou réfracte la lumière (comme les objets de verre) il ralentit considérablement le rendu. Pour les tests, la désactivation de l'un d'eux ou des deux augmente grandement la vitesse. Par exemple, pendant le test d'objets de verre, il est habituellement suffisant de tester seulement la réfraction et d'ajouter la réflexion pour le rendu final. (Le problème avec les objets à la fois réfléchissant et réfractant est que les rayons rebondissent à l'intérieur de l'objet jusqu'à ce que max_trace_level soit atteint, et c'est très lent.)
• Si vous avez la réflexion/réfraction et un très haut max_trace_level, essayez de placer adc_bailout à quelque chose de plus grand que le 1/256 par défaut.

2.4.6.3 Vitesse des CSG

"Que valent les différentes sortes d'objets CSG en vitesse ? Comment les accélérer ?"

Il y a beaucoup de désinformation sur la vitesse des CSG. Une allégation très commune est que "la fusion est toujours plus lente que l'union". Cela n'est pas vrai. La fusion est parfois plus lente que l'union, mais dans certains cas elle est beaucoup plus rapide. Par exemple, considérons le code suivant :

global_settings {max_trace_level 40}
camera {location -z*8 look_at 0 angle 35}
light_source {<100, 100,-100> 1}
merge {
	#declare Ind = 0;
	#while(Ind < 20)
		sphere {z*Ind, 2 pigment {rgbt .9}}
		#declare Ind = Ind+1;
	#end
}

Il y a 20 sphères semi transparentes fusionnées ici. Un rendu de test prend 64 secondes. La substitution de la fusion par l'union prend 352 secondes (5.5 fois plus long). La différence en vitesse est notable.

Donc pourquoi la fusion est-elle plus rapide que l'union dans ce cas ? Bien, la réponse est probablement que le nombre de surfaces visibles joue un rôle important dans la vitesse de rendu. Quand les sphères sont réunies, il y a 18 surfaces internes, tandis que quand elles sont fusionnées, il n'y en a pas. POV-Ray doit calculer l'éclairage et l'ombrage de chacune de ces surfaces et c'est ce qui le ralentit. Quand les sphères sont fusionnées, il n'est pas utile de faire ces calculs pour ces 18 surfaces.

Donc est-ce que la fusion est toujours plus rapide que l'union ? Non. Si vous avez des objet complètement opaques, alors la fusion est légèrement plus lente, et dans ce cas vous devez toujours utiliser l'union. Cela n'a pas de sens d'utiliser la fusion avec des objets opaques.

Une autre allégation commune est que "la différence est très lente; beaucoup plus lente que l'union". Cela peut être aussi démonté. Considerez l'exemple suivant :

camera {location -z*12 look_at 0 angle 35}
light_source {<100, 100,-100> 1}
difference {
	sphere {0, 2}
	sphere {<-1, 0,-1>, 2}
	sphere {<1, 0,-1>, 2}
	pigment {rgb <1, 0, 0>}
}

Cette scène demande 42 secondes de rendu, tandis qu'avec des unions elle prend 59 secondes (1.4 fois plus long).

La chose cruciale est la taille des surfaces à l'écran. Plus la taille est grande, plus le rendu est lent (parce que POV-Ray doit faire plus de calculs d'illumination et d'ombrage).

Mais l'une des déclarations est plus proche de la vérité : les différences sont habituellement lentes à rendre, spécialement quand les objets membres de la différence sont beaucoup plus grands que l'objet CSG résultant. Cela parce que l'encapsulage automatique de POV-Ray n'est pas parfait. Quelques mots sur l'encapsulage :

Supposons que vous avez des centaines d'objets (comme des sphères ou autre chose) formant un gros objet CSG, mais que cet objet est assez petit à l'écran (comme une petite maison par exemple). Ce sera réellement lent de tester les intersections rayon-objet pour chacun de ces objets pour chaque pixel de l'écran. Cela est accéléré par l'encapsulage de l'objet CSG avec une forme englobante (comme une boîte). Les intersections rayon-objet sont d'abord testées pour la boîte englobante, et ne sont testées sur les objets dans la boîte que si cette dernière est touchée. Cela accélère considérablement le rendu puisque les tests ne sont faits que sur cette petite zone où se tient l'objet CSG et nulle part ailleurs.

Puisque c'est assez simple de calculer automatiquement une boîte englobante correcte pour un objet donné, POV-Ray le fait et vous n'avez pas à le faire vous-même.

Mais cet encapsulage automatique n'est pas parfait. Il y a des situations où c'est très difficile à calculer. Une situation est lors des opérations CSG de différence et d'intersection. POV-Ray fait ce qu'il peut, mais quelque fois il fait un piètre travail. Cela peut être spécialement vu quand le résultat est très petit comparé aux objets membres de la CSG. Par exemple :

intersection {
	sphere {<-1000, 0, 0>, 1001}
	sphere {<1000, 0, 0>, 1001}
}

(Cela est identique à une différence avec la seconde sphère inversée)

Dans cet exemple, les objets membres s'étendent de <-2001,-1001,-1001> à <2001, 1001, 1001> tandis que l'objet résultat est une petite lentille avec seulement 2 unités de long dans la direction x et peut-être 10 ou 20 unités dans les directions y et z. Comme vous pouvez le voir, il est très difficile de calculer les dimensions actuelles de l'objet (mais ce n'est pas impossible).

Dans ce type de cas, POV-Ray fait une énorme boîte englobante qui est inutile. Vous pouvez encapsuler ce type d'objet à la main (spécialement quand il a de nombreux objets membres). Cela peut être fait avec le mot clé bounded_by.

Voici un exemple :

camera {location -z*80 look_at 0 angle 35}
light_source {<100, 200,-150> 1}
#declare test = difference {
	union {
		cylinder {<-2,-20, 0>, <-2, 20, 0>, 1}
		cylinder {<2,-20, 0>, <2, 20, 0>, 1}
	}
	box {<-10, 1,-10>, <10, 30, 10>}
	box {<-10,-1,-10>, <10,-30, 10>}
	pigment {rgb <1, .5, .5>}
	bounded_by {box {<-3.1,-1.1,-1.1>, <3.1, 1.1, 1.1>}}
}

#declare copy = 0;
#while (copy < 40)
	object {test translate -20*x translate copy*x}
	#declare copy = copy + 3;
#end

Cela prend 51 secondes à rendre. En commentant la ligne 'bounded_by' le rendu passe à 231 secondes (4.5 fois plus lent).

2.4.6.4 Est-ce que POV-Ray supporte 3DNow ?

Non, et sans doute jamais.

Il y a plusieurs bonnes raisons à cela :

• 3DNow utilise des nombres en simple précision, tandis que POV-Ray exige (oui, il exige) des nombres en double précision. La simple précision n'est pas suffisante (cela a été testé en pratique).
  (Pour mieux comprendre la différence entre la simple et la double précision, imaginez que vous pouvez représenter des valeurs entre 0 et 1000 avec les nombres à simple précision. Avec les nombres à double précision, vous n'avez pas une fourchette de 0 à 2000 (comme certains le pensent), mais de 0 à 1000000. La différence est énorme et la simple précision n'est pas suffisante pour ce que fait POV-Ray).
• L'ajout du support pour 3DNow (ou tout autre caractéristique spécifique au CPU) à POV-Ray le rendrait dépendant de la plate-forme et non portable. Bien sûr, on pourrait faire un binaire séparé pour supporter le 3DNow, mais il n'y a que deux façon de le faire :
1. Compiler POV-Ray avec un compilateur qui peut automatiquement faire le code 3DNow pour C. Autant que je sache, un tel compilateur n'existe pas, qui convertit les doubles précisions utilisées par POV-Ray en simples précisions demandées par 3DNow. Je ne sais même pas si un compilateur supporte 3DNow.
2. Changer le code source à la main dans le but d'utiliser les instructions 3DNow. Cela demande beaucoup de travail (spécialement parce que vous devrez probablement utiliser l'assembleur en ligne). Le code source de POV-Ray n'est pas très petit. Cela vaut-il de tels efforts ?

Note : il y a certaines choses dans POV-Ray qui utilisent la simple précision (comme la gestion des couleurs). C'est un champ où quelque optimisation est possible sans dégrader la qualité de l'image.