ça je comprends bien. Il s'agit du format d'échange, non du format de travail. De même de des développeurs ne donnent pas seulement un code source aux utilisateurs, mais ils leur donnent une version binaire prête à l'emploi d'un double clic.
Maintenant laisse moi te donner un exemple:
Tu fais ton sprite. C'est un bonhomme tout petit, et il bouge pas beaucoup. Mais il bouge quand même les pieds au moins quand il marche, probablement les mains aussi, peut-être même qu'il tourne la tête.
Qu'est-ce que tu fais quand tu veux faire les diverses versions de sa démarche? Bien sûr, tu peux faire le petit bonhomme complet, puis tu dupliques le calque (ou tu fais une autre image, ou que sais-je), et tu changes juste un peu les pieds, puis les mains, puis tu re-dupliques le calque, etc. Tu fais autant de calques/images que de frames.
Mais voilà, un jour, tu veux changer son corps. Un truc tout con: tu trouves que la veste rouge lui va pas. Tu veux la faire bleue. Bah! Facile. Tu dois changer la couleur de la veste sur chaque frame finie de l'animation! Donc tu recharges chaque png un à un, et tu modifies la veste.
Pourtant le corps est exactement le même sur chaque! Mais tu multiplies ton travail par le nombre de frame/png.
Maintenant plutôt que faire cela, voilà ce que tu pourrais faire: tu fais le corps qui bouge jamais sur un calque, deux versions de la tête (une à gauche, une à droite, ou que sais-je), trois versions des bras (balancés d'un côté ou de l'autre, ou au "repos"), pareil pour les jambes. Et tu as maintenant 1 * 2 * 3 * 3 = 18 frames différentes en seulement 1 +たす 2 +たす 3 +たす 3 =わ 9 calques (avec juste quelques pixels par calque. Dans ton cas, un calque, c'est juste les bras par exemple). Et le jour où tu veux changer la couleur du corps, tu changes seulement deux calques, puis tu lances un script (que tu as écrit à côté) qui regénère tes 18 frames de png en 1 centième de secondes.
Puis le jour où tu veux changer plus, facile aussi, et fait en quelques secondes.
En travaillant que sur des png par contre, ce jour là où tu veux faire un gros changement sur ton bonhomme, t'es vraiment dans la merde, et tu peux tout aussi bien tout reprendre du début.
Julien Jorge dans ce journal a montré un très bon exemple de ce workflow dont je parle, et que tu as tout intérêt à prendre dans ton cas aussi. Regarde bien sa copie d'écran. Il a un layer pour le corps, des layers pour diverses positions pour chaque aile, etc.
Moi c'est encore pire. On fait des dessins animés. Genre 10, 24 ou plus images par seconde, taille HD. Tu te rends bien compte que si je recopiais des éléments fixes à chaque frame, le jour où je veux changer cet élément (qui bougeait pas pendant genre 10 secondes par exemple, donc quelques centaines de frames!), c'est mort, on se tire une balle.
C'est pour cela que tu devrais vraiment travailler avec des XCF, sauver tes XCF et même les versionner (les png par contre, sauf cas particulier, ne les versionne pas si tu peux éviter. C'est du généré! Pas du source). Ton application finale, elle utilisera toujours des png, qui seront générés automatiquement à partir des tes XCF par une commande dans le Makefile (ou autre système de compilation), ce qui fait que tu as jamais à t'en préoccuper, mais tu bosses uniquement sur les XCF. Tu ne devrais même pas à avoir à exporter à la main dans GIMP en png en fait. Tu te rends compte si tout le monde faisait cela? On n'utiliserait jamais GIMP! Ou alors tu veux te limiter à une dizaine de persos dans ton jeu, ou alors tu aimes le boulot chiant de fourmi (afficher le layer, masquer avant, exporter, afficher, masquer, exporter, etc. 1 fois par frame), ou alors tu prévois de sous-traiter en Inde. :-D
Non on ouvre GIMP, on fait la partie "intéressante" (on dessine), on sauve, on ferme GIMP, et on veut taper Make, et basta. C'est fini. On a un jeu (dans ton cas) compilé avec de nouvelles images juste finie. :-)
Ce que tu es en train de faire là, c'est l'équivalent pour un programmeur de bosser directement sur la source compilée, ou plutôt sur du code généré: tu as un code, tu le compiles, puis tu jettes ton code original. Et lorsque tu veux modifier ton code, tu bosses à partir de la version générée que tu recompiles, puis tu rejettes, etc. Bien sûr c'est encore faisable car dans ton cas ton code "compilé" (png) est moins barbare qu'un binaire, mais ça reste de la donnée générée, avec tout ce que cela implique (perte de donnée, complexification, etc.).
D'ailleurs je viens de revoir à nouveau ton post sur nanim, tu écris
Enfin, il faut recommencer pour toutes les positions clefs de l'animation, n'ayant pas la possibilité d'engager une armée d'intervallistes, je me suis contenté de 5 frames
Forcément, tu redessines tout à chaque fois! Alors que si tu avais séparé avec des calques, et généré avec un script tes pngs, t'as juste à dessiner une nouvelle position des bras, et paf t'as une nouvelle frame.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: xcf-utils
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Outils autour de Gimp : Pack My Sprites et Xcftools. Évalué à 2.
Salut,
ça je comprends bien. Il s'agit du format d'échange, non du format de travail. De même de des développeurs ne donnent pas seulement un code source aux utilisateurs, mais ils leur donnent une version binaire prête à l'emploi d'un double clic.
Maintenant laisse moi te donner un exemple:
Tu fais ton sprite. C'est un bonhomme tout petit, et il bouge pas beaucoup. Mais il bouge quand même les pieds au moins quand il marche, probablement les mains aussi, peut-être même qu'il tourne la tête.
Qu'est-ce que tu fais quand tu veux faire les diverses versions de sa démarche? Bien sûr, tu peux faire le petit bonhomme complet, puis tu dupliques le calque (ou tu fais une autre image, ou que sais-je), et tu changes juste un peu les pieds, puis les mains, puis tu re-dupliques le calque, etc. Tu fais autant de calques/images que de frames.
Mais voilà, un jour, tu veux changer son corps. Un truc tout con: tu trouves que la veste rouge lui va pas. Tu veux la faire bleue. Bah! Facile. Tu dois changer la couleur de la veste sur chaque frame finie de l'animation! Donc tu recharges chaque png un à un, et tu modifies la veste.
Pourtant le corps est exactement le même sur chaque! Mais tu multiplies ton travail par le nombre de frame/png.
Maintenant plutôt que faire cela, voilà ce que tu pourrais faire: tu fais le corps qui bouge jamais sur un calque, deux versions de la tête (une à gauche, une à droite, ou que sais-je), trois versions des bras (balancés d'un côté ou de l'autre, ou au "repos"), pareil pour les jambes. Et tu as maintenant 1 * 2 * 3 * 3 = 18 frames différentes en seulement 1 +たす 2 +たす 3 +たす 3 =わ 9 calques (avec juste quelques pixels par calque. Dans ton cas, un calque, c'est juste les bras par exemple). Et le jour où tu veux changer la couleur du corps, tu changes seulement deux calques, puis tu lances un script (que tu as écrit à côté) qui regénère tes 18 frames de png en 1 centième de secondes.
Puis le jour où tu veux changer plus, facile aussi, et fait en quelques secondes.
En travaillant que sur des png par contre, ce jour là où tu veux faire un gros changement sur ton bonhomme, t'es vraiment dans la merde, et tu peux tout aussi bien tout reprendre du début.
Julien Jorge dans ce journal a montré un très bon exemple de ce workflow dont je parle, et que tu as tout intérêt à prendre dans ton cas aussi. Regarde bien sa copie d'écran. Il a un layer pour le corps, des layers pour diverses positions pour chaque aile, etc.
Moi c'est encore pire. On fait des dessins animés. Genre 10, 24 ou plus images par seconde, taille HD. Tu te rends bien compte que si je recopiais des éléments fixes à chaque frame, le jour où je veux changer cet élément (qui bougeait pas pendant genre 10 secondes par exemple, donc quelques centaines de frames!), c'est mort, on se tire une balle.
C'est pour cela que tu devrais vraiment travailler avec des XCF, sauver tes XCF et même les versionner (les png par contre, sauf cas particulier, ne les versionne pas si tu peux éviter. C'est du généré! Pas du source). Ton application finale, elle utilisera toujours des png, qui seront générés automatiquement à partir des tes XCF par une commande dans le Makefile (ou autre système de compilation), ce qui fait que tu as jamais à t'en préoccuper, mais tu bosses uniquement sur les XCF. Tu ne devrais même pas à avoir à exporter à la main dans GIMP en png en fait. Tu te rends compte si tout le monde faisait cela? On n'utiliserait jamais GIMP! Ou alors tu veux te limiter à une dizaine de persos dans ton jeu, ou alors tu aimes le boulot chiant de fourmi (afficher le layer, masquer avant, exporter, afficher, masquer, exporter, etc. 1 fois par frame), ou alors tu prévois de sous-traiter en Inde. :-D
Non on ouvre GIMP, on fait la partie "intéressante" (on dessine), on sauve, on ferme GIMP, et on veut taper Make, et basta. C'est fini. On a un jeu (dans ton cas) compilé avec de nouvelles images juste finie. :-)
Ce que tu es en train de faire là, c'est l'équivalent pour un programmeur de bosser directement sur la source compilée, ou plutôt sur du code généré: tu as un code, tu le compiles, puis tu jettes ton code original. Et lorsque tu veux modifier ton code, tu bosses à partir de la version générée que tu recompiles, puis tu rejettes, etc. Bien sûr c'est encore faisable car dans ton cas ton code "compilé" (png) est moins barbare qu'un binaire, mais ça reste de la donnée générée, avec tout ce que cela implique (perte de donnée, complexification, etc.).
D'ailleurs je viens de revoir à nouveau ton post sur nanim, tu écris
Forcément, tu redessines tout à chaque fois! Alors que si tu avais séparé avec des calques, et généré avec un script tes pngs, t'as juste à dessiner une nouvelle position des bras, et paf t'as une nouvelle frame.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]