Blog ca suffit pas comme titre ?

Un nouveau blog sur Wefrag le blog de Ze_PilOt.

L’évolution des moteurs de rendu part 2.

Dimanche 24 novembre 2013 à 11:55

part 1 : http://blogs.wefrag.com/Ze_PilOt/2011/02/07/levolution-des-moteurs-de-rendu/

La première partie parlait des 25 ans de Pixar.

Cette deuxième partie a pour point de départ les 25 ans de PRMan.

Le roi est mort, vive le roi !

La version 19 est sur les rails, et marque un virage à 180° dans la philosophie du moteur.
Si les version précédentes avaient des capacités de raytracing, le résultat était risible.

Développée en grande partie pour Monster University, elle intégrera un moteur Monte-Carlo complet, comblant ainsi 10 ans de retard technologique.

Là où des shots de Toy Story 3 nécessitaient plusieurs centaine de lampes, les shots les plus complexes de MU en ont une dizaine.

Enfin rendu en raytracing, la hausse de qualité est bien visible tout le long du film.

Se coupant également de tout pre-process (shadow map, point cloud,…), les artistes sont capable d’itérer bien plus rapidement.

Il est amusant de noter que l’investigateur de ce changement (Christophe Hery) a du leur ré-apprendre leur manière de travailler, plus proche désormais d’un directeur photo que d’un technicien.

Pareillement, il a fallu ré-apprendre des concepts assez basiques de physique aux développeurs des “shaders”.

Malheureusement, il ne fait pas entièrement table rase du passé, et devient un de ces moteurs hybrides usine à gaz.

Le grand virage.

Ce changement, j’en parlais dans la partie 1 il y a deux ans, annonçant un virage à venir pour l’industrie, grâce à Arnold.

Ce virage a bien eu lieu, et extrêmement rapidement.

Toute les boites majeures de l’industrie utilisent désormais Arnold.
Parmis les blockbusters et autres films sortis cette année et utilisant Arnold, notons :
- Toutes les cinématiques précalculées de l’e3 d’Ubisoft et Microsoft  -Watchdog, AC4- Par Digic.
- Pacific Rim (ILM)
- Elysium (La base spatiale par WhiskyTree)
- Gravity (Framestore)

Pacific Rim, rendu sur Arnold

Pacific Rim, rendu sur Arnold.

Le fait qu’ILM ait laissé tomber Prman, pourtant bien rodé sur les Transformers, au profit d’Arnold est assez significatif de la viabilité de la philosophie derrière celui-ci :

Le temps machine ne fait que diminuer, le temps humain lui est incompressible.

Mon expérience personnelle/professionnelle avec Arnold.

Contrairement à il y a deux ans, je peux désormais parler un peu plus librement d’Arnold en lui même.

Après avoir souffert avec Mental Ray et subit un moteur renderman pendant de longue années, j’ai poussé ma boite à passer à Arnold.

Il me semblait tout à fait remplir le cahier des charges du type de productions que l’on réalisait, en plus d’être étonnamment simple et robuste.

A cette époque, il fallait signer un NDA pour l’utiliser, et le plugin pour Maya était à l’état embryonnaire.
Cependant, une des autres force d’Arnold est d’avoir une API (l’interface de programmation qui permet de communiquer avec le moteur) simple, et surtout, les plugins applicatifs (qui permettent d’envoyer les données du soft 3d vers le moteur de rendu) étaient Open Source.

Les premières versions utilisables de MtoA (le plugin Maya To Arnold) ont été le fruit d’une collaboration entre directeurs technique de différentes boites.

J’ai notamment pu contribuer activement au développement de ce qui nous étaient nécessaire pour nos productions. (Si vous ouvrez la boite “about” du plugin, vous y verrez mon nom dans les contributeurs :)

Le gros avantage est que le plugin est pensé à la base pour la production, s’affranchissant des stupidités que l’ont peut voir dans les plugin Mental Ray ou Vray.

Depuis, le plugin a été repris entièrement par SolidAngle (la boite qui édite Arnold), mais le code est toujours ouvert, et l’équipe fortement à l’écoute de ses utilisateurs.

La version 4.1 est sortie récemment, et la barre est toujours plus haut.

YouTube Preview Image

Dans la même optique, une autre grande évolution est également apparue ces dernière années :

L’open Source.

Vous allez me dire que ça existe depuis des décennies, et qu’il y a même un soft 3d entièrement open source. Mais ce n’est pas de ça dont je parle.

Le mouvement a été initié par ILM. Il n’y avait aucun format d’image existant que remplissait le cahier des charges nécessaire au monde de la 3d.
Ils ont donc développé un nouveau format, l’EXR. Se rendant compte qu’un format n’est viable que s’il est utilisé, ILM a ouvert le code et aidé à son intégration dans différent software.

L’EXR est depuis le format de référence utilisé partout dans l’industrie.

Depuis, énormément de projets Open Source provenant de pointures de l’industrie ont vu le jour.

OpenColorIO (Sony) : Qui unifie et simplifie la chaine de traitement colorimétrique qui en avait bien besoin.

Alembic (Sony/ILM) : Probablement aussi important que l’EXR. C’est un format de stockage 3d. Ca n’a l’air de rien dit comme ça, mais il n’existait aucun standard viable avant son apparition.

Il y avait bien l’OBJ, mais qui était bien limité (pas d’animation, seulement des polys,…), le FBX (trop complexe est peu pratique) ou GTO (trop confidentiel), mais Alembic les surclassent.

Sans rentrer dans les détails, il permet de “baker” non seulement des polys, mais aussi des matrices de transformations, des curves, des point cloud, voir même des shaders, avec une gestion hiérarchique (on garde donc le parentage).

En plus de cela, grâce à un hash systématique de toutes les données, il ne duplique pas les données redondantes sur une animation, et au niveau du rendu, il permet de re-instancier les objets sans que l’artiste ait quelque chose à faire.

OpenVDB (DreamWorks) : Pour schématiser grossièrement, c’est le pendant d’Alembic pour les données volumétrique.

Ce sont les principaux projets, mais bien d’autres existent.

Et dans la continuité …

Outre l’open Source, l’innovation ne vient désormais plus que part des boites spécialisées dans le développement.

Ainsi, Nuke, devenu le standard pour le compositing, est originaire de Digital Domain.

The Foundry se fait fort de récupérer le développement interne de boites de 3d et les booster.

Notons :

- Mari (Weta Digital) : Le premier soft qui permet réellement de peindre sur un objet 3d. Il y a certes eu des tentatives plus ou moins réussies par le passé, mais Mari est le seul soft qui peut promettre de mettre définitivement photoshop au placard.

-  Katana (Sony) : Un soft de lighting nodal. Encore quelques problèmes du à sa jeunesse (il n’est pas encore commercialisé “officiellement”), mais pour l’avoir utilisé et avoir développé autour (notamment un projet Open Source d’échange de shaders Arnold “application agnostic” via Alembic), je ne me vois pas utiliser autre chose dans 5 ans. En attendant, je continue de souffrir sur le dinosaure Maya :).

- Flix (Sony) :  Jamais utilisé, je ne peux rien en dire.

L’évolution, déjà en cours,  est probablement la disparition de soft monolithiques (Max, Maya,..) à la faveur de soft dédiés une seule tache plus précise (Zbrush, Modo, Katana, Massive, …).

A noter l’apparition de “moteur” ouverts qui permettent à une boite de développer  elle même ses outils facilement:
http://fabricengine.com/ ou le “Houdini Engine” :

http://www.vimeo.com/70073569

References :

Interview 3DVF sur le spot Milk où je reviens sur les concepts abordés ici.

Article FX guide sur Gravity (Chpitre “Animation, effects and rendering” pour Arnold)

Monsters University: rendering physically based monsters

The state of rendering part 1 & part 2


5K, HD : Le test.

Lundi 17 décembre 2012 à 11:06

Essayons de comparer objectivement les formats “HD”.

Prenons une source correcte, provenant d’une caméra 5K (RED Epic en occurrence).

Faut cliquer pour pouvoir se rendre compte du piqué réel de l’image :)

Le jeu est le suivant : J’ai pris d’autres images de ces séquences. Certaines sont toujours en 5K, d’autres ont été converties en 1080p et remises en 5K. A vous de me dire qui est qui.

En test final, j’ai pris des images d’autres plans pour éviter de pouvoir comparer à l’original.
1.

2.

3.

4.

5.

6.

- La taille de votre écran ne joue pas dans ce test : L’image n’est pas affichée totallement, vous voyez donc l’image tel quel serait si votre diffuseur était réellement en 5k.
- La distance de vision joue. En collant le nez à l’écran, ca peut devenir facile de trouver qui est qui. Mettez vous à une distance de vision normale : Si vous le faites sur votre TV, mettez vous dans le canapé.
Imaginez également la taille de votre dalle par rapport à l’image. Si votre moniteur/TV fait du 1920*1080, il devrait être 2,5x plus grand.
- La qualité de la dalle joue. N’hésitez pas à faire le test sur différents supports !

Complément d’information : http://www.swift.ac.uk/about/files/vision.pdf

Je pense qu’il est temps de parler de …

Mardi 26 juillet 2011 à 11:25

Forged Alliance !

(Oui bon encore)

Si vous avez suivi mes deux derniers posts, vous savez de quoi il s’agit.

La première version de Forged Alliance Foverer vient de sortir !

0.2.0.0b : http://users.edpnet.be/zepilot/FAFovererLobby.msi

Plus de détails ici

Cette version patch également le jeu en 3604.

Pour ceux qui ne connaissent pas ou qui aimeraient découvrir, vous avez besoin d’une installation fonctionnelle de FA, patchée en 3599 (http://cdn.thqonline.com/SC/Patches/supcom_fa_patch_1.5.3596_to_1.5.3599.exe)… Et c’est tout.

Vous installez FAForever Lobby, vous suivez les instructions, et tout devrait bien se passer.

Pour plus de fun, vous pouvez nous rejoindre sur le mumble de canard PC !

N’ayez pas peur, il y a de tout les niveaux, même du tout petit nouveau !

YouTube Preview Image

En parallèle, TheBigOne (le frère de TheLittleOne, la star de starcraft 2 qui a débuté sur supcom) relance des tournois FA :

La première édition est dispo en VOD ici :
http://www.regame.tv/vod/5456 et http://www.regame.tv/vod/5457, avec une intro pour ceux qui viennent de starcraft. Un petit succès qui a ramené un peu plus de 250 viewers.

Dev Diary #2 : TrueSkill

Lundi 25 juillet 2011 à 14:26

Cet article est très largement basé de cet excellent article.

Je voulais intégrer une feature qui donnerait à mon projet un gros avantage par rapport a GPGNet, et le plus rapidement possible.

Quand on veut classer des joueurs sur un ladder, il y a plusieurs systèmes bien connus et éprouvés. Le plus connu, et utilisé sur GPGnet, restant le Elo.

La grande question a laquelle essaient de répondre ces systèmes est “Comment mesurer le “skill” d’un joueur ?”. Autant pour un sprint c’est facile (suffit de mesurer le temps), autant sur un RTS, c’est bien plus complexe.

La réponse la plus simple serait de comptabiliser le nombre de victoires et de défaites. Mais ca ne serait pas juste pour ceux qui jouent beaucoup ou peu. On peut évidemment ne prendre en compte que le ratio de victoires, mais ca ne serait pas juste pour ceux qui ne jouent que contre plus faible ou plus fort.

De plus, le but ultime, en plus de classer les joueurs, est de pouvoir leur offrir du challenge. Quelqu’un qui est correctement “matché” devrait avoir 50% de victoires. En fait, dans un système parfait, tout le monde devrait avoir ce ratio. Classer par pourcentage de victoire est donc impossible.

Ce qui nous importe finalement est de savoir si X est potentiellement meilleur que Y, et de donner une valeur a la différence de niveau. La valeur importe peu, tant qu’elle reste relativement correcte entre chaque joueur.  Ce qui nous importe, c’est de savoir la probabilité que X a de gagner contre Y, ou de perdre, ou de faire un draw.

Venons en aux échecs, pour qui le système Elo a été inventé. Une différence de 200 points entre 2 joueurs donne au mieux classé une chance de victoire 75%. 200 est totalement arbitraire : Ce qui importe, c’est que notre joueur X, s’il a 200 points en plus que Y, gagnera potentiellement 3 parties sur 4.

La courbe de probabilité de notre joueur X est déterminé par une gaussienne. Je vous laisse lire l’article linké au début de cette page pour des explications plus détaillées.

Les problèmes du système de calcul Elo sont les suivants :

- Il ne gère absolument les équipes. Une équipe est considérée comme un seul joueur, et il est impossible de transférer votre résultat en équipe sur votre valeur individuelle.
- Les draws sont considérés comme des demi-victoires, alors qu’ils veulent dire que le matchup était équilibré, ce qui a beaucoup d’importance dans le calcul de votre rating.
- Arbitrairement, une limite de gain ou de perte est attribuée selon votre niveau : Plus vous êtes bas, plus vous pouvez gagner, afin d’artificiellement permettre au système de plus vite vous classer.
- Ce système souffre d’inflation : Même avec la limitation de points, les premiers vont continuer à grimper alors que leur niveau n’évolue pas.

Mon idée pour le projet était d’offrir un système qui classerait les joueurs, même pour les parties customs, afin de permettre de faire des parties équilibrées, sans entrer dans un système compétitif de ladder. En gros, éviter de se faire traiter de noob sans raisons :)

Du coup le ELO était hors de question, il me fallait un système qui gère au moins le jeu en équipe. D`où TrueSkill.
L’algo de Microsoft a plusieurs avantages sur l’Elo :

- Il gère aussi bien le 1 vs 1 que le 6vs6 ou le 2vs2vs2vs2, ou le FFA complet. Chaque équipe est composée du skill de chaque joueur participant,  cette entité a ses propres probabilités de gagner, et le résultat de ces probabilités est correctement redistribué aux joueurs. De plus, il ne fait pas que comparer deux joueurs mais une chaîne de joueurs.

- Les draws sont correctement gérés. Tout d’abord il tient en compte le milieu de jeu : Si une carte a une probabilité de draw de 90% (calculé selon les parties jouées dessus), le fait que vous gagnez a beaucoup plus de sens que si vous avez battu le même adversaire sur une map ou la probabilité de draw n’est que de 10%.
A l’inverse, faire un draw sur une map où la probabilité d’en faire un est faible rapprochera plus les joueurs l’un vers l’autre.

- Il ne triche pas. Chaque rating prend en compte le skill du joueur, mais aussi le degré d’incertitude (voir l’article de Moser ou le wiki sur les gaussiennes). Une fois votre niveau atteint, il devrait rester stable.

- TrueSkill permet, comme Elo, de calculer si un match est équilibré. Sauf qu’il peut le faire pour des équipes, et du coup il est facile de calculer quelle est la meilleure combinaison d’équipe possible pour avoir un bon match !

On m’a souvent cité Dawn of War 2 comme contre exemple du trueSkill. Il faut cependant prendre un compte que les développeurs n’y ont certainement rien compris :

- Le range trueskill “normal” s’étant entre 0 et 50 avec une moyenne a 25. (J’utilise pour ma part 1500 comme moyenne pour correspondre a GPGNet). Avec une plage aussi petite, il est évident que les chiffres derrière la virgule sont très importants.

Souvenez vous de mon exemple des échecs : Si 200 représente 75% de chances de gagner aux échecs, sur un TrueSkill de 0 a 50, une différence de 4,16 représente 80% de chances de gagner !

Il est évident que supprimer les chiffres derrière la virgule est ridicule et retire tout l’intérêt du système.

Par exemple, en faisant quelques tests rapidement, deux personnes rankée 30 sont en réalité rankées 29,62 et 30,41, et que celle a 30,41 a 15% de chances de gagner sa partie contre celle a 29,62.

TrueSkill est déjà intégré à mon projet, qui atteint doucement le stade de la première Beta..

Dev Diary : Forged Alliance Forever.

Lundi 18 juillet 2011 à 10:15

J’adore les RTS.

Le problème, c’est que j’aime pas trop les RTS “tactiques”, et il n’y a quasiment que ça sur le marché,
Ruse est trop lent pour moi, les Total Wars par assez dynamiques.

Reste StarCraft 2, sûrement très bon, mais qui m’a fatigué au bout d’un mois. Il remplace trop la réflexion par les réflexes.

Non, le seul bon compromis, le seul jeu qui gère les 3 espaces de combats correctement, tout en étant nerveux, c’est pour moi Forged Alliance.

Pour ceux qui ne connaissent pas, c’est un add-on a Supreme Commander, le fils spirituel de Total Annihilation. Il corrigeait pas mal de problèmes de Supreme Commander, notamment en recentrant le jeu sur la prise de terrain. (Là où Supreme Commander 2 est hélas revenu a un modèle plus starcraftien).

Pour les fans de Starcraft 2 qui liraient cet article, TheLittleOne (TLO) vient de FA, et a du l’abandonner en premier lieu pour starcraft 2 à cause du manque de suivi  de FA. (en un deuxième temps quand il est devenu bon, parce qu’il y avait de la thune à se faire :) Il était d’ailleurs bien plus impressionant sur FA du fait des possibilités accrues.

Le jeu gère en effet tout la balistique de façon physique, il est donc possible par exemple d’éviter les tirs, ou de détourner une tourelle ennemie de sa cible.
C’est aussi le jeu de la démesure, avec du Nuke, et les fameuses expérimentales (concept quasiment repris dans StarCraft 2 d’ailleurs).

En images qui bougent :

YouTube Preview Image YouTube Preview Image

Jeu trop gourmand a sa sortie (plus vraiment un problème maintenant), jeu de niche, … Résultat, il s’est mal vendu et le support a stoppé assez vite.

J’avais déjà à l’époque tenté de le faire revivre en sortant un Community Balance Patch (avec l’aide de la communauté de moddeurs), qui a donné par la suite un nouveau patch de GPG, le 3603, hélas jamais sorti par THQ.

MAIS BORDEL !

Je veux continuer a jouer a ce jeu excellent ! Avec kekouse, on s’est alors demandé pourquoi a l’époque, le projet Galatic Wars (un metagame au dessus de FA) n’était jamais sorti en l’état, car il proposait des lobbys fait maison, et donc la possibilité pour les joueurs d’assurer le support.

Je me suis alors demandé quel serait la difficulté de faire un lobby à la TA Spring… Plus ou moins au meme moment, THQ avait répondu a la communauté en disant que c’était cool qu’on joue toujours a FA, mais qu’eux, ils assurent le service minimum et que c’est déjà  bien comme ça. Allez, banco alors, je sors Eclipse !

Je choisis d’abord de tester le protocole réseau en python, vu la rapidité de prototyping (pas besoin de compiler, et le language est très permissif tout en ayant une TONNE de libraires pour tout et n’importe quoi).

Premier tests, premier paquet envoyé d’un serveur ultra basique vers le jeu :

Premier paquet

25 Juim - Premier paquet

Les paquets sont encodé en little-endian, un integer pour la taille du header, puis un integer pour chaque donnée.

“Super !” bon, on regarde les commandes nécessaires pour créer un lobby :

Premier lobby

27 Juin - Premier lobby

Banco !

Bon, là, c’est viable. On a besoin d’un chat pour le lobby, je décide de ne pas chercher midi à 14h et d’utiliser IRC.

29 Juin - Test de lirc

29 Juin - Test de l'irc

Pour la partie graphique, je décide d’utiliser QT, disponible en python via un wrapper : pyQT. Ça a l’avantage d’être toujours rapide à coder, tout en proposant des fonctions avancées tournant en c++ bien rapide.

Je peux également, plus tard, recoder “facilement” en c++, vu que je me base le plus possible sur QT et le moins possible sur python et ses libraires customs.

30 Juin, gestion du login avec base de donnée MySQL sur le serveur.

30 Juin, gestion du login avec base de donnée MySQL sur le serveur.

Le serveur est lui aussi codé en pyQT en QApplicationCore (pas d’UI) - Fonctions de threading haut et bas niveau, fonctions réseaux simples et puissantes.

4 Juillet, première connection deux joueurs.

4 Juillet, première connection deux joueurs.

La première Alpha est prête deux jours plus tard.

Je vais dans cet article me concentrer sur la partie serveur, dont voici la structure :

Pas la peine de me dire que jai pas les bonnes conventions, jy connais rien en organigrammes, jai fais joli.

Pas la peine de me dire que j'ai pas les bonnes conventions, j'y connais rien en organigrammes, j'ai fais joli.

Au lancement du server, il spawn deux socket entrant, un pour le lobby, un pour FA.
Il se connecte à la DB, et passe la connexion à ces deux entités.
Il crée également une entité “players” et une entité “games”. Eux même contiennent une entité “player” et “game”.
Il passe également “players” et “games” aux deux serveurs “lobby” et “Fa games”. (quand je dis passe, pensez plutôt à des pointeurs mémoire en c++ : il renseigne le thread où se trouve ces infos en mémoire, elles sont donc communes à toutes ces entités)

- “Players” contient la liste entière des “player”. Un “player” est créé à chaque connexion entrante, et liste son état (rien, lobby, en jeu, cherche un ladder,…), son login, ip, gameport …
- “Games” contient la liste entière des “game”. Un “game” est créé à chaque fois qu’un joueur host une partie. Il contient le nom de la map, .. Et une liste de “player” dans l’entité “game” en cours.

A chaque connexion au lobby, un thread est créé. L’entité “lobby” lui passe un lien vers la DB, la liste des “players” et des “games”.
Ce thread est autonome, mais peut communiquer avec les autres threads via la DB ou les entités “players” et “games”. (Grace a QT, je peux gérer les locks/mutex de façon très très simple).
C’est ce thread qui créera les entités “player” contenue dans “players” ainsi que les entités “game” dans “games”.
Chaque thread est intimement lié à sa propre entité “player”. Elle est unique et invariable pour chaque thread. Il est aussi unique : un “player” ne peut pas appartenir à plusieurs threads (je m’en assure via un numéro de session unique pour chaque joueur)

A chaque connexion au FA Server, un thread “FA Game” est aussi créé.
Ce thread est censé être créé à la suite d’une action “HOST” venant d’un thread “Lobby”.
Pour savoir qui est l’entité “player” responsable, il interroge les “players”, et regarde ceux dont l’ip correspondent à l’adresse de la connexion qu’il reçoit.
Si cette IP est inconnue, il rejette la connexion.
Pareillement, si l’entité “player” trouvée disparaît (son thread est mort parce que le joueur déconnecte du lobby”), ce thread se ferme également.
Chaque thread “Fa Game” est intimement lié à une entité “game” qui lui est unique. Pour savoir à quelle entité “game” il appartient, il interroge la liste des “games” et cherche si le joueur précédemment trouvé en fait partie.
Contrairement aux threads “lobby”, plusieurs thread “game” sont liées à la même entité “game”. Si un thread ferme, il n’entraîne pas la disparition de l’entité “game”, sauf si c’est l’hôte qui quitte.

Les threads me permettent de traiter les demandes simultanément plutôt que consécutivement pour chaque joueur.
Chaque thread a sa propre “bulle” mémoire, et si quelque chose de bizarre se passe dedans, si un bug se produit, et que le thread meurt, il n’entraînera pas la chute de tout le système.

Ça me permet également de mettre à jour le code à la volée.
Le code “server” et les deux codes “FA lobby server” et “FA game server” sont in-changeable sans redémarrer le serveur. Par contre, ils ne font qu’une dizaine de lignes et n’ont pas varié depuis le premier jour.
Je peux updater par contre le cœur du système, le code de chaque “thread”, à n’importe quel moment : Un thread en court ne variera pas, mais les nouveaux threads créés vont utiliser le nouveau code.
Je peux également updater le code des entités “games/game” et “players/player”, sans soucis autre que le possible crash de threads utilisant l’ancien code, et recevant ou ne retrouvant pas des fonctions. En pratique, c’est rare que ça arrive.

Infos supplémentaires :

Ma roadmap : http://bitbucket.org/thepilot/falobby/wiki/RoadMap

Le lobby est pour le moment en alpha. Je ne posterais pas le lien ici car j’estime qu’il n’est pas encore pret pour le “grand public”, mais si vous êtes intéressés, c’est facile a trouver sur les forums de GPGNet ou Canard PC.

Le prochain article traitera du matchmaking et plus particulièrement de TrueSkill.

Minuscule - Saison 2

Lundi 11 avril 2011 à 10:30

Minuscule, c’est une série d’animation 3d dans des décors réels. créé par Hélène Giraud et Thomas Szabo.

Pour ceux qui ne connaissent pas, la première saison est en partie disponible sur youtube et dailymotion.

La saison 2 est sur le point d’être diffusée, et elle s’annonce d’encore meilleure qualité (Et je ne dis pas ça parce que c’est nous qui la réalisons :)

On clique sur la vignette pour le trailer !

On clique sur la vignette pour le trailer !

L’évolution des moteurs de rendu.

Lundi 7 février 2011 à 21:16

(Je ne parlerais ici que des moteurs de rendu utilisé dans les productions de films)

La gènese de Renderman.

Il y a 25 ans naissait Pixar. Je vous laisse lire cet article de 3dvf, qui fait le lien avec l’historique de son célèbre moteur de rendu Photorealistic Renderman que je vais vous raconter ici.

Début des années 80.

Afin de remplacer le traitement optique des images, LucasFilms, sous la houlette de Ed Catmull, créa une suite logicielle, composée de Pixar-2D, EditDroid et Pixar-3D.

Pixar-3D était une architecture hardware de traitement d’image de synthèse.
La partie software de cette architecture s’appellait “REYES”, pour “Render Everything You Ever Saw”. Une première version fut utilisé dans la séquence “Genesis Project” de Star Trek : The Wrath of Khan et le chevalier sortant du vitrail de Young Sherlock Holmes.

YouTube Preview Image

John Lasseter rejoindra ensuite LucasFilms, et sous la demande de Ed Catmull, expérimentera l’animation assistée par ordinateur. Quelques mois plus tard naissait le court métrage “The Adventures of Wally and Andre B”.

YouTube Preview Image

En 1986, Pixar nait de cette division 3d de LucasFilm, rachetée alors par Steve Jobs.

Pixar-3D fut renommé “Reyes Machine” : Une machine de guerre composée d’un hardware hors de prix et de plusieurs extensions se chargeant de chaque partie du pipeline du Reyes software.

Peu de succès commercial, ils sortiront le RM-1 Project (RM pour Reyes Machine), une machine moins chère censée remplacer le premier “Reyes machine”.

Pour anecdote, une des idées était que la Reyes Machine devienne aussi petite qu’un walkman, avec des lunettes de projection.

Mais la vraie idée sous-jacente de ce projet  était d’avoir une architecture unifiée “à la” Silicon Graphics (avec son hardware GL - Graphic Language), et Pixar commença donc les travaux sur la next-gen du GL : le RI  Rendering Interface).

Par la suite, le RM du RM-1 changea pour RenderMan.

ILM fut l’acheteur principal de ces RM-1, et un groupe formé de grosses compagnies fut fondé pour supporter le “RI” comme le nouveau standard à adopter.

Steve Jobs, grand marketeux devant l’éternel, trouvait que “Rendering Interface” ne tapait pas suffisamment. Il fallait un nouveau nom. Le hardware et le software furent renommés “RenderMan”, “Renderman Interface”, “Renderman-1 Hadware” et “Renderman Toolkit”. Le hardware ne sortira jamais de beta, toujours dépassé par les nouvelles innovations en la matière.

Lasseter pendant ce temps réalisait “Luxo Jr” afin de démontrer la force de Renderman, tant techniquement qu’artistement.

YouTube Preview Image

Pixar lâcha la version suivante de sa suite sous le nom de “PhotoRealistic Renderman”, ou PRMan.

L’évolution de Renderman.

En 1988, Pixar publia les RiSpec 3.0, bien que le seul moteur de rendu au monde a utiliser ce standard était le leur.
Du moins jusqu’au milieu des années 90, où un étudiant de Cornell University du nom de Larry Gritz écrivit BMRT (Blue Moon Rendering Tools), un renderman gratuit.

BMRT incorporait une fonctionnalité que PRMan ne supportait pas (et ne suportera pas avant longtemps), le raytracing.

Pixar embaucha Gritz et utilisa BMRT comme moteur annexe afin de profiter de cette mini-révolution, notamment dans Bug’s Life.

Gritz fut aussi l’auteur du livre de référence Renderman :

En 2000, Larry Gritz quitta Pixar pour fonder Exluna, afin de développer Entropy, un Renderman basé sur BMRT incorporant des tonnes d’amélioration et d’optimisation (et pour ce que ce j’en avais testé à l’époque, il enterrait PrMan profondément). Exluna et Entropy furent rachetés en 2002 par Nvidia, alors que le soft n’était pas encore sorti.

Le vilain petit Pixar.

A la suite de ce rachat, Pixar lança une action en justice contre Gritz et Exluna, pour vol de technologie, copyright et autres secrets. Ces plaintes furent rejetée par Exluna, mais l’affaire acheva BRMT et Entropy qui cessèrent d’être développés.

Gritz et d’autres employés d’ExLuna restèrent chez Nvidia pour développer Gelato, un moteur de rendu utilisant principalement la carte graphique.

Gélato connu deux versions sans énorme succès. Il fut néamoins à l’origine de la création d’OpenImageIO (ou OIIO), une API de trairement d’image.

Le GPU en production.

La version 2.1 (nommée Sorbetto), cependant, fut testée chez Sony Pictures ImageWorks comme outil de relighting. Malheureusement, sa complexité et son manque interactivité sur des scènes complexes furent qu’il sera rapidement abandonné.

La version 3.0 (Mocha), encore plus centrée sur le GPU, permettant la compilation des shaders “on the fly” vers la carte graphique au moment du rendu, fut montrée au siggraph 2007. Il ne sortira jamais.

La déception.

Larry Gritz fut cependant embauché par Sony Pictures ImageWorks. Sony utilisa Entropy avant sa disparition, et était en recherche d’un nouveau moteur de rendu capable de les sortir des travers de Renderman :

Les problèmes de l’architecture REYES, entre autre, sont le manque de parallélisme, l’utilisation de calculs superflus et la redondance des appels au shaders, ainsi de la difficulté d’utiliser des géométries non rectangulaires.

Mais surtout, au fil des ans, Prman se devait de supporter GI et raytracing. Ce fut malheureusement au prix de la simplicité. La  gestion des point clouds par exemple, pour la GI ou le sub-scattering, bien que puissante, est lourde en temps humain et de pre-processing à mettre en place.

L’arlésienne.

En 2000, Marcos Fajardo créa un petit buzz en sortant une série de courts métrages mettant en scène pépé, un petit personnage façon pate à modeler, des robots de Star wars,..

YouTube Preview Image YouTube Preview Image

Le plus impressionnant étant que le rendu était géré par un moteur qu’il avait lui même codé, basé exclusivement sur le raytracing et la GI : Arnold.

D’autres courts métrages utiliseront cette première version d’Arnold, notamment Fifty Percent Grey.

YouTube Preview Image

Arnold 1.0 était censé être commercialisé peu après, mais ne vit jamais le jour. Des rumeurs de sortie s’ébruitaient de temps à autre, mais la seule version jamais sortie était une intégration au logiciel Project Messiah, en 2002.

La rencontre.

Marcos fonda Solid Angle, et fut embauché par Sony Pictures ImageWorks, afin d’implémenter conjointement avec Larry Gritz Arnold à leur pipeline.

Le premier projet de Sony utilisant Arnold fut Monster House (2006), utilisé en temps que raytracer conjointement à PrMan.

Arnold se libérait des faiblesses de Prman, et le test de Monster House motiva Sony à continuer le développement. Arnold fut utilisé comme raytracer sur leurs projets suivants.

En 2009 sortira “Cloudy With a Chance of Meatballs”, premier projet utilisant Arnold comme renderer principal et unique. Suivra Eagle Eye, G-Force, Alice in Wonderland, 2012, Arthur Christmas et Hotel Transylvania (en production).

Arnold permettra de sortir les images en une seule passe, plus facile à gérer. La charge pour les artistes fut également allégée, avec la disparition des pré-process, et la réduction du nombre de lampes nécessaires. (Toy Story 3 comptait plus de 200 lampes dans certains plans, chacune demandant une passe de pré-process !)

Larry, Marcos et Sony feront un certains nombres de conférences et interview ventant les mérites d’Arnold :

Et maintenant ?

D’autres moteurs renderman on vu le jour depuis Entropy, tels que Air ou 3delight, tout deux utilisés en production de films (Renaissance, District 9,…).

Le futur, tel que le voit Larry Gritz et tourné vers le raytracing : le temps humain est bien plus couteux que le temps machine, et le temps machine ne cesse de diminuer quand le temps humain n’est pas compressible.

Le temps réel, bien que prometteur sur papier, a trop de contrainte physiques et software, et l’absence d’un standard tue toute viabilité en production.

Arnold est actuellement en beta test fermé,  toujours développé conjointement avec Sony, mais également utilisé par des boites comme PsyOp, The Mill, MPC, Luma Pictures (sur le prochain Thor), Blur, Mikros, Nozon (hmhm :)…

Quelques productions “Arnold” :

YouTube Preview Image YouTube Preview Image YouTube Preview Image http://www.vimeo.com/15660200

Showreel 2010

Mercredi 29 décembre 2010 à 22:33

Quand j’ai entendu cette musique, je me suis que ça ferait trop bien sur un showreel. Du coup voilà :

http://www.vimeo.com/18278581

(”HD” dispo sur vimeo. C’est  normalement toujours du PAL)

Celui de ma boite est dispo sur le site de ma boite pour ceux qui voudraient en voir plus.

Et j’en fais(ais) partie.

Le jeu m’a l’air d’avoir beaucoup de potentiel cependant, mais comme d’habitude chez GPG, ils nous ont sorti une démo en caca.

Tout d’abord il faut savoir que la démo se base sur une vieille build.

Les différences “sûres” entre la démo et la version finale qui sort la semaine prochaine :

Les teintes des factions

Le jeu a des couleurs playschool bien flashy. Palette justifiée finalement, car on a besoin de reconnaitre facilement les unités du terrain.

Cependant la saturation est bien abusée, alors que la version finale ressemble plutôt à ça :

Mais avec du bleu au lieu du vert.

Mais en plus bleuté et doré au lieu de vert.

Si vous voulez plus de preuves, on peut voir la bonne palette en vidéo ici

Et cette vidéo, même si elle montre une stratégie de merde, donne envie.

Et même sur les décors, tout est bien mieux.

Les dialogues sont mal écrits.

Bon, on sera tous d’accord pour dire que le scénario d’un jeu est rarement son point fort, mais il y a un vrai travail d’écriture.
Apparemment le jeu serait parsemé de référence historiques.
Le dialogue du “chef” UEF apprenant que la femme de Maddox est Illuminate serait donc une citation d’Himmler apprenant qu’un de ses Oberst avait une femme juive.
Le commandeur “un peu” Gay cybran, Gauge, cite de la poésie (et je ne m’avancerais pas sur laquelle, mes connaissances là dessus s’arrêtent à l’illyade et l’odysée d’Homère, de très loin).
Bref, ca casse pas trois pas à un canard, mais au moins au peu pas leur reprocher d’y apporter un peu de culture. (Et Gauge me parait complétement barré avec ses réflexions ironiques et son attitude abusée, j’adore)

Les fonctions manquantes.

Les arbres de recherches sont amputés, mais également les fonctions. Ainsi, la version finale comprend une fonction tant réclamée dans le premier, l’area command :

C’est une vidéo Xbox 360, mais cette fonction a été confirmée sur la retail PC

La démo montre également très peu de choses. C’est sans compter sur des petits malins qui ont tenté de rentrer en mode debug comme dans le premier, et ça marche.

Voici donc la méthode (et je quote Kekouse)

Appuyez sur la touche Windows et la touche F, un menu apparait.
Cherchez Game.prefs
Il va vous donner plusieurs possibilités (ou une seule si vous n’avez que cette démo comme jeu GPG)
Le game.prefs qui nous intéresse est celui de ce dossier:
C:\Users\(Ton nom)\AppData\Local\Gas Powered Games\Supreme Commander 2 Demo

Ouvrez donc le game.prefs avec un éditeur de texte et foutez ca à l’intérieur du fichier sur la fin

Code:
debug = {
	enable_debug_facilities = true
}

Sauvegardez et lancez la démo.
Sélectionnez une mission et faites désormais ALT F2.
Un menu apparait

Vous pouvez spawner n’importe quelle unité à volonté.

En faisant CTRL + SHIFT + R vous débloquez tous les points de recherche sur toutes factions. En spawnant des coms de chaque factions et en faisant mumuse y’a moyen de voir ce que le jeu à VRAIMENT dans les tripes.

Alors les plus par rapport à FA:
-Vous dites d’attaquer une cible, vous faites un ordre de mouvement et MAGIE…votre unité garde sa cible en mémoire
-Vous chopez un sous-marin vous donnez un ordre de mouvement et tout de suite après un ordre d’immersion…MAGIE il va sous la flotte sans interrompre son mouvement.
Plein de petits trucs qui sont des ajouts mineurs mais au combien attendu par les joueurs réguliers de FA

Voilà de quoi vous amuser, et découvrir des petites choses amusantes :

  • Les cybrans ont tous des petits jumpjet, et c’est carrément amusant à utiliser.
  • Chaque shield agit différemment. Les UEF bloquent tout, les aeons renvoyent les tirs balistique et ralentissent (mais laissent passer) les armes energétiques, …

Le jeu est complétement moddable !

et même bien plus que le premier !

Pour faire court, dans le 1 une grosse partie des fonctions était en LUA. Celles qui étaient dans le moteur même était pas modifiables.

Dans le 2, pleins de trucs sont en C dans le moteur.
Le lua appelle la fonction en C, la function en C calcule le truc prévu, et renvoie le resultat au lua. Plus rapide.
A priori c’est embêtant pour modder, sauf que non : on peut appeller une autre fonction en LUA plutôt que la fonction en C. Donc TOUT est potentiellement modifiable contrairement au 1 !

Pour ceux que ça amuse, la liste des fonctions lua :

http://chirmaya.no-ip.org/files/supcom2_demo_luadoc.txt

Les ranges sont petits !

Il existe déjà un mod qui double les ranges d’unités et retire l’auto track des missiles des bombers : http://filesmelt.com/dl/RangeScaleTest.zip
à copier à la racine du jeu, pas dans gamedata ou data.

Attention, ca rajoute pas mal de difficulté (et c’est pas un mal) aux missions de la démo.

Tout est trop grand ! On manque de place !

Un mec a déjà sorti un prototype de mod (si on peut appeler ça un mod, c’est 10 lignes de code) qui scale à 50% toutes les unités/bâtiments.. Oui c’est plutôt cool.

Et hop, un scale à la Supcom 1 !

Et hop, un scale à la Supcom 1 !

D’ailleurs il est à noter que le plus petit batiment (la tourelle), a en réalité un tile de 2×2. Hmm.. Des ranges à 50%, des tailles à 200%, je suis le seul à voir un lien ? :)

Idem pour les lignes de portée trop grosses (une petite variable à changer), la nouvelle gestion de l’économie, qui n’est finalement que l’ancienne avec un mod noob-proof par dessus, assez facile de revenir en arrière.

Conclusion

Bref, de “ouille ouille”, je suis passé à “très impatient”. Sans parler du flowfield, qui même s’il n’est pas parfait est une grosse avancée.

Reste à voir la balance, et un hypothétique éditeur de map. En tout cas il me manque pas grand chose pour me faire oublier FA et passer sans regrets sur ce Supcom2 (et c’est un mec qui joue encore au ladder du 1 qui vous le dit)

Alors oui, tout ces trucs sont des mods, c’est pas “officiel”, mais rien n’empêche GPG de les inclure dans le multi de supcom2 si la demande est suffisante et justifiée (après tout, le dernier patch qui ne sortira hélas peut-être jamais pour FA est beaucoup du à sa communauté, et change radicalement la balance) .

GPG est très à l’écoute de ses joueurs, même s’ils ont un poil trop peu communicatif.

Dans le cas contraire, ça ne sera pas le premier jeu à avoir un “promod”, ou un mod hardcore. Sans compter que le système de ladder de steam sera bien plus flexible (sinon il y aura bien des ladders alternatifs starcraft-like)

Espérons donc un suivant satisfaisant, et n’oublions pas à quoi ressemblait la démo de supreme commander 1, et du jeu avant le passage de Forged Alliance. Voir même, si on va chez la concurrence, à quoi ressemblait starcraft 1 avant ses 10 ans de patchs.

Pourquoi Gimp ne remplace toujours pas photoshop.

Jeudi 3 décembre 2009 à 14:15

Suite a une discussion sur un autre blog, on m’a demandé pourquoi je descendais Gimp alors que “c’est super”.

Je dois reconnaitre qu’à chacune de mes tentatives, gimp me semble de plus en plus une alternative au leader photoshop. Néamoins, dans une optique pro et un usage quotidien, de nombreuses choses m’empechent toujours de le considérer comme un concurrent sérieux. Détaillons.

(Je teste la dernière version dispo, à savoir la 2.6)

Petit détail, à l’install, Gimp est suffisamment prétentieux pour ne pas proposer de “unselect all”

Unselect all...

Non, faut tout virer à la main..

Moi qui aime associer mes images à un logiciel de visu rapide, me voilà obliger de tout dé-selectionner.

On peut me rétorquer que si j’avais tout mes fichiers liés, il me suffirait de cliquer “Select Unused”. C’est vrai, mais ca m’arrange quand même pas. De plus, je me suis retrouvé avec la VF alors que mon windows est anglais, sans rien avoir demandé, soit…

La chose qui m’avait le plus choqué dans la version antérieure de gimp était l’absence de réglages pour les brosses. Il fallait selectionner une brosse pour chaque taille et flou désiré, anti-productif.

Cette fois, c’est gentil, ils ont pensé à la taille…

Ok c'est gentil, mais le blur ?

Ok c'est gentil, mais le blur ?

Un sur deux, c’est pas mal, mais rien que ça m’empechera d’utiliser gimp sérieusement. De plus, dans photoshop, un simple clic droit sur le l’espace de travail et hop, on peut régler flou et taille.. Sur gimp, non, il faut revenir dans la boite à outil.. Aie. J’aurais pu vivre sans flou si gimp avait ça, mais non…

Pourquoi répéter le menu du haut dans le menu contextuel ?? Qui s’en sert !?

Bon, mon deuxième plus gros point noir était la gestion des calques. La aussi il y a du mieux, mais c’est toujours pas ça.

Je voulais juste créer un calque moi :-(

Je voulais juste créer un calque moi :-(

Un clic sur nouveau calque, et ce dialogue apparait. Sachant qu’on crée des calques sans arrêt.. Bon, je suis mauvaise langue ici aussi, un shift-clic passe la boite. Mais pourquoi l’afficher par defaut !? ON S’EN FOUT DE LA TAILLE DU CALQUE.

Bon, ils ont supprimé la confirmation lors de l’effacement d’un calque, c’est déjà ça..

Vient la gestion des masques de calque (layer mask). Ici aussi, ca y est comme sur photoshop, mais toujours pas top.

Par exemple, sous photoshop, un simple shift clic désactive le calque. Ici c’est Ctrl, c’est parfait. Sauf que…

Le jeu du jour : Est-ce que ce masque est-il actif ou non ?

Le jeu du jour : Est-ce que ce masque est-il actif ou non ?

Sous photoshop, on a droit une belle croix sur le masque. Ici, le cadre change de couleur. Pas super lisible quand on a 50 calques…

De plus, pas moyen de lier/délier un masque à un layer..

Et évidemment, on a droit à la boite de dialogue lorsqu'on crée le masque..

Et évidemment, on a droit à la boite de dialogue lorsqu'on crée le masque.. Et ici pas moyen d'y couper ..GRRrr..

Dans les choses qui manquent, il y a evidemment les fabuleux calques d’ajustement (la dernière nouveauté utile de photoshop… il y a 4 ans..), ni les groupes de calques !!!

Et pas de groupes de calques, ni de masques sur les groupes, ni de fusion sur les groupes et pas toute la comp, c’est simplement rédibitoire. Ca me renvoie à l’ergonomie de photoshop 5.0 (si mes souvenirs sont bons), et c’était atroce dès qu’on dépasse 10 calques.. (C’est à dire tout les psd que j’ai).

En général, je check ces deux fonctions de base et je m’arrete ici parce que ça me suffit. Mais par curiosité, j’ai testé la 3ème option la plus utilisée, ctrl-T (transform).

Et comment dire… Dans photoshop, on selectionne un calque, on fait une selection, ctrl-T, on déplace/tourne/scale, enter, fini.

Dans gimp : On selectionne. Ensuite, il faut choisir son outil !!!!

On ne peut pas scaler ET tourner en meme temps, c’est l’un ou l’autre ! Heureusement l’outil déplacement est dipo dans les deux modes.. Mais il faut avoir un peu pivoté ou scaler avant d’y avoir accès !

Il y a peut-être un move tout court, mais pas trouvé..  Et puis même, pourquoi les séparer en 2 ou 3 outils !?

Heuuuu ?

Heuuuu ?

Mais ça serait rien si la preview n’était pas imbitable. Ici, je tourne ma selection (le carré en pointillé). Le carré plein est ma selection tournée. Qu’est-ce qui me choque ?

Pourquoi je vois toujours ma selection d’origine ?
Pourquoi mon image de départ est toujours affichée ?

Parce que si j’applique ma rotation :

Hein ?

Hein ?

Ben oui, forcement, c’est normal. Sauf que je ne vois pas dans l’aperçu ce que sera ce resultat final !

Et le gros cadre qui fait une bouding box autour de ma selection, j’ai pas la moindre idée de ce que c’est.

En si, plus ou moins : visiblement, ma rotation est pas frezée, je peux encore la modifier (pas mal en soi). Sauf que là, l’affichage passe la porte de l’incompréhensible :

Gné ?

Gné ?

Ok, là, j’abandonne.

Je passe le fait qu’aucun raccourci clavier n’est setté pour les calques (ctrl-shift-U pour desaturer, ctrl-L pour level ?).

Gimp est malheureusement un outil créé par des programmeurs, pour des programmeurs. Ils peuvent ainsi se dire “regardez, en opensource aussi on a photoshop !”. Sauf qu’ils ont oublié que l’utilisateur final était graphiste, et que l’ergonomie était le point n°1 avant les fonctions.

Quand je vais dans les filtres, il y en a une chiée (un spirographe ? Un lava generator ? VRAIMENT ?). Vous savez combien de filtres photoshop j’ai utilisé en prod cette année ? 2. Le gaussian blur et le sharpen.

Le reste, c’est de le brosse et du calque, deux choses que gimp ne fait pas correctement.