Mais putain, Dorian, tu vas encore faire un billet beaucoup trop long avec des termes super générique qui raconte rien ! J’ai des graphistes à aider, moi !

Ne vous inquiétez pas, on va essayer d’aller à l’essentiel.

Le problème

On va être très concret, et lister quelques problèmes récurrents :

  • Quand un modeleur publie son travail, on peut vouloir exporter ses modés/son décor dans la foulée, sans bloquer son Maya.
  • Quand un layouteur/animateur publie son travail, il est intéressant d’enchainer avec quelque chose derrière. Ça peut être un playblast ou un export alembic/USD, sans bloquer son Maya.

Plus un pipeline fait de choses pour détester délester le graphiste, plus cette question se pose. :reflechi:

Il y a un paquet d’options disponibles ; Ouvrir un terminal, un subprocess Maya, passer par un microservice (qui ouvre Maya, bien joué, Roger ! :aupoil: ), etc.

Elles sont toutes assez limitées ; Sature la RAM locale, le message d’erreur dans le terminal n’est pas lu/remonté, Maya crash en fond et les microservices c’est opaque pour l’utilisateur.

Le problème est tellement difficile à gérer qu’il n’est pas rare que tout le monde abandonne et choisissent de bloquer le graphiste qui « en profitera pour faire une pause café ». Bon, je sais qu’un graphiste qui boit du café c’est important pour la productivité, mais un lead/sup peut être amené à publier énormément de choses sur des scènes problématiques, et ça serait vraiment con que votre lead modé fasse un arrêt en publiant sa cinquantième retake de brins d’herbe… :nevroz:

Abrège, Dorian…

En gros soit le graphiste ne voit rien, soit il perd du temps. Et je ne parle même pas d’isoler un crash (je sais, je sais, les scripts ne sont pas supposés planter, mais dès que ton input c’est une scène faite par un humain, c’est dogmatique de penser que tout va rouler).

Notez que parmi les options disponibles, je n’ai pas parlé de la farm : On pourrait parfaitement publier la scène puis envoyer une série de job sur la farm pour faire le boulot. :dentcasse:

Le problème est que l’utilisateur ne voit pas ce qui s’y passe et les UI de farm sont souvent imbitables. Et c’est le début de la solution que je propose. :redface:

La solution

Le problème de la farm, on l’a vu, c’est que personne ne la regarde parce que :

  • La UI est souvent lourde.
  • C’est le bordel.
  • La UI est souvent moche.
  • C’est le bordel.

Pourtant, la farm est surement le moyen de plus simple de garder un job qui échoue tout en permettant de reproduire le problème (et si vos jobs ont des effets de bords, je vous invite à lire ces deux billets sur le sujet :papi: ).

L’approche présentée plus bas part du principe qu’on peut résoudre ces problèmes de façon pragmatique, sans demander un effort de dev trop important ; vous vous doutez que si j’en parle, c’est que j’ai déjà utilisé un mécanisme similaire et que ça fonctionnait. :laClasse:

L’idée est donc de permettre à l’utilisateur de suivre les jobs qu’il envoie, sans lui exposer le détail des jobs en question ; autres que wip/done/pending.

Quel que soit votre système de farm, chaque job a un identifiant. Quelle que soit la tache à faire, il est rare qu’un seul job suffise. Pour un simple playblast, vous aurez souvent la génération des images depuis Maya, l’ajout de cartons et la génération du fichier vidéo.

On va grouper tous ces jobs dans un ensemble qu’on va appeler un job group. Et il va falloir stocker cette entrée dans une base de donnée dédiée (et non, bordel non : ShotGrid n’est pas une base de donnée dédiée, mais d’autres en parlent mieux que moi).

Chaque graphiste ne voit donc que les job group qu’il a lancé, et qui ne sont que des agrégats de jobs de farm.

Pseudo-implémentation

Donc vous sortez votre base de donnée SQL préférée, et vous me créez une table dédiée :

  • User id : Contiendra l’identifiant de l’utilisateur qui a envoyé le groupe de jobs.
  • Label : Un petit texte faisant office de nom du groupe de jobs.
  • Liste des job ids : Liste des identifiants des jobs de farm auquel ce groupe fait référence.

Même pas besoin de mettre une clef primaire, c’est tellement magique !

Notez que certains gestionnaires de farm permettent déjà de grouper les jobs, il peut alors être pertinent de pointer vers l’id du groupe de job de votre gestionnaire de farm plutôt que faire la liste vous-même.

C’est bien, vous avez une table que vous commencez à remplir : Chaque fois qu’un graphiste fait une publication, on envoie une série de job en farm et on crée une entrée dans la table qui stocke la liste des jobs envoyés.

Il faut maintenant afficher ça aux graphistes.

Faites un QTableWidget avec deux colonnes :

  • Label
  • Progress

Label affichera un très court descriptif du job group : « Playblast anim sq9999sh001 », « Export Alembic toto_001 sq9999sh001 ».

Progress affiche l’avancée générale des jobs : « WIP 2/5 », « DONE ».

Vous pouvez ajouter quelques boutons comme :

  • Supprimer les jobs terminés.
  • Copier l’erreur du job sélectionné.
  • Ouvrir dans « gestionnaire de farm du studio ».
  • etc.

Ça donne un truc comme ça :

Designer est ton ami, mais j’y ai quand même passé beaucoup trop de temps. :slow_clap:

Et paf, vous avez une UI qui liste les jobs envoyés par l’utilisateur courant sous formes de groupes, les détails n’étant pas affichés. Ce n’est pas un bug, c’est une feature qui fait que votre UI n’est pas lourde ni repoussante ; elle est minimaliste.

Notez que ce n’est pas parce que cette UI est simple qu’elle doit être codée avec le cul. Au contraire, cette simplicité est supposée se retrouver dans son code. Si vous faites ça bien vous pourrez lancer cette UI depuis n’importe quel logiciel (e.g. juste après une publication).

Avec tout ça, le graphiste peut maintenant publier à la chaine avant d’aller prendre sa pause café (notre problème original), et surtout, a enfin un moyen précis de communiquer sur ce qui est bloqué ou non, sans être dans le noir, tout en permettant aux TD/Wrangler de l’aider rapidement. :banaeyouhou:

Comme nous passons par une base de donnée dédiée, les job groups ne sont pas perdus après un redémarrage. :zinzin:

Certains pourront me répondre que des gestionnaires de farm propose déjà une UI « artist » de leur produit. Notez que je n’ai pas parlé de rendre des images, mais bien de publier de modé/layout/anim. L’idée de ce système est de permettre à des opérations en sorties de tels départements de se faire de façon déportée, tout en restant visible pour l’utilisateur et en lui évitant la charge cognitive qu’implique de voir les jobs sous-jacents.

Exposé de la sorte, les job group sont une abstraction qui permette de faire le lien entre :

  • Une tache côté utilisateur ; J’ai publié ma modé, mon layout, mon anim, etc.
  • Et des dizaines de jobs de farm ; export png, création du movie, etc.

Je continue de penser que filer une grosse UI à un graphiste qui veut juste savoir si son travail a été exporté correctement est une erreur.

La UI va donc faire des requêtes aux jobs de la farm (en utilisant l’API de cette dernière). Ces requêtes peuvent être assez lourdes si on est bête (ce qui n’est surement pas votre cas, si vous lisez ce blog :petrus: ). Voici quelques idées pour améliorer l’implémentation :

  • Ne pas demander à la farm le status des jobs terminé (un flag dédié peut être mis dans la table job group pour ne faire aucun accès à la farm sur un groupe donné, considéré comme déjà terminé).
  • Ne pas demander à la farm le status des jobs en erreur (un job peut rester des mois en erreur), mais ajouter un bouton « refresh erreur » pour permettre au graphiste de revérifier le job, après que le TD/wrangler ait résolu le souci.
  • Diminuer l’intervalle des requêtes des status des jobs en attente (pending).
  • Automatiquement supprimer les job groups terminés depuis X semaines (2, c’est pas mal). Ça peut être un cron. On peut faire la même chose, sur une durée plus longue pour les jobs en erreur.

Autre truc important : Cette UI doit pouvoir être lancé pour n’importe quel utilisateur (par une variable d’environnement, comme JOB_GROUP_UI_USR=julie), pour simplifier le travail des TDs qui peut accéder directement aux problèmes d’un graphiste sans lui demander quoi que ce soit, et dans un élan de grâce qui les caractérise si bien, ils peuvent même cliquer sur le « refresh erreur » à sa place.

Conclusion

Si vous n’êtes pas convaincu, c’est que vous manquez simplement d’ouverture d’esprit, vous avez tort, vous aimez Node.js, le chocolat aux raisins, Dieu, et vous êtes une personne méprisable qui aurait surement vendu sa grand-mère en 40.

Je ne vous félicite pas…

:marioCours: