Pipeline - du Dataflow au Workflow [1ère Partie]

Un Peu d'Histoire

Naissance

Il y a longtemps, pour créer des images avec des ordinateurs, on utilisait une armada de petits outils (éditeurs, calculateurs, ...) dédiés à des tâches atomiques bien précises (définir des polygones, générer des couleurs, calculer des normales, rendre une image, ... )

En dehors des "éditeurs", le travail de l'utilisateur consistait à nourrir de données et de paramètres les "calculateurs" pour créer de nouvelles données.

S'est alors développé le besoin de représenter, gérer et exécuter chaque processus particulier mis en place pour un résultat/produit particulier. Naturellement, les Devs qui avaient mis en place les outils CG ont également apporté leur solution à ce besoin.

Ils ont utilisé leur culture et leurs propres outils pour cela: ceux qui gèrent les dépendances et l’exécution des processus de Compilation/Livraison comme "make", ainsi que le concept du 'I/O pipeline' des terminaux Unix.

C'est certainement de là que vient le terme "Pipeline" qu'on utilise dans le monde CG. C'est un dataflow parce que le but était de gérer les données en entrée et en sortie de l'armada d'outils informatiques.

Parmi les exemples français, on peut citer "B-Proc" de Buf Companie, ou les outils en ligne de commande qui formait les prémices du logiciel de compositing "Trukor" à MacGuff Ligne.

Mort

La situation a par la suite évolué avec l'apparition des logiciels de DCC (Digital Content Creation) qui stockaient les dépendances dans des "scènes". Le DAG de Maya a été un progrès majeur: Un "Lazy Directed Acyclic Graph" qui représente toutes les dépendances et calculs de données nécessaires pour faire le boulot.

Exploiter et encapsuler le concept du Dataflow était une aubaine pour les Artistes qui pouvaient dorénavant se concentrer sur autre chose, ainsi que pour les Techs qui pouvaient de leur côté mettre en place des outils spécifiques pour les Artistes.

Ces logiciels ont rendu obsolètes la plupart des outils de gestion de dépendances de données puisque que le travail des Artistes se faisait maintenant dans un seul DCC omnipotent.

Exhumation

Mais, au fur et à mesure que les aspects techniques de la création digitale devenaient de plus en plus complexes, le besoin d'outils spécialisés a commencé à se faire ressentir de nouveau : il vaut mieux exceller dans un domaine que d'être moyennement efficace sur mille sujets.

Et la même idée s'est développée à propos des Talents : des profils spécialisés plutôt que généralistes. Ce qui nous a menés très vite vers des équipes plus grandes et plus interconnectées.

Les Devs ont alors ressorti leurs outils pour solutionner ce nouveau problème de connexions.

Diviser pour mieux Complexifier

Mais cette fois-ci ça ne pouvait pas marcher puisse que le problème était autant au niveau Logiciel que Humain. Ces solutions n'avaient pas été conçues pour gérer les données comme des tâches.

C'est là que les équipes de Ressources Humaines ont dégainé leurs outils, qui étaient - eux - faits pour gérer l'humain.

Et c'est alors qu'est apparue la séparation entre l'Asset Management et le Suivi de Production. Et c'est alors que tout est parti en cacahuète :)

À Suivre...

Dans la deuxième partie (à venir) nous feront un état des lieux rapide de l'Asset Management et du Suivi de Production en général. Nous verrons en quoi ils sont à la fois proches et très différents du concept de Workflow exploité à d'autres industries. Et nous nous poserons la question de comment améliorer la situation.