Voler en hélico avec POV-Ray

Un amateur de 3D isolé comme moi ne peut pas raisonnablement espérer rivaliser avec un studio d’animation d’une cinquantaine de personnes, mais des animations spectaculaires d’un type bien particulier sont quand même à sa portée. L’idée est simple: sur la base d’une vaste scène riche en détails où rien ne bouge, on représente le parcours d’une caméra extrêmement mobile et susceptible de moduler sa vitesse dans des proportions considérables; capable de lambiner comme un piéton à proximité d’un objet, et aussi de foncer à la vitesse d’un avion à réaction sur une vue générale.

J’ai commencé à travailler sur une animation de ce type, dont je vous présente ici le brouillon. Oh, je suis bien conscient que sa qualité technique n’a rien pour déclencher votre enthousiasme… alors, perdu pour perdu, je vais carrément vous inonder de chiffres pour que ce soit encore plus rébarbatif! (accessoirement, cette logorrhée numérique pourra ultérieurement me servir de référence)

Les images que vous pouvez voir ci-dessus ont été calculées avec une résolution de 320 x 240 pixels et à la cadence de 15 vues par seconde. En d’autres termes, c’est très médiocre (hyper-pixelisé et saccadé) comme vous n’aurez pas manqué de vous en faire la réflexion. Un standard actuel serait de 1024 x 768 pixels à 30 images par seconde, mais cela demanderait… vingt fois plus de puissance de calcul. Or, même dans son état rudimentaire, cette vidéo dure environ trois minutes, soit, à 15 images par seconde, environ 2700 images, et même dans une définition aussi basse, chacune requiert déjà une dizaine de secondes de calculs (avec POV-Ray). C’est qu’avec son relief texturé, ses six bâtiments (dont un très complexe et détaillé) et les quelques autres fariboles qui l’agrémentent, cette scène comporte quand même quelque 50.000 triangles (correspondant d’ailleurs à plusieurs semaines de modélisation, mais c’est une autre histoire). Pour produire la même chose dans un standard de qualité contemporain, il faudrait que mon ordinateur tourne vingt fois plus longtemps que les sept heures de calcul que m’a demandées ce brouillon… donc ma machine serait monopolisée pendant plusieurs semaines. Je ne dis pas que je n’envisagerai jamais un tel investissement en temps… mais alors il faudra que le projet en vaille davantage la peine.

C’est égal, je ne suis pas mécontent du résultat, que je trouve franchement prometteur. Le principe général est le suivant: on met en place « manuellement » une série de caméras représentant des positions intermédiaires (au départ, je l’ai fait avec un petit utilitaire à moi — une moulinette –, mais j’ai ensuite affiné avec Blender), dont on note soigneusement les caractéristiques: coordonnées x, y, z, azimut, site (angle par rapport à l’horizontale) et éventuellement focale. Le nombre de ces « caméras de passage » est indifférent, mais pour mes 2700 images finales j’ai quand même dû en définir une quarantaine (et dans l’idéal, je devrais encore en ajouter une bonne douzaine). L’inventaire de ces données constitue un fichier de texte banal (sauf, bien sûr, que je m’astreins à respecter une certaine syntaxe, mais elle n’a rien de complexe), lequel sera bien sûr lu et exploité ultérieurement par une moulinette. En plus des coordonnées déjà relevées, j’y ajoute manuellement (et entièrement au pifomètre! mais c’est facile à retravailler) des indications de vitesse de déplacement (jusqu’à 300 km/h pour les vues générales, parfois pas plus de 2 km/h lorsque l’on est proche d’un objet).

Et tout cela étant fait, j’applique là-dessus mes super-pouvoirs de spécialiste des moulinettes: cette liste d’une cinquantaine de caméras seulement est démultipliée en un tournemain (par une technique d’interpolation par courbes de Bézier définies dans l’espace-temps, laquelle je me flatte d’avoir conçue à partir de rien et programmée de A à Z), et elle devient une liste exactement du même type (un autre fichier de texte avec la même syntaxe) mais contenant cette fois autant de positions intermédiaires qu’il y aura d’images produites au final (plusieurs milliers, donc). Il n’y a plus qu’à exploiter cette nouvelle liste avec une nouvelle moulinette (en fait, une série de moulinettes) pour obliger POV-Ray à la transformer en une série d’images, et hop, c’est parti pour plusieurs heures de calcul automatisé.

Enfin, tout à fait en aval, les images produites sont transformées en animation (d’abord au format AVI, puis MP4) par plusieurs logiciels libres (le couple mplayer-mencoder, plus un peu de fignolage avec Kdenlive pour l’ajout d’une bande-son et la compression en MP4). Et ça donne… le (très petit) chef-d’oeuvre que vous pouvez voir ci-dessus. Tout ça avec un ordinateur de bureau de modèle banal.

Dans l’idéal, il faudrait retravailler un peu tout ça pour réduire la durée de quelques transitions ennuyeuses et ajuster la fluidité de certains changements de direction. Il n’empêche que globalement, je suis assez content du résultat. Les mouvements de caméra sont presque toujours parfaitement fluides (quand par exception ils ne le sont pas, c’est dû à de mauvais choix de positions de passage, pas très compliqués à corriger), la caméra va à une vitesse folle quand il le faut, ralentit à mort quand il le faut, et même les passages où l’on se faufile au milieu de petits détails restent parfaitement compréhensibles (vous avez vu la traversée du petit chalet? et la montée de l’escalier? mmm? c’est pas top moumoute, ça?).

C’est pas pour me vanter, mais tout ça, ce n’est vraiment pas à la portée du premier pignouf venu… mais c’est possible pour un clampin tout seul à la seule condition que comme moi il ait appris à se servir d’Unix, de Python, de POV-Ray et de quelques autres logiciels libres moins connus. Le logiciel libre, c’est vraiment pas toujours simple… mais quand on sait s’en servir, pétard, ça dépote.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *