| 3DVF : Quelle a été l’implication de Framestore, en termes de durée/nombre d’artistes impliqués ? Quel a été ton rôle ?
Lucas Janin : Framestore a réalisé 300 plans. Une partie d’entre eux impliquait le département de effets. Pour moi, l’ensemble du projet a duré un an et avec un maximum de 8 personnes dans le département d’effets. En plus de la supervision de l’équipe effets, j’ai développé plusieurs systèmes dans Houdini : Les abeilles, la pluie, l’effets de bug de Joi et le sable dans Las Vegas. |
3DVF : Sur Blade Runner 2049, tu as eu de plus grosses responsabilités de supervision que par le passé ; quels étaient les enjeux, et comment s’organisait ton travail au quotidien ? En particulier, quels étaient tes liens avec le reste de la hiérarchie ?
L.J. : En effet, cela faisait longtemps que je n’avais pas géré un projet en effet seul. Chez DreamWorks et Weta, j’avais été superviseur de séquence ou d’effets, mais c’était sous la supervision d’un head of FX ou un FX supervisor. Sur Blade Runner 2049, j’ai pu gérer directement le projet en effets sous la houlette directe des superviseurs CG et VFX. Deux fois par jour je faisais des “rounds” pour voir si les artistes avaient ni trop ni pas assez de travail. Je faisais attention à ce qu’ils aient tous les assets dont ils avaient besoin. De même, je les aidais si nécessaire au niveau technique ou artistique. Puis dans l’après-midi, nous avions des “dailies” avec le CG sup pour l’approbation des versions temporaires ou finales des effets. Deux fois par semaine, cette rencontre était réalisée avec le superviseur VFX. Après un passage en lighting et en compositing, les plans étaient montrés au client. Si nécessaire, ils revenaient en effets pour une deuxième passe. |
| 3DVF : Tu as notamment travaillé sur une simulation de foule mettant en scène 35 000 abeilles : quelques mots sur ce défi technique ? Comment as-tu approché cet effet ? L.J. : Après deux semaines de formation aux pipelines de Framestore à mon arrivée, je me suis attelé à trouver une solution pour animer plus de 30 000 abeilles. La première voie que j’ai exploré était une simulation de foule (crowd) avec Houdini, une nouvelle chose pour moi. Je me suis rapidement rendu compte que cela n’était pas la solution la plus appropriée. En effet, cela impliquait de “baker” les 35 000 abeilles sur disque pour chacune des frames.J’ai donc proposé au superviseur 3D une approche moins onéreuse. Mon idée était de demander au département d’animation de générer des cycles d’animation de marche, de mouvement sur place et de vol ainsi que des cycles de transition entre les différents cycles. L’ensemble de ces cycles étant générés par un système de particules et rendu avec des instances.Le code que j’ai créé en VEX (langage de programmation en script disponible sous Houdini) dans un Popnet (node Houdini qui permet d’intégrer un réseau de simulation de particules, volumes, feux, eaux,..) me permettait de gérer l’ensemble de la logique comportementale du déplacement des abeilles sur les ruches et le personnage, ainsi qu’en vol. Cela comprenait une logique d’évitement des obstacles statiques et animés, ainsi qu’une logique d’évitement entre les abeilles elles mêmes, une gestion de transition entre les cycles statiques, marches et vols. |
Pour chacun des 50 cycles, j’ai défini des informations de probabilité pour passer sur d’autres cycles ou rester sur le même. J’ai créé une interface sur des nodes pour configurer ces probabilités mais les informations étaient au final stockées sur des points dans Houdini pour une lecture plus rapide durant la simulation.
Le plus gros défi était l’atterrissage. En effets, il fallait ajuster la vitesse et la trajectoire de l’abeille pour que la transition d’atterrissage se fasse au bon moment et de la manière la plus naturelle possible. Ensemble, ces cycles avait 3 niveaux de détail : résolution basse et moyenne sans poil et haute avec poils. Après la simulation, un processus permettait d’adapter la résolution des abeilles en fonction de leur présence dans le champ de vision de la caméra ainsi que leur distance. Un autre traitement permettait de calculer si certaines abeilles étaient tout de même passées à travers des objets et de les éliminer. Pour la passe finale, je pouvais aussi effacer les abeilles dont le comportement ne plaisait pas via une liste d’“ids”. Enfin, un nuage de points était exporté avec l’ensemble des informations d’instance des abeilles (position, vitesse, orientation, taille, index du cycle, frame du cycle, niveau de détail). Ce fichier était très léger. Pour finir, le pipeline de Framestore permettait de créer les instances et de les rendre. |
| 3DVF : Tu as aussi mis en place un rig pour contrôler un élément étroitement lié à l’esthétique Blade Runner : la pluie. Quelles indications artistiques/techniques avais-tu reçues, et comment les as-tu prises en compte dans la mise en place de ce rig ?
L.J. : Oui en effet, il ne pouvait pas avoir un nouveau Blade Runner sans pluie :-). Pour Framestore, celle-ci était présente dans “Trash Messa”, la grosse décharge avant que Roy n’arrive à l’orphelinat. En tout premier, j’ai isolé la zone visible dans le champ de caméra et dans une distance maximum sur l’ensemble du plan. Puis, j’ai découpé cette zone en régions carrées de 25 mètres de côté pour les plans proches et 75 mètres pour les plans éloignés.
|
Pour chacune de ces régions, j’ai calculé un objet de collision VDB, créé un émetteur dans le ciel juste au dessus de champ de vision de la caméra, rempli de manière procédurale le ciel pour éviter d’avoir un preroll trop grand, calculé un émetteur depuis les bâtiments pour simuler les ruissellements. Pour ce dernier point, j’ai utilisé un nouage de points (point cloud) pour déterminer où étaient les rebords. Deux simulations étaient générées : celle du ciel et celle des ruissellements. Ensuite, la simulation de l’ensemble des impacts sur le sol de ces deux simulations étaient créée. Pour finir un processus de nettoyage et optimisation était effectué après ces simulations et le résultat était exporté dans le pipeline de Framestore.
L’ensemble de ces tâches étaient générées sur la render farm en parallèle. Il pouvait avoir jusqu’à 350 régions par plan. Ces tâches géneraient des nombreux téraoctets de données en quelques heures ! Une bonne manière de rencontrer régulièrement le data manager du studio :-).
|
| 3DVF : A ce propos, dans ce genre de cas où les effets deviennent très lourds, quels sont les échanges avec le data manager ? S’agit-il de planifier avec lui les volumes de données, de demander de l’espace supplémentaire, voire de recevoir comme retour “désolé, pas plus de place, il faudra faire avec” ?
|
L.J. : Oui en effet, il fallait effectuer un travail de planification donc de faire une évaluation. Cela n’a pas été facile car suivant la taille de l’environnement et l’altitude de la caméra, une simulation pouvait utiliser plus de 20 fois plus de place qu’un autre plan de durée similaire. À part quelques rares accidents d’estimation, le data manager a toujours trouvé la place pour que je génère mes terabytes de particules :-). |
