Dorian Fevrier's blog - Mot-clé - ocelotJe m’appelle FEVRIER Dorian, je suis infographiste 3D passionné par mon métier, l’informatique en général, l’internet, la programmation et l’évolution de tout ce petit monde. Vous trouverez sur ce blog des tutoriaux, mes coups de cœurs, avis, etc.2024-01-02T23:48:05+01:00FEVRIER Dorianurn:md5:695d9c73474c33ce3dab043823509c4bDotclearLes Contes de la Nuit, résumé d'une supervision techniqueurn:md5:67e0389842c58f3d9b666734b39a3c692011-07-31T15:22:00+02:002013-07-26T18:07:50+02:00NarannInfographie 3D - Boulotfilmfrles contes de la nuitocelotpost-mortemscriptsupervision<p><img src="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/lcdln_resume_superviseur_tn.png" alt="lcdln_resume_superviseur_tn.png" style="float:left; margin: 0 1em 1em 0;" title="lcdln_resume_superviseur_tn.png, juil. 2011" height="150" width="150" />Comme vous le savez peut être déjà, le long métrage <a href="http://www.allocine.fr/film/fichefilm_gen_cfilm=183772.html" hreflang="fr">Les Contes de la Nuit</a> de <a href="http://www.imdb.com/name/nm0643664/" hreflang="en">Michel Ocelot</a> (<a href="http://www.allocine.fr/film/fichefilm_gen_cfilm=18446.html" hreflang="fr">Kirikou</a>, <a href="http://www.allocine.fr/film/fichefilm_gen_cfilm=57417.html" hreflang="fr">Azur et Asmar</a> entre autres) est sorti!</p>
<p>J'ai eu la chance de superviser la partie technique de la production. Au delà du fait que je trouve que ce film est une vraie réussite, ce fut sans hésiter l'une de mes plus belle expérience professionnelle. :sourit:</p>
<p>Dans ce billet je vous propose de faire le tour des moyens mis en place pour réaliser ce beau, que dis-je? Magnifique projet!</p>
<p>(Et faire un petit peu de pub aussi :siffle: )</p> <h3>Note</h3>
<blockquote><p>Bien que le contenu de ce blog soit sous licence Créative, toutes les images présentes sur ce billet sont la propriété de leurs auteurs respectifs. Tout contrevenant s'expose à des poursuites judiciaires et pourra se voir kidnappé dans son sommeil, lapidé sur la place publique et privé de bonbons. :gniarkgniark:</p></blockquote>
<h3>Mon arrivé sur le projet</h3>
<p>Tout d'abord, une remise en place du contexte me semble intéressante.</p>
<p>Tout commence fin 2009, je suis à <a href="http://www.def2shoot.com/" hreflang="en">Def2Shoot</a> sur le long métrage d'animation <a href="http://www.imdb.com/title/tt1039651/" hreflang="en">Yona Yona</a> (nom du projet à l'époque). A la suite de plusieurs réunions de prod franco-japonaises, le choix de faire l'animation des personnages principaux sous Maya et les décors sous XSI est fait. Je me retrouve à être le seul TD sous Maya (D2S étant sous XSI).</p>
<p><a href="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/yona.jpg" title="yona.jpg"><img src="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/.yona_m.jpg" alt="yona.jpg" style="display:block; margin:0 auto;" title="yona.jpg, juil. 2011" height="560" width="411" /></a></p>
<p>Franck Malmin (<a href="http://www.excessif.com/cinema/actu-cinema/dossiers/la-naissance-de-yona-par-franck-malmin-producteur-executif-5668560-760.html">lire son témoignage</a>, très sincère, sur le film), alors directeur du studio, propose au Surfacing TD du projet d'aider "une production" à se lancer. Celui ci commence ainsi à passer quelques après midi à <a href="http://www.nord-ouest.fr/">Nord Ouest Film</a>, ou une partie de "l'équipe de Michel" est déjà en place.</p>
<p>A ce moment là je n'en savais pas plus. Mais les difficultés qu'allaient rencontrer Yona Yona commençaient à se faire ressentir et la production demande le retour à plein temps de son surfacing TD sur le projet.</p>
<p>A Def2Shoot, la partie sous Maya posant de moins en moins de soucis (grâce notamment à l'arrivé d'un second TD), Franck me demande de continuer le travail commencé chez Nord Ouest.</p>
<p>C'est à ce moment là que je rencontre ceux que je connaissais sous l’appellation "l'équipe de Michel", tous des gens formidables. :sourit:</p>
<p>Au début, mon travail ne devait pas durer longtemps et était très basique. Il fallait prendre connaissance des besoins du projet et les aiguiller vers des solutions rapides (aide pour convertir les .map de mental ray car les plans des décors étaient monstrueusement grand, définir une hiérarchie de dossier et expliquer le pourquoi du comment de chaque dossier, etc...).</p>
<p>Malgré les besoins techniques assez limité que nécessitait ce projet (Les Contes de la Nuit, ce n'est pas Transformers avec du raytracing partout), l'équipe, finalement assez réduite et composé de <del>peu</del> pas de techniciens, pouvait, à long terme, se retrouver à passer plus de temps à régler des soucis techniques qu'à vraiment travailler sereinement. :reflechi:</p>
<p>Il y avait quand même, à ce moment là, 10 épisodes de 13 minutes en Full HD à sortir.</p>
<p>Cette inquiétude était partagée avec le reste de l'équipe et au bout de quelques conversations entre Franck et la production, il fut décidé que je continuerai le projet jusqu'à la fin (le projet durait un an et demi et il est à noter que les délais furent respectés).</p>
<p>Je faisais donc officiellement partie de l'équipe!</p>
<center>:youplaBoum:</center>
<h3>Les grands moyens</h3>
<p>Cette décision allait pas mal changer mon implication sur le projet et je pouvais voir "plus loin", faire des choses plus avancées, gérer des cas plus complexes etc...</p>
<p>L'assistant réal de Michel Ocelot venait de la 2D et avait l'habitude faire un travail de préprod <del>conséquent</del> monstrueux. Ainsi, le storyboard et la mise en scène est déjà faite et un dépouillement technique et d'intention était déjà dans les fichiers Excel de la directrice de production avant même qu'un épisode ne parte en Layout.</p>
<p>Ce genre de chose m'a pas mal rassuré car la perspective de devoir tout changer au dernier moment (mentalité <del>très</del> trop présente dans la pub et le cinéma dit "à l'américaine") ne m'aurait pas incité à prendre certains risques pour améliorer la prod et ces conditions. Forcément quand on a une certaine assurance que ce qu'on souhaite faire est bien ce qu'on va faire, on se prend moins la tête à prévoir du temps pour le bricolage.</p>
<p>C'est à ce moment que j'ai pu commencer à définir les grandes lignes du workflow.</p>
<h3>L'usage du script</h3>
<p>N'y allons pas par quatre chemins: Le script était partout ou personne n'osait s'aventurer. :sourit:</p>
<p>L'importance d'une hiérarchie de fichier techniquement cohérente était donc primordiale pour pouvoir automatiser des taches, tout en gardant à en tête qu'elle allait aussi être manipulé par des "humains" et, de ce fait, devait également rester compréhensible.</p>
<p><img src="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/noShowPlans_001.png" alt="noShowPlans_001.png" style="display:block; margin:0 auto;" title="noShowPlans_001.png, juil. 2011" height="246" width="338" /></p>
<p>Le langage de prédilection fut le MEL pour tout ce qui touche Maya (Je n'étais pas encore à l'aise avec "Python de Maya" à ce moment là) et du Python pour tout ce qui touche la manipulation de fichiers (<em>os</em> et <em>re</em> sont tes amis).</p>
<p>L'utilisation du scripting c'est surtout faite aux "points de passages" des informations/fichiers. J'y ferais souvent référence durant le reste de ce billet car j'ai quasiment passé cette prod mes doigts sur le clavier. :pafOrdi:</p>
<h3>Résumé du pipeline</h3>
<p><a href="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/Schema_pipeline.png" title="Schema_pipeline.png"><img src="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/.Schema_pipeline_m.jpg" alt="Schema_pipeline.png" style="display:block; margin:0 auto;" title="Schema_pipeline.png, juil. 2011" height="215" width="560" /></a></p>
<center><i>Un plan qui résume grosso modo les différentes étapes du pipeline</i></center>
<h4>Les décorateurs</h4>
<p>Les "décorateurs" ("mappeurs") faisaient leurs décors sous Photoshop (dans des fichiers très grands et très lourds ^^ ), ils exportaient le fruit de leur travail sous différentes couches en tiff dans un dossier dédié et suivant une convention de fichier défini à l'avance.</p>
<p>Au début, il convertissaient eux même leurs .tiff en .map (et .dds) mais cette manipulation leur prenait du temps. J'ai donc rapidement fait un script qui passait sur tout le projet en cours et vérifiait que chaque .map (ou .dds) était plus vieille que son .tiff. Dans le cas contraire, il effectuait une conversion. :dentcasse:</p>
<h4>Les personnages</h4>
<p>Je n'étais pas directement impliqué dans la création des personnages.</p>
<p>Un graphiste 2D faisait les versions Photoshop des personnages, "les éclatait" sur un plan, un character TD, rejoint temporairement par un animateur avaient mis en place un système de rig automatique pour générer les personnages.</p>
<p>Les images des personnages étaient converties de la même façon que les décors.</p>
<p>Ma partie, dans le pipeline commençait au niveau du Layout avec un outil pour les lister et les importer dans la scène en fonction de l'épisode.</p>
<p><img src="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/layoutGen_001.png" alt="layoutGen_001.png" style="display:block; margin:0 auto;" title="layoutGen_001.png, juil. 2011" height="341" width="412" /></p>
<p>Ce fut donc un gros travail de communication pour savoir qui lister et dans quel cas ne pas lister tel ou tel personnage.</p>
<h5>Note sur le format .dds</h5>
<p>Michel Ocelot validait l'animation sur les playblasts. Il fallait donc que les playblasts soit "le plus proche possible" du rendu final.</p>
<p><a href="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/playblast001.png" title="playblast001.png"><img src="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/.playblast001_m.jpg" alt="playblast001.png" style="display:block; margin:0 auto;" title="playblast001.png, juil. 2011" height="315" width="560" /></a></p>
<center><i>Ceci est un playblast. :sourit:</i></center>
<p>Pour ça, les textures utilisées dans les scènes Maya devaient être celles utilisées dans le rendu, moyennant un redimensionnement.</p>
<p>J'ai donc codé un shader cgfx auquel je donnais les version .dds des textures pour diminuer leur charge dans la mémoire du GPU.</p>
<p>Cette technique à très bien fonctionné concernant les décors mais un bug que je n'ai pu résoudre faisait disparaitre certaines textures lors des mouvements des contrôleurs des personnages.</p>
<p>J'ai du bricoler une sorte de surface shader pour le viewport mais on perdait l’intérêt des texture en .dds car il m'a semblé que Maya décompressait puis plaçait entièrement la texture dans la mémoire du GPU. :pasClasse:</p>
<p>C'est dommage car c'était justement les personnages qui prenaient le plus de place en terme de texture. J'ai du faire des version "low" des .dds (qui étaient déjà de la basse def) ainsi qu'un outil pour switcher rapidement entre .dds normal et .dds "low", certains plans ayant pas mal de personnages.</p>
<h4>Le layout</h4>
<p>J'ai donc fait l'importeur de personnage mais aussi le "générateur de décors". Chaque plan du film est en fait une superposition de couches de décors:</p>
<p><a href="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/orgaDesPlans001.png" title="orgaDesPlans001.png"><img src="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/.orgaDesPlans001_m.jpg" alt="orgaDesPlans001.png" style="display:block; margin:0 auto;" title="orgaDesPlans001.png, juil. 2011" height="339" width="560" /></a></p>
<p>Comme la nomenclature des fichiers était claire, il était très simple, via un script, de savoir ou étaient les différentes couches du plan en court.</p>
<p>Il suffisait alors de préciser le numéro de l'épisode ainsi que le numéro du plan qu'on souhaite générer, de valider.</p>
<p>Un rig de décor était importé puis adapté au plan. Les couches du décor étaient chargées sur leur plan respectif et l'image plane de la camera affichait l'animatique exportée du montage.</p>
<p>Il ne restait "plus qu'à" placer les personnages.</p>
<p>J'ai également scripté un "transfert de plan" pour que les "layouteurs" n'ait pas à remplacer tous les personnages alors que deux plans plus tard ils sont dans la même position.</p>
<h4>L'animation</h4>
<p>Il n'y avait rien de "pipeliné" concernant la publication des scènes de layout. Les animateurs copiaient la scène de layout de leur plan et commençaient à animer.</p>
<p>J'ai codé un panel de personnage qui était surtout utilisé pour les mains des personnages. Les mains étaient des textures plaquées sur des faces affichées/masquées au fil de l'animation.</p>
<p>Les textures des mains ainsi que les numéros des attributs à "afficher/masquer" respectaient une nomenclature. Ainsi, à chaque ajout d'une main, il suffisait d'ajouter une ligne pour que le tout apparaisse dans le panel.</p>
<p>En revanche, répondre à la contrainte d'automatisation du rendu nécessitait que les scènes soient publiées dans un dossier ou le script allait pouvoir les récupérer.</p>
<p>J'ai donc fait un outil de publication des animations qui sauvait la scène en cours ainsi qu'un petit fichier vide qui jouait le role de "marqueur" pour préciser que cette scène venait d'être republiée.</p>
<h4>Le rendu</h4>
<p>Sur cette partie il n'y avait quasiment aucune intervention humaine. Tout avait été scripté par mes soins.</p>
<p><a href="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/script001.png" title="script001.png"><img src="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/.script001_m.jpg" alt="script001.png" style="display:block; margin:0 auto;" title="script001.png, juil. 2011" height="509" width="560" /></a></p>
<center><i>jEdit était mon copain! :laClasse:</i></center>
<p>Je lançais un script qui reprenait toute les scènes des animateurs ayant un marqueur, les ouvrait et leurs appliquait un script qui faisait pas mal de choses (liste non exhaustive):</p>
<ul>
<li>Changer les chemins de texture (remplaçant ".dds" par ".map" entre autre).</li>
<li>Modifier les options des textures (pour utiliser le filtrage elliptique).</li>
<li>Setter des bon paramètres de rendu.</li>
<li>Aller chercher, dans un fichier texte, si le plan en question avait du motion blur et l'activer si c'était le cas.</li>
<li>Appliquer certaines modifications (décalage de l'animation des mains de 0.5 frame en cas de rendu avec motion blur pour éviter d'avoir des sautes durant les rotations sur une image, masquer certains contrôleurs visibles au rendu, etc...).</li>
<li>Faire quelques bricolages propres à l'épisode (Appliquer un blur différent au mains du Garçon Tamtam par exemple).</li>
<li>Générer les fichier de job contenant les lignes de commande à lancer (nous utilisions <a href="http://www.uberware.net/smedge/" hreflang="en">Smedge</a>) ainsi qu'un .bat en cas de rendu en local.</li>
<li>Supprimer le fichier marqueur.</li>
<li>Sauver la scène prête à rendre dans le bon dossier.</li>
</ul>
<p><img src="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/batchSmedge001.png" alt="batchSmedge001.png" style="display:block; margin:0 auto;" title="batchSmedge001.png, juil. 2011" height="224" width="238" /></p>
<center><i>Les lanceurs de job généré par mon script</i></center>
<p>Les graphistes, quand ils quittait leur poste le soir ou durant la pause de midi, lançait un client de Smedge et leur machine calculait les rendus.</p>
<p>Mental ray était le moteur utilisé et a très bien joué son rôle (c'était mon moteur de prédilection aussi). Une fois les .map et le filtrage elliptique mis en place, tout à roulé!</p>
<h4>Le compositing</h4>
<p>Le compositing était fait sous After Effect et se divisait en deux parties.</p>
<ul>
<li>Une première contenant tout les "trucs un peu spéciaux" (effets de fumé, transformations, certaines animations aussi) était assuré par un animateur 2D.</li>
<li>La seconde partie représentait le plus gros des plans (80% je dirais) et était principalement de la retouche rapide (patates), des effets globaux (profondeur de champ), etc...</li>
</ul>
<p>J'ai fait un script After Effect (une première expérience) qui créait une compo pour le plan, importait toutes les couches, les empilait dans l'ordre et créait un set d'export.</p>
<p>C'était aussi grâce à ce script qu'on pouvait avoir un retour rapide des rendus "bruts": On lançait le script pour tout les plans rendus, on cliquait sur "Rendu" et le calcul de toute les couches se faisait. Il ne restait plus qu'à vérifier dans le projet de montage (Final Cut) qui se mettait automatiquement à jour.</p>
<p>Un second script (utilisé dans le premier en fait) générait les set d'export depuis les compos sélectionnés dans After Effect ce qui simplifiait le travail des graphistes qui n'avaient plus à perdre de temps sur l'export de leur travail.</p>
<h4>Tout le reste</h4>
<p>Bien entendu, il y avait tout pleins de petites taches qu'il fallait remplir au fil du projet:</p>
<ul>
<li>Backup des épisodes.</li>
<li>Gestion de la place sur le serveur.</li>
<li>Dépouillement technique.</li>
</ul>
<h3>Passage du stade de série au stade de long métrage en relief</h3>
<p>Et oui! Parce que c'est ça qui est particulièrement intéressant sur ce projet. L'idée partait d'une série full HD pour Canal+ et se finit en un long métrage en relief, ce n'est pas un truc qu'on voit tout les jours. :redface:</p>
<p>Je me rappel que c'est suite à une projection pour Canal+ que l'idée d'un long métrage (on ne parlait pas de relief à ce moment là) à commencer à se faire entendre, sans jamais être réellement officielle. Concrètement, cela changeait peu de choses pour nous.</p>
<p>Mais quand on a commencé à parler de relief, les choses ont un peu évolué. <a href="http://www.macguff.fr/fr#/jobs/456-les-contes-de-la-nuit" hreflang="fr">Mac Guff</a> était dans le coup. Nous leur avions donné quelques plans suffisamment représentatif de l'ensemble et ils en ont fait du "vrai" relief.</p>
<p>J'insiste sur le terme "vrai" relief car Mac Guff disposait de toute les couches (et nos fichiers After Effect en fait) et a put travailler le relief sans avoir à recréer artificiellement de la profondeur.</p>
<p>Lors de la première présentation nous étions 5-6 et je dois dire que j'étais particulièrement impressionné par le résultat. La profondeur et le noir donnait un véritable effet de théâtre à l'ensemble. L'équipe du relief avait fait de l'excellent travail et je pense que tout le monde était conquis. (Avatar pouvait aller se rhabiller, il venait de se prendre un low kick rotatif inversé là! :baffed: )</p>
<p>Une fois le relief officiellement validé, le nombre de couche à explosé. Il arrivait que les compos After Effect plombe notre petit réseaux. Finalement, calculer les images en local s'est révélé une solution simple, pas cher, et qui solutionnait, en partis, le problème.</p>
<p>La production c'est donc très bien fini, sans douleurs et c'est assez rare pour être précisé.</p>
<h3>Ce que j'aurais aimé faire mieux</h3>
<p>Forcément, avec le recul, je me dis que quelques points aurait mérité un peu plus d'attention.</p>
<ul>
<li>J'aurai aimé résoudre le problème des textures (cgfx + .dds) qui popaient dans le viewport lorsque les animateurs bougeaient leur contrôleurs. La solution trouvé n'était pas optimale et alourdissait la charge de Maya quand il y avait beaucoup de persos. Les <em>seg faults</em> étaient fréquent...</li>
<li>J'ai choisi d'utiliser le .png pour l'ensemble des images du projet (sauf export Photoshop car le .tiff était le seul format qui conservait bien les alphas lors d'une conversion en .map) car ce format était particulièrement "clair" (RGBA et pis c'est tout!) et je voulais éviter le tiff qui était beaucoup plus "opaque" (plusieurs type de compressions possible, nombre de channel, ne s'ouvre pas partout, etc...). C'est quelque chose que je considère comme une erreur de débutant maintenant car le .png est un format de fichier extrêmement lourd à ouvrir. Le .tiff, si il est bien géré, à tout les endroits du pipeline (au moins au rendu), offre un bien meilleur confort.</li>
<li>Surement d'autres choses...</li>
</ul>
<p><a href="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/yona_contes_de_la_nuit.jpg" title="yona_contes_de_la_nuit.jpg"><img src="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/.yona_contes_de_la_nuit_m.jpg" alt="yona_contes_de_la_nuit.jpg" style="display:block; margin:0 auto;" title="yona_contes_de_la_nuit.jpg, oct. 2012" height="373" width="560" /></a></p>
<h3>Conclusion</h3>
<p>Vous l'aurez surement compris, ce fut une belle expérience autant professionnel que personnel. Bosser avec Michel Ocelot c'est presque un cadeau.</p>
<p>Ce fut aussi une première supervision technique sur un long métrage pour moi.</p>
<p>Le film <a href="http://www.allocine.fr/film/fichefilm-183772/palmares/" hreflang="fr">sera nominé 8 fois</a> au festival international de Berlin ce qui est quand même un grande réussite quand je me remémore le nombre de personnes finalement assez faible qui a travaillé sur ce projet (comparé à d'autres productions d'animation cinématographique).</p>
<p>Les critiques de la presse sont très bonnes et j'espère que ce billet un peu technique vous aura donné envie de voir ce film fait avec amour. :sourit:</p>
<div class="external-media" style="margin: 1em auto; text-align: center;">
<iframe width="640" height="390" src="http://www.youtube.com/embed/vjG45ZTFFjM" frameborder="0" allowfullscreen></iframe>
</div>
<p><a href="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/lescontes.jpg" title="lescontes.jpg"><img src="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/.lescontes_m.jpg" alt="lescontes.jpg" style="display:block; margin:0 auto;" title="lescontes.jpg, juil. 2011" height="560" width="411" /></a></p>
<p>Mes contes préféré?</p>
<ul>
<li>Le Loup-Garou: Parce que le travail fait sur les feuilles rend le relief magnifique.</li>
<li>L'élue de la ville d'or: Parce que dans une salle de cinéma, avec la musique et tout, votre cœur d'adulte lâchera obligatoirement quelques larmes de bonheur.</li>
</ul>
<p>A bientôt!</p>
<p>Dorian</p>
<h3>Liens</h3>
<ul>
<li><a href="http://www.imdb.com/title/tt1828229/fullcredits" hreflang="en">Page IMDb des Contes de la nuit</a></li>
<li><a href="http://www.imdb.com/title/tt1723666/fullcredits" hreflang="en">Page IMDb de Dragons et Princesses</a></li>
<li><a href="http://www.allocine.fr/film/fichefilm_gen_cfilm=183772.html" hreflang="fr">Page allocine</a></li>
<li><a href="http://fr.wikipedia.org/wiki/Dragons_et_Princesses" hreflang="fr">Page Wikipedia de Dragons et Princesses</a></li>
</ul>Tales of the Night, summary of a technical supervisionurn:md5:9ae2161d6ae68c514e18540d668a0aed2011-07-21T16:41:00+02:002013-07-26T18:07:43+02:00NarannInfographie 3D - Boulotcgfxenocelotpost-mortemsupervisingtales of the night<p><img src="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/lcdln_resume_superviseur_tn.png" alt="lcdln_resume_superviseur_tn.png" style="float:left; margin: 0 1em 1em 0;" title="lcdln_resume_superviseur_tn.png, juil. 2011" height="150" width="150" />This is an english traduction of <a href="https://www.fevrierdorian.com/blog/post/2011/07/20/Les-Contes-de-la-Nuit-resume-d-une-supervision-technique">a post</a> I've made some time ago.</p>
<p>As you maybe know, the feature film <a href="http://www.imdb.com/title/tt1828229/" hreflang="en">Tales of the Night</a> (<em>Les Contes de la Nuit</em> in french) from <a href="http://www.imdb.com/name/nm0643664/" hreflang="en">Michel Ocelot</a> (<a href="http://www.imdb.com/title/tt0181627/" hreflang="en">Kirikou</a>, <a href="http://www.imdb.com/title/tt0439123/" hreflang="en">Azur et Asmar</a> and others) has been released in August.</p>
<p>I was fortunate to supervise the technical aspects of production. Beyond that I think this film is a real artistic success, it was definitely one of my most beautiful experience. :sourit:</p>
<p>In this post I purpose to go around the means in place to achieve that beautiful, what do I say? Wonderfull project!</p>
<p>(And do little advertising too :siffle: )</p> <h3>Note</h3>
<blockquote><p>Although the content of this blog is licensed under a Creative Common, all images on this post are the property of their respective authors. Violators may be subject to prosecution and could be kidnapped in their sleep, stoned in the public place and deprived of candies. :gniarkgniark:</p></blockquote>
<h3>How I arrived on the project</h3>
<p>First, replacing the context seems to me interesting.</p>
<p>All start in the end of 2009, I'm working in <a href="http://www.def2shoot.com/" hreflang="en">Def2Shoot</a> the animated feature <a href="http://www.imdb.com/title/tt1039651/" hreflang="en">Yona Yona</a> (old project name). Following several french-Japanese production meetings, the choice to do animation of the main characters in Maya and sets in XSI is made. I find myself being the only TD in Maya (D2S is on XSI).</p>
<p><a href="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/yona.jpg" title="yona.jpg"><img src="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/.yona_m.jpg" alt="yona.jpg" style="display:block; margin:0 auto;" title="yona.jpg, juil. 2011" height="560" width="411" /></a></p>
<p>Franck Malmin (<a href="http://www.excessif.com/cinema/actu-cinema/dossiers/la-naissance-de-yona-par-franck-malmin-producteur-executif-5668560-760.html">read his post-mortem</a>, really honnest, about the film, in fr), D2S CEO , purpose to the Yona Yona Surfacing TD's to help "a production" to start. This one begins to spend few afternoons in <a href="http://www.nord-ouest.fr/" hreflang="fr">Nord Ouest Film</a>, where a part of "Michel's team" is already in place.</p>
<p>At that point I knew no more. But difficulties that would encounter Yona Yona began to be felt and production ask for the full-time return of his surfacing TD on the project.</p>
<p>In Def2Shoot, the Maya part is less of a problem (thanks to the arrival of a second TD) and Frank asked me to continue the work begun at Nord Ouest.</p>
<p>It was at this time I meet peoples I knew as the "Michael's team", all great persons. :sourit:</p>
<p>At first, my job was not to last long and was very basic. I had to understand the project needs and refer them to quick solutions (help to convert mental ray's .map because some matte painting was monstrously large, define a folder hierarchy and explain the "why" and the "how" of each file, etc. ...).</p>
<p>Despite the rather limited technical needs that require this project (Tales of the Night, it's not Transformers with raytracing everywhere), the team, actually rather small and composed of <del>few</del> no technicians, could, in long-term, end up spending more time dealing with technical problems rather than really work peacefully. :reflechi:</p>
<p>There was still, at that time, 10 episodes of 13 minutes each release in full HD.</p>
<p>This concern was shared with the rest of the team and after few conversations between Frank and production, it was decided that I will continue the project until the end (the project lasted one year and a half and it should be noticed that deadlines were met).</p>
<p>I was now officially part of the team!</p>
<center>:youplaBoum:</center>
<h3>Drastic measures</h3>
<p>This decision will quite change my involvement on the project and I could see "farther", do things more advanced, manage more complex cases etc...</p>
<p>Michel Ocelot's Director sssistant came from 2D and was used to do a <del>heavy</del> amazing preprod work. Thus, storyboard and directing was already made and technical stripping was already in Excel files of the director of production (sorry, I don't really know english terms for this) even before an episode would only go in Layout.</p>
<p>This kind of thing quite assured me because have to think about changing everything at the last moment (<del>very</del> too present attitude in advertisement and the cinema aka "à l'américaine") would not led me to take some risks improving the production and it conditions. Naturally when you have some assurance that what you want to do is what we gonna do, you provide less time for "bad crafting".</p>
<p>That's when I could begin defining the outline of the workflow.</p>
<h3>Use scripts</h3>
<p>Let's don't turn around the bush: Scripting was everywhere no one dared venture. :sourit:</p>
<p>The importance of a technically coherent folder hierarchy was thus essential in order to automate tasks, while keeping in mind that it would be handled by "human" and, therefore, should also remain comprehensible.</p>
<p><img src="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/noShowPlans_001.png" alt="noShowPlans_001.png" style="display:block; margin:0 auto;" title="noShowPlans_001.png, juil. 2011" height="246" width="338" /></p>
<p>The preferred language was MEL in all Maya aspects (I was not yet comfortable with "Python in Maya") and Python for everything related to file manipulation (<em>os</em> and <em>re</em> are your friends).</p>
<p>Scripting usage was mainly made for "crossing points" of information/files. I will often refer about it during the rest of this post because I almost passed this production my fingers on the keyboard. :pafOrdi:</p>
<h3>Pipeline summary</h3>
<p><a href="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/Schema_pipeline.png" title="Schema_pipeline.png"><img src="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/.Schema_pipeline_m.jpg" alt="Schema_pipeline.png" style="display:block; margin:0 auto;" title="Schema_pipeline.png, juil. 2011" height="215" width="560" /></a></p>
<center><i>A plan that basically sums up the different steps of the pipeline</i></center>
<h4>Decorators</h4>
<p>"Decorators" (mappers) made their sets in Photoshop (in very huge and very heavy files ^^ ), they exported their work in different layers in tiff in a dedicated folder following ad naming convention specified in advance.</p>
<p>At first, they converted their .tiff in .map (and .dds) themselves but this highly repeteative task took time. So I quickly made script that was going through all textures of the current project and checked that each .map (or .dds) was older than her .tiff. Otherwise, it made a conversion. :dentcasse:</p>
<h4>Characters</h4>
<p>I wasn't directly involved in the characters creation.</p>
<p>A 2D artist did the Photoshop version of the characters, burst them on a plan, a character TD, temporarily joint bye an animateur had set up an automated rig system to generate animable characters.</p>
<p>Character maps was converted the same way than decors.</p>
<p>My part, in the pipeline started at Layout stage with a tool to list characters and import them in the Maya scenes depending on the episode we was working on.</p>
<p><img src="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/layoutGen_001.png" alt="layoutGen_001.png" style="display:block; margin:0 auto;" title="layoutGen_001.png, juil. 2011" height="341" width="412" /></p>
<p>So it was a big communication work to know who list and in which case do not list a particular character.</p>
<h5>Notice about .dds format</h5>
<p>Michel Ocelot validate animation on playblasts. So it need that playblast look "much as possible" near the final render.</p>
<p><a href="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/playblast001.png" title="playblast001.png"><img src="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/.playblast001_m.jpg" alt="playblast001.png" style="display:block; margin:0 auto;" title="playblast001.png, juil. 2011" height="315" width="560" /></a></p>
<center><i>This is a playblast. :sourit:</i></center>
<p>For this, textures used in the scene had to be thoses used in render, dealing with a resizing.</p>
<p>So I've coded a CgFX shader which I gave the .dds texture versions to reduce their load in GPU memory.</p>
<p>This technique worked very well on sets but a bug I was unable to resolve made some textures disappear during controller movements of the characters.</p>
<p>I had to hack a kind of surface shader for the viewport but we loose the advangate of .dds textures because it seems that Maya uncompress and place the entire texture in GPU memory. :pasClasse:</p>
<p>It's a shame because it was character textures size that take more memory actually. So I had to make some "low" version of .dds texture (which already was in low def) and a tool to switch between versions (some shot had a lot of characters)...</p>
<h4>Layout</h4>
<p>So I've made the character importer but also a "set generator". Each shot in the film is actually a layering of maps:</p>
<p><a href="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/orgaDesPlans001.png" title="orgaDesPlans001.png"><img src="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/.orgaDesPlans001_m.jpg" alt="orgaDesPlans001.png" style="display:block; margin:0 auto;" title="orgaDesPlans001.png, juil. 2011" height="339" width="560" /></a></p>
<p>As file naming convention was clear, it was very simple, using a script, to know where were the different layers of the current shot.</p>
<p>It was enough then to specify the episode number and the shot number we want to generate, and click ok.</p>
<p>A set rig was imported and adapted to the shot. Layers of set maps was load on their own plane and the camera's image plane displayed the animatic exported from the montage.</p>
<p>All that remained was "only to" put the characters.</p>
<p>I've also write a "transfer to shot" script to make layouters don't have to reposition every character whereas their was in the same position two shot later...</p>
<h4>Animation</h4>
<p>There was nothing "pipelined" concerning the layout's scene publication. Animators just copy the layout scene and start to animate they shot from this.</p>
<p>I've coded a character panel which was mainly used for hands. Hands simply textures on faces displayed/hidden during the animation.</p>
<p>Hand textures and numeric attributes for "display/hide" followed naming convention. So, each time a new hand was created by mappers, I just had to add a line in my panel's code to make everything appear in the panel.</p>
<p>However, responding to the render automation constraint required that scenes was published in specific folders where the script could find them.</p>
<p>So I've made a publication tool which save the current Maya scene and a little empty file (who played the role of "marker" to specify this scene had just been republished).</p>
<h4>Rendering</h4>
<p>There was no human need for this part. All had been scripted by me.</p>
<p><a href="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/script001.png" title="script001.png"><img src="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/.script001_m.jpg" alt="script001.png" style="display:block; margin:0 auto;" title="script001.png, juil. 2011" height="509" width="560" /></a></p>
<center><i>jEdit was my friend! :laClasse:</i></center>
<p>I had to launch a script getting the whole scene from animation who had a "marker", open them and apply another script which do many things (some examples):</p>
<ul>
<li>Change texture path (replacing ".dds" by ".map" for examples).</li>
<li>Change texture options (to use <a href="http://download.autodesk.com/us/maya/2011help/mr/manual/node24.html" hreflang="en">elliptical filtering</a>).</li>
<li>Set optimal render parameters.</li>
<li>Go lookup, in a text file, if the actual shot had motion blur and activate it.</li>
<li>Apply some modifications (animation offset of hands of 0.5 frame if render with motion blur to avoid "poping effect" during image rotation, hide some visible controlers, etc...).</li>
<li>Do some hack depending of the episode/shot (apply a different blur to the "Garçon Tamtam" hands for example).</li>
<li>Generate job file containing command lines to launch (we used <a href="http://www.uberware.net/smedge/" hreflang="en">Smedge</a>) and a .bat for special case we need to render locally.</li>
<li>Remove the "marker" file.</li>
<li>Save the "ready to render" scene in the good folder.</li>
</ul>
<p><img src="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/batchSmedge001.png" alt="batchSmedge001.png" style="display:block; margin:0 auto;" title="batchSmedge001.png, juil. 2011" height="224" width="238" /></p>
<center><i>Job file generated by the script</i></center>
<p>When lunch time came, artists launched a Smedge client on they worksation to let renders be computed.</p>
<p>Mental ray was the main render engine and it did it well (it was my favorite render engine...). Once the .map created and the elliptical filter set, everthing was fine!</p>
<h4>Compositing</h4>
<p>Compositing était fait sous After Effect et se divisait en deux parties.
Compositing was made with After Effect and was divided in two parts.</p>
<ul>
<li>A first one containing every "a little special things" (smoke effects, morphings, some particular animations, etc...) was done by a 2D animator.</li>
<li>A second one representing the most of the shots (80%) was mainly quick improvements, global effects (depth of field), etc...</li>
</ul>
<p>I've made a After Effect script (my first one) who created a compo for the shot, import every layers, stacked them in the good order and created an export set.</p>
<p>It was also using this script we could quickly had "raw" renders: We launched this script for a list of shot to render, click the "Render" button and the computing of everything just start. It only remained to check the editing project (Final Cut) which was automatically updated.</p>
<p>A second script (used by the first one actually) generate export sets from selected compos in After Effect. This simplify compositor life which never loose time to correctly export they work.</p>
<h4>All the rest</h4>
<p>Of course, there was many little task to do during the project:</p>
<ul>
<li>Episode backup.</li>
<li>Disque space management on servers.</li>
<li>Technical storyboard reading.</li>
<li>etc...</li>
</ul>
<h3>Passage du stade de série au stade de long métrage en relief
From a serie to a relief full feature film</h3>
<p>Yeap! Because this is what make this project interesting. The original idea was to do a full HD serie for a french TV channel (Canal+) and it terminate with a full feature film in relief. This is not something you work on everyday. :redface:</p>
<p>I remember that it's following a projection for Canal+ that the idea of a full feature film has begun, without be really official (there was no talk about relief at this time). In practice, this change really few things for us.</p>
<p>But when we started to talk about relief, things have changed a little. <a href="http://www.macguff.fr/fr#/jobs/456-les-contes-de-la-nuit" hreflang="fr">Mac Guff</a> was on it. We gave them some shots sufficiently representative of the movie and they've done "real" (<em>not-like-clash-of-the-titans</em>) relief.</p>
<p>I insist on the word "real" relief because Mac Guff had all layers (and our After Effect files) and was able to work the relief without having to artificially recreate the depth.</p>
<p>During the first projection we were 5-6 et I must say I was really impressed by the result. The depth and the black gave a real theatrical effect. The relief team had done an excellent job and I think everyone was won over. (Avatar could go get dressed, he'd just take a low kick reverse rotation there! :baffed: )</p>
<p>Once the relief has been officially validated, the number of layer had exploded. It happened that After Effect projects beating down our little network. Finally, compute images locally was a simple and cheap solution that solves in part the problem.</p>
<p>The production is very well done, without pain and it's rare enough to be notified.</p>
<h3>What I would have liked to do better</h3>
<p>Of course, with retrospective, I think that some points would have deserved a little more attention.</p>
<ul>
<li>I wish I solve the texture problems (cgfx + .dds) that "pop" in the viewport when animators were moving their controllers. The solution found was not optimal and would increase the Maya load when there was a lot of characters. <em>seg faults</em> were too recurrent...</li>
<li>I've choose to use .png at every step of the project (excepted Photoshop because .tiff file format was the only one that keep alphas during .map conversions) because this format was very "simple" (RGBA and that's all!) and I wanted to avoid the .tiff which was much more "opaque" (many kind of possible compression, number of channel, can't be opened everywhere, etc...). This is something I see as a "rookie" mistake now because the .png file format is extremely slow to open. The. tiff, if it is well managed in all steps of the pipeline, offers a much better speed.</li>
<li>Probably other things...</li>
</ul>
<h3>Conclusion</h3>
<p>As you maybe understood, this was a great both professional and personal experience. Work with Michel Ocelot is very pleasant.</p>
<p>It was also a first technical supervision for me on a feature film.</p>
<p>The movie will be <a href="http://www.allocine.fr/film/fichefilm-183772/palmares/" hreflang="fr">8 times nominated</a> to the International Festival of Berlin which is still a great achievement when I remember the actually low number of peoples who worked on this project (compared to other productions of film animation).</p>
<p>Press reviews are very good and I hope this post, a little technique, will make you want to see this film made with love. :sourit:</p>
<div class="external-media" style="margin: 1em auto; text-align: center;">
<iframe width="640" height="390" src="http://www.youtube.com/embed/ZoZGOtCzGLc" frameborder="0" allowfullscreen></iframe>
</div>
<p><a href="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/lescontes.jpg" title="lescontes.jpg"><img src="https://www.fevrierdorian.com/blog/public/billets/2011_04_06_lcdln_resume_superviseur/.lescontes_m.jpg" alt="lescontes.jpg" style="display:block; margin:0 auto;" title="lescontes.jpg, juil. 2011" height="560" width="411" /></a></p>
<p>My favorite tales? :sourit:</p>
<ul>
<li>The Werewolf: Because the work done on the leaves makes great stereo.</li>
<li>The Chosen One of the Golden City: Because in the movie theater, with the music, your adult heart will necessary let fall some tears of happiness.</li>
</ul>
<p>See you!</p>
<p>Dorian</p>
<h3>Liens</h3>
<ul>
<li><a href="http://www.imdb.com/title/tt1828229/fullcredits" hreflang="en">IMDb Les Contes de la nuit</a></li>
<li><a href="http://www.imdb.com/title/tt1723666/fullcredits" hreflang="en">IMDb Dragons et Princesses</a></li>
<li><a href="http://en.wikipedia.org/wiki/Dragons_et_princesses" hreflang="en">Wikipedia Dragons et Princesses</a></li>
</ul>Tkinter: Vous aussi, faites des GUI en Python... Ouai, mes fesses ouai...urn:md5:530872bfaa7e3f875a1c8a456bce3cac2009-03-13T23:53:00+01:002013-07-26T22:41:38+02:00NarannScript et code32bits64bitsbidouilledossiersfichiersfiledialogfrocelotproductionpythonscripttrackingwxpython<p><img src="https://www.fevrierdorian.com/blog/public/ecureuilFileTrack/ecureuil_002.png" alt="ecureuil_002.png" style="float:left; margin: 0 1em 1em 0;" title="ecureuil_002.png, mar. 2009" height="150" width="150" />Travaillant actuellement sur un projet de <a href="http://fr.wikipedia.org/wiki/Michel_Ocelot" hreflang="fr">Michel Ocelot</a> (les incultes, cliquez sur le lien :bete: ), je fais une interface graphique pour un logiciel de "tracking de fichier". Ça consiste en gros à lister tous les fichiers d'un certain type (ex: ExxPxx_DecA.tif) dans une hiérarchie donnée (par exemple: Z:/Exx/Pxx/Decors) en ne changeant que quelques variables dans le chemin, ce qui permet d'avoir rapidement un aperçu de "qu'est-ce qu'il manque", de l'âge des fichiers, de savoir qui est plus récent que qui, etc... Super pratique donc! Mais je ne vais pas m'attarder sur le sujet trop longtemps (J'y reviendrai peut-être un jour si je fais une version "publique" et si ça intéresse quelqu'un...). Je voudrais vous parler de Python 3.0 et des problèmes que j'ai rencontrés (et que je rencontre encore à l'heure actuelle) concernant l'utilisation de tkinter. Problèmes qui se révèlent être un des cotés sombres de Python et des modules indépendants qui l'entourent.</p> <h5>Explications <a name="Explications"></a></h5>
<p>Comme je l'ai dit avant, <a href="https://www.fevrierdorian.com/blog/index.php?post/2008/12/23/Pyhton-dans-Maya...-Ou-l-inverse..." hreflang="fr">Python "cay bien"</a>, le seul problème ici c'est que j'ai fait le choix d'utiliser la version 3.0 qui n'est pas rétrocompatible... Cela dit, je m'en foutais dans la mesure où après avoir évalué mes besoins, je ne comptais utiliser que la ligne de commande (et je n'avais besoin que des librairies standards) :hehe: .</p>
<p>Bon, le projet commence, mes scripts marchent à merveille:</p>
<ul>
<li>Renommage des fichiers exportés par Final<del>caca</del>cut (Qu'on ne vienne pas me dire que Mac en prod ça déchire, j'ai un surplus d'arguments allant dans le sens inverse à gérer...)</li>
<li>Cherchage d'erreurs dans les nomenclatures des fichiers: "Pourquoi c'est là ça?", "Il manque un tiret à ton nom de fichier", etc...</li>
<li>Comparaison des fichiers et update par exécution de programme en ligne de commande automatiquement: "Fichier .tiff plus récent que fichier .map, conversion...", "Fichier .map absent mais fichier .tiff présent, conversion...", etc...</li>
<li>Frame "checkage": "Image E01P001_color.tiff de 0 octet", "Image E01P001_color.tiff de 128 octet -> Erreur mental ray probable", etc...</li>
</ul>
<p>Bref, que du bonheur... :youplaBoum:</p>
<h5>Toujours plus! <a name="Toujours_plus"></a></h5>
<p>Mais voila, au fur et à mesure de mon avancement, je me suis fait une lib de petites fonctions bien pratiques et j'ai voulu commencer à faire une petite interface graphique pour tout ça... En toute logique, je commence avec tkinter (une lib graphique vieille comme pas permis mais intégrée en standard à Python 3.0, je la trouve bien moins puissante que le mel, même pour des choses "simples"). Pour ce que je voulais faire (au début), c'était largement suffisant. Quelques colonnes et puis c'était bon...</p>
<p><img src="https://www.fevrierdorian.com/blog/public/ecureuilFileTrack/ecureuil_001.png" alt="ecureuil_001.png" style="display:block; margin:0 auto;" title="ecureuil_001.png, mar. 2009" height="372" width="628" /></p>
<p>Mais comme tout bon (ou mauvais) projet, on se met à vouloir (et devoir) faire évoluer son outil et les besoins en terme de "possibilités" grandissent... Bon, mon interface étant très simple, et voyant le truc venir, je commence à me tourner vers d'autres tool kits graphiques. Et là, je me prends un mur dans les dents (c'est l'effet Python 3.0), à savoir, tous les portages des librairies graphiques les plus connus sont actuellement sous Python 2.x. En effet, Python 3.0 n'était pas rétroactive, la plupart des projets sont frileux à l'idée de passer à la nouvelle version. J'ai trouvé <a href="http://lists.wxwidgets.org/pipermail/wxpython-users/2008-July/078115.html" hreflang="fr">un post</a> d'une personne qui semble être impliquée dans un projet (wxPython, on y reviendra) disant que le portage n'est pas prévu....</p>
<blockquote><p>- "Hi,
I was wondering if there are already any plans when or how wxPython
will support/start moving to python 3? Are there a lot of issues
involved with porting wxPython framework? (I don't mean user
programs.) I know it is still a bit early but as it is coming closer
maybe there is a roadmap already."</p>
<p>
- "Nothing solid yet. I've got a general idea of things that will likely
need to be done, but haven't yet confirmed any of it or done any real
investigations."</p></blockquote>
<p>Qu'a cela ne tienne, mes scripts étant relativement simples, je vire la version 3.0, installe la version 2.6.1 et corrige mes script pour les rendre compatibles: 15 minutes... Aux vues de l'investissement que ça représentait, je n'étais, à priori pas perdant au change dans la mesure où j'allais me retrouver avec une "vraie" lib graphique qui n'allait pas me limiter (comme le fait tkinter).</p>
<p>Après un aperçu rapide des <a href="http://python.developpez.com/outils/Librairies/?page=IHM" hreflang="fr">libs graphiques existantes</a> je remarque une certaine sympathie des utilisateurs pour la librairie <a href="http://www.wxpython.org/" hreflang="fr">wxPython</a>. En ayant déjà entendu parlé, je décide de m'y tenter.</p>
<h5>"Quand les emmerdes arrivent c'est moi qui interviens..." <a name="Quand_les_emmerdes_arrivent"></a></h5>
<p>J'installe tout ça (avec la "doc et démos" qui est extrêmement bien faite, et je pèse mes mots) et commence à lancer une fenêtre, tout marche bien mais dès que je place mon curseur sur la dite fenêtre, python plante (avec envois de rapport d'erreur et tout...). Je continue, utilise différents exemples... Défois ça marche, défois pas (ça fait très débordement de mémoire)... Je cherche sur le forum et je trouve un type <a href="http://www.developpez.net/forums/d697375/autres-langages/python-zope/gui/wxpython/pb-vista-p-python-2-6-p-wxpython/" hreflang="fr">dans le même cas que moi</a>, un système 64bits. Il renvoi à <a href="http://trac.wxwidgets.org/ticket/10082" hreflang="en">un rapport de bug</a>. Le problème est donc connu mais non résolu. C'est spécifique aux systèmes 64bits...</p>
<blockquote><p>"Same problem here with wxPython2.8-win32-unicode-2.8.9.1-py26 under Vista Ultimate x64. Simple applications crash as soon as one moves the mouse onto their window. More complicated applications seem to work fine. Even the demo crashes if you move the mouse onto the splashscreen. If you leave the mouse outside the spashscreen and let it disappear, the demo seams to run fine."</p></blockquote>
<p>Naïvement, je désinstalle mon wxPyhon et mon Python, tous deux en 64bits, puis réinstalle le tout en 32bits... Même problème. :mechantCrash:</p>
<p>Je commence à réfléchir aux alternatives et n'en voit qu'une seule: Passer à Python 2.5...</p>
<p>(Edit: Une personne <a href="http://morison.biz/technotes/articles/55" hreflang="en">semble avoir trouvé une solution</a> mais c'est pas ce qu'il y a de plus propre disons...)</p>
<p>Bon, là ça commence à me gonfler un peu. Après une longue réflexion, je décide de rester sous Python 3.0 avec tkinter. Pourquoi? J'en sais trop rien en fait... Ça me fait bizarre de repasser sous une ancienne version de Python. Mais surtout, j'ai pris conscience de quelque chose: le support est assuré uniquement sur les librairies standard... En gros, tous les portages ne sont pas assurés dans le temps (j'en veux pour preuve la grande quantité de lib python qui ne sont plus maintenus) ce qui fait que si on veut être sûr d'avoir quelques chose qui dure dans le temps, il faut rester sur les librairies standards.</p>
<h5>tkinter! <a name="tkinter"></a></h5>
<p>C'est ici que commence le billet en fait. Tout le début était une intro. :sauteJoie:</p>
<p>Je continue donc ma petite interface sous tkinter. Sauf que voila, la documentation est désastreuse...</p>
<p>Pour résumer, disons que:</p>
<ul>
<li>Il n'y a pas de "vrai doc ultime"</li>
<li>Elle est éparpillée sur le net</li>
<li>Les exemples datent et ne sont plus adaptés à Python 3.0 (L'effet Python 3.0 que je citais plus haut)</li>
</ul>
<p>On s'amuse donc comme un petit fou à tenter tout et n'importe quoi pour réussir certaines manipulations, à trouver une bride d'infos qu'on retranscrit comme on peut (j'ai du aller regarder directement dans les libs py pour savoir comment faire certaines choses :baffed: ). Allez trouvez un moyen de lancer une FileDialog sous Python 3.0, le truc de base à faire. J'ai cru qu'au final j'allais devoir me rescripter une FileDialog. Soit je suis nul, soit ça prouve que c'est un peu la misère, (non pas à faire, mais ça se devine pas... Et sans doc, on est comme un imbécile). Au final, on trouve mais en mettant en relation différentes documentations. Pour mon exemple:</p>
<ul>
<li>"FileDialog" est un sous module de tkinter (Doc1)</li>
<li>Il faut l'appeler avec "asksaveasfilename" (Doc2) (Ne me dites pas que ça se devine...)</li>
<li>L'attribut pour lui mettre un path par défaut est "initialdir" (Doc3)</li>
</ul>
<p>Super! Maintenant (après plus d'une heure), j'ai une FileDialog. :casseTeteMur:</p>
<p>La raison pour laquelle j'ai créé ce billet est la suivante: J'ai tellement galèré pour trouver des morceaux de documentation que je vous propose de les lister ci-dessous (Tout est en vrac mais au moins, vous en avez déjà pas mal).</p>
<ul>
<li><a href="http://fr.wikibooks.org/wiki/Programmation_Python/Tkinter" hreflang="fr">http://fr.wikibooks.org/wiki/Programmation_Python/Tkinter</a></li>
<li><a href="http://infohost.nmt.edu/tcc/help/pubs/tkinter/" hreflang="en">http://infohost.nmt.edu/tcc/help/pubs/tkinter/</a></li>
<li><a href="http://www-acc.kek.jp/WWW-ACC-exp/KEKB/control/Activity/Python/TkIntro/introduction/index.htm" hreflang="en">http://www-acc.kek.jp/WWW-ACC-exp/KEKB/control/Activity/Python/TkIntro/introduction/index.htm</a></li>
<li><a href="http://effbot.org/tkinterbook/" hreflang="en">http://effbot.org/tkinterbook/</a></li>
<li><a href="http://www.pythonware.com/library/tkinter/introduction/" hreflang="en">http://www.pythonware.com/library/tkinter/introduction/</a></li>
<li><a href="http://python.developpez.com/faq/?page=Tkinter" hreflang="fr">http://python.developpez.com/faq/?page=Tkinter</a></li>
<li><a href="http://python.developpez.com/cours/TutoSwinnen/" hreflang="fr">http://python.developpez.com/cours/TutoSwinnen/</a> (Chapitre 8, 13 et 15 mais beaucoup de "dessin")</li>
<li><a href="http://sebsauvage.net/python/gui/index_fr.html" hreflang="fr">http://sebsauvage.net/python/gui/index_fr.html</a></li>
<li><a href="http://python.developpez.com/sources/?page=Tkinter" hreflang="en">http://python.developpez.com/sources/?page=Tkinter</a></li>
<li><a href="http://www.java2s.com/Code/Python/GUI-Tk/CatalogGUI-Tk.htm" hreflang="en">http://www.java2s.com/Code/Python/GUI-Tk/CatalogGUI-Tk.htm</a></li>
<li><a href="http://www.tcl.tk/man/tcl8.5/TkCmd/contents.htm" hreflang="en">http://www.tcl.tk/man/tcl8.5/TkCmd/contents.htm</a></li>
<li><a href="http://www.manning.com/grayson/" hreflang="en">http://www.manning.com/grayson/</a> (Livre que je vais peut-être m'acheter en PDF)</li>
</ul>