Exporter vers les moteurs

La fenêtre Exporter

Exporter (Ctrl+E) se trouve juste après Importer dans l’en-tête de la fenêtre, et ouvre une fenêtre dessinée comme celle d’Importer (D51) :

1. Pipeline d’asset — celui qu’affiche le sélecteur Asset de l’en-tête, au départ. Ce qu’il écrit se conçoit dans le graphe d’asset.
2. Dossier d’export — tapez un chemin, ou Choisir… en choisit un. Le projet le conserve.
3. Exporter maintenant — le projet tel qu’il est ouvert, enregistré ou non : exporter ne l’enregistre jamais, et un projet sans titre s’exporte tel quel.

Avant que vous n’appuyiez sur Exporter, la fenêtre liste chaque fichier que l’export écrira, tels que les nomme pxr names : chacun par son chemin dans le dossier et son type (planche de sprites, JSON, GIF…), avec sera remplacé sur un fichier que le dossier contient déjà. La liste est recalculée — avec un petit indicateur de chargement, sans jamais bloquer la fenêtre — quand vous changez de pipeline d’asset, de dossier ou de projet. Un pipeline qui ne peut pas être exporté tel quel (deux sorties écrivant un même fichier, par exemple) dit pourquoi à cet endroit, et Exporter attend qu’il soit corrigé.

Une fois pressé, ces mêmes lignes, à leur place, sont l’export : chacune avec un indicateur de chargement jusqu’à ce qu’elle soit écrite, puis une coche, sa taille, Ouvrir (dans le programme avec lequel votre système l’ouvre) et Afficher le dossier. Ce qui ne va pas est indiqué sur le fichier où l’export s’est arrêté. Arrêter interrompt un export à mi-chemin : ce qui a été écrit reste, le fichier en cours d’écriture est supprimé. La fenêtre peut être fermée pendant l’export ; Exporter la rouvre.

Il exécute exactement ce qu’exécute la ligne de commande : pxr render PROJECT --pipeline NAME -o FOLDER, dans un processus à part, pour que Pixor reste réactif — sur un instantané du projet tel qu’il est ouvert, écrit dans le dossier généré (avec les chemins de ses fichiers rendus absolus) et supprimé à la fin de l’export. Les fichiers sont nommés comme pxr render nomme ceux de ce projet : d’après le projet, ou, pour un projet sans titre, d’après son modèle. Chaque fichier est écrit à neuf à partir du pipeline : ce que Générer produit sur les nœuds du graphe d’asset n’est jamais copié.

Chaque fichier va dans le dossier. La planche prend son nom de fichier du nœud PNG du projet (out/hero.png écrit FOLDER/hero.png) ; un fichier dont le chemin est sous le dossier de la planche garde sa place sous FOLDER, et tout autre chemin (une archive, une animation, des icônes nommées ailleurs) ne garde que sa dernière partie.

Ce qu’écrit un export

Chaque export écrit une planche : une rangée par action et par côté, une colonne par image, toutes les cases de la même taille, avec le pivot sur le même pixel dans chacune. Ajoutez des nœuds Fichier à la planche dans le graphe d’asset (ou utilisez --export en ligne de commande) pour obtenir des fichiers à côté d’elle, avec le même nom. Chacun est un nœud relié à la planche, avec ses propres réglages. --export all écrit tous les formats ci-dessous sauf p8 et video, qui ne sont écrits que s’ils sont nommés : une cartouche n’accepte qu’une planche faite pour elle, et une vidéo non compressée de chaque clip et chaque côté peut peser des gigaoctets. Deux d’entre eux n’écrivent jamais le même fichier : pxr names refuse un projet où ce serait le cas.

Format	Fichier	Pour
png	name.png	la planche, un PNG indexé (indice 0 transparent)
json	name.json	rectangles des cellules, durées des images, un tag par action et par côté, le pivot. La disposition « array » d’Aseprite, pour que les importateurs écrits pour Aseprite la lisent
aseprite	name.aseprite	un fichier Aseprite indexé : calques final, lines, flat, et un par sortie supplémentaire du graphe de Style ; un tag par action et par côté ; des durées par image ; une slice pivot
normale	name_normal.png	une carte de normales avec la même disposition, pour l’éclairage 2D
profondeur	name_depth.png	la profondeur avec la même disposition : blanc pour le plus proche, sombre pour le plus éloigné, une seule échelle pour toute la planche (meta.pixor.depth donne les deux en mètres) ; transparent là où il n’y a rien. Pour le tri, le brouillard et l’éclairage en 2.5D
émission	name_emission.png	chaque pixel lumineux dans sa propre couleur, aussi intense qu’il brille (un matériau lumineux, ou la carte émissive du modèle) ; transparent ailleurs. Pour la lueur et le bloom
calques	name_lines.png, name_flat.png, et name_LAYER.png pour chaque sortie supplémentaire du graphe de Style	les calques de traits et d’aplats sous forme de planches, et l’image d’un nœud là où le graphe de Style en nomme une
palette	name.hex, name.gpl	la palette (formats Lospec et GIMP)
godot	name.tres	une ressource Godot 4 SpriteFrames
gif	name_walk_Southeast.gif, …	un GIF animé par action et par côté, les tenues en délais d’image, pour le partage et les aperçus
apng	name_walk_Southeast.apng, …	la même chose en PNG animés, avec des délais exacts à la milliseconde
vidéo	name_walk_Southeast.avi, …	une vidéo par action et par côté : un AVI non compressé, chaque pixel tel quel, pour une bande-annonce ou une page de boutique
light-kit	name_ramps.png, name_normal.png, name_light.png, shaders	éclairage fidèle à la palette dans les moteurs (voir ci-dessous)
rapport	name_report.png	la planche avec les constats de chaque vérification marqués (voir ci-dessous)
p8	name.p8	une cartouche PICO-8 (voir Modes de la console)
zip	le chemin sur son nœud	un nœud Archive ZIP dans le graphe d’asset : les fichiers qui y sont reliés, ou tout ce qu’a écrit l’export

Une ligne est nommée d’après son action et son côté : walk_Southeast.

Les images que prend une planche, leur disposition et le nombre de fichiers qu’écrit un rendu relèvent du graphe d’asset : un nœud Planche et ses nœuds Fichier, tant que vous ne le reliez pas autrement.

Comment s’appellent les images, et ce qu’elles sont

Chaque image d’une planche a un nom et un id, et ils répondent à deux questions différentes.

Le nom est un modèle, un motif construit sur les mots de votre propre projet : la valeur par défaut toute simple convient au débutant, et un studio peut suivre une convention qu’il n’a pas choisie :

{project}_{action}_{side}_{index:2}.{ext}     hero_walk_East_00.png

Les mots sont {project}, {object}, {action}, {side}, {layer}, {set} (le jeu de parties avec lequel un nœud Sprites a dessiné l’image), {size}, {index} et {ext}. {index:3} complète un nombre avec des zéros jusqu’à trois chiffres. {{ et }} écrivent une accolade. Un mot que Pixor ne connaît pas est une erreur dès que vous tapez le modèle, et non un fichier appelé hero_{genre}_00.png, et un mot vide emporte avec lui le séparateur qui le précède : un sprite sans côté donne hero_Static_00.png.

Une valeur qui ne peut pas faire partie d’un nom de fichier (/ \ : * ? " < > |) est refusée plutôt que remplacée en silence ; une espace devient _. La seule exception est le mot propre à Pixor : un clip de bibliothèque appelé lib:walk devient lib-walk dans un nom, car ces deux-points sont ceux de Pixor et non les vôtres.

Deux images qui recevraient le même nom sont refusées avant tout rendu. Réglez-le avec --names en ligne de commande, ou conservez-le dans le projet :

pxr project set hero.pixor --names '{object}/{action}-{side}-{index:3}.{ext}'
pxr names hero.pixor                  # what it will write, without rendering
pxr names hero.pixor --json           # the same, for a build script

L’identifiant dit ce qu’est une image, jamais où elle a atterri. C’est un hachage de l’objet, de l’action, du côté, de l’instant dans l’action et du calque, et il est écrit à côté de chaque image dans le JSON et dans les données utilisateur du .aseprite. Réagencer une planche, ajouter un clip ou changer la marge déplace des rectangles et laisse les identifiants intacts : un build qui se réfère aux images par identifiant ne casse pas à chaque passage de l’empaqueteur. Rééchantillonner un clip à une autre fréquence d’images change bien ses identifiants, car ce sont d’autres images.

Des planches plus petites

Sur le nœud Disposer du graphe d’asset (ou en ligne de commande) :

• Rogner l’espace vide (--trim) réduit chaque image à ses pixels. Le JSON donne la position de chaque image dans la cellule complète (spriteSourceSize, trimmed: true) et le fichier Godot règle la margin de chaque image, si bien que les moteurs placent toujours chaque image sur le pivot.
• Stocker une seule fois les images répétées (--dedupe) : les images strictement identiques (poses tenues, côtés d’un objet immobile) partagent un même emplacement.
• Largeur max. de la planche (--max-width 4096) commence une nouvelle rangée avant que la planche ne devienne plus large, pour les moteurs et les GPU qui limitent la taille des textures.
• Hauteur max. de la planche (--max-height 2048) découpe une planche plus haute que cela en pages, des clips entiers par page : hero_1.png, hero_2.png, chacune avec son propre JSON et les autres fichiers à côté.
• Images par ligne (--columns 8) place autant d’images sur une rangée, chaque clip enchaînant après le précédent : une planche contact, ou la grille fixe que demande l’importateur d’un moteur.
• Un côté tiré d’un autre (le nœud Retourner du graphe d’asset) : un modèle symétrique gauche-droite a le même aspect vu de gauche qu’une vue de droite retournée, si bien que le côté ouest n’a même pas besoin d’être rendu — prenez les sprites de la caméra est, retournez-les en Ouest, et la planche contient walk_West tiré de walk_East, avec pixels, normales, boîtes et root motion en miroir. Ne rendez que les caméras qui diffèrent ; retournez le reste.
• Les degrés de chaque côté figurent dans le JSON : sur chaque image (pixor.degrees) et, pour tous, sous meta.pixor.sides ({"South": 0, "Southeast": 45, ...}) : des degrés depuis l’avant, dans le sens antihoraire vu de dessus, tels que les prend --sides. Un jeu transforme un angle en rangée grâce à ce tableau.

Calque d’ombre

Calque d’ombre (--shadow contact ou --shadow drop) écrit name_shadow.png, disposé comme la planche : noir là où tombe l’ombre, transparent ailleurs. Contact est une tache sous les pieds, à la taille de l’emprise du modèle ; Portée est la silhouette projetée au sol à l’opposé de la lumière principale. Dessinez-la sous vos sprites avec l’opacité qui vous plaît, ou triez-la à part. Le nœud Calque d’un graphe d’asset peut désigner shadow, et une Superposition la place sous le sprite dans une seule planche (Graphe d’asset).

Cycle de couleurs à l’exécution

Avec des matériaux à cycle, le JSON liste chacun sous meta.pixor.cycles ("material" et ses "indices" dans la palette, dans l’ordre du cycle), et Pixor écrit name_index.png, la planche en indices de palette. Un moteur peut faire tourner ces entrées de palette à chaque tick au lieu de stocker plus d’images. Les autres matériaux qui partagent les mêmes nuances tournent avec eux, comme dans tout cycle de palette ; donnez à un matériau à cycle ses propres couleurs pour le garder à part.

Scènes à plusieurs modèles, et arrière-plans en parallaxe

Un projet peut contenir plus d’une chose : des modèles disposés sur un plan de sol et rendus en une seule image, avec une seule lumière et des ombres de l’un sur l’autre — un coin de village, une salle de donjon, un campement, une illustration de page de boutique tirée de la bibliothèque gratuite.

Chacun est un élément : un modèle, l’endroit où il se tient, la direction dans laquelle il regarde et sa taille — un nœud Élément du Graphe de scène, ajouté au bout de sa chaîne, qu’un anneau ou une dispersion placés après lui répètent. En ligne de commande, chaque --item en est un :

pxr project new camp.pixor \
  --item tent.glb@-1.8,-1.6,25,1.2 \
  --item campfire.pixoritem@0,0 \
  --item barrel.glb@2,1,0,1,2 \
  --ground 7,5,#5d7a45 \
  --size 200
pxr render camp.pixor

@x,z[,yaw[,scale[,layer]]] indique où se trouve un élément (en mètres, x vers la droite, z vers la caméra) ; --ground W,D[,#rrggbb] place un plan de sol sous les éléments. Ajoutez :clip[,phase] et cet élément joue un clip à lui, à son propre point du clip, tandis que ceux d’à côté restent immobiles. Les chemins sont relatifs au projet.

Les calques de parallaxe (un nœud Fichier Calques de parallaxe, de 2 à 8 calques, ou --parallax N) découpent l’image par profondeur en calques pour un arrière-plan défilant : chacun est rendu seul sur la même scène et la même palette, et les calques lointains s’estompent, plus sombres et plus bleus, vers la couleur de brume (--haze), comme le fait la distance (Brumer les calques lointains désactivé, ou --haze none, garde chaque calque sur la palette tel quel, pour un jeu dont la palette est fixe). Le calque d’un élément le place dans un calque (0 est le plus lointain) ; les autres sont répartis selon la profondeur. Pixor écrit name_layer0.png, name_layer1.png, …, name_parallax.json (l’image de chaque calque et une vitesse de défilement suggérée, de 0.25 pour le plus lointain à 1 pour le plus proche) et name_parallax.png, les calques empilés. N’importe quel modèle peut être découpé, pas seulement une scène à plusieurs modèles. Le nœud Calque d’un graphe d’asset désigne un calque par layer0, layer1, … pour le mettre sur une planche de sa propre composition (Graphe d’asset). pxr project set --parallax N --haze #rrggbb|none règle les deux sur un projet.

Modes de la console

Pour le homebrew et les consoles virtuelles, choisissez une Console sous Style (ou --console). Pixor utilise alors les couleurs de la console et ses limites :

Console	Couleurs	Par sprite	Notes
Game Boy	les 4 nuances de vert	3 + transparent	nuances par luminosité
NES	la palette maîtresse de 54 couleurs	3 + transparent	vérifié aussi par tuile de 8 × 8
PICO-8	son 16	les 16	exporter une cartouche .p8 (cochez p8 ; la planche doit tenir dans 128 × 128 : réglez une largeur maximale de 128)
TIC-80	son 16 (Sweetie 16)	les 16	importez le PNG avec import sprites de TIC-80
C64	son 16	3 + transparent	sprites multicolores : pixels deux fois plus larges ; gardez une largeur paire (les sprites C64 font 24 px)

Là où un sprite ne peut utiliser que trois couleurs, Pixor choisit les trois couleurs de la console qui couvrent le mieux votre modèle en ombre, couleur de base et lumière, pour que chaque image et chaque côté utilisent les trois mêmes. La section Style indique si l’image à l’écran est conforme ; pxr console check sheet.png vérifie toute une planche (couleurs, couleurs par image et par tuile, paires double largeur, taille) et lit la console dans la recette contenue dans la planche. Chaque rendu en mode console effectue la même vérification sur la planche qu’il a écrite, et échoue (code de sortie 1, avec la liste des problèmes) quand elle n’est pas conforme. Une palette à vous est conservée en mode console, pas remplacée par celle de la console — une palette de seize couleurs sur une Game Boy est donc signalée haut et fort, plutôt que remplacée en silence par les quatre verts. Les couleurs de la NES sont calculées par Pixor à partir du signal vidéo de la console, les autres sont les valeurs publiées des consoles.

Un éclairage fidèle à la palette dans les moteurs

Les moteurs éclairent les sprites à partir de cartes de normales avec un ombrage lisse, ce qui fait apparaître des couleurs que votre palette n’a jamais eues. Cochez Kit de lumière (ou --export light-kit) et les sprites réagissent à la lumière du jeu tandis que chaque pixel éclairé reste sur un cran de sa propre rampe de couleurs, avec les bandes, le décalage de teinte et les reflets de Pixor. Pixor écrit, à côté de la planche :

Fichier	Ce que c’est
name_ramps.png	la rampe de couleurs de chaque pixel (numéro de rampe + 1 en rouge ; 0 pour les pixels que la lumière ne touche pas, comme les traits)
name_normal.png	les normales, en espace vue : x vers la droite, y vers le haut, z vers la caméra
name_light.png	la texture de correspondance : une ligne par rampe, une colonne par niveau de lumière, puis la couleur du reflet, puis deux colonnes qui ne sont pas du tout des couleurs — les seuils de reflet propres à cette rampe, car un matériau brillant ou métallique prend son reflet plus facilement qu’un matériau mat
pixor_palette_light.gdshader, name_light.tres	le shader Godot et un matériau avec chaque texture réglée : mettez le matériau sur un Sprite2D ou un AnimatedSprite2D
PixorPaletteLight.shader	le shader Unity : créez avec lui un matériau pour un SpriteRenderer et réglez ses trois cartes
pixor_palette_light.fsh, .vsh	le shader GameMaker ; les commentaires montrent comment lier les cartes

Les shaders éclairent avec une lumière principale (light_dir, vers la lumière, dans l’espace des normales), la lumière d’appoint du préréglage, et des reflets spéculaires et de contour dont les seuils viennent de la texture de correspondance, par rampe, comme le faisaient ceux de Pixor. Régler specular ou rim sur un nombre entre -1 et 1 les remplace pour tout le sprite ; au-dessus de 1, ces reflets sont désactivés ; en dessous de -1 (par défaut), ce sont ceux de la texture de correspondance. Un reflet n’est dessiné que là où l’un des quatre pixels voisins en a un aussi, c’est la règle de Pixor contre un pixel clair isolé — min_highlight 1 la désactive. Déplacez la lumière depuis un script, par exemple vers une torche : material.set_shader_parameter("light_dir", dir). Importez les trois cartes sans filtrage, sans compression et sans mipmaps. Pour le voir avant d’exporter, activez l’Aperçu de l’éclairage 2D (L) sur le sprite et choisissez Éclairer comme : le kit d’éclairage : la lumière se tourne vers le pointeur et l’image est éclairée à travers la même texture de correspondance, selon les mêmes règles (reflets seulement à côté d’un autre, pixels sans rampe intacts), comme l’éclairent les shaders. Avec la lumière du rendu, une image apparaît exactement comme Pixor l’a dessinée (à quelques pixels près aux bords des bandes) ; les ombres portées, le tramage et le lissage du scintillement des planches animées sont propres à Pixor : désactivez donc les ombres portées pour les planches que vous éclairez dans le moteur. Le JSON liste les fichiers et la lumière sous meta.pixor.light_kit.

Variantes de palette

Ajouter une variante (--variant NAME, répétable) exporte la même planche dans d’autres couleurs. Pixor dessine en indices de palette, si bien qu’une variante ne change que la palette : chaque pixel, trait et nuance reste à sa place.

• Effets : hit-flash, frozen, poisoned, petrified, burning, silhouette, selected, les heures du jour dawn, noon, dusk, night, et les saisons autumn et winter (les verts deviennent orange, ou pâles et enneigés).
• Couleurs d’équipe : team:blue (ou red, green, yellow, purple, orange, teal, pink, white, black, ou team:#3050e0) ne recolore que la couleur d’équipe — les matériaux ou couleurs marqués avec --team ou sous Matériaux — et laisse la peau, l’acier et l’or tels quels. Chaque nuance garde sa luminosité, si bien que la rampe se lit toujours. Quatre équipes à partir d’un seul sprite : --team cloth --variant team:red --variant team:blue --variant team:green --variant team:yellow. Le JSON liste les indices de palette de l’équipe sous meta.pixor.team, pour les moteurs qui recolorent à l’exécution via la texture de correspondance ci-dessous.
• Chaque couleur tournée : hue:120 fait tourner chaque nuance colorée de 120 degrés ; les gris restent gris.
• Autres palettes : palette:pixor-8 ou palette:my-colours.hex ramène chaque couleur à la plus proche de cette palette, en gardant clairs et sombres séparés.

Chaque variante est name_<variant>.png. Avec une variante, quelle qu’elle soit, Pixor écrit aussi deux fichiers pour changer de palette à l’exécution, si bien qu’une seule planche sert pour chaque rang et chaque équipe :

• name_index.png : la planche avec l’indice de palette de chaque pixel sous forme de valeur de gris (0 est transparent) ;
• name_lut.png : une texture de correspondance de 256 pixels de large, une ligne par palette (la ligne 0 pour celle de la planche, la ligne k pour la variante k).

Un shader consulte lut(index / 255, row). Le JSON liste les variantes et leurs lignes sous meta.pixor.variants.

La recette dans chaque export

Chaque fichier exporté par Pixor se souvient du projet qui l’a créé : la planche, ses planches de calques et ses cartes (_lines, _flat, _normal, _depth, _emission, _shadow), ses variantes de palette et sa planche d’index, le .aseprite, et chaque GIF (dans un commentaire) et APNG. Déposez n’importe lequel sur Pixor (ou choisissez-le dans Ouvrir un projet…) pour récupérer le projet : le fichier .pixor s’il est toujours là, ou un nouveau projet reconstruit à partir de la recette. Les chemins sont enregistrés relativement au fichier exporté ; un chemin qui ne peut pas être rendu relatif ne garde que son nom de fichier, si bien qu’une planche que vous partagez ne montre pas les noms de vos dossiers. Décochez Recette dans les fichiers (ou passez --no-recipe) pour la laisser de côté.

Godot 4

1. Copiez name.png et name.tres dans votre projet, côte à côte.
2. Le .tres charge la planche depuis res://name.png. Si vous la placez ailleurs, passez --godot-path res://path/name.png lors de l’export en ligne de commande, ou modifiez le chemin en haut du .tres.
3. Créez un AnimatedSprite2D et réglez ses Sprite Frames sur name.tres. Chaque action et chaque côté est une animation, en boucle, avec ses tenues d’image.
4. Pour des pixels nets, réglez Texture > Filter sur Nearest.

Unity

• Avec le paquet Aseprite Importer (2D Aseprite Importer) : déposez name.aseprite dans Assets. Chaque tag devient un clip d’animation ; utilisez le calque final.
• Sans lui : importez name.png comme Sprite (Multiple), Filter Mode Point, Compression None, et découpez-le par taille de cellule (la taille de cellule est dans name.json sous meta.pixor.cell). Le pivot est dans meta.pixor.pivot, en pixels depuis le coin supérieur gauche de la cellule.

GameMaker

Importez name.png comme bande de sprites : utilisez un export avec la disposition Bande (--layout strip) par animation, ou découpez la grille par taille de case. Placez l’origine sur le pivot indiqué dans name.json.

Aseprite

Ouvrez name.aseprite, ou cliquez sur Ouvrir sur le nœud de fichier Aseprite (Pixor trouve Aseprite dans le PATH et dans les dossiers Steam et itch habituels, et sinon demande où il se trouve). Les tags listent chaque action et chaque côté. Le calque final est visible ; lines et flat sont des calques d’aide masqués pour les retouches à la main, tout comme chaque sortie supplémentaire nommée par le graphe de Style, au-dessus de final. Le fichier est en mode indexé avec la palette de Pixor.

Peignez par-dessus sans perdre votre travail. Ajoutez vos propres calques et peignez, puis modifiez le modèle ou le look dans Pixor et refaites le rendu :

pxr rebake out/hero.aseprite

Pixor ne possède que ce qu’il a écrit, rien d’autre. Un nouveau rendu refait le rendu du projet et :

• remplace les pixels des calques produits par Pixor (final, lines, flat), là où personne n’a peint dessus ;
• laisse vos calques exactement tels qu’ils sont — jamais déplacés, renommés, réordonnés ni recolorés — avec chaque cel peint sur l’image où il a été peint. Chaque image porte un identifiant tiré de ce qu’elle est (action, côté, instant) : si la marche gagne trois images au milieu, vos yeux peints restent sur leurs propres poses au lieu de glisser sur les nouvelles — et le nouveau rendu le signale, image par image : moved your paint on frame 1 is on frame 2 now, et indique quelles images sont nouvelles (moved et new_at dans --json) ;
• garde chaque couleur avec laquelle vous avez peint à son indice, en ajoutant les nouvelles couleurs à la fin de la palette — ou, sur une planche que vous avez passée en niveaux de gris ou en RVB dans Aseprite, écrit le rendu en gris ou en couleurs pour correspondre ;
• garde vos slices, leurs clés sur les images où elles étaient, où que ces images soient allées ;
• marque d’un tag les images où le modèle s’est déplacé sous vos retouches, pxr check, et laisse les retouches là où elles sont.

Deux choses qu’il ne décide pas seul, et dont il garde les deux jusqu’à ce que vous décidiez :

Ce qui s’est passé	Ce que fait le nouveau rendu
Vous avez peint sur l’un des calques de Pixor	Le calque de Pixor reçoit le nouveau rendu ; votre retouche passe sur un calque à vous, final edits, juste au-dessus ; l’image reçoit le tag pxr conflict
Une image que vous avez peinte ne figure pas dans le nouveau rendu (le clip a raccourci)	l’image est conservée à la fin, avec vos retouches, marquée du tag pxr removed

Rien n’est perdu dans un cas comme dans l’autre. pxr rebake sort alors avec le code 7 tant que vous n’avez pas dit dans quel sens trancher : --resolve keep garde vos retouches comme calques à vous, --resolve pixor prend le rendu de Pixor et les abandonne. --dry-run dit ce que ferait un nouveau bake sans rien écrire, et --json le dit pour un outil ; l’extension vous pose la même question dans une boîte de dialogue.

GIF et APNG

Chaque action et chaque côté devient un fichier en boucle (un clip qui ne boucle pas se joue une fois). Les images utilisent la palette du sprite, avec l’index 0 transparent. Échelle, sur le nœud GIF ou APNG (--anim-scale K), les agrandit d’un nombre entier, de 1 à 16, pour qu’un sprite de 64 px puisse sortir en GIF de 256 px avec chaque pixel toujours net.

Le GIF stocke les délais en centièmes de seconde : le délai de chaque image est donc arrondi, mais la durée totale du clip est conservée. Les navigateurs affichent les délais inférieurs à 20 ms comme 100 ms, donc aucune image de GIF ne dure moins de 20 ms : au-delà de 50 ips, le GIF laisse de côté les images qui s’afficheraient moins longtemps, et dure aussi longtemps que le clip. L’APNG stocke les millisecondes exactes, arrondies sur le total cumulé comme dans le JSON, si bien que les images d’un clip à 12 ips durent 83 et 84 ms. Renommez un fichier .apng en .png si un site n’accepte que le PNG. Un clip dessiné par le nœud Calque d’un graphe d’asset anime ce calque — les traits seuls, les couleurs unies — tel que la planche le montre ; un Calque des cartes de normales, de profondeur ou d’émission anime le sprite, car un GIF ne contient que des couleurs de palette.

Vidéo

Vidéo par clip écrit chaque action et chaque côté sous la forme name_walk_Southeast.avi : un AVI non compressé, en couleurs 24 bits, que tout éditeur et convertisseur ouvre et qui ne perd rien — aucun codec ne bave sur un pixel. Son nœud a trois réglages :

• Échelle (de 1 à 16, 4 au départ) : combien de pixels vidéo vaut un pixel d’art.
• Images par seconde (1 à 100, 30 au départ) : une vidéo tourne à une seule cadence, si bien qu’une image de sprite est écrite autant de fois qu’elle dure, et le clip garde sa durée à une image vidéo près.
• Arrière-plan : ce qu’il y a derrière le sprite. Une vidéo n’a pas de transparence.

--export video en ligne de commande prend les valeurs de départ, ou --video-scale K, --video-fps N et --video-background #RRGGBB. --export all laisse les vidéos de côté : nommez-les.

Elle n’est pas compressée, donc elle est lourde — un sprite de 64 px à l’échelle 4 pèse environ 200 Ko par image — et une vidéo de plus d’un gigaoctet est refusée plutôt qu’écrite. Pour la mettre en ligne, convertissez-la : ffmpeg -i hero_walk_South.avi -crf 0 hero_walk_South.mp4.

Moteurs simples et votre propre code

Lisez name.json : frames[i].frame est le rectangle de la case et frames[i].duration sa tenue en millisecondes ; meta.frameTags regroupe les images en animations, et un tag qui se joue une fois au lieu de boucler porte "repeat": "1", comme l’écrit Aseprite. frames[i].pixor indique le tag de l’image (le nom de son tag d’images), son index dans ce tag, son action et son side, son id, et son pivot — le point de la case sur lequel le moteur pose le sprite, qui est celui de la planche sauf si un nœud Tag a donné au clip le sien. La slice de pivot dans meta.slices a une clé partout où le pivot change, et la slice de pivot du fichier .aseprite a les mêmes clés.

Root motion

Un clip exporté Sur place a deux valeurs de plus par image, en pixels avec les fractions conservées (x vers la droite, y vers le bas) :

• frames[i].pixor.root : là où serait la racine du modèle, mesurée depuis sa position au début du clip.
• frames[i].pixor.root_delta : de combien la racine se déplace jusqu’à l’image suivante. Pour la dernière image, c’est le déplacement jusqu’à la fin du clip, si bien que les marches en boucle continuent à la même vitesse.

Pour déplacer le personnage comme le faisait le clip, ajoutez root_delta à la position du sprite à la fin de chaque image.

Icônes d’inventaire

pxr icons (ou un nœud Icônes dans le graphe d’asset, produit à l’export du projet) transforme des modèles en icônes d’inventaire assorties : chaque modèle vu sous le même angle ¾ avec l’éclairage Studio, à 16, 24, 32 et 48 pixels (ou --sizes), avec la silhouette dans la couleur de sa rareté (--rarity common|uncommon|rare|epic|legendary) et, avec --framed, sur une tuile encadrée comme un emplacement d’inventaire. Chaque icône est un PNG, et chaque taille reçoit un atlas icons_N.png avec un icons_N.json indiquant où se trouve chaque icône. Pointez-le vers un dossier pour transformer tout un pack en jeu d’icônes — dans l’application, déposez le dossier sur la fenêtre et activez Des icônes au lieu de sprites : les tailles, la rareté (d’après le nom de chaque fichier, sauf si vous en choisissez une) et le cadre s’y trouvent, et la recette est enregistrée à côté des icônes sous icons.pixoricons :

pxr icons library/pickups --out icons --rarity epic --framed

--rarity from-name donne à chaque modèle la rareté qu’indique un mot de son nom de fichier (potion_rare.glb, Sword-Epic.glb ; sans un tel mot, il est commun), et le JSON indique celle de chaque icône. Les fichiers sont pris dans l’ordre des noms, si bien que l’atlas est le même quel que soit l’ordre dans lequel le dossier les liste.

Une recette conserve le pack : --save pack.pixoricons écrit les dossiers et les réglages (chemins relatifs à la recette), et pxr icons pack.pixoricons refait le pack, octet pour octet. Un accessoire ajouté au dossier rejoint l’exécution suivante ; une option placée après la recette modifie un réglage pour cette exécution (pxr icons pack.pixoricons --sizes 64).

Voxels et piles de sprites

Un .vox MagicaVoxel s’ouvre comme n’importe quel autre modèle : chaque modèle de sa scène à l’endroit où le place le graphe de scène (tourné et déplacé comme le montre MagicaVoxel), sa palette, et les voxels d’un matériau lumineux qui brillent. Un voxel est lu comme un dixième de mètre, +Z vers le haut.

pxr voxels MODEL -o hero.vox --height 32 transforme n’importe quel modèle en voxels, de 32 de haut : la surface échantillonnée à partir de ses textures et de ses couleurs, l’intérieur rempli, chaque voxel dans la palette propre au look (--preset, --palette et les autres options de look), pour que les voxels correspondent aux sprites. Avec --stack, il écrit aussi une pile de sprites : hero_stack.png, le modèle découpé en tranches horizontales côte à côte, en commençant par le bas, chacune vue de dessus, et hero_stack.json avec la taille et le nombre de tranches. Un jeu dessine la tranche k un pixel au-dessus de la tranche k - 1 et les fait toutes tourner ensemble : c’est ainsi que le sprite stacking simule la 3D.

pxr voxels knight.glb -o knight.vox --height 32 --stack --preset selout

Vérifier que tout correspond

pxr audit folder --style game.pixorkit lit chaque PNG et chaque fichier .aseprite exportés d’un dossier et les compare au kit, à l’aide de la recette contenue dans chaque fichier : préréglage, éclairage, vue, inclinaison de la caméra, lumière principale, bandes de lumière, traits, palette et pixels par mètre, et vérifie que chaque couleur utilisée est dans la palette du kit. Sans kit, le premier fichier sert de référence. Chaque différence est listée ; toute différence donne le code de sortie 1, ce qui permet de protéger un build.

Dans l’application, le tableau de cohérence (le bouton aux trois silhouettes, Tableau de cohérence : tous les côtés à la fois, ou B) montre l’image actuelle de chaque côté, côte à côte sur une même ligne de sol, avec le sommet de chaque silhouette marqué et sa largeur, sa hauteur et son nombre de couleurs en dessous. Sous le bouton :

• Silhouettes dessine chaque côté réduit à sa forme, d’une seule couleur : une pose qui ne se lit pas en silhouette ne se lit pas à la taille du jeu.
• Pivots marque le pixel sur lequel chaque côté se tient et autour duquel il tourne. Un côté dont les pieds n’y sont pas glisse quand le sprite tourne.
• Nombre de couleurs écrit le nombre de chaque côté ; le tableau signale quand les hauteurs diffèrent de plus d’un pixel entre les côtés (Les hauteurs diffèrent … entre les côtés), ou quand un côté a plusieurs couleurs de plus qu’un autre (généralement une lumière qu’un seul côté reçoit).

pxr audit ci-dessus est la moitié à l’échelle du dossier : chaque planche comparée à un seul kit.

Ce qu’ont trouvé les vérifications, sur les pixels concernés

Chaque vérification de Pixor — pixels isolés, coins de traits dessinés d’un seul pixel, traits épais, couleur hors palette, tuile ou image avec plus de couleurs que n’en permet un mode console — marque les pixels concernés au lieu de simplement afficher une ligne de texte au moment de l’export.

• Dans l’application : le bouton Vérifications au-dessus du sprite (le triangle d’avertissement) dessine les marques sur l’image, et la section Rapport des étapes Style et Asset liste chaque constat de chaque image rendue jusque-là. Cliquez sur l’un d’eux et Pixor va à cette image et à ce côté, marques affichées. Sous la liste, chaque type de constat indique quel réglage en décide — les pixels isolés le nettoyage, les coins dentelés les traits, les couleurs la palette, les limites de console le mode console, un côté retourné qui ne correspond pas au miroir de l’export — et Aller au réglage ouvre ce réglage.
• Côtés en miroir : avec un nœud Retourner dans le graphe d’asset, un côté qui sera dessiné retourné est comparé à celui qu’il retourne, et là où le modèle n’est pas assez symétrique pour cela, les pixels qui changent sont marqués, pendant que vous choisissez encore — pas seulement un avertissement à l’export.
• À l’export : cochez report (ou --export report) et Pixor écrit name_report.png à côté de la planche : la planche avec chaque constat marqué. Les pixels isolés sont remplis ; une tuile ou une image est encadrée, pour que ce dont il s’agit reste visible au travers.

Couleur	Quoi
cyan	un pixel isolé (un orphelin)
jaune	un trait qui tourne un coin en un pixel
magenta	un bloc de trait de deux sur deux : un trait épais
rouge	un pixel hors palette
orange	une tuile de 8 x 8 avec plus de couleurs que la console n’en permet
orange foncé	une image avec plus de couleurs que la console n’en permet
rose	une couleur que la console n’a pas
violet	un pixel qui diffère du côté dont il est le miroir
boîte verte	une partie dessinée dans sa couleur unie parce que son fichier de texture manque : placez le fichier à côté du modèle

Effets de pixels

Un nœud Effet du graphe de scène (listé sous Effets dans l’Arborescence) ajoute un effet dessiné à partir de particules 3D : Explosion, Hit-spark, Slash, Magic-burst, Heal, Portal, Smoke-puff, Dust, Fire-loop, Rain, Snow, Fireflies et Falling-leaves. Chacun est sa propre action (fx-explosion, …), rendue par le même pipeline que le modèle : il prend la palette, la taille de pixel, la lumière et les traits du sprite, et semble appartenir au même jeu. Réglez ses images, sa taille, son énergie, sa position et sa graine (la même graine donne toujours les mêmes pixels) ; faites-lui suivre un os (une entaille partant de la main, un éclair à la bouche d’un canon) et jouez-le sur un clip (le coup d’épée sous l’entaille, ou un clip à clés créé dans Pixor) ; cochez Effet uniquement pour le dessiner sans le modèle, comme un calque à part aligné sur la planche du personnage. Image d’impact marque l’image où le coup porte : le JSON la liste sous meta.pixor.hits. En ligne de commande : --effect fireflies:12 --effect-clip shatter --effect-hit 6, le clip pouvant lui aussi être créé dans Pixor — des éclats animés par clés qui volent sous les paillettes. Créer un effet sur l’écran d’un projet vide, à côté de Importer… et Parcourir les modèles gratuits (ou pxr effect explosion -o fx.png), crée un effet sans aucun modèle.

Hitboxes, hurtboxes et points d’attache

La Boîte d’une partie dans l’Inspecteur (ou --hitbox, --hurtbox) en fait une hitbox (elle porte des coups : une épée) ou une hurtbox (elle peut être touchée : le corps), et le Point d’attache dans le JSON d’un os (ou --socket) en fait un point d’attache (une main, une bouche de canon). Le JSON de chaque image contient alors pixor.boxes (part, kind, x, y, w, h en pixels de cellule, d’après les pixels que chaque partie couvre réellement) et pixor.sockets (la position de chaque os en pixels de cellule), si bien que le code du jeu peut vérifier les coups et attacher des effets sans deviner. Un fichier de modèle peut aussi marquer des parties (pxr.box).

Calques paper doll

Avec des accessoires attachés, Calques paper doll (--paper-doll) écrit aussi name_base.png, le modèle sans ses accessoires sur le même canevas, et un calque par accessoire (name_sword.png), ses pixels visibles avec les traits qui les entourent. Empilés en commençant par la base, ils donnent la planche complète ; échanger le calque d’un accessoire change l’équipement. name_stacked.png est leur empilement dans cet ordre, comme le moteur les empilera : l’aperçu qui montre qu’ils s’alignent. Les pixels de chaque pièce sont ceux de la planche elle-même ; la base est le corps dessiné sans les pièces : elle ne diffère donc de la planche qu’à quelques pixels du bord d’une pièce, et là où une pièce projette une ombre sur le corps — désactivez les ombres portées (--no-shadow) pour des calques qui s’empilent exactement. Les lignes qu’un nœud Sprites dessine avec un jeu de parties appartiennent à la propre planche de ce nœud, pas aux calques. (L’application les produit avec pxr à partir du projet enregistré, en l’enregistrant d’abord s’il a changé : les calques sont donc ce qui est à l’écran.)

Un équipement qui fait partie du modèle — un casque, un bouclier, une cape modélisés avec le personnage plutôt qu’attachés comme accessoire — est une pièce :

pxr render knight.glb --clip all --paper-doll --piece helmet:Knight_Helmet --piece gear:Round_Shield,1H_Sword
pxr project set knight.pixor --paper-doll --piece helmet:Knight_Helmet

Chaque pièce nomme les parties qui la composent (telles que l’Arborescence les liste) et devient un calque à part, name_helmet.png, exactement comme celui d’un accessoire (dans l’application, Son propre calque de paper doll sur une partie en fait une, nommée d’après elle) : seuls ses pixels visibles, si bien qu’un bouclier derrière le corps est masqué là où le corps le cache. La base est rendue sans aucune pièce ni aucun accessoire, donc ce qu’un casque couvrait — la tête en dessous — y est dessiné. --no-pieces les retire d’un projet. Le nœud Calque d’un graphe d’asset nomme base ou une pièce ou un accessoire par son nom comme calque, pour disposer les calques à sa guise (Graphe d’asset).