P.S.: en tous cas pour Flatpak. Pour Docker, je sais pas, mais comme c'est orienté plutôt services et système de prob, j'en doute. Et pour d'autres alternatives de bureau, type Snap, aucune idée non plus du modèle adopté.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Tu cites déjà la réponse dans ton journal. Je pense que Flatpak, si le projet continue dans la bonne direction (ça a l'air d'être le cas pour l'instant), peut être la solution au problème cité.
Note que je ne considère absolument pas que le système de paquet par distribution est cassé pour autant, ni qu'il disparaîtra. C'est simplement complémentaire. L'écosystème logiciel GNU est simplement devenu trop important pour que tous les logiciels intéressants soient inclus dans les paquets gérés par la distrib (on peut voir cela comme un succès du "bureau Linux" si on veut alimenter le troll! :P). Donc il faut trouver des solutions pour répartir mieux le travail, et ça veut en général dire que les développeurs doivent s'y mettre. Par contre — on le sait bien depuis le temps — faire un paquet par distribution n'est pas gérable, surtout si ce sont des logiciels faits sur le temps libre (cas non rare dans le logiciel libre!). Un format standard comme flatpak, utilisable sur toute distribution GNU/Linux, est donc une très bonne alternative.
Mais là, qui va s'assurer que tout vos containers utilisent bien la dernière version patchée d'une bibliothèque critique ?
Alors je sais pas comment ça marche pour Docker que tu cites aussi, mais j'imagine bien qu'y a pas de mise-à-jour automatique (surtout parce que c'est fait pour les serveurs et on veut pas voir des trucs genre maj auto en prod!). Par contre Flatpak a un système de dépôt. En gros, chaque projet aura désormais un mini-dépôt de paquets pour ses logiciels et mettra à jour ses dépendances (note: il est aussi possible de faire des Flatpak standalone, sans dépôt, mais ce n'est pas la procédure conseillée).
Ainsi quand le projet mettra à jour son paquet, l'ensemble des gens qui auront installé ce paquet recevront des notifications qu'une mise-à-jour est dispo. Personne ne se baladera avec des applis et dépendances trouées (tant que le projet upstream est maintenu). Note que le projet n'a même pas à maintenir l'ensemble des dépendances possibles d'un logiciel puisque Flatpak fonctionne par "niveaux" de runtime. Ainsi le projet Flatpak lui-même maintient un runtime "Freedesktop" qui à lui seul contient déjà environ 200 dépendances de base qui vont suffire pour énormément de projets. Le projet GNOME aussi maintient un runtime, basé sur celui Freedesktop et qui ajoute environ 50 dépendances. Le projet KDE aussi maintient un runtime. Un logiciel doit simplement choisir un runtime sur lequel se baser.
Pour énormément de projet, celui signifie qu'il n'y aura peut-être aucune dépendance supplémentaire à ajouter dans le Flatpak (et donc à maintenir), ou très peu. Cela dilue énormément la tâche tout en permettant de rester sécurisé.
Ainsi pour les distributions, ça ne change pas grand chose: elles peuvent continuer à proposer les logiciels les plus notables notamment, et avoir des mises-à-jour fonctionnelles pas forcément au taquet (mais une fois tous les 6 mois ou 1 an en fonction du cycle de sortie de la distrib). Ça sera suffisant pour la majorité des logiciels.
Les développeurs eux auront moins de travail puisqu'il n'y aura plus qu'un seul paquet à maintenir pour être dispo partout.
Enfin tout le monde aura accès à des mises-à-jour immédiates fonctionnelles ET de sécurité si on choisit d'installer le paquet Flatpak upstream.
En tous cas, le projet GIMP par exemple fournira désormais un paquet Flatpak upstream que je crée et maintiens. Je pense que c'est vraiment une avancée car jusqu'à ce jour, les gens sous Windows ont un installeur, ceux sous OSX un DMG, et sous Linux… on leur disait d'attendre le paquet de leur distrib ou de compiler. Ça fait limite "citoyens de seconde zone" (bon c'est pas vrai, hein. Quasi tous les dévs de GIMP sont sous Linux, et donc ça veut dire notamment que la version nux est bien plus stable que les autres! Mais bon on pourrait croire). Ben plus maintenant. Tant que je serai dév de GIMP, les linuxiens auront leur Flatpak (bon à part si une alternative encore mieux fait son apparition bien sûr, ou si je découvre un truc horrible qui me fait changer d'avis sur l'utilité… espérons que non, mais on sait jamais!) et seront toujours des citoyens de première zone! :-D
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
En effet, je pense que leur suite creative cloud a encore une longue vie devant elle. D'ailleurs même le logiciel "Flash" a probablement un avenir sous son nouveau nom Animate. Simplement le "focus" a changé et le but n'est plus d'exporter en format Flash mais en HTML5 ou en d'autres formats vidéos.
Donc oui, Flash, le format, est sur la pente descendante, et Shockwave l'est encore plus (depuis bien plus longtemps puisque cette technologie fut justement totalement éclipsée par Flash quasi dès ses débuts! C'est dire à quel point c'est mort. J'explique cela dans les sections "Premier pas", puis "Age Sombre" de l'article sur Flash) et c'est donc normal que les logiciels dédiés à ces formats disparaissent (ou deviennent génériques comme fut le cas pour "Animate").
Mais effectivement je doute qu'Adobe en tant que société soit mourante. Pas du tout même. Une petite recherche sur le web indique un chiffre d'affaire en croissance. Apparemment ils ont eu une baisse du chiffre en 2013-14 (si je comprends bien comment on lit ces tableaux) mais ils sont repartis en force en 2015.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Microsoft Office est l'un des fleurons commerciaux de Microsoft. Il me semble — si je ne m'abuse — que cela compte pour une grande part dans les revenus de la compagnie (rapide recherche sur le net, si je comprends bien les graphiques, surtout le dernier, leur suite office fait environ 25% de leur revenu, au delà des produits serveur et des OSes).
Le fait est qu'aujourd'hui comme il y a 20 ans, une chose n'a pas changé: les gens ont besoin d'écrire des textes (courriers, contrats, histoires…) et pour cela les traitements de texte de ce type reste l'outil essentiel de la majeure partie des gens. Les tableurs sont aussi une ressource très commune et ne disparaîtront pas de sitôt, les gens en entreprise ont régulièrement besoin de faire des présentations…
Donc quelle est l'intérêt d'investir dans une suite office, vraiment? Quand tout dans l'utilisation informatique quotidienne des gens ainsi que dans les chiffres de l'entreprise informatique qui vend la suite office la plus utilisée au monde montre qu'il y a un potentiel financier énorme, cela me paraît une bien étrange question… :-)
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 ]
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 ]
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 ]
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 ]
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 ]
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.
;-)
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 ""):
tryraise(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 ]
[^] # Re: tendance
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 4. Dernière modification le 31 janvier 2017 à 00:34.
Si ça y répond même plutôt pas mal. :-)
Cf. mon message plus bas.
P.S.: en tous cas pour Flatpak. Pour Docker, je sais pas, mais comme c'est orienté plutôt services et système de prob, j'en doute. Et pour d'autres alternatives de bureau, type Snap, aucune idée non plus du modèle adopté.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Flatpak pour les paquets de logiciels de bureau
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 10.
Tu cites déjà la réponse dans ton journal. Je pense que Flatpak, si le projet continue dans la bonne direction (ça a l'air d'être le cas pour l'instant), peut être la solution au problème cité.
Note que je ne considère absolument pas que le système de paquet par distribution est cassé pour autant, ni qu'il disparaîtra. C'est simplement complémentaire. L'écosystème logiciel GNU est simplement devenu trop important pour que tous les logiciels intéressants soient inclus dans les paquets gérés par la distrib (on peut voir cela comme un succès du "bureau Linux" si on veut alimenter le troll! :P). Donc il faut trouver des solutions pour répartir mieux le travail, et ça veut en général dire que les développeurs doivent s'y mettre. Par contre — on le sait bien depuis le temps — faire un paquet par distribution n'est pas gérable, surtout si ce sont des logiciels faits sur le temps libre (cas non rare dans le logiciel libre!). Un format standard comme flatpak, utilisable sur toute distribution GNU/Linux, est donc une très bonne alternative.
Alors je sais pas comment ça marche pour Docker que tu cites aussi, mais j'imagine bien qu'y a pas de mise-à-jour automatique (surtout parce que c'est fait pour les serveurs et on veut pas voir des trucs genre maj auto en prod!). Par contre Flatpak a un système de dépôt. En gros, chaque projet aura désormais un mini-dépôt de paquets pour ses logiciels et mettra à jour ses dépendances (note: il est aussi possible de faire des Flatpak standalone, sans dépôt, mais ce n'est pas la procédure conseillée).
Ainsi quand le projet mettra à jour son paquet, l'ensemble des gens qui auront installé ce paquet recevront des notifications qu'une mise-à-jour est dispo. Personne ne se baladera avec des applis et dépendances trouées (tant que le projet upstream est maintenu). Note que le projet n'a même pas à maintenir l'ensemble des dépendances possibles d'un logiciel puisque Flatpak fonctionne par "niveaux" de runtime. Ainsi le projet Flatpak lui-même maintient un runtime "Freedesktop" qui à lui seul contient déjà environ 200 dépendances de base qui vont suffire pour énormément de projets. Le projet GNOME aussi maintient un runtime, basé sur celui Freedesktop et qui ajoute environ 50 dépendances. Le projet KDE aussi maintient un runtime. Un logiciel doit simplement choisir un runtime sur lequel se baser.
Pour énormément de projet, celui signifie qu'il n'y aura peut-être aucune dépendance supplémentaire à ajouter dans le Flatpak (et donc à maintenir), ou très peu. Cela dilue énormément la tâche tout en permettant de rester sécurisé.
En tous cas, le projet GIMP par exemple fournira désormais un paquet Flatpak upstream que je crée et maintiens. Je pense que c'est vraiment une avancée car jusqu'à ce jour, les gens sous Windows ont un installeur, ceux sous OSX un DMG, et sous Linux… on leur disait d'attendre le paquet de leur distrib ou de compiler. Ça fait limite "citoyens de seconde zone" (bon c'est pas vrai, hein. Quasi tous les dévs de GIMP sont sous Linux, et donc ça veut dire notamment que la version nux est bien plus stable que les autres! Mais bon on pourrait croire). Ben plus maintenant. Tant que je serai dév de GIMP, les linuxiens auront leur Flatpak (bon à part si une alternative encore mieux fait son apparition bien sûr, ou si je découvre un truc horrible qui me fait changer d'avis sur l'utilité… espérons que non, mais on sait jamais!) et seront toujours des citoyens de première zone! :-D
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: En dehors de Flash
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal adobe c'est bientôt mort ?. Évalué à 10.
En effet, je pense que leur suite creative cloud a encore une longue vie devant elle. D'ailleurs même le logiciel "Flash" a probablement un avenir sous son nouveau nom Animate. Simplement le "focus" a changé et le but n'est plus d'exporter en format Flash mais en HTML5 ou en d'autres formats vidéos.
Donc oui, Flash, le format, est sur la pente descendante, et Shockwave l'est encore plus (depuis bien plus longtemps puisque cette technologie fut justement totalement éclipsée par Flash quasi dès ses débuts! C'est dire à quel point c'est mort. J'explique cela dans les sections "Premier pas", puis "Age Sombre" de l'article sur Flash) et c'est donc normal que les logiciels dédiés à ces formats disparaissent (ou deviennent génériques comme fut le cas pour "Animate").
Mais effectivement je doute qu'Adobe en tant que société soit mourante. Pas du tout même. Une petite recherche sur le web indique un chiffre d'affaire en croissance. Apparemment ils ont eu une baisse du chiffre en 2013-14 (si je comprends bien comment on lit ces tableaux) mais ils sont repartis en force en 2015.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: La FSF et le logiciel libre en phase terminale ?
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Flash est en phase terminale!. Évalué à 9.
Microsoft Office est l'un des fleurons commerciaux de Microsoft. Il me semble — si je ne m'abuse — que cela compte pour une grande part dans les revenus de la compagnie (rapide recherche sur le net, si je comprends bien les graphiques, surtout le dernier, leur suite office fait environ 25% de leur revenu, au delà des produits serveur et des OSes).
Le fait est qu'aujourd'hui comme il y a 20 ans, une chose n'a pas changé: les gens ont besoin d'écrire des textes (courriers, contrats, histoires…) et pour cela les traitements de texte de ce type reste l'outil essentiel de la majeure partie des gens. Les tableurs sont aussi une ressource très commune et ne disparaîtront pas de sitôt, les gens en entreprise ont régulièrement besoin de faire des présentations…
Donc quelle est l'intérêt d'investir dans une suite office, vraiment? Quand tout dans l'utilisation informatique quotidienne des gens ainsi que dans les chiffres de l'entreprise informatique qui vend la suite office la plus utilisée au monde montre qu'il y a un potentiel financier énorme, cela me paraît une bien étrange question… :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Changement de logo chez Mozilla (donc changement d'autocollants)
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Album Autocollants du Libre : appel aux associations. Évalué à 2.
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 ]
[^] # Re: KOKOPELLI
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Album Autocollants du Libre : appel aux associations. Évalué à 2.
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 ]
[^] # Re: Mageia.org
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Album Autocollants du Libre : appel aux associations. Évalué à 2.
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 ]
[^] # Re: TuxFamily.org
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Album Autocollants du Libre : appel aux associations. Évalué à 2.
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 ]
[^] # Re: Incoming PauLLA Stickers ! :D
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Album Autocollants du Libre : appel aux associations. Évalué à 2.
Super! Merci. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: XML sapu et autres billevesées
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 4. Dernière modification le 13 janvier 2017 à 17:42.
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.
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:
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:
Puis un peu plus bas:
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.
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.
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 ]
[^] # Re: Merci LinuxFR!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Meilleures contributions LinuxFr.org : les primés de novembre 2016. Évalué à 5. Dernière modification le 13 janvier 2017 à 16:25.
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 ]
[^] # Re: XML sapu et autres billevesées
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 2.
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 ]
[^] # Re: XML sapu et autres billevesées
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 2.
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).
Je ne comprends pas ce que tu veux dire.
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.
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 ]
# Que cherches-tu exactement?
Posté par Jehan (site web personnel, Mastodon) . En réponse au message [GNOME 3] Extension : Ajouter une barre de lancement rapide. Évalué à 3.
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 ]
[^] # Re: Avancement ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche ZeMarmot : compte‐rendu de fin 2016 et appels aux dons. Évalué à 4. Dernière modification le 09 janvier 2017 à 00:34.
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).
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. :-)
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. ;-)
De rien. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Avancement ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche ZeMarmot : compte‐rendu de fin 2016 et appels aux dons. Évalué à 2. Dernière modification le 08 janvier 2017 à 19:09.
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.
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 ]
[^] # Re: Avancement ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche ZeMarmot : compte‐rendu de fin 2016 et appels aux dons. Évalué à 2. Dernière modification le 08 janvier 2017 à 15:49.
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.
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!
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.
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 ]
[^] # Re: Ne plus avoir de voiture
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Et vous, vous voulez qu'elle fasse quoi votre voiture autonome ?. Évalué à 10.
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 ]
# Merci LinuxFR!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Meilleures contributions LinuxFr.org : les primés de novembre 2016. Évalué à 9.
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 ]
[^] # Re: Ne plus avoir de voiture
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Et vous, vous voulez qu'elle fasse quoi votre voiture autonome ?. Évalué à 5.
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 ]
[^] # Re: Ne plus avoir de voiture
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Et vous, vous voulez qu'elle fasse quoi votre voiture autonome ?. Évalué à 5.
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 ]
# Logiciel libre
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal LilyPond ne sera pas dans Debian Stretch. Évalué à 10.
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 ]
# Regain de développement sur librsvg?
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Librsvg utilise maintenant le langage Rust. Évalué à 10.
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 ]
[^] # Re: Bring out the gimp
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Attention, le concours de jeux de mots se termine fin janvier 2017 !. Évalué à 2. Dernière modification le 05 janvier 2017 à 18:19.
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 ]
[^] # Re: Bring out the gimp
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Attention, le concours de jeux de mots se termine fin janvier 2017 !. Évalué à 3. Dernière modification le 05 janvier 2017 à 14:42.
;-)
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 ""):Ç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 ]