Dans la première partie, nous avons abordé les différents jobs qu’on peut retrouver sur une ferme de calcul. Ici nous allons parler de certains aspects tel que la notion de prédiction de données, relation aux versions, gestion du temps de chargement des scènes et des versions des logiciels et plugins.
L’exécution de tâches (jobs) sur des gestionnaires de tâche (job manger, render manager, farm manager) est courante dans énormément de secteurs liés à l’informatique. Que ce soit la compilation de code, l’exécution et le rapport de tests unitaires, le calcul financier, ça pullule. :popcorn:
Internet regorge d’informations et de bonnes pratiques liées à l’exécution et la gestion des tâches sur des fermes de calcul. Pourtant, beaucoup de ces informations sont trop génériques et passent à côté de certains problèmes de fond, propres à notre industrie. :triste:
Je voudrais, modestement et de façon totalement subjective, faire un retour d’expérience autour de l’organisation et la structure de la ferme de calcul. Notez que je n’affirme pas avoir LA bonne méthode pour gérer les fermes de la façon la plus efficace qui soit, mais j’aborde et commente différentes problématiques que j’ai pu rencontrer.
Si vous avez déjà essayé de compiler alembic, vous avez sûrement été confronté à pas mal de soucis. Compiler alembic n'est en effet pas simple et les méthodes pour y arriver sont nombreuses suivant ce que vous souhaitez faire.
Dans ce billet, je vous propose d'expliquer ligne à ligne un script bash afin de voir les différentes étapes. Notez que c'est plus un partage d’expérience qu'un vrai tuto. Il y a de fortes chances que ce script ne fonctionne pas sans modifications de votre part.
Je préfère prévenir: Mieux vaut être habitué à tout ce qui touche à la compilation. :mechantCrash:
Cela fait un moment que j'ai cet ocarina mais du fait du peu d’intérêt pour ce type d'instrument sur la scène francophone je ne voyais pas de raisons d'en parler.
J'ai cependant l'impression que ça change et que certains artisans francophones s'y mettent tout comme certains musiciens, eux aussi français, sortent de l'ombre pour échanger. :sourit:
Ce livre a été publié après la session de cours Multithreading and VFX au Siggraph 2013 où un certain nombre de studios présentaient comment ils avaient utilisés le multithreading dans leur outils. Les papers étaient suffisamment intéressant pour qu'ils décident de les rassembler en un livre.
Dans la mesure ou ce type de livre fait parti du marche de niche que sont les VFX, parlons en! :enerve:
Dans ce billet je vous propose d'utiliser une méthode simple un bricolage (on parle de mental ray for Maya là :baffed: ) visant à diminuer le flicking du Final Gather.
Vous allez voir que l'approche est un peu particulière mais elle vise tout bêtement à reproduire le comportement de l'option Interp. samples de Vray.
Ceci est la traduction d'un billet de old school, posté il y a quelques mois, qui explique, très clairement, le fonctionnement interne de Houdini. Ce post est une mine d'or et je conseille à quiconque souhaitant s'améliorer sur Houdini d'en prendre connaissance.
Il y a beaucoup de lecture, je me suis permis de mettre des titres et quelques images pour "classer" un peu l'ensemble (le bonhomme aborde beaucoup de chose d'une traite). Alors accrochez-vous! :grenadelauncher:
Bien entendu, si vous êtes totalement débutant sur Houdini il n'est pas forcément pertinent de lire tout ça sans avoir suivi quelques tutos (vous partiriez en courant :hihi: ), même succinct sur comment utiliser le soft.
Depuis Maya 2011 et son passage à Qt, le picker de couleur a été modifié et il n'est plus possible de picker une couleur en dehors de l'interface Maya.
En fait si, et c'est tout con a faire! :hehe:
Il suffit, une fois le picker sélectionné, de cliquer dans l'interface Maya mais de garder le bouton gauche enfoncé et de glisser à l’extérieur de l'interface pour récupérer la couleur qui vous intéresse.
Et encore un petit script prétexte à utilisation de l'API Maya. :sauteJoie:
L’idée est de reproduire l'effet de géométrie en voxel que vous avez peut être déjà observe.
Rien de bien méchant et ça existe surement déjà et en plus rapide. Pour tout vous dire, je n'ai même pas cherché. Le but est encore une fois d'utiliser l'API. :baffed:
Voici un tuto que je voulais faire depuis pas mal de temps. :dentcasse:
VRay propose, depuis un bon moment maintenant, d’utiliser des attributs par objet pour contrôler certaines valeurs. Ça peut aller assez loin mais bien souvent, ce sont les shaders qui en profite. L’idée est d’appliquer un seul et unique shader à un grand nombre d’objet, mais que chaque objet ait des attributs « spéciaux » avec une valeur bien particulière qui se verront appliquer sur les attributs du shader. Si vous vous rappelez bien, je vous avais présenté une feature similaire sous mental ray (Les User Data).
Mais avant même de faire ça, ce tuto va vous expliquer comment exporter puis importer des vrmesh et refaire des assignations de shader à l’intérieur des-dits vrmesh ! Bref, un gros programme ! :bravo:
Ne vous est il jamais arrivé d'avoir un éclairage un peu vicieux ou monsieur Final Gather vous propose un bloblotage du pire effet? La seule solution étant souvent de monter les temps de rendu (quand c'est encore possible ^^') pour cacher la misère.
Et encore, parfois, monter tous les paramètres comme un goret n'est pas suffisant, tout simplement parce que le Final Gather ne peut pas gérer ce cas.
Depuis peu, une solution permettant de régler drastiquement (mais pas toujours) ce soucis a été mise au point: C'est les importons.
C'est rien du tout mais à chaque fois que je dois déplacer un fichier vers un dossier qui n'existe pas je me retape cette fonction à la mano avec les désagrément que peut engendrer l'utilisation des os.mkdir et os.rename. :casseTeteMur:
Comme ce genre de fonction peut intéresser des gens je la met ici pour en faire profiter tout le monde (afin de participer activement et agrandir cette intelligence collective qu'est l'internet... Pourquoi je dis ça? Euh... Et bien en fait j'essais de grapiller quelques lignes sinon le bloc du code se place mal... :seSentCon: )
Ça fait un moment que j’entends Damien (alias Deex) parler de son tool. J'ai même eu l'occasion d'être sur la même prod que lui quand il réfléchissait aux grandes lignes. Quand il m'a dit que son outil était enfin fini, je n'ai pas pu m’empêcher de lui demander une licence pour tester ça. :sourit:
L'idée de ce billet est de présenter les principales features d'Arsenal. Vous allez voir que malgré une approche qui peut sembler un peu trop user friendly, cette outil est un vrai outil de production qui facilite pas mal le boulot.
Pour info, GOG était l’abréviation de Good Old Games et proposait (et propose toujours) des jeux sans DRM, à des prix attractifs et surtout une compatibilité avec les nouveaux systèmes.
C'est précisément ça qui m'a amené à dépenser la moitié moins du prix d'une peinte parisienne (c'est le premier argument qui m'est passé par la tête au moment de payer, allez savoir pourquoi...) pour ce jeu dont j'ai dû passer plus de temps sur la démo que sur la plupart des autres jeux que j'avais pu acheter à l’époque. :baffed:
Nuke, After Effect et surement d'autres, peuvent se révéler très "gourmand" en termes d’accès disque. A tel point qu'ils peuvent rapidement mettre des disques réseaux à genoux si plusieurs stations font des rendus.
Dans ce billet je vous propose une explication rapide du comment du pourquoi ainsi qu'une petite classe Python qui fait office de prototype pour solutionner le probleme.