2.4.3 Autres choses en relation
"J'ai rendu une image avec POV-Ray, mais comment puis-je la sauver en JPG ou GIF ou tout autre format d'image ?"
Cela est un problème typique de la première utilisation de la version Windows.
POV-Ray est un raytraceur qui n'a qu'un but : lire un fichier source qui décrit un scène à rendre, la calculer et la sauver sur le disque dans un format d'image supporté, habituellement TGA (et optionnellement PNG, BMP, etc).
POV-Ray a toujours eu ce but, l'a toujours, et ne changera jamais. Il est majoritairement orienté ligne de commande. Il supporte des choses non essentielles comme montrer l'image pendant le rendu.
Un GUI ne change rien. POV-Ray est toujours POV-Ray, avec ou sans GUI. Il prend un code source et calcule l'image puis la sauve sur le disque. Par défaut il affiche l'image pendant le rendu, mais ce n'est qu'une caractéristique secondaire, pas essentielle. Cela peut être désactivé et POV-Ray continuera de faire son travail.
Donc la réponse à la question est : l'image est toujours sauvée sur le disque.
Habituellement il la sauve au format TGA ou BMP (cela dépend du paramétrage) avec le même nom que le code source (donc si le source est nommé CHAIR.POV, l'image sera nommée CHAIR.TGA ou CHAIR.BMP ou autre). La location est soit le même dossier que celui du fichier .pov ou alors le dossier commun des images (que vous pouvez paramétrer dans le fichier povray.ini principal).
(Réponse de Johannes Hubert)
Pour POV-Ray 2.2 : Essayez Crossroads (http://www.europa.com/~keithr/crossroads) ou si vous voulez convertir vers des fichiers MDL de Moray, essayez POV2MDL (http://www.tb-software.com/) de Thomas Baier.
Pour POV-Ray 3.1 et suivants : Il y a malheureusement pas grand chose à faire. Il n'y a pas encore de programme pouvant lire (et convertir) les scripts POV-Ray 3.1 (sauf par POV-Ray lui-même :-). Le meilleur choix pourrait être : POV2RIB (http://www9.informatik.uni-erlangen.de/~cnvogelg/pov2rib/index.html) si vous voulez convertir vers un format RIB. Si vous savez programmer en C++, vous pouvez obtenir la bibliothèque ParPov C++ depuis la même URL. C'est une bibliothèque de classes pour lire les scripts POV 3.1 et les convertir en objets C++ (il a aussi été utilisé pour POV2RIB).
3DWin de Thomas Baier (voir l'URL au-dessus) convertit depuis le format POB vers pleins d'autres formats. POB est un binaire spécial de POV-Ray décrit par Thomas et est écrit par une version personnalisée de POV-Ray 3.0 (obtenez le POB-SDK à la même URL) : cette version de POV-Ray lit les scripts POV et sort des fichiers POB, qui peuvent être convertis par 3DWin. Le revers de la médaille : bien que tous les objets, textures, etc. de la scène sont dans le fichier POB, tout n'est pas reconnu par 3DWin. Seuls les triangles et maillages de triangles sont reconnus. Tout le reste est perdu....
Crossroads (http://www.europa.com/~keithr/crossroads) peut convertir une très petite gamme des primitives Povray (sphères et triangles fonctionnent mieux). Particulièrement, il peut être utilisé pour convertir les unions de triangles réguliers (pas adoucis) vers d'autres formats.
Une autre option est 3DWin (http://www.tb-software.com/.)
Comme POV-Ray 3.5 supporte l'application UV, les objets texturés utilisés par les moteurs de rendu comme 3D-Studio peuvent être utilisés après une conversion. Vous pouvez trouver une liste de convertisseurs et d'autres logiciels en relation à http://www.povray.org/links/3D_Programs/Conversion_Utilities/.
(Réponse de Peter J. Holzer)
D'abord, vous devez en savoir plus sur la façon dont une image est stockée en JPEG.
Au contraire de la pluspart des formats d'image, il ne stocke pas les valeurs RGB, mais les valeurs YUV (1 valeur de gris et deux valeurs de "différence de couleur") tout comme pour le signal TV. Puisque l'oeil humain utilise surtout la valeur de gris pour détecter les bords, on peut stocker l'information colorée à une plus faible résolution - un 800x600 JPEG a typiquement une information pour le gris en 800x600, mais l'information couleur en 400x300. C'est ce qui est appelé le suréchantillonnage.
Pour chaque canal de couleur séparemment, l'image est divisée en petits carrés et la transformation cosinusoïdale de chaque carré est calculée. Une belle caractéristique de cette transformation est que si vous rejetez quelques valeurs, la qualité ne sera que peu dégradée, mais l'image sera mieux compressée. Le pourcentage de valeurs stockées est appelé la qualité.
Finalement, les données sont compressées.
La plupart des programmes ne vous laissent que la possibilité de changer la qualité. Cela est suffisant pour les photos et les rendus photorealistes de scènes "naturelles". Généralement, les valeurs de qualité autour de 75% donnent le meilleur compromis entre la qualité et la taille du fichier.
Toutefois, pour des images qui contiennent des couleurs saturées, la basse résolution des canaux de couleur provoque l'apparition d'artefacts visibles très similaires à ceux causés par des paramètres de qualité bas. Ils peuvent être minimisés en paramétrant une extrèmement grande qualité (proche de 100%), mais cela augmente dramatiquement la taille du fichier, et souvent les artefacts restent visibles.
Une meilleure méthode est de désactiver le suréchantillonnage. Une plus grande résolution provoque seulement une légère augmentation de la taille du fichier, qui est plus que gagné par la possibilité de baisser la qualité.
L'utilitaire de commande en ligne cjpeg (qui doit être disponible sur tous les systèmes qui ont la commande en ligne, c.a.d. Linux, MS-DOS, Unix, ...) a un "-sample" pour paramétrer les facteurs d'échantillonnages de tous les passages.
cjpeg -sample 1x1,1x1,1x1 -quality 75 -optimize
sont de bonnes valeurs par défaut qui ne devront être changées que rarement.
"Pourquoi y a-t-il tant de convertisseurs des autres formats 3D vers POV, mais pratiquement aucun de POV vers les autres formats ?"
C'est une erreur de croire qu'un fichier POV-Ray est du même genre de données que les fichiers de la plupart des autres modeleurs.
Le format de fichier de la plupart des moteurs de rendu est juste un fichier de données contenant des valeurs numériques (coordonnées de sommets, indices de triangles, textures, coordonnées uv, données NURBS...) décrivant la scène. Habituellement ils sont juste un peu plus que des conteneurs de données numériques.
Par contre, les fichiers POV-Ray sont beaucoup plus que des fichiers de données. Les fichiers de POV-Ray sont le code source du langage de script POV-Ray. Le langage de script POV-Ray est en de nombreux points un langage de programmation complet. Il contient de nombreuses caractéristiques typiques aux langages de programmation et peu typique des fichiers de données (comme les variables, boucles, fonctions mathématiques, macros, etc). Il a beaucoup de caractéristiques pour décrire les choses selon une voie plus abstraite que de simples séries de chiffres.
Voilà pourquoi la conversion de fichier POV vers un fichier de données lisible par d'autres moteurs de rendu est si difficile. Le programme de conversion doit 'exécuter' cela, interpréter le langage de script (de la même manière qu'est interprété un source BASIC ou Perl). Fabriquer un interpréteur de langage de script est un travail beaucoup plus complexe que la conversion de données numériques d'un format vers un autre.
Il y a aussi un autre problème : POV-Ray décrit beaucoup de ses objets comme des entités mathématiques tandis que la plupart des autres moteurs de rendu gèrent seulement des triangles (ou NURBS ou des primitives similaires facilement 'tesselable'). Un convertisseur aura à faire quelques 'tesselations' pour convertir la plupart des primitives POV-Ray vers d'autres formats. Cela peut être un travail assez laborieux pour faire un convertisseur (il aura à intégrer pratiquement un moteur de rendu semblable à POV-Ray).
Voilà pourquoi la fabrication d'un convertisseur pleinement opérationnel de fichiers POV vers tout autre format est une tâche pratiquement impossible.
"Pourquoi les maillages de triangles sont en format ASCII ? Ils sont énormes ! Un format binaire serait plus léger. Si POV-Ray peut lire les formats binaires, pourquoi ne peut-il pas lire les données de maillage binaire ?"
Ce n'est pas aussi simple que vous le pensez.
Vous ne pouvez pas comparer des données binaires de maillage et des fichiers image. Oui, les images sont des données binaires, mais il y a une grosse différence : les fichiers image utilisent des nombres entiers (habituellement des bytes, dans certains cas des entiers 16 bits), qui sont facilement lus dans tous les systèmes.
Par contre, les maillages utilisent des nombres à décimale flottante.
Cela peut être surprenant que ce soit loin d'être simple de les représenter en format binaire pour qu'ils soient lus dans tous les systèmes possibles.
Il est très important de garder en tête que POV-Ray est fait pour être un programme très portable, qui doit être compilable dans virtuellement tous les systèmes avec un compilateur C décent. Ce n'est pas une fable; POV-Ray EST utilisé sur une très large variété de systèmes d'exploitation et d'architectures, incluant Windows, MacOS, Linux, (Sparc) Solaris, Digital Unix et autres.
La représentation interne des nombres à virgule flottante peut différer en nombre de bits, et en bits réservés pour chaque partie du chiffre. Il y a aussi le déplorable problème poids fort/poids faible (ainsi, même si les nombres à virgule flottante sont identiques dans deux systèmes différents, ils peuvent être écrits selon différents ordres de bytes dans un fichier).
Si vous essayez de faire un module qui lit et écrit des nombres à virgule flottante dans un format binaire, vous trouverez rapidement qu'il ne fonctionne que sur une certaine architecture (ex. PC) et pas sur d'autres.
Dans le but de stocker des nombres à virgule flottante pour qu'ils puissent être lus par tous les systèmes, vous devez les stocker dans un format universel. ASCII est aussi bon qu'un autre.
Toutefois, vous n'êtes pas complètement malchanceux en cherchant à compresser les données de maillage. Cela a été fait auparavant. Par exemple, vérifiez :
http://www.geocities.com/ccolefax/pcm.html
Depuis la version 3.5, POV-Ray supporte un nouveau type de maillage (appelé mesh2) qui stocke les données de maillage dans un format plus compact (similaire à celui utilisé dans le format PCM décrit dans le lien précédent, mais avec plus de 'syntaxe' autour).
| 2.4.3 Autres choses en relation |
2.4.5 Utilitaires, modèles, etc... |