Ligne de commande

pxr rend les mêmes sprites que l’application (le même projet donne les mêmes pixels) et convient aux scripts de build et au traitement par lots. pxr help affiche chaque commande et option, pxr help COMMAND une commande avec ses options, et pxr --version la version. Une ligne de commande qu’il ne peut pas lire lui fait dire ce qui ne va pas, comment s’utilise cette commande, et de consulter pxr help COMMAND.

Tâches courantes

# One sprite, 64 px, three-quarter view
pxr render knight.glb -o knight.png

# Every clip, 8 sides, 12 fps, all export formats
pxr render knight.glb --clip all --ring 8 --export all -o out/knight.png

# Two clips, hand-picked frames for the attack
pxr render knight.glb --clip walk --clip attack --keys 0,0.2,0.35,0.6 -o out/knight.png

# A different look
pxr render knight.glb --preset selout --view isometric --light -30,50 --bands 4 --aa 1 -o knight.png

# Your palette
pxr render knight.glb --palette my-palette.hex -o knight.png

# Save the settings as a project, then render it again later (or open it in the app)
pxr render knight.glb --clip all --ring 8 --export aseprite -o out/knight.png --save-project knight.pixor
pxr render knight.pixor

# A whole folder, every clip of every model, with a report
pxr batch models/ --recursive -o out/ --ring 8 --export all

Un projet est sa propre recette : en faire le rendu lit le look et la scène depuis le projet, et ne prend de la ligne de commande que l’endroit où vont les fichiers (-o, --export, --names, --scale, --anim-scale, --no-recipe, --debug), les calques supplémentaires (--paper-doll, --piece, --parallax, --haze), le moteur de rendu et le pipeline d’asset qu’il écrit. Toute autre option est signalée par un avertissement, puisqu’elle ne changerait rien : réglez-la dans le projet avec pxr project set.

Quel pipeline d’asset. pxr render project.pixor écrit le premier pipeline d’asset du projet, comme la fenêtre d’export de l’application écrit celui qu’on y choisit, qui est au départ celui de l’en-tête ; --pipeline NAME en écrit un autre, et --pipeline all tous. Un fichier porte le même nom quel que soit le pipeline écrit, donc --pipeline all écrit exactement les fichiers que les pipelines écrivent un par un. pxr names, pxr watch et pxr run acceptent aussi --pipeline.

Où vont les fichiers. -o PATH (ou --out PATH ; chaque commande accepte les deux) est l’endroit où une commande écrit. Pour une commande qui écrit un seul fichier — render, stylize, effect, voxels, tiles, shapes, rebake, project blueprint, project set (la planche du projet) —, c’est ce fichier, ou un dossier où le fichier va sous son propre nom quand le chemin se termine par / ou est un dossier existant : pxr render knight.glb -o out/ écrit out/knight.png. Un projet rendu avec -o écrit chaque fichier dans ce dossier (D51) : le dossier des planches du projet (out/ par défaut) devient ce dossier, un chemin situé dessous garde sa place en dessous, et tout autre chemin sa dernière partie — archives, animations et icônes comprises. La fenêtre d’export de l’application exécute exactement pxr render PROJECT --pipeline NAME -o FOLDER, sur une copie du projet tel qu’il est ouvert, enregistré ou non, nommée comme le projet ; --recipe-project FILE.pixor (ou none pour un projet sans titre) est ce que la recette de la copie nomme à la place de la copie. Les commandes qui écrivent de nombreux fichiers — batch, golden, gbuffer, stages, icons, run --jobs — prennent un dossier.

Les fichiers de clips placés à côté d’un modèle et nommés <model>@<clip>.<ext> sont ajoutés automatiquement. D’autres fichiers avec le même squelette peuvent être ajoutés avec --anim FILE.

Commandes

Commande	Opération
pxr render MODEL | PROJECT.pixor	un sprite, ou une planche quand des clips, des côtés ou des actions sont demandés ; un projet écrit une planche par groupe de caméras cadrées ensemble
pxr stages MODEL -o DIR	une image de chaque étape du pipeline (albedo, normales, profondeur, couverture, lumière, bandes, bords, traits, nettoyage, lint…), --only edges,lines pour certaines ; --node N écrit à la place ce que produit le nœud N du graphe de Style sous le nom KIND.still.png (l’écran d’un CRT) : une image fixe, jamais un sprite ni une planche
pxr batch FOLDER -o DIR	chaque modèle d’un dossier (.gltf, .glb, .fbx, .obj, .vox ; --recursive pour les sous-dossiers) ; les modèles en échec sont signalés et ignorés ; DIR/report.json ; --blueprint B.pixorblueprint fait passer chaque modèle par un même plan de projet ; --cache DIR sert les modèles qui n’ont pas changé (voir bibliothèques). Dans l’application, déposez le dossier sur la fenêtre
pxr run BLUEPRINT.pixorblueprint --in model=M	un plan de projet avec ses entrées remplies (voir le graphe de scène) ; --set NODE.SETTING=VALUE change un réglage, --set PIPELINE/NODE.SETTING=VALUE la même chose dans un seul pipeline (--set hold.times=4 le nœud Tenue de chaque pipeline d’asset) ; --jobs TABLE.csv -o DIR exécute une ligne d’un tableau par rendu ; --pipeline NAME|all comme pour render
pxr rebake SHEET.aseprite	refaire le rendu du projet dans une planche sur laquelle vous avez peint, en gardant vos calques et vos modifications (voir Aseprite)
pxr cache stat|gc DIR	ce que contient un cache ; gc --keep 20GiB supprime les rendus les moins récemment utilisés jusqu’à ce qu’il tienne
pxr golden CASES.txt	rendre des cas de test et les comparer à des images stockées (voir ci-dessous) ; --only TEXT exécute les cas dont le nom le contient, --tolerance F accepte une fraction F de pixels différents, -o DIR (target/golden par défaut) est l’endroit où vont les résultats ; --graph les rend plutôt à travers le graphe de nœuds du look — celui du préréglage sous la forme du groupe Pixéliser fourni — et --flat à travers le même graphe avec chaque groupe aplati en atomes ; les deux doivent correspondre aux mêmes images. --cache DIR écrit le sprite de chaque cas dans --out via le cache et compare ce fichier, servi ou rendu ; --no-cache écrit les mêmes fichiers sans lui
pxr bench MODEL	mesurer chaque budget de tests/budgets.txt et indiquer met ou MISSED ; --rounds N (10 par défaut) fait la moyenne des temps sur N exécutions ; --from INFO.json ajoute ceux que mesure l’application
pxr import MODEL --report	ce qui arrive au fichier à l’import, sans le rendre : trouvé, corrigé et pourquoi, suggéré, manquant, triangles par pixel de sprite ; --json pour un lot qui repère d’abord les fichiers défectueux
pxr reference SPRITE.png	réglages lus sur un sprite que vous avez : palette, taille, contour, bandes, décalage de teinte, tramage, chacun avec sa justification ; pxr project set P --match-sprite S.png les applique
pxr voxels MODEL -o OUT.vox	le modèle en voxels, de --height de haut (de 1 à 256), dans la palette du look : un fichier MagicaVoxel ; --stack écrit aussi une pile de sprites (voir Voxels et piles de sprites)
pxr nodes [--graph G] [--json]	chaque nœud des quatre graphes (style, action, scene, asset) tel que ce Pixor les a : ce qu’il fait, ce qu’il prend et donne, chaque réglage avec sa plage et sa valeur par défaut ; --json pour les outils (la référence des nœuds du site web est construite à partir de là)
pxr inspect FILE	ce que l’importateur a trouvé dans n’importe quel fichier qu’importe Pixor (les formats, aussi dans pxr help inspect) : pour un modèle, les objets, matériaux, os, clips, avertissements ; pour un .vdb, ses grilles et leur taille ; pour une image, sa taille ; pour une palette, ses couleurs
pxr gbuffer MODEL -o DIR	les cibles de rendu brutes, pour les rapports de bug ; le dump .pxrg contient les arêtes du maillage quand le look les dessine
pxr stylize DUMP.pxrg	exécuter les passes de pixels sur un rendu enregistré, fil de fer compris
pxr diff OLD NEW	deux dossiers d’export (ou deux planches) : quels fichiers sont nouveaux, ont disparu ou diffèrent, de combien de pixels, et, d’après la recette de chaque fichier, quel réglage ou quelle entrée en est la cause ; --all liste aussi les fichiers identiques, --exact sort avec le code 1 au moindre changement. Deux dumps .pxrg sont comparés cible par cible (--depth-tolerance EPS, --samples N)
pxr adapters	les GPU que Pixor peut utiliser
pxr doctor	ce avec quoi cette machine peut rendre, et si son GPU s’accorde avec la référence CPU
pxr project new|set|show PROJECT.pixor	créer, modifier ou afficher un projet depuis des scripts et des outils : --name NAME le nomme (le nom de l’en-tête, pas celui du fichier ; show l’affiche avec le reste)
pxr project key PROJECT.pixor TARGET CHANNEL	une clé d’un clip créé dans Pixor (--clip, --frame, --value, --how, --remove…), pour qu’un script puisse construire un clip
pxr project bake PROJECT.pixor CLIP	un clip propre au modèle sous forme de clip créé dans Pixor, chaque os ayant une clé à chaque image (--as NAME, --fps F)
pxr project scene PROJECT.pixor [NODE]	le graphe de scène, un nœud à la fois : ring, row, grid, scatter, look-at, vary… ajoutés en bout de chaîne, les options de chaque nœud portant le nom de ses réglages (--count, --radius, --size de Vary, --box d’un Scatter, --bumps de Displace et --hills de Height field en mètres, --times de Subdivide, --how de Select) ; un nœud qui ne prend rien en entrée (object, import) commence la chaîne à la place de l’import nu, et se place à côté d’une chaîne plus longue, fusionné avec elle ; aucun nœud ne l’affiche
pxr project blueprint PROJECT.pixor -o B.pixorblueprint	le projet sous forme de plan de projet, ses fichiers de modèle, de palette, d’accessoire et de volume extraits dans des emplacements nommés
pxr style new KIT --from PROJECT	enregistrer le premier Style d’un projet comme kit de Style
pxr kit show FILE.pixorkit	ce que contient un kit : un groupe de nœuds, un Style, un préréglage ou un pipeline
pxr names PROJECT.pixor [--names T] [--pipeline NAME|all]	les noms qu’écrira le projet et l’identifiant de chaque image, sans rendu, les fichiers de chaque rendu selon leur propre chemin ; deux images sous un même nom, deux rendus sur un même fichier (would be written twice), ou deux fichiers sur un même chemin (la base d’un paper doll et celle du kit d’éclairage, une variante de palette et un calque), sont une erreur ici plutôt qu’un fichier perdu plus tard
pxr graph list|set|add|drop|wire|save|swap|flatten|extra FILE --which scene|action|style|asset	n’importe lequel des quatre graphes depuis un script. --pipeline NAME choisit lequel : une action par son nom, un Style ou un pipeline d’asset, le premier si rien n’est nommé. Affichez-le, changez un réglage, ajoutez un nœud dans la chaîne (ou à côté avec --alone, en y reliant d’autres avec --in SLOT=NODE), supprimez-en un, reliez-en deux avec wire --from N --to M --slot S, enregistrez-le comme kit (save -o KIT.pixorkit : le graphe de Style entier, le graphe de scène, d’action ou d’asset comme un seul nœud, --as-pipeline un pipeline d’asset entier qu’un autre projet utilise avec pxr project set --use-pipeline), insérez un kit de nœuds comme groupe (add --kit KIT) ou à la place d’un nœud (swap --kit KIT), ou écrivez un graphe avec ses groupes développés ; extra --node N --name LAYER fait aussi de l’image d’un nœud de Style un calque des exports, et --drop l’arrête. --node (et --set NODE.SETTING dans pxr run) désigne un nœud par son numéro, son type, le nom d’un groupe, ce que dit son Appelé (un Fichier image, une Planche) ou le nom qu’on lui a donné dans l’application (F2) ; un nœud object est le modèle (of=model), et un élément, une forme ou une image est un nœud à part entière. Les nœuds sprites, frame-range et hold d’un graphe d’asset se règlent comme les autres (--node sprites --set action=walk,Static — action=every-one-except-static est la valeur d’un nouveau nœud, action= toutes les actions, Static compris — --set smart=6, --node frame-range --set from=2 --set to=5, --node hold --set times=2) ; ceux d’une action — clip, bob, spin, merge… — par type ou par numéro, et un nœud ajouté sans --alone joue aussitôt, fusionné avec ce qui est là. Dans le graphe de Style, un nœud arrive relié à rien ; --in SLOT=NODE et wire le raccordent. Une modification qui rendrait un graphe impossible à exécuter est refusée, et le fichier reste tel quel (voir le graphe de scène, le graphe d’asset et les nœuds)
pxr shapes [PROJECT] -o OUT.glb	écrire les formes construites dans l’application sous forme de géométrie, pour un modeleur ou un moteur
pxr icons MODELS... -o DIR	des icônes d’inventaire avec un atlas par taille ; la rareté vient du nom de chaque fichier, et --save garde une recette à relancer (voir Export)
pxr audit FILE|FOLDER... [--style KIT]	vérifier que les planches exportées correspondent : préréglage, éclairage, vue, tangage, lumière, bandes, traits, palette et pixels par mètre, d’après la recette de chaque fichier, et, avec un kit de Style, que chaque couleur est dans sa palette (code de sortie 1 sinon)
pxr watch PROJECT.pixor	réexporter chaque fois que le projet, son modèle ou sa palette change
pxr effect KIND[:FRAMES]	un effet en pixels seul : explosion, hit-spark, slash, magic-burst, heal, portal, smoke-puff, dust, fire-loop, rain, snow, fireflies, falling-leaves
pxr console list|check SHEET.png	les modes console, ou si une planche est conforme à l’un d’eux (code de sortie 1 sinon) ; la console vient de --console ou de la recette de la planche

Options de rendu

Option	Par défaut
--view VIEW	celui du préréglage	side, three-quarter, isometric ou top-down
--pitch DEG	celui de la vue	degrés sous l’horizon
--yaw DEG	0	faire tourner un sprite seul, ou le côté unique d’une planche d’un tel sprite
--camera GENRE		la caméra d’un genre de jeu : platformer, fighting, beat-em-up, adventure, top-down-rpg, action-adventure, isometric, tactics, strategy, racing, top-down-shooter, shmup, icon (vue, tangage, rotation ; taille et côtés sauf s’ils sont indiqués)
--camera-yaw DEG	0	faire tourner la caméra autour du modèle, tous les côtés
--size N	64	tenir dans N x N, de 4 à 2048 ; --size 960x540 tient dans un canevas de cette largeur et de cette hauteur (une image de titre, un fond)
--pixels-per-metre F		nombre fixe de pixels par mètre au lieu de --size, de 0.5 à 4096 (le Pixels/m de l’application)
--up AXIS	décidé à l’import	l’axe qui pointe vers le haut dans le fichier (y, z, -z, x, -x, -y) : pour un modèle exporté couché
--import-scale F, --import-offset X,Y,Z	décidé à l’import	l’unité et le mouvement, indiqués à la main
--no-import-fix		rendre le fichier exactement tel qu’il est, sans rien corriger
--samples N	4	échantillons par pixel sur chaque côté, de 1 à 8 (les Échantillons de l’application)
--light AZ,EL	-45,45	lumière principale relative à la caméra
--light-space S	caméra	monde : la lumière reste fixe dans la scène au lieu de suivre la caméra
--fill F	celui du préréglage	intensité de la lumière d’appoint, de 0 à 1
--no-shadow		pas d’ombres portées
--bands N	celui du préréglage	bandes de lumière, de 1 à 4
--palette P		un fichier .hex, .gpl ou .png, ou une palette intégrée : pixor-16, pixor-8, dusk-12, forest-12, desert-12, ice-10, mono-8
--aa N	0	anticrénelage : 0 désactivé, 1 silhouette, 2 chaque trait
--match-space S	oklab	comment les couleurs trouvent leur plus proche dans une palette fixe : oklab, srgb ou weighted
--dither-pattern P	bayer	bayer (le quadrillage) ou blue-noise (dispersé uniformément) ; les deux restent sur la surface quand le modèle bouge
--even-stairs	désactivé	des bords de silhouette droits aux paliers réguliers (2, 2, 2 plutôt que 3, 1, 2)
--smear PX	0	images de traînée, de 0 à 64 : ce qui a bougé de PX pixels ou plus depuis l’image précédente laisse une traînée
--nudge X,Y	0,0	déplacer le modèle d’une fraction de pixel sur la grille (chacun de -0.5 à 0.5) ; seul l’échantillonnage change
--foot-plant	désactivé	les pieds posés d’un humanoïde sur la même ligne de pixels à chaque image d’un clip
--preset NAME	net	clean, selout, retro4, flat, wireframe, ou un kit de préréglage enregistré (.pixorkit)
--style KIT		un kit de Style (.pixorkit) : un Style entier (pxr style new, Enregistrer le kit… d’un Style), avec son graphe de Style, ou un graphe de Style seul (pxr graph save --which style) ; les options suivantes le modifient encore. Dans un fichier de cas de référence, relatif à celui-ci. pxr icons et pxr audit acceptent la même chose
--dither F	0	tramage ordonné entre bandes de lumière voisines, de 0 à 1
--line-colour HEX	celui du préréglage	couleur des traits Sombre, #rrggbb (palettes automatiques seulement)
--no-lines MATERIAL		pas de traits autour de ce matériau (répétable ; pxr inspect les liste)
--crease-angle DEG	55	à partir de quel angle un pli dessine un trait de pli, de 1 à 179
--depth-step PX	2.5	l’écart de profondeur, en pixels, qui dessine un trait intérieur, de 0.1 à 40 (l’Écart de profondeur de l’application)
--shortest-line N	3	le trait intérieur ou de pli le plus court conservé, de 0 à 16 pixels (le Trait le plus court de l’application)
--no-part-lines		pas de traits entre des parties en contact sans saut de profondeur
--outline-inside		la silhouette sur le bord même du sprite
--convex LINE	aucun	un trait clair sur les plis qui bombent vers la caméra : none, dark ou highlightN
--no-material-channels		ignorer le métal, la rugosité, l’émissif, le non éclairé et la transparence d’un matériau glTF, et ombrer à partir de sa seule couleur
--backend B	auto	auto, vulkan, metal, dx12, gl, webgpu ou cpu (voir Choisir un moteur de rendu)

Options de lumière et de couleur

Option
--rig NAME	un éclairage : noon, dusk, torchlight, moonlight ou studio
--cycle MATERIAL	faire tourner les couleurs de ce matériau sur une action --colour-cycle (répétable)
--team MATERIAL|#RRGGBB	la couleur d’équipe : un matériau, ou chaque rampe de la teinte de cette couleur (répétable) ; --variant team:blue ne recolore qu’elle
--console C	un mode console : gameboy, nes, pico8, tic80, c64 (voir Modes de la console)

Options d’animation

Option
--clip NAME	un clip à rendre (répétez pour en ajouter), ou all
--anim FILE	utiliser aussi les clips de FILE
--ring N	côtés, dans le sens antihoraire depuis l’avant (de 1 à 64, 1 par défaut), nommés Sud, Sud-est, Est… : une caméra chacun, partageant une même taille, dans une seule planche
--sides A1,A2,...	un côté à chaque angle à la place, en degrés (0 = face, 90 = tourné vers la droite)
--fps F	images par seconde du temps du clip (12 par défaut), la découpe de chaque nœud Sprites
--keys T1,T2,...	instants du clip choisis à la main, en secondes, la découpe de chaque nœud Sprites
--clip lib:NAME	un clip de la bibliothèque de mouvements ajusté au squelette du modèle : idle, walk, run, jump, attack, hit, death
--parallax N	découper l’image selon la profondeur en N calques (2–8) pour des fonds défilants (voir Scènes de plusieurs modèles)
--haze #RRGGBB	la couleur vers laquelle s’estompent les calques de parallaxe lointains ; none garde chaque calque sur la palette tel quel
--spring NODE[:S,D,G]	NODE et ce qui se trouve en dessous se balancent avec le mouvement : rigidité, amortissement, gravité (répétable) ; dans un projet, un nœud Ressort du graphe de scène
--smart-frames N	garder N images de chaque clip, choisies parmi ses poses (chacune tenue jusqu’à la suivante), la découpe de chaque nœud Sprites
--root-motion M	keep (par défaut), in-place (fixe l’os racine à l’horizontale) ou in-place-sway (ne retire que le déplacement net du clip)
--turntable N	ajouter une action de N images qui fait faire un tour au modèle
--turntable-seconds S	la durée de ce tour (par défaut : N images à --fps)
--motion M[:N[:A]]	ajouter une boucle : spin, bob, swing, pulse, squash ou flicker, N images, intensité A (pour spin, la fraction de tour que fait la boucle : spin:8:0.125 tourne une gemme à huit facettes d’une facette, une boucle sans couture)
--colour-cycle N	ajouter une action de N images qui fait tourner les nuances des matériaux à cycle
--prop FILE:BONE[@at=X,Y,Z][@turn=X,Y,Z][@scale=S][@grip=NODE]	attacher un autre modèle à un os, tenu par sa poignée, déplacé et tourné selon les axes de l’os (voir Accessoires sur des os)
--shape SPEC	ajouter une forme : [NAME=]KIND[:SIZE[:AT[:#RRGGBB[:TURN]]]], par exemple box:1,0.5,1:0,0.25,0:#c86432, ou wheel=cylinder:0.5,0.2,0.5:0.7,0.25,0.5:#14101c:90,0,0 pour une roue nommée posée sur le flanc (répétable). KIND vaut box, sphere, cylinder, cone, torus, plane, capsule, wedge, pyramid, prism, stairs, arch ou letters (pxr help render les liste à partir de la même liste que lit l’option) : letters correspond aux pixels de la police extrudés en blocs, épelant PIXOR, ou les mots d’un projet, pxr project set --add-shape letters --words WORDS --font NAME (render n’accepte pas --words)
--volume SPEC	ajouter un volume : puff, flame, cloud, mist ou un chemin .vdb, puis [:SIZE[:AT]], puis [:FRAMES[,EVERY[,LOOP]]] pour une séquence .vdb numérotée, puis @BONE pour être porté par un os ou @effect:N par l’émetteur du N-ième effet (Volumes)
--wire LINE	le look fil de fer : none, dark ou seloutN, avec --wire-fill, --wire-hidden, --wire-angle (de 0 à 180), --wire-all-edges et --wire-glow MATERIAL (réglages)
--light-sweep N	ajouter une action de N images qui déplace la lumière
--effect KIND[:N]	ajouter une action d’effet en pixels de N images (voir pxr effect), avec --effect-size, --effect-energy, --effect-seed, --effect-at X,Y,Z, --effect-bone BONE, --effect-clip CLIP, --effect-hit FRAME et --effect-alone
--hitbox PART, --hurtbox PART, --socket BONE	boîtes et positions des os par image dans le JSON (répétable ; voir Export)
--paper-doll, --piece NAME:PARTS	calques paper doll (voir Export)
--item MODEL@X,Z[,YAW,SCALE[,LAYER]][:CLIP[,PHASE]], --ground W,D[,#RRGGBB]	d’autres modèles à côté du premier, chacun un nœud Élément du graphe de scène dans un projet, avec un plan de sol sous eux (voir Export)
--chunks COLSxROWS	écrire une grande carte en blocs aux raccords exacts ; --chunk-margin N (8 par défaut)
--max-flicker F	avertir au-delà de cette part de scintillement (par exemple 0.01) ; dans un cas de référence, échouer
--require-visible OBJECT	avertir si OBJECT disparaît sur une image

Options d’export

Option
--export LIST	séparés par des virgules ou répétés : png, json, aseprite, normal, depth, emission, layers, palette, godot, gif, apng, light-kit, p8, report, video, ou all (tous sauf p8 et video, qui ne sont écrits que s’ils sont nommés) ; le PNG est toujours écrit (voir Export). render, batch, run, watch, project set et tiles (avec ses propres formats) le lisent de la même façon
--layout L	grid (une ligne par action et par côté, par défaut) ou strip
--padding N	pixels transparents entre les cellules, de 0 à 256 (0 par défaut)
--extrude N	répéter les bords des cellules de N pixels vers l’extérieur, de 0 à 64 (0 par défaut)
--pot	taille de planche en puissance de deux
--godot-path RES	où Godot trouve la planche (par défaut res://<png name>)
--anim-scale K	échelle entière des fichiers GIF et APNG, de 1 à 16 (1 par défaut)
--video-scale K, --video-fps N, --video-background #RRGGBB	comment les vidéos sont écrites : échelle de 1 à 16 (4 par défaut), de 1 à 100 images par seconde (30 par défaut), ce sur quoi le sprite est dessiné (noir par défaut)
--trim	réduire chaque cellule à ses pixels (le JSON et le fichier Godot gardent le placement)
--dedupe	stocker une seule fois les images identiques
--max-width N	commencer une nouvelle ligne avant que la planche dépasse N pixels de large (de 0 à 65536 ; 0 : sans limite)
--columns N	N images par rangée, chaque clip enchaînant après le précédent : une planche contact
--max-height N	découper une planche plus haute que N pixels en pages, des clips entiers par page (NAME_1.png, NAME_2.png ; de 0 à 65536)
--variant NAME	exporter aussi une variante de palette (répétable) : un effet comme hit-flash ou night, hue:DEG, team:COLOUR (un nom ou #rrggbb ; nécessite --team), ou palette:NAME|FILE ; ajoute une planche d’indices et une texture de correspondance
--shadow KIND	écrire aussi name_shadow.png : contact ou drop
--names TEMPLATE	comment les fichiers et les clés JSON sont nommés : un modèle à base de {project}, {object}, {action}, {side}, {layer}, {set}, {size}, {index} et {ext}, avec {index:3} complété à trois chiffres (voir Export)
--no-recipe	ne pas stocker la recette (la façon dont la planche a été faite) dans le PNG et le .aseprite
--scale K	agrandir le PNG K fois (aperçus seulement ; pas avec d’autres formats)
--save-project FILE.pixor	écrire aussi cette ligne de commande sous forme de projet
--debug DIR	cibles de rendu, palette, images de lint et de scintillement

Des tests de référence pour votre propre pipeline

Un fichier de cas liste un rendu par ligne : un nom, un chemin de modèle ou de projet (relatif au fichier) et des options.

hero-walk   models/hero.glb --clip walk --ring 8 --max-flicker 0.02
hero-proj   hero.pixor

pxr golden cases.txt --bless enregistre les résultats sous NAME.png à côté du fichier ; ensuite, pxr golden cases.txt échoue dès qu’un pixel change, qu’un sprite présente des problèmes de lint (pixels isolés, coins de traits en L, traits de 2 px), ou qu’une vérification --max-flicker ou --require-visible échoue ; l’erreur indique quels cas ont des pixels différents (leurs NAME.actual.png et NAME.diff.png sont dans target/golden) et lesquels ont échoué à leurs vérifications. --bless enregistre les images même quand une vérification échoue, et sort avec 1 en nommant ces cas. Utilisez-le pour repérer quand une modification de modèle altère vos sprites.

Une bibliothèque, pas une exécution

Un studio refait le rendu des mêmes cinq mille sprites parce qu’une rampe a bougé. Trois choses en font une décision plutôt qu’un travail de toute une nuit.

Un cache qui survit au processus. --cache DIR sur pxr batch et pxr run conserve chaque rendu qu’il produit, avec les fichiers lus et une empreinte de leur contenu : le modèle, les fichiers de clips à côté, les textures que référence un .gltf, les palettes, les kits, les images et les volumes. L’exécution suivante sert chaque rendu dont les fichiers ont toujours la même empreinte, et rend le reste.

pxr batch models/ --cache .pxrcache --out out/     # renders what changed
pxr cache stat .pxrcache
pxr cache gc .pxrcache --keep 20GiB                # least recently used go first

Le cache n’est jamais la source de vérité : --no-cache donne les mêmes octets, un fichier stocké dont le hash ne correspond pas à son nom est rendu à nouveau plutôt que servi, et une nouvelle version de Pixor démarre un nouveau cache plutôt que de faire confiance à l’ancien.

Un fichier de tâches. Un tableau avec une ligne par rendu, une colonne par emplacement du plan de projet, et éventuellement des colonnes name (le dossier de la ligne), out (sa planche sous --out) et NODE.SETTING (un --set pour cette ligne) :

model,name,palette,sprites.fps
heroes/knight.glb,knight,palettes/steel.hex,8
heroes/mage.glb,mage,palettes/robes.hex,

Ici, sheet.pixorblueprint provient de pxr project blueprint sheet.pixor, un projet de heroes/knight.glb avec une palette, donc ses emplacements sont model et palette ; le chevalier est découpé à 8 images par seconde et le mage, dont la case est vide, à la cadence propre du plan de projet. Chaque ligne écrit out/NAME/NAME.png.

pxr run sheet.pixorblueprint --jobs assets.csv --cache .pxrcache --out out/ --jobs-report report.json
pxr run sheet.pixorblueprint --jobs assets.csv --cache /shared/cache --out out/ --rows 400..   # the second machine, of 800 rows

Les chemins sont relatifs au tableau. Une ligne est exactement pxr run avec les --in et --set de la ligne ajoutés, si bien qu’une ligne qui échoue peut être lancée seule. Une ligne en échec n’arrête jamais les autres : le rapport liste chaque ligne en indiquant si elle a été rendue, servie depuis le cache, ou si elle a échoué et pourquoi, et la tâche sort avec 1 à la fin si l’une d’elles a échoué.

Des budgets sous forme d’options. --max-pixels N, --max-memory SIZE et --max-time DURATION s’appliquent par rendu (par ligne, par modèle). Ce que le plan sait déjà — combien de pixels aura une planche, à peu près combien de mémoire elle occupera — est vérifié avant que quoi que ce soit ne soit dessiné ; le temps et la mémoire sont vérifiés entre les images. Un dépassement quitte avec 6 en indiquant de quoi il s’agissait et où le rendu s’est arrêté ; dans une tâche, la ligne échoue pour cette raison et les autres continuent.

pxr run sheet.pixorblueprint --jobs assets.csv --out out/ --max-memory 1.5GiB --max-time 5m --max-pixels 16M

Clips longs. Les images d’un clip sont dessinées, puis finalisées ensemble, puisque les passes qui empêchent un clip de scintiller regardent tout le long. Ce qu’elles lisent est limité à 512 Mio (la moitié de --max-memory quand il est indiqué), quelques côtés à la fois ; un clip trop long même pour un seul côté est conservé sur le disque pendant qu’il est dessiné — sous ~/.cache/pixor/spill, ou PXR_SPILL_DIR — et relu au besoin : les mêmes pixels, plus lentement, et le dossier disparaît avec le rendu.

Codes de sortie

Code
0	succès
1	un rendu, un export, un modèle de lot, une ligne de tâche ou un cas de référence en échec
2	une erreur d’utilisation : le message, l’usage de la commande et see pxr help COMMAND sur stderr
3	une entrée illisible : un modèle, un projet, une palette, un kit, un fichier de cas ou un dump
4	un backend demandé par son nom qui n’est pas disponible
5	une sortie impossible à écrire : un fichier ou un dossier
6	au-delà d’un budget --max-pixels, --max-memory ou --max-time
7	un nouveau rendu qui a conservé des retouches sur lesquelles il ne tranchera pas seul (--resolve keep|pixor)

L’absence totale de GPU n’est pas une erreur : Pixor dessine alors avec son propre rastériseur. Une erreur dit ce qui n’allait pas de la même façon partout : --flag takes A to B, got X.

Choisir un moteur de rendu

--backend auto|vulkan|metal|dx12|gl|webgpu|cpu indique qui dessine la géométrie. Le look — chaque passe sur les pixels — est calculé sur le CPU quoi qu’indique cette option.

• auto (la valeur par défaut) prend ce dont dispose la machine, et se rabat sur le CPU quand aucun adaptateur ne fonctionne.
• cpu est le rastériseur propre à Pixor. Il ne demande ni adaptateur ni pilote, il est dans le binaire, et il dessine les mêmes pixels sur chaque machine — le choix portable pour un pack d’assets ou un build en CI.
• Un moteur de rendu nommé mais absent est une erreur (code de sortie 4), car faire le rendu ailleurs en silence est pire que de le signaler.

La recette de chaque export enregistre quel backend l’a dessiné. pxr doctor affiche les adaptateurs trouvés, celui que Pixor choisirait, les versions des pilotes, et si ce backend dessine la même image que la référence CPU :

adapter  NVIDIA GeForce RTX 3070 Ti (Vulkan, DiscreteGpu) driver NVIDIA 610.57.04
backend  vulkan (NVIDIA GeForce RTX 3070 Ti (Vulkan, DiscreteGpu))
agrees   vulkan vs the CPU reference: coverage 0.00%, ids 0.00%, albedo 0.00% (allowed 1.00%); normals within 0.028 deg, depth within 9.5e-7

Dans l’application, le même choix se trouve dans Préférences › Moteur de rendu › Dessiner les sprites sur le CPU, ou, pour une seule session, pixor --backend B avec les mêmes noms que pxr (cpu, auto, ou un backend GPU par son nom), ce qui laisse la préférence telle quelle. Chacun garde ce qu’il a dessiné : passer à l’autre refait le rendu des images, et revenir en arrière rend les images du premier sans nouveau rendu, tant que rien n’a changé dans la scène.

Pour les outils et les scripts

Ajoutez --json à n’importe quelle commande : la sortie standard porte alors un événement JSON par ligne (progress, wrote, warning, error, done) et le journal lisible passe sur la sortie d’erreur. Les commandes qui lisent au lieu d’écrire donnent aussi ce qu’elles affichent sous forme d’un événement : inspect, adapters, tiles --list (terrains), graph list et graph flatten, et diff de deux dumps.