Jehan a écrit 1667 commentaires

Wow. Ça change vraiment!

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

On a déjà beaucoup avec strictement des assos de logiciels libres, mais c'est pas exclu. Les contributeurs qui créeront l'album décideront de ce qui rentre dans le cadre du projet ou non.
Par contre, il faudrait que cette association, Kokopelli, nous contacte (un simple email) et nous envoie les autocollants d'abord.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Même questions que pour TuxFamily, plus haut! :-)

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Salut,

Ce sont juste des logos, ou aussi des autocollants? Il faut que les gens puissent pouvoir se les procurer (sans les imprimer eux même, mais plutôt à un stand TuxFamily par exemple…). Et si ce sont bien des autocollants, lesquels et quelles dimensions métriques?
Merci! :-)

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Super! Merci. :-)

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

La différence entre et tutu . Sémantiquement, c’est compliqué de savoir lequel est la « forme à utiliser ».

Ben quand tu as un truc unique qui peut être exprimé en valeur simple, tu fais un attribut. Ensuite dès que c'est une donnée compliquée (qui va être composée de plusieurs valeurs), ou que tu peux en avoir plusieurs, c'est forcément un nœud fils. Quand tu crées ton schéma, c'est à toi de connaître tes données.

Un protocole qui impose l’encodage va quelque part à l’encontre de la norme.

Pas du tout. On avait ce type de remarques régulièrement sur XMPP, du type "XMPP, c'est pas du vrai XML car vous n'utilisez qu'une partie des fonctionnalités" (voir les restrictions XML). Mais non, ce n'est pas vrai. Tout flux XMPP est un document XML absolument bien formé qui sera traité sans erreur dans n'importe quel parseur XML générique.
Encore une fois, XML n'a pas pour but d'être un format final en soi. Il n'y a aucune sémantique dans XML. D'ailleurs si tu fais une recherche sur la spec du terme "semantic", ça ne retourne qu'une seule occurrence qui dit exactement cela:

This specification does not constrain the application semantics, use, or (beyond syntax) names of the element types and attributes, except that names beginning with a match to (('X'|'x')('M'|'m')('L'|'l')) are reserved for standardization in this or future versions of this specification.

C'est à chacun de faire un format et d'y ajouter de la sémantique. La création du format final peut ainsi passer par se limiter à un sous-ensemble de XML. C'est comme l'utilisation d'un langage de programmation: cela n'oblige absolument pas les développeurs à utiliser toutes les fonctionnalités du dit-langage, voire même les autorise à en interdire certaines dans leur programme (exemple très courant: le C++ où beaucoup de développeurs vont interdire l'utilisation de certains fonctionnalités dans leur code, comme dans le Google C++ style guide; notamment les exceptions sont une fonctionnalité interdite dans beaucoup de gros projets C++). Est-ce à dire que le code C++ de Google ou d'ID Software (Doom 3) n'est pas du C++ parce qu'ils n'utilisent qu'un sous-ensemble (clairement interdisant pas mal de fonctionnalités)?

Enfin pour revenir plus précisément à cette fonctionnalité (codage de caractères dans XML), la spéc dit clairement:

(processors are, of course, not required to support all IANA-registered encodings)

Puis un peu plus bas:

Unless an encoding is determined by a higher-level protocol, it is also a fatal error if an XML entity contains no encoding declaration and its content is not legal UTF-8 or UTF-16.

Comme tu vois, la spéc XML est clairement préparée à ce que le codage puisse être déterminé non par la déclaration, mais par le protocole de plus haut niveau (par exemple XMPP). XML est vraiment fait dans l'optique qu'il va en général y avoir une spéc de plus haut niveau qui donnera une vraie sémantique aux éléments et attributs. Sans cela, XML n'est qu'une sorte de syntaxe ou grammaire générique.

Si tu veux un exemple simple, une contrainte comme « date < date_du_jour » (contrainte métier tout à fait raisonnable) n’est pas exprimable. Au final, la validation xsd ne te dispense pas de faire ton boulot correctement.

Bien sûr, tu ne peux pas tout valider dans un schéma XML (qui est aussi un format générique et n'a bien entendu aucune logique par rapport à ton besoin particulier, ou "logique métier" comme on dit), mais tu parlais pas de ça. Tu parlais des types de base et comme quoi XML n'en avait pas hormis string, contrairement à json. Je te réponds que si, avec les schémas. Et maintenant tu réponds que ça fait pas le café non plus! Faut pas changer non plus d'argument à chaque phrase! Non parce que json non plus ne fait le café! :P

Le fait est que XML a des types de base, et c'était donc ma réponse à ton assertion comme quoi il n'y en avait pas; et qu'en plus la validation de ces types peut être faite avant le code spécifique (pas en json, où ça doit être fait dans le code, à moins d'ajouter un mécanisme de schéma spécifique au json). Ça n'empêche en effet absolument pas une validation complémentaire dans le code si nécessaire (comme ton exemple de date). Mais au moins, on sait que les données arrivent directement dans le bon type si on valide avec un schéma.

Par curiosité, comment tu fais quand tu as des données arborescentes à représenter dans tes fichiers de conf (ou simplement des listes) à plat ?

Je l'explique plus haut, dans un autre commentaire. En gros, si tu as un besoin super complexe dans un fichier destiné à être édité par un humain de manière régulière, j'aurais tendance à dire qu'y a un problème plus profond de design logiciel. Si tu dois représenter des données très complexes, faut alors avoir une interface graphique adaptée et compréhensible (et en interne, un format adapté, pas du clé=valeur). Parce que je suis désolé, mais que ce soit du json ou du XML, si y a plusieurs niveaux et une arborescence avancée, c'est juste imbitable pour un non-programmeur. Je mets pas ça entre les mains des gens par design comme étant dans le fonctionnement normal de l'application.

Un truc que tu veux éditable par les gens dans le fonctionnement habituel du programme, c'est un fichier très simple. Sinon y a vraiment un problème de design.

Ensuite ces formats clé=valeur ont tout de même des types de base (chaînes de caractère, nombre et booléen), et des listes (ex: le format clé=valeur standardisé par Freedesktop, dont je donne déjà le lien plus haut a des listes avec séparation des éléments par des point-virgules). Et puis il y a des groupes (mais ca s'arrête là au niveau "arborescence", pas de niveau supplémentaire au delà).
Il y a un minimum de fonctionnalité tout de même! :-)
Cela devrait être bien suffisant pour un fichier destiné à édition manuelle.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Aujourd'hui je reçois un paquet énorme, je me dis "mais qu'est-ce que c'est? J'ai rien commandé!".

J'ouvre et c'est en fait le livre qui a été mis dans un paquet qui fait peut-être 15 fois sa taille!

Enfin voilà, ça m'a fait marrer alors je voulais partager car envoyer un livre dans un si énorme paquet, c'est pas commun quand même. :P

Merci encore!

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

si c'est pour une édition par des humains, je préfère YAML.

J'ai eu une fois à implémenter un parseur YAML. C'était vraiment l'horreur. Ils ont fait des choix vraiment bizarres et ont défini plein de façons de noter la même donnée. On ne s'en rend pas compte côté utilisateur car on va en général utiliser la même notation partout. Mais quand on fait un parseur, il faut être exhaustif (pour ce 1% de gens qui vont envoyer des fichiers avec cette syntaxe). Très mauvaise expérience.

Si pour une édition par des humains, je préfère quelque chose de bien plus simple encore, type fichiers clé-valeur simple. Il y a des formats de ce type standardisés, typiquement celui de FreeDesktop qui fut défini pour les fichiers .desktop (donc utilisés par la plupart des — sinon tous les — bureaux libres). Ce type de format reste simple à parser (et en général, y a même pas besoin de faire soi-même, si on utilise une bibliothèque de bureau, par exemple glib). Ce format peut contenir des chaînes de caractères, nombres, booleans et des listes, des sections (même la localisation est prise en charge si besoin est, et elle peut être automatisée avec extraction du texte original par gettext puis génération de fichiers qui contiennent toutes les localisations; c'est ce qui est fait en général pour localiser les fichiers desktop!) et il n'emploie pas 10 variantes par type ni de logique super-compliquées.

Sinon y a aussi des formats encore plus simples, plus proches du INI de Microsoft (le format standardisé par Freedesktop est d'ailleurs très proche, bien qu'avec quelques différences) qui est aussi beaucoup utilisé, même sur nos systèmes libres.

Ces formats sont souvent suffisants et je ne vois pas l'utilité d'apporter la complexité du YAML pour un fichier destiné à être édité par des humains. Ensuite je dis pas, YAML a des fonctionnalités plus avancées et peut-être dans des cas d'usage très particuliers, il convient de monter d'un cran et d'utiliser ce format. Mais je n'ai jamais eu le cas. En général, lorsque le besoin devient vraiment complexe, ce n'est plus un format que je destine à l'édition par des humains, mais par un programme (et à ce moment, ce n'est pas non plus le YAML que je vais choisir).

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

• meilleur rapport signal / bruit (moins d’octets perdus)

Le XML (comme tout format texte avec syntaxe répétitive) est très compressible, rendant l'argument obsolète. Tous les formats ou protocoles qui sont basés sur XML le compressent dans l'usage "normal" (hors débuggage où on désactivera la compression temporairement).

• pas de différentiation entre attribut et valeur du nœud

Je ne comprends pas ce que tu veux dire.

• encodage fixé par la norme

Si c'est pour de l'échange de fichier, le fichier XML définit simplement son codage dans sa déclaration. Ensuite le décodage est quand même un truc de base sur tous les systèmes. La seule problématique est lorsqu'un format de fichier ne déclare pas le codage donc il faut faire de la détection (ce qui n'est pas du 100% de réussite). Mais comme XML le fait, y a pas de problème ici.
En plus dans les faits, très souvent les sous-formats vont imposer un codage unique (souvent UTF-8). C'est le cas par exemple de XMPP.

• types de base existants dans le langage (liste, flottants, chaînes), faisant partie de la norme, là où XML n’a que des chaînes

Si tu fais du XML bête et méchant, sans schéma, oui il n'y a pas vraiment de types. Mais un format XML est fait pour être défini (en fait XML en soi est un format générique pour faire des formats spécifiques!), par exemple dans un schéma XML et là tu as tous les types que tu veux.
En outre, là où XML va avoir une étape de validation générique au niveau de ton parseur (que tu n'as donc en général pas à implémenter dans le code; en utilisant une bibliothèque XML externe, on se contente de fournir le schéma et la validation est faite pour nous), tu dois en général implémenter de la validation spécifique pour un format json.

Sans compter la reprise sur erreur: comme XML a une étape de validation du schéma, il est capable d'ignorer tout erreur de contenu (mauvais type, attributs inconnus, etc.), mais en le prenant en compte, avec par exemple simplement un avertissement dans le programme qu'il y a une corruption possible du fichier. En très peu de ligne (encore une fois, en se reposant sur une bibliothèque générique), on va définir de la gestion d'erreur précise pour divers cas et on ne sortira en erreur complète que sur les problèmes majeurs. C'est même la base de certains sous-formats de XML, par exemple XMPP encore, qui est extensible par nature, a certaines caractéristiques obligatoires mais peut aussi accueillir des extensions (et un client/serveur peut les ignorer s'il ne les prend pas en charge mais sans jamais casser la connexion ou le transfert fiable et complet des données).
Json pourrait faire tout cela bien sûr, mais nécessite beaucoup de code spécifique et sera donc bien plus prompt aux erreurs de programmation. Surtout en gestion d'erreur, on sait tous que c'est exactement le genre de trucs chiants que beaucoup vont laisser "pour plus tard"; et le manque dans le code ne se voit pas pendant longtemps — puisque logiquement en général le contenu utilisé est valide — jusqu'au jour où on tombe sur un bout de données corrompu et là, le programme risque de vraiment mal le prendre!

Ensuite XML est clairement beaucoup plus lourd à mettre en place et ce n'est pas à utiliser selon moi pour des usages simples. Genre effectivement pour une API web, on va peut-être éviter de la compression (quoique ça dépend; même pour du json, si l'API est faite pour transporter pas mal de données, cela peut être rentable de compresser). De même pour plein de petits formats très courts (typiquement dans une API web, on peut considérer que chaque réponse à une fonction a potentiellement un format différent), on veut peut-être pas écrire plein de mini-schémas XML. Ce serait vite ennuyeux.
Dans plein de cas, json est bien plus léger, simple et flexible. Donc c'est plus agréable pour tous ces petits usages simples. Par contre dans le cas de la création d'un format long et complexe, beaucoup utilisé et structuré, je ne choisirai probablement jamais json. C'est juste le moyen idéal pour se retrouver avec des fichiers invalides sans même s'en rendre compte pendant des semaines (jusqu'au jour où notre programme a besoin de parser ce bout du fichier et saute à notre figure).

Quant à des fichiers de conf (si on prévoit édition par un humain), je n'utiliserais ni json ni XML, mais un format simple "attribut: valeur" ou "attribut = valeur", type fichiers INI. Parce que quand on parle d'édition et lisibilité possible par un humain, je suis désolé mais ni json ni XML ne sont de bons choix. Typiquement c'est très facile de casser un fichier de l'un ou l'autre format (classique: oublier le tag fermant en XML ou le crochet fermant en json).
Par contre lisibilité par un développeur (pour débugguer par exemple), je trouve les 2 aussi lisibles du moment qu'ils indentés pour faciliter le débuggage (et les 2 aussi illisibles s'ils sont pas indentés ou sans retour à la ligne).

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Salut!

Pour t'aider efficacement, il serait bon que tu expliques ce que tu reproches à Dash to Dock comme ça on saurait mieux quoi conseiller. :-)

Bon sinon, personnellement je n'ai jamais utilisé Dash to Dock, ni aucun autre dock depuis que je suis passé à GNOME 3 (je n'en vois personnellement plus l'utilité. C'est simplement 1000x plus rapide/pratique de taper la touche Super puis quelques lettres dans l'overview pour chercher n'importe quel programme).
Cependant il fut une époque où j'utilisais Cairo-Dock et j'appréciais cela beaucoup. Ce n'est pas un plugin GNOME 3, mais un dock générique qui marche avec n'importe quel WM ou bureau (j'utilisais cela avec OpenBox à l'époque).
Bon le développement m'a l'air très ralenti, à en juger par une absence de commits depuis plusieurs mois. Est-ce que le projet est tout simplement devenu très stable et a juste peu de nouveautés (note que Dash to Dock n'a pas non plus un développement intensif; ce type de logiciel n'en a pas forcément besoin)? Ou bien y a plus vraiment de maintenance? Je sais pas et ça fait maintenant quelques temps que je n'ai plus utilisé. Mais bon, c'est une piste pour toi. :-)

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Star Wars Rebels, qui semble t'avoir marqué (en mal)

Je ne suis pas un hater de Star Wars Rebel. Je l'utilisais juste en exemple car j'ai regardé plusieurs épisodes y a pas si longtemps et donc c'est un exemple frais. C'est tout. :-)
Je ne regarde pas énormément de séries animées 3D, mais ce n'est pas une question de qualité graphique. C'est juste que je trouve peu de séries 3D qui semblent avoir un script ou mise en scène qui me plaise. Souvent les séries 3D semblent faites pour les très jeunes seulement (avec ces grosses ficelles pas subtiles du tout) alors que les séries pour adultes/tout âge semblent plutôt se diriger vers la 2D (je ne prétends pas non plus connaître toutes les séries animées).

très très loin du fond du panier.

Je m'en rends bien compte.
Ensuite je n'ai pas trouvé SW Rebel extraordinaire, mais comme dit plus haut, c'est plutôt au niveau scénaristique/mise en scène. Je m'attache pas à la qualité visuelle seulement et suis tout à fait conscient que les séries ont rarement des moyens conséquents.
D'ailleurs dans les séries animées que j'adore, y a The Simpsons et on peut pas vraiment dire que ce soit du grand art graphique et animé. South Park est d'ailleurs une bonne série également (même si le côté pipi-caca, c'est moins mon kif) et eux vont carrêment à fond dans l'anti-qualité graphique et animée.

Tout ça pour dire que je ne limite pas mes sélections au critère "beau". Simplement, c'était le sujet du fil de discussion (-> qu'est-ce qui prend du temps dans l'animation?). Et je ne déteste pas Star Wars Rebel. C'est juste moyen en tant que série, mais c'est loin d'être le fond du panier, comme tu dis. :-)

D'où le fait que je soit impressionné. ;)

Et ça veut donc dire qu'ils ont réussi leur coup. Comme souvent ce qui importe, c'est de trouver un public à qui ça plaît. Il n'est pas nécessaire d'être un "prodige" technique. Je dirais même plus: ça sert à rien d'être un prodige si ça ne plaît pas. On voit ça des fois, une œuvre inutilement compliquée et extraordinaire techniquement; ou alors super intellectuelle (ou philosophique, ou au contraire totalement abstraite, ou sans aucun sens ou dans le but unique de choquer, etc.). Je ne suis pas fan non plus de cela (mais certains le sont, et donc y a un public, c'est ce qui compte).
Des fois, des trucs plus simples mais qui "marchent", c'est bien aussi. ;-)

En tout cas, merci beaucoup de l'analyse très poussée.

De rien. :-)

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Ben pas vraiment. J'ai regardé tes exemples, au contraire, ça illustre parfaitement mon propos qu'on va tricher dès qu'on essaie de faire des trucs un peu 3D.

Dans le premier exemple (la danse), bon bah à part les persos, y a rien qui tourne. D'ailleurs comme tu le notes, y a même pas de décor, alors y a rien à faire tourner. Or bien sûr qu'on va faire tourner les persos dans de l'anim 2D! C'est un minimum et tout le monde le fait (à part quand tu veux aller dans les extrêmes, genre South Park). :-)

Quand je parle de rotation, c'est le reste dont je parle, et surtout le décor, qui lui est habituellement très peu (sinon du tout) changé dans un même plan, donc le faire changer d'angle, c'est vraiment se mettre des bâtons dans les roues en se donnant beaucoup de travail compliqué en plus qui n'est normalement pas à faire.
D'ailleurs en 2D vectorielle, c'est même l'inverse, ils vont avoir tendance à encore moins jouer avec les angles, même sur les personnages, et tes 2 exemples en sont le parfait exemple: les persos vont avoir tendance à toujours être dans des positions très figées (de face, de côté, de quart, trois-quart, etc. Très peu de nuance par rapport à la 2D dessinée et à la 3D) pour se donner moins de travail. C'est un peu le propre de ce style d'ailleurs.

Dans le second exemple, parles-tu de cette rotation vue de haut à 13:54-55? Si oui, alors c'est pas du tout ça dont je parle. Dans ce cas, ils ne font pas du tout tourner le décor, mais la caméra! Il n'y a pas de travail sur la perspective dans ce plan. Au contraire, même, c'est une ruse qui permet d'utiliser une seule image statique pendant plusieurs secondes tout en donnant une impression de mouvement! C'est donc une solution de facilité (ce qui ne la rend pas pour autant très bien, hein! Qu'on me fasse pas dire ce que j'ai pas dit: trouver et appliquer les solutions de facilité fait aussi partie du boulot et est aussi un critère de travail de qualité!).

Ou alors, tu parles de cette rotation autour du perso en 13:57 -> 14:01? Ben là aussi, c'est une grosse ruse! Ils sont dans une clairière comme par hasard quasi-parfaitement circulaire et quelque soit l'angle qu'on prenne, on voit à peu près la même chose: des arbres. Il a donc "suffi" de copier-coller ces arbres (peut-être avec de petites retouches, en particulier dans leur taille pour donner une impression de différence en passant vite) et de déplacer la caméra rapidement dans un plan parallèle. Cela combiné avec le plan immédiatement précédent (où on a bien montré au public le caractère très "circulaire" dans la situation des personnages avec cette vue de dessus et l'effet de rotation de caméra dont je parlais) et avec la rotation effective des personnages suffit pour tromper le cerveau.
D'ailleurs tu remarqueras l'énorme flou donné à cet arrière-plan (pour être bien sûr de ne rien remarquer de bizarre) ainsi que le fait que les ennemis — qui sont des dizaines tout autour des 2 héros sur le plan précédent — sont soudainement invisibles pendant cette rotation; à part à la toute fin du plan, t'en as 3 qui rentrent dans le champ caméra au moment où le héros saute dans un portail… tout est fait pour tromper le public tout en se simplifiant la tâche et sans faire le moindre travail sur la perspective.

Il n’empêche qu'à l'époque (il y a 8 ans, déjà), et même aujourd'hui, c'est assez bluffant.

Attention, il n'y a rien à reprocher aux animateurs de Wakfu qui m'ont l'air de faire du bon boulot (en me basant sur ces quelques extraits). Ce n'est pas une critique, juste une analyse de ces extraits. :-)
Mais il faut quand même le dire: ce sont des choses que tout le monde fait en 2D depuis des décennies. Ils bossent bien, pas de problème de ce côté là, mais je vois absolument rien d'extraordinaire (ou de "bluffant") dans ces scènes. Désolé.

Il arrive des fois de voir du travail vraiment bluffant dans du changement de perspective sur certains films en 2D pure (j'arrive plus à me rappeler quel film, mais je me souviens d'un cas y a pas longtemps: on regardait un film et on arrête sur un plan, on revient en arrière plusieurs fois, et on se demande s'ils se sont aidés de 3D justement ou s'ils ont vraiment fait ce plan entièrement à l'ancienne). Mais je suis désolé, ça ne m'a pas l'air d'être le cas du tout dans tes 2 exemples.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Tiens, c’est curieux, j’étais persuadé que le passage à la 3D avait notamment été dicté par des contraintes de coût, parce que ça coûtait moins cher (càd, ça va plus vite) de faire de la 3D que de l’animation « traditionnelle ».

Moi aussi les chiffres plus faibles en 3D m'ont étonné. Ensuite le but de mon commentaire n'était pas de comparer 2D et 3D en temps d'animation, et cet article est bien trop imprécis pour être pris en référence ultime. C'est simple: ça dépend bien trop des choix d'animation. Tu vas pas mettre autant de temps pour animer disons une balle qui rebondit (exemple typique en animation) dans un monde Tex Avery et un personnage d'un film Pixar. Donc faut pas non plus trop s'accrocher à ces chiffres. Leur but premier est d'expliquer que l'animation en règle générale prend énormément de temps et plus tu montes en qualité, plus ce temps est important.
Aussi je me suis demandé si l'auteur de cet article ne comptait pas les parties modélisation + rigging dedans. Il est connu qu'en 3D, cela prenne énormément de temps. En gros, en 2D trad, le palier de préparation est relativement court et on peut rapidement commencer à animer. Alors qu'en 3D, y a un gros blocage au début avec la modélisation/rigging, mais une fois que les persos sont faits, il me semblait que tu pouvais animer plus vite; et donc sur de longs projets qui réutilisent les mêmes persos souvent, c'est plus rentable au final (alors que sur un projet très court au contraire, c'est peu rentable… sauf si justement tu fais de la tellement basse qualité que tu utilises des persos tout faits dans des banques de persos 3D par ex, et donc tu fais sauter modélisation et rigging; ou bien que tu fais du copier-coller de persos en changeant juste le visage, etc.). Mais ça, c'est ce que je pensais. Ce type d'article va à l'encontre de cette vision, donc je ne saurais dire. Peut-être que non en fait, peut-être que même l'animation est plus longue en 3D. Ou alors le rapport temps/qualité n'est pas linéaire: peut-être qu'en haute qualité 3D, tu passes plus de temps à animer qu'en haute qualité 2D, mais qu'à l'inverse en basse qualité 3D, tu passes moins de temps à animer qu'en basse qualité 2D (ça serait en fait assez logique, car en 2D, même en basse qualité, tu dois quand même redessiner des choses; c'est déjà plus qu'en basse qualité 3D où tu peux juste te contenter de placer ton perso approximativement).
Il faudrait croiser les infos. Ou mieux, avoir des stats basées sur des milliers d'animateurs et des définitions claires dans le contexte de ces stats. :-)
Mais cela n'a pas beaucoup d'importance. Ce qui est sûr, c'est que même si ça allait en fait plus vite en 3D, ça prend toujours du temps de bien animer. Le choix de la technique n'est jamais fait dans un but de gain temporel quand on veut faire de la qualité (ce qui est notre cas, et bien évidemment le cas de Disney pour ses films cinés), car par défaut on a choisi un chemin difficile et quoiqu'on fasse, ce sera long, coûteux et plein d'obstacles. Y a pas de miracle.

coûtait moins cher (càd, ça va plus vite)

Sur ce point en particulier, le rapport temps/coût n'est pas toujours vrai (bon il l'est souvent, il faut bien le dire, surtout dès que des humains sont en jeu car c'est le temps humain qui coûte le plus). Lors de notre visite de l'atelier Weta (un studio vraiment génial qui font des costumes, objets, maquettes… c'est simple, ils sont au générique de quasi tous les blockbusters Hollywood), on nous expliquait que les films faisaient de moins en moins d'animatronique (ex: si un gars a une main de robot, tu pourrais soit l'éditer ensuite en 3D, soit tu pourrais faire une vraie main robotisée que l'acteur pourrait mettre au dessus de sa vraie main pendant le tournage…) au profit de la 3D. Mais ce n'était pas une histoire de coût car la 3D revient en fait plus cher. Par contre, c'est plus rapide!

Ça se vérifie notamment bien dans les animes, où les décors sont beaucoup réalisés en 3D pour gagner du temps

Alors non, ce n'est pas la raison de l'utilisation de 3D dans un film 2D. Tu vas d'ailleurs prendre bien plus de temps pour modéliser ton décor 3D que le dessiner (je le disais, la partie modélisation prend beaucoup de temps; et pour comparer entièrement avec un dessin 2D final, faut rajouter aussi textures, etc.).
La raison d'utiliser de la 3D en 2D est simplement pour faire des choses quasi-impossible en 2D. Alors c'est pas vrai que ce soit impossible (c'est du dessin, tout est théoriquement possible), mais c'est très très dur. En particulier tout ce qui est mouvement de caméra non planaire. En 2D trad, tous tes mouvements de caméra suivront un plan: tu peux aller à gauche/droit (l'équivalent d'un travelling sur rails dans le cinéma), en haut/bas, tu peux zoomer… mais tu ne vas pas par exemple tourner autour du personnage. Pourquoi? Parce que la perspective est une technique très difficile (demande à n'importe quel peintre s'il a jamais eu de problème avec la perspective, et aussi s'il est aussi fort dans tous les angles; très souvent les peintres ont des préférences de perspective), alors si en plus tu dois faire de la perspective changeante dans un même plan, c'est la mort cérébrale du pauvre artiste!
Et puis en plus, ça veut dire qu'il faut redessiner le même décor à chaque frame, alors que dans les scènes habituelles 2D, tu te contentes de redessiner les personnages et tu gardes le même décor (sur lequel la caméra peut zoomer ou se déplacer parallèlement). Sur ce point, tu pourrais dire: donc finalement, c'est bien une question de temps puisqu'il faut en fait comparer une seule modélisation de décor à X décors dessinés! Et même si tu peux avoir raison sur un plan assez long, une telle demande est surtout un coup à rendre tes dessinateurs fous: "redessine moi ce décor 20 fois en imaginant que la caméra tourne autour de ce point (le perso probablement), avec des angles de 1° entre chaque dessin". Ça s'est fait un peu (ou plus souvent, y a des moyens de tricher un peu, notamment en jouant avec les objets en premier plan, on peut faire illusion), mais y a des limites.
C'est ça la vraie raison de l'utilisation de 3D dans un film 2D.

Du coup, tu sais ce qui a motivé le choix de l’abandon du dessin traditionnel chez Disney ?

Ben je pense que c'est la cool-attitude. La 3D, c'était le truc hype à faire pour être dans le coup. Et de nos jours, c'est l'attente usuelle. Même si la 2D au ciné existe encore et a son petit public, il faut dire ce qui est: ce n'est plus le cinéma à grand succès. Donc de nos jours, ils continuent pour suivre la demande. Y a plus de retours en arrière (du moins pas sans risque financier majeur pour une boîte dont le but est de faire beaucoup d'entrées cinéma).
En tous cas, on peut pas dire que ce soit une question de diminuer les coûts, quand on voit les budgets de production de plus en plus énormes à chaque film.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Comme disait quelqu'un dans un autre journal, va par exemple essayer de te plaindre à la poste que le livreur laisse toujours un papier alors que tu es chez toi.

Mouais… je peux pas dire que je sois très content non plus des services de livraison privées. Je me souviens de pas mal de mauvaises expériences similaires (le gars qui sonne même pas et laisse un papier). Une de mes anecdotes les plus symptomatiques: je travaillais dans des bureaux en région parisienne et comme ces sociétés livrent dans les heures de bureau, ben j'avais donné l'adresse de mon boulot plutôt que chez moi, en notant bien mon numéro de téléphone portable ainsi qu'un commentaire pour dire au livreur de me demander à l'accueil (c'était une PME, l'accueil nous connaissait tous), voire simplement le laisser à l'accueil. Franchement ça pouvait pas être plus simple.
Personne n'est passé de la journée, alors le soir, je regarde le site et le livreur a laissé en commentaire disant qu'il a sonné et qu'il n'y avait personne! C'était des bureaux, il suffisait juste de montrer au premier étage de l'immeuble et la porte était ouverte. Y avait aucune porte fermée (ni en bas, ni à l'étage) ni sonnerie! En gros le livreur ne s'était pas donné la peine de rentrer dans l'immeuble (sinon il aurait su qu'y avait pas de sonnerie comme dans un immeuble d'habitation) et il n'avait pas essayé d'appeler sur mon portable non plus. Je me suis plains. Ils m'ont fait le coup une seconde fois et au final le colis est reparti à l'envoyeur (c'était un support-client qui m'envoyait une pièce; ça m'a fait perdre des semaines)! Et ce n'était pas la poste mais une des grosses boîtes privées de transport de paquet (je ne saurais plus dire laquelle pour sûr pour cette anecdote précise par contre, mais à peu près toutes m'ont fait un coup similaire une fois dans ma vie).

Alors la poste, ils sont loin d'être parfait. Ceci dit, je serais loin d'être aussi catégorique que toi sur la binarisation privé versus public que tu fais sur le sujet.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Comme d'hab, merci. :-)

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Le transport collectif fait partie de leurs attributions

Historiquement, en France, oui. Mais on sait bien que la tendance est à la privatisation des transports existants, et par conséquent elle n'est pas à faire des nouveaux transports de nouveaux services publics.

Ce type de service — s'il arrive — risque fort d'être soit 100% privé, avec probablement quelques subventions par les administrations locales, soit lancé comme une sorte de marché public où toute la gestion est laissée à une entreprise privée. Donc bien que l'argent publique sera fort vraisemblablement dépensé, ça ne sera pas du service public.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Ce serait mieux, en effet. Mais même sans cela, ça resterait avantageux. C'est à dire que même si ces véhicules collectifs se dégradaient bien plus vite, devaient subir plus souvent des réparations et être changés après moins de kilomètres qu'un véhicule individuel bien entretenu, je suis sûr que ce serait tout de même plus écologique. Déjà car les voitures en circulation seraient vraiment utilisées. Quand je disais que ça durerait moins qu'un véhicule individuel, ça reste en effet très théorique; beaucoup de gens utilisent tellement peu leur véhicule qu'ils finissent au final "vieux" et à la casse avec juste quelques dizaines de milliers de km. Et puis le parc automobile serait plus petit en un temps donné, ce qui veut dire moins de voitures produites (or la construction d'une voiture est extrêmement polluant! Ce qui rend d'autant plus rageant ces lois et autres décrets débiles qui poussent les gens à acheter de nouvelles voitures sous prétexte d'écologie; c'est une aberration logique).

En outre, beaucoup de gens ne sont pas respectueux (ou pour être plus précis: pas conscient) de leurs biens personnels non plus. Il suffit de voir tous ces gens qui se retrouvent en panne sur l'autoroute car leur moteur a surchauffé; ils ne vérifient jamais le liquide de refroidissement, l'huile, tous les trucs de base. Je dis ça, je suis pas du tout un expert de la mécanique non plus et j'ai fait mon lot de conneries; maintenant je fais bien plus attention.
Et puis les véhicules dégueulasses, c'est pas du tout rare non plus (là non plus, je suis pas exempt de tout reproche). La seule différence, c'est que c'est "notre" crasse donc on l'accepte plus facilement que celle du transport en commun. C'est tout.

Tout ça pour dire que je suis d'accord avec l'idée. Ce serait une bonne chose. Et pourtant je dis tout ça, mais j'adore conduire (voiture et moto). Mais il faut aussi savoir se rendre à l'évidence que nous ne pourrons pas continuer ainsi indéfiniment et que des changements sont à effectuer dans nos choix de société, de préférence dans un futur proche.

Par contre se posera alors la question de qui a la gestion de ce parc automobile autonome (et "comment" est faite cette gestion). Parce que ce que tu proposes, ben c'est exactement ce que veulent faire des boîtes comme Uber ou Google (y a plein d'articles sur le sujet, par exemple après une rapide recherche "uber voiture autonome" sur le web). Et le problème, c'est que ce seront probablement les premiers qui y arriveront. Or cela pose pas mal de problèmes de société, social notamment quand on sait que le business model actuel d'Uber est d'éliminer la concurrence en vendant ses services à perte depuis le début; ce qui veut dire que quand ils seront en quasi monopole, ils n'auront pas d'autre choix que d'augmenter les prix (le problème est que la plupart des utilisateurs se basent sur les prix bas mais n'arrivent pas à voir que c'est une vision court-termiste). Sans compter tous les problèmes de précarisation du travail que l'on retrouve dans la plupart de ces sociétés sous le terme hype de "crowdsourcing" (concept totalement perverti dans ces cas d'usage).
Quant au "comment", on pense notamment aux problèmes de sécurité et commercialisation des données persos, comme un autre commentaire plus bas le note. Que ce soit des sociétés privées ou des gouvernements qui gèrent le service, il faut voir exactement quelles données ils rassemblent sur nous et ce qu'ils en font.

Mais bon, soyons réalistes: mes problématiques ne seront jamais prises en compte dans les choix de sociétés. Quand on voit comment toutes ces choses passent déjà maintenant auprès du public sans aucun questionnement… ça ne rentrera pas en compte dans le futur non plus. :-/

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Se pose ainsi la question du modèle choisi par Debian.

Vient alors la question du modèle du logiciel libre! Celle-ci implique que tu n'es pas forcé d'attendre d'avoir un logiciel dans le système de paquet de ta distrib pour l'installer toi-même.
Alors je me rends bien compte que c'est chiant. Même en tant que développeur, c'est jamais une partie de plaisir de compiler des logiciels. Je préférerais de loin les avoir tout faits, prêts à utiliser.
Mais bon, au moins c'est possible! Et il m'arrive ainsi régulièrement de m'installer des outils logiciels qui ne sont pas dispos dans ma distrib. :-D

La seconde réponse: peut-être pourrais-tu discuter avec les dévs de Lilypond et leur proposer de proposer un paquet indépendant? Je pense notamment à Flatpak. Quiconque pourra alors installer Lilypond indépendamment et les dépendances principales seront embarquées. Plus de problème de ce côté là. :-)

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Ah si ça veut dire un regain sur le développement de librsvg, c'est surtout cela qui m'intéresse! Car librsvg a été assez moribond depuis pas mal d'années maintenant avec une quasi absence de maintenance. D'ailleurs je viens de jeter un œil sur le dépôt, je constate effectivement un afflux soudain de commits à partir de fin octobre 2016.
Depuis pas mal d'années, les sorties de librsvg, c'était à peine quelques commits.

J'ai pas mal de rapports de bugs (et même plusieurs patchs) qui attendent dans le bugtracker. Peut-être mes patchs vont-ils enfin avoir une revue de code et une intégration? :-) Ce serait bien, car librsvg est en effet utilisé par beaucoup de logiciels, mais il a des bugs assez sévères qui le rendent dans certains cas presque inutile pour le traitement de fichiers SVG (ce qui est triste quand on sait que c'est son cas d'utilisation!).

À moins que ça signifie que nos patchs seront simplement abandonnés si les portions de code sont convertis en Rust? Bon si ça veut dire que ça marche mieux, moi je veux bien. J'espère donc que ce regain d'activité va perdurer dans le temps!

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Le trait droit pour la bouche. Ensuite, je suis pas un spécialiste des smileys du tout du tout non plus. On peut sûrement faire mieux… :-)
Tiens pour me faire des points, parce que les chats ça fait toujours augmenter ses scores sur le net, paraît-il.

(ma source, un tweet de Patrick David, aucune idée s'il en est l'auteur)

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

;-)
Ocaml est un de mes vieux amis, même si je n'ai plus rien écrit dans ce langage depuis pas mal d'années. Alors c'est l'occasion de le ressortir. :P

Sinon dans mon code précédent, je rajouterais bien un petit smiley du gimp dans le raise (Failure ""):

         try raise (Failure "(o_o)") with

Ça ressemble, non? Les 2 gros yeux globuleux et la fermeture éclair… :-D
Bon par contre, si vous voulez voter pour mon code, votez sur l'original plutôt! Pour pas perdre mes votes précédents! :P

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

De même! LinuxFR ne serait rien sans ses principaux contributeurs, et toi en tête, il faut bien le dire. C'est simple, dans mon esprit, j'associe souvent LinuxFR à "Benoît Sibaud" (je sais bien que tu n'es pas le seul, et je ne souhaite en rien diminuer la contribution de tous! C'est juste que tu es un peu le "visage public" de LinuxFR, et c'est un visage sympa en plus!).

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Salut!

Je te souhaite également une très bonne année, Jehan.

Bonne année à toi aussi!

Ton message, bien que très intéressant, est très long. De nombreuses réflexions le jalonnent et j'émets de gros doutes quant à pouvoir y répondre avec intelligence. Sois clément s'il te plaît ! :)>

Pas de problème. Je sais que mes messages sont souvent très (trop) longs. Je vais essayer de faire plus court cette fois (edit en fin d'écriture: j'ai pas réussi à faire court!).

Je vais être franc avec toi, je ne vois pas où ils perdent tant de temps (hors rendu). 3/4 secondes par semaine, ça me paraît ridicule avec les moyens actuels
[…]
la plupart des situations appellent des mécanismes d'animation déjà-vus
[…]
En 3D, avec les outils modernes, les scènes lumineuses préconçues, les particules gérées, la colorimétrie réglable en 2 clics, les riggings (squelettes) existants, je ne vois pas où ils perdent tant de temps, surtout que leurs ressources doivent être monstrueuses.

Je pense que c'est là ton "problème" (si on peut dire): tu ne vois pas que l'animation est principalement humaine, pas mécanique. Tu ne fais pas d'animation avec un ordinateur, mais avec un être humain, qui a étudié le corps humain, notamment l'anatomie (ses muscles, ses os…), puis qui recrée des mouvements à partir de ses connaissances.
Un exemple très connu dans le monde de l'animation: les meilleurs animateurs se plaignent en général des riggers trop consciencieux. Ces derniers en fait vont rajouter pleins de règles "super géniales" dans leurs squelettes. J'expliquais dans mon blog post que "bouger le bras", ça n'existe pas. En fait on bouge le corps entier dans une configuration où le bras se trouve à l'endroit désiré (lire le post pour comprendre mieux). Un rigger va normalement créer des règles sur un squelette pour répercuter ce type de mécanismes corporels. Parfois par contre s'il en fait trop, il va rendre le corps trop "rigide", mécanique et limiter le pouvoir de l'animateur. Et ça devient un problème. C'est pourquoi un bon rigger n'est pas forcément celui qui automatise le plus. L'automatisation n'est pas toujours bonne.

En gros, non, pas tout ne peut être fait avec les outils modernes. Beaucoup de choses ont encore besoin d'un être humain qui non seulement a une forte connaissance, mais aussi a une sensibilité artistique. On veut des mouvements jolis, cool, gais, drôles, parfois tristes… ce sont des choses qu'un animateur sait faire. Pas une machine. Et c'est là où l'animation est un art. Le jour où l'animation sera 100% générée par les "outils modernes", ce ne sera plus un art. Et il y a de fortes chances que les films produits ne seront pas du tout agréables à regarder. J'espère que ce jour n'arrivera jamais.

Bien évidemment, pour une scène très compliquée, cela peut arriver

Quand un animateur donne ce type de temps, il ne parle en général même pas de la scène entière puisqu'un animateur ne va animer qu'une partie de la scène (dans une même scène, un animateur va animer un personnage, un autre un second personnage, un autre le décor… bon bien sûr, on parle de l'industrie où on peut se le permettre; dans ZeMarmot, Aryeom fait tout; un jour — si tout se passe bien — ce ne sera plus le cas!). Donc ces temps de quelques secs par semaine ne concernent même pas une scène complète, mais en général le temps d'animation d'1 seul perso par 1 animateur au sein d'une scène plus complexe (et probablement ça inclue même pas le coloriage; ni bien sûr la création/peinture/modélisation des décors statiques non plus!). Donc la complexité de la scène ne rentre même pas en compte dans ces stats.

Sans aller dans cet extrême, en animation télé, voire jeu vidéo, tu peux descendre à la minute par semaine. Ils en parlent aussi dans l'article. […]

C'est effectivement d'une basse qualité, ce qui permet surtout d'économiser sur le temps de rendu. Le travail sur la DA, la lumière et les textures existe déjà. La seule raison viable de ne pas l'utiliser est simplement de gratter des ressources par-ci, par-là, pour moi.

Encore une fois, tu ne vois pas du tout là où est le travail. Ce qui prend du temps, ce n'est pas le temps de rendu! Bon bien sûr que si, ça prend du temps, des heures, des jours et des semaines même! Sauf que l'animateur, quand il lance son rendu, il va pas juste attendre et rentrer chez lui! Il lance, ça va sur une ferme de serveur pour calcul, puis il passe à autre chose (il continue à animer, par ex une autre scène, il se croise pas les pouces). Ces stats données n'incluent pas le temps de rendu, mais uniquement le temps humain passé par l'animateur.
En outre bien sûr, sur ces séries, ils font aussi du rendu de qualité plus faible, mais ce n'est absolument pas ce que j'entendais par basse qualité! Je parle vraiment de qualité de l'animation, les mouvements, les sentiments, tout. En faisant abstraction de la qualité graphique, tu peux vraiment comparer l'animation d'une série 3D à un film cinéma Disney?
Genre tiens, je parlais de "Star Wars Rebel", je viens de taper ça dans Youtube et prend le premier lien d'un trailer (un extrait de scène). Si tu ne vois pas la différence d'animation entre ça et par exemple Zootopia, super film animé… ben je sais pas quoi dire.
Encore une fois, je ne parle pas de qualité graphique. On pourrait faire un rendu de zootopia en super basse qualité (où les corps des persos pourraient avoir l'air tout angulaires) que ce serait toujours 1000x fois mieux animé.

Donc non, les ressources grattées dans ces séries/jeux, ce ne sont pas juste des ressources informatiques. Ce sont surtout des ressources humaines!

Là où c'est similaire, c'est, sur la nature (vent dans les arbres, rivière, mer, mouvement de la pluie) et sur les personnages (le squelette, bien évidemment, mais aussi les déformations, l'anticipation, les courbes de mouvement, le timing, les actions secondaires, etc.) ainsi que sur les mouvements de caméra (hyper simple à gérer en 3D).

Mais… non! Encore une fois, si tu laisses tout ça entièrement géré par la machine, ben ton animation elle sera juste pas agréable à regarder. Le vent (le lien Wikipédia, c'est pour que tu lises des bases sur les mécaniques des vents et que tu vois que c'est tout sauf simple) dans les arbres? Il va dans quelle direction? Y a des rafales de temps en temps, et parfois ça ralentit, puis ça reprend… Déjà rien que ça, y a des trucs à réfléchir, décider, organiser et animer au delà du "je clique sur le bouton 'vent'"
Puis y a encore plus à faire. Par ex, le vent affecte aussi les personnages. Et je parle pas de trucs automatiques, genre "les cheveux volent au vent"; je dis qu'un perso quand il parle et que le vent souffle fort, il élève la voix et sa gestuelle va changer en conséquence, son thorax se gonflera davantage et son corps va probablement se redresser pour se faire mieux entendre (et si le vent est très très fort, il mettra probablement ses mains en entonnoir pour crier et la gestuelle va être encore plus exacerbée). Tout se voit dans le corps. Peut-être qu'à un moment il sera très légèrement déstabilisé aussi. S'il est face au vent, il va probablement plisser les yeux ou se les cacher de l'avant-bras. Et puis le vent dans les arbres, les feuilles tombent au sol, elles s'accumulent, puis elles continue à virevolter de temps en temps, même au sol (le vent n'affecte pas que les feuilles dans les arbres); puis quand les persos marcheront dans les tas de feuilles, elles vont se déplacer. Bien sûr, tu peux faire des feuilles qui tombent et disparaissent (on l'a déjà fait dans un film 3D très simple pour un spectacle de danse, on n'avait pas le temps pour mieux), mais pas dans un film qui veut faire ça bien! Pour toutes ces choses, t'as pas un bouton magique "changer la scène et les personnages en fonction du vent".
Et le vent n'est pas en ligne droite, surtout avec les obstacles et encore moins en intérieur de bâtiments. Les tornades sont l'exemple extrême que le vent n'est pas juste rectiligne. Sans aller dans cet extrême, ta bourrasque de vent dans ton animation ne sera de même pas juste une déformation rectiligne. Si tu scriptes juste du vent linéairement dans le temps et l'espace dans ton programme 3D, bien sûr que ce sera rapide. Ce sera aussi moche, non crédible et probablement ridicule. Maintenant oui tout a été fait, et du vent linéaire, tu en verras clairement dans plein d'animation faite en 3-2 à la télé. Encore une fois, tout dépend du niveau de qualité souhaité.

Ne me laisse même pas commencer à parler de la mer, rivière, pluie… Tiens laisse moi te dire juste ça: le réalisateur de "La Tortue Rouge" expliquait dans sa conférence qu'il y avait une équipe d'animateurs entièrement dédiée au mouvement de l'eau (uniquement ça)! Une équipe entière qui n'a fait que le mouvement de l'eau pendant toute la durée de production du film!

Quant aux mouvements de caméra… on se demande pourquoi y a des gens dont le seul métier est de gérer les mouvements de caméra! Donc oui, c'est simple de poser une caméra là et de filmer ta scène. Mais la différence, tu la verras avec la même scène filmée par un gars qui va passer plusieurs heures à réfléchir aux meilleures positions, aux trajectoires, angles, vitesse, courbes d'accélération…

C'est fou comme tu as une idée hypra simpliste d'un truc que des gens étudient depuis plus de 100 ans.
Bien sûr que tout est techniquement simple si on se limite à la technique. N'importe qui peut faire du cinéma: il suffit de prendre une caméra et d'appuyer sur "Record". Pareil pour l'animation 2D et 3D. La technique est super simple: des images qui se suivent et basta! Mais ce n'est pas là qu'est la "qualité" et le pouvoir artistique ou émotionnel de l'animation (ou du cinéma en général)! C'est dans les hommes qui sont derrière chacune de ces images et qui font des choix. Et c'est ça qui prend du temps. Si tu te limites aux possibilités techniques de ton logiciel, ton film sera juste nul (sans vouloir t'offenser). Ces possibilités techniques sont là pour aider les animateurs, mais certainement pas pour faire tout le boulot. Bien sûr, dans une démo sur internet, on va l'utiliser ainsi. On va tout laisser par défaut et montrer: hop tu vois le vent fait bouger l'herbe. Tadaaaa! Mais si tu t'arrêtes là et que tu fais une scène entière avec ça, ça va être super bizarre. C'est là qu'intervient l'animateur pour rendre ce truc automatique crédible et beau.

Sans vouloir juger, cela pourrait être dû à un manque d'expérience, à un manque de talent, à un manque de confiance en soi, en bref, rien de très "technique". Du coup, l'argent serait investi dans "l'entraînement d'une animatrice débutante".

Mais pas du tout! Aryeom est jeune et (comme tout le monde) apprend constamment, mais elle n'a rien d'une débutante. Elle a commencé à dessiner quand elle était toute petite, a étudié l'animation aux Beaux Arts en Corée pendant des années, a été diplômée dans cette spécialité, et a travaillé en freelance professionnellement pendant plusieurs années. Franchement t'as de la chance que je sois bonne nature car c'est très dur à ne pas prendre mal ce genre de remarque! Tu dis toi-même peu connaître ni à la 2D, ni à la 3D, alors vaudrait mieux éviter ce genre de remarques, tout de même! L'animation, c'est pas juste une keyframe ici, une autre ici et basta!

Toutes les stats sont avec nous. As-tu lu le lien qui donne les temps d'animation classiques dans le métier? Personne, absolument personne au monde ne fait le type de stats dont tu parles pour faire un bon film (visuellement; ensuite y a tous les autres aspects d'un film…). C'est simple, c'est impossible. Et si tu y arrives vraiment, tu es tout simplement un génie. Oui plein de gens peuvent faire ce type de stats pour du travail bâclé (comme je le disais, techniquement tu peux faire une animation avec juste 2 keyframes, c'est l'extrême ultime), ou pour faire des effets de style (on voit beaucoup de films en festivals avec des choix stylistiques particuliers qui les rendent aussi plus simples et rapides à créer; ce qui ne veut pas dire qu'ils sont moches d'ailleurs, c'est aussi très intéressant, parfois stylisé, expérimental, etc.). Mais dès que tu souhaites faire de l'animation dans des logiques de qualité cinéma plus classique, non c'est impossible.
Tous les exemples au monde sont contre tes dires, alors je comprends vraiment pas comment tu t'obstines et arrives à sortir que c'est probablement dû à un manque d'expérience/talent/confiance de notre part!
Et encore une fois, je serais très intéressé par voir ton film si tu voulais le mettre en ligne.
Quand tu me dis:

Je vais être franc avec toi, je ne vois pas où ils perdent tant de temps (hors rendu). 3/4 secondes par semaine, ça me paraît ridicule avec les moyens actuels. Bien évidemment, pour une scène très compliquée, cela peut arriver, mais honnêtement, je n'ai pas vraiment vu de réalisations épatantes (ou loin de ma portée) méritant un soin tout particulier.

Encore une fois, soit tu es le meilleur animateur du monde (tu dis même que tu n'as encore jamais vu de scène loin de ta portée!), soit tu ne comprends pas du tout le travail de l'animation. Je ne vois pas d'autres réponses possibles à ce type d'affirmations.

Sauf que Blender a quoi ? 20 ans ? Ce n'est pas un peu gourmand que de vouloir réformer l'animation 2D ? (Simple question, c'est pour savoir où tu te situes là-dedans !)

Techniquement l'animation 2D n'est pas compliquée. Il faut juste faire les bons outils pour aider l'animateur. Au final, encore une fois, c'est l'animateur qui est le plus important, pas les outils.
Et c'est probablement vrai dans tous les métiers. Y a cette expression du "mauvais ouvrier qui blâme ses outils", mais même si c'est trop simpliste (on peut avoir de trop mauvais outils qui nuisent à la qualité), ça reste globalement vrai. Derrière l'animation, il y a des humains qui ont fait un travail de fou, pas juste des bons logiciels et des développeurs (qui font aussi un très bon travail, mais c'est un travail de collaboration et le film a besoin des 2). Et je pense que c'est vraiment la partie que tu n'arrives pas à appréhender car toutes tes réponses se focalisent sur le logiciel. Tu ne vois pas l'humain.

Donc non, je ne réforme pas l'animation 2D. Je crée un logiciel pour nous épauler en fonction de nos besoins. Et il n'est pas encore aussi complet que d'autres logiciels plus anciens, bien évidemment, mais de toutes façons, peu utilisent toutes les fonctions de tous les logiciels utilisés. Et puis faut bien commencer à un moment! Le fait est que quand j'ai commencé à coder, il n'existait aucun logiciel libre pour la 2D traditionnelle (non il n'était pas encore question d'animation sur Krita quand j'ai commencé; et OpenToonz n'était pas encore libre; il n'existait que des logiciels libres de 2D vectorielle).

Alors, 180 euros par mois, ce n'est probablement rien dans le milieu de l'informatique et de l'animation, bien évidemment, mais en réalité, ça reste une somme conséquente à mes yeux.

Pour une personne en tant que "dépense", peut-être. Mais comment peut-on prétendre que c'est beaucoup en salaire par mois, peu importe le métier?

Pour rappel, un SMIC est à 7,50 euros (NET). Soit 60 euros par jour.

Tu compares net et somme totale (avec toutes les charges).

en fait, vous êtes plus proches de 300 entre Patreon/Tipeee et votre levée de fond, non ?

Résultat de notre petite promotion de fin d'année.

Sinon, en délocalisant, rien n'oblige à mal payer des animateurs. Tout dépend du niveau de vie du pays, et même de la mentalité. Mais le sujet est bien trop complexe. Tu veux rester en France, c'est tout à fait compréhensible.

Je ne cherche pas à rester en France et n'aurais aucun problème à aller ailleurs (j'ai vécu au Danemark, en Corée, au Japon, en Nouvelle Zélande…). Je ne suis certainement pas nationaliste de ce point de vue là et n'aurais aucun problème à délocaliser, ou même à avoir une équipe internationale et distante si on arrivait à organiser convenablement le travail. Simplement ma raison de faire cela ne serait pas pour diminuer les coûts.

Bien évidemment, il y a tout un camaïeu de personnes impliquées, bien intentionnées, contentes de faire leur travail, mais ce n'est pas quelque chose qu'on nous transmet, ni quelque chose de transparent.

Bien sûr, c'est le principal problème du cinéma traditionnel. Il n'y a aucune passation de savoir et de techniques. Une grande partie reste en interne et peut potentiellement mourir avec l'entreprise (une partie sort et se retrouve enseignée dans les écoles, des livres, etc. Mais il reste beaucoup de "secrets professionnels"). C'est vrai pour un peu toutes les entreprises traditionnelles (c'est à dire quasi toutes les entreprises du monde à l'heure actuelle) d'ailleurs, pas juste le cinéma.
Et c'est justement une des logiques à l'encontre desquelles nous allons. Nous voulons partager toutes les techniques (pas seulement les logiciels, mais aussi la connaissance sur l'animation).

Si "La Reine des Neiges" est un bon moyen de faire tourner l'économie, j'aimerais que l'on m'explique pourquoi, parce que franchement, je n'y crois pas du tout.

Ben comme toute activité où tu payes des gens, non? Comme tu dis, l'argent tourne (en les payant, eux même peuvent payer d'autres choses et ainsi de suite).

J'ai essayé de comprendre où tu voulais en venir, j'espère y être plus ou moins parvenu. Ne te force pas à répondre à mes "questions", elles sont davantage là pour égailler mes propos et mes pensées.

J'y ai quand même répondu. J'avoue être troublé car je ne comprends pas comment tu arrives à tes diverses conclusions. Elles vont à l'encontre de 100 ans d'expériences par des millions de personnes qui ont travaillé dans de l'animation et plus globalement au cinéma. Mais tu restes persuadé que ces millions de personnes ont tout faux.
Ça me sidère. C'est pour ça que j'ai essayé de répondre une dernière fois.
Mais ensuite je crois que je vais arrêter là. Ne m'en veux pas si je ne fais pas plus de réponses sur ce sujet. Mais si tu réponds, je lirai quand même. :-)

Si, pour l'instant, je n'accroche pas tout à fait à ZeMarmot, j'accroche à ton caractère et ton implication ! Plutôt que de donner pour un projet, je donnerai peut-être pour un homme.

Pas de problème. Nous ne forçons personne et le film sera quand même visible par tous (enfin il nous faut quand même une base de contributeurs financiers pour assurer une fin de projet parfaitement heureuse, et on est encore loin du montant requis mais j'ai bon espoir! Ça va dans le bon sens).
Mais si tu contribues quand même, nous en serons reconnaissant, cela va sans dire. :-)

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Allez, assumons un des plus gros trolls autour de GIMP, son nom! Pour donner un peu de référence à ceux qui ne savent pas, le terme "Gimp" a été popularisé par Pulp Fiction qui en a fait le nom d'un perso sado-maso. Depuis c'est un sujet récurrent, une fois tous les X mois, un anglophone viendra se plaindre du terme et nous demandera de changer le nom du programme.
Ce "programme-blague" ci-dessous est une référence à la fameuse scène, et en particulier à la citation par un personnage: "Bring out the Gimp".

Note: ce programme crée un fichier appelé "Pulp Fiction" dans votre répertoire courant (avec aucun but autre qu'utiliser des mots de fonction marrant!). Donc ne pas faire tourner ce code si par pur hasard, vous avez déjà un fichier de ce nom! Le code marche mais n'est pas fait pour être utile! :-)
C'est du CC 0.

# open Unix;;
# let quote = fun
    f -> let box = open_out_bin f in
         seek_out box 0b1;
         ignore (sleep 0x0); 
         try raise (Failure "") with
             | _ -> output_string box "Bring out the gimp!";
                    close_out box
in quote "Pulp Fiction";;

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

GitHub me disait par exemple que les sources de mon projet devaient être publiques…
Ce n'est donc plus moi qui décide ?

Moi ça me choque pas. Le business model de Github est assez clair: soit tu payes et tu es le client; soit tu payes pas, et tu es le produit (pour eux, tu es juste alors un "chiffre" marketing qui montre à leurs clients à quel point Github est devenu central et "indispensable"; ils doivent donc le prouver et pour ça, seuls les "produits" publiques sont acceptés).

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]