Kommandozeile

pxr rendert dieselben Sprites wie die App (dasselbe Projekt liefert dieselben Pixel) und eignet sich für Build-Skripte und Stapelarbeit. pxr help gibt jeden Befehl und jede Option aus, pxr help COMMAND einen Befehl mit seinen Optionen und pxr --version die Version. Eine Befehlszeile, die es nicht lesen kann, sagt, was falsch ist, wie dieser Befehl benutzt wird, und verweist auf pxr help COMMAND.

Häufige Aufgaben

# 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

Ein Projekt ist sein eigenes Rezept: Wer eines rendert, liest Look und Szene daraus und nimmt von der Kommandozeile nur, wohin die Dateien gehen (-o, --export, --names, --scale, --anim-scale, --no-recipe, --debug), die zusätzlichen Ebenen (--paper-doll, --piece, --parallax, --haze), das Backend und welche Asset-Pipeline es schreibt. Jedes andere Flag wird in einer Warnung genannt, da es nichts ändern würde: Setze es im Projekt mit pxr project set.

Welche Asset-Pipeline. pxr render project.pixor schreibt die erste Asset-Pipeline des Projekts, so wie das Export-Fenster der App die darin gewählte schreibt, die mit der der Kopfzeile beginnt; --pipeline NAME schreibt eine andere und --pipeline all jede. Eine Datei heißt gleich, egal welche geschrieben wird; --pipeline all schreibt also genau die Dateien, die die Pipelines einzeln schreiben. pxr names, pxr watch und pxr run nehmen ebenfalls --pipeline.

Wohin Dateien gehen. -o PATH (oder --out PATH; jeder Befehl nimmt beides) ist, wohin ein Befehl schreibt. Für einen Befehl, der eine Datei schreibt — render, stylize, effect, voxels, tiles, shapes, rebake, project blueprint, project set (das Sheet des Projekts) — ist es diese Datei, oder ein Ordner, in den die Datei unter ihrem eigenen Namen kommt, wenn der Pfad auf / endet oder ein existierender Ordner ist: pxr render knight.glb -o out/ schreibt out/knight.png. Ein mit -o gerendertes Projekt schreibt jede Datei in diesen Ordner (D51): Der Sheet-Ordner des Projekts (standardmäßig out/) wird zu ihm, ein Pfad darunter behält seinen Platz darunter, und jeder andere Pfad seinen letzten Teil — Archive, Animationen und Icons eingeschlossen. Das Export-Fenster der App führt genau pxr render PROJECT --pipeline NAME -o FOLDER aus, auf einer Kopie des Projekts, so wie es offen ist, gespeichert oder nicht, benannt wie das Projekt; --recipe-project FILE.pixor (oder none für ein unbenanntes Projekt) ist, was das Rezept der Kopie statt der Kopie nennt. Die Befehle, die viele Dateien schreiben — batch, golden, gbuffer, stages, icons, run --jobs —, nehmen einen Ordner.

Clip-Dateien neben einem Modell mit dem Namen <model>@<clip>.<ext> werden automatisch hinzugefügt. Andere Dateien mit demselben Skelett lassen sich mit --anim FILE hinzufügen.

Befehle

Befehl	Tut
pxr render MODEL | PROJECT.pixor	ein Sprite oder ein Sheet, wenn Clips, Seiten oder Actions verlangt sind; ein Projekt schreibt ein Sheet pro Gruppe gemeinsam gerahmter Kameras
pxr stages MODEL -o DIR	ein Bild jeder Pipeline-Stufe (Albedo, Normalen, Tiefe, Abdeckung, Licht, Stufen, Kanten, Linien, Bereinigung, Lint…), --only edges,lines für einige; --node N schreibt stattdessen, was Node N des Style-Graphen erzeugt, als KIND.still.png (der Bildschirm eines CRT): ein Standbild, nie ein Sprite oder Sheet
pxr batch FOLDER -o DIR	jedes Modell in einem Ordner (.gltf, .glb, .fbx, .obj, .vox; --recursive für Unterordner); fehlerhafte Modelle werden gemeldet und übersprungen; DIR/report.json; --blueprint B.pixorblueprint schickt jedes Modell durch einen Blueprint; --cache DIR liefert die unveränderten Modelle aus (siehe Bibliotheken). In der App zieh den Ordner auf das Fenster
pxr run BLUEPRINT.pixorblueprint --in model=M	ein Blueprint mit ausgefüllten Eingängen (siehe den Szenen-Graphen); --set NODE.SETTING=VALUE ändert eine Einstellung, --set PIPELINE/NODE.SETTING=VALUE dasselbe nur in einer Pipeline (--set hold.times=4 die Halten-Node jeder Asset-Pipeline); --jobs TABLE.csv -o DIR führt pro Render eine Zeile einer Tabelle aus; --pipeline NAME|all wie bei render
pxr rebake SHEET.aseprite	das Projekt erneut in ein Sheet rendern, auf das du gemalt hast, und dabei deine Ebenen und Änderungen behalten (siehe Aseprite)
pxr cache stat|gc DIR	was ein Cache enthält; gc --keep 20GiB entfernt die am längsten nicht genutzten Renders, bis er passt
pxr golden CASES.txt	Testfälle rendern und mit gespeicherten Bildern vergleichen (siehe unten); --only TEXT führt die Fälle aus, deren Name ihn enthält, --tolerance F akzeptiert einen Anteil F abweichender Pixel, -o DIR (Vorgabe target/golden) ist das Ziel der Ergebnisse; --graph rendert sie stattdessen durch den Node-Graphen des Looks – den des Presets als mitgelieferte Gruppe Verpixeln –, und --flat durch denselben Graphen, jede Gruppe zu Atomen aufgelöst; beide müssen dieselben Bilder treffen. --cache DIR schreibt das Sprite jedes Falls über den Cache nach --out und vergleicht diese Datei, ausgeliefert oder gerendert; --no-cache schreibt dieselben Dateien ohne ihn
pxr bench MODEL	jedes Budget in tests/budgets.txt messen und met oder MISSED melden; --rounds N (Vorgabe 10) mittelt die Zeiten über N Läufe; --from INFO.json fügt die hinzu, die die App misst
pxr import MODEL --report	was mit der Datei beim Import passiert, ohne sie zu rendern: gefunden, korrigiert und warum, vorgeschlagen, fehlend, Dreiecke pro Sprite-Pixel; --json für einen Stapel, der zuerst die kaputten Dateien findet
pxr reference SPRITE.png	Einstellungen, abgelesen von einem vorhandenen Sprite: Palette, Größe, Kontur, Stufen, Farbtonverschiebung, Dithering, jeweils mit Begründung; pxr project set P --match-sprite S.png setzt sie
pxr voxels MODEL -o OUT.vox	das Modell als Voxel, --height hoch (1 bis 256), in der Palette des Looks: eine MagicaVoxel-Datei; --stack schreibt außerdem einen Sprite-Stack (siehe Voxel und Sprite-Stacks)
pxr nodes [--graph G] [--json]	jede Node der vier Graphen (Style, Action, Szene, Asset), wie dieses Pixor sie hat: was sie tut, was sie nimmt und gibt, jede Einstellung mit Bereich und Vorgabe; --json für Tools (die Node-Referenz der Website wird daraus gebaut)
pxr inspect FILE	was der Importer in jeder Datei gefunden hat, die Pixor importiert (die Formate, auch in pxr help inspect): bei einem Modell Objekte, Materialien, Knochen, Clips, Warnungen; bei einer .vdb ihre Grids und deren Größe; bei einem Bild seine Größe; bei einer Palette ihre Farben
pxr gbuffer MODEL -o DIR	die rohen Render-Ziele, für Fehlerberichte; der .pxrg-Dump enthält die Kanten des Meshes, wenn der Look sie zeichnet
pxr stylize DUMP.pxrg	die Pixel-Durchgänge auf einen gespeicherten Render anwenden, Drahtgitter inklusive
pxr diff OLD NEW	zwei Export-Ordner (oder zwei Sheets): welche Dateien neu, weg oder anders sind, um wie viele Pixel und, aus dem Rezept jeder Datei, welche Einstellung oder Eingabe es verursacht hat; --all listet auch die identischen Dateien, --exact endet bei jeder Änderung mit 1. Zwei .pxrg-Dumps werden Ziel für Ziel verglichen (--depth-tolerance EPS, --samples N)
pxr adapters	die GPUs, die Pixor nutzen kann
pxr doctor	womit dieser Rechner rendern kann und ob seine GPU mit der CPU-Referenz übereinstimmt
pxr project new|set|show PROJECT.pixor	ein Projekt aus Skripten und Tools erstellen, ändern oder ausgeben: --name NAME benennt es (der Name in der Kopfzeile, nicht der der Datei; show gibt ihn mit dem Rest aus)
pxr project key PROJECT.pixor TARGET CHANNEL	ein Key eines in Pixor erstellten Clips (--clip, --frame, --value, --how, --remove…), damit ein Skript einen Clip bauen kann
pxr project bake PROJECT.pixor CLIP	ein eigener Clip des Modells als in Pixor erstellter Clip, jeder Knochen in jedem Frame gekeyt (--as NAME, --fps F)
pxr project scene PROJECT.pixor [NODE]	der Szenen-Graph Node für Node: ring, row, grid, scatter, look-at, vary… ans Ende der Kette angefügt, die Optionen jeder Node nach ihren Einstellungen benannt (--count, --radius, --size bei Variieren, --box bei Verstreuen, --bumps bei Verschieben und --hills bei Höhenfeld in Metern, --times bei Unterteilen, --how bei Auswählen); eine Node, die nichts aufnimmt (object, import), beginnt die Kette anstelle des bloßen Imports und kommt neben eine längere Kette, mit ihr zusammengeführt; ohne Node wird er ausgegeben
pxr project blueprint PROJECT.pixor -o B.pixorblueprint	das Projekt als Blueprint, die Dateien für Modell, Palette, Requisiten und Volumen in benannte Slots herausgelöst
pxr style new KIT --from PROJECT	den ersten Style eines Projekts als Style-Kit speichern
pxr kit show FILE.pixorkit	was ein Kit enthält: eine Gruppe von Nodes, einen Style, ein Preset oder eine Pipeline
pxr names PROJECT.pixor [--names T] [--pipeline NAME|all]	die Namen, die das Projekt schreiben wird, und die ID jedes Frames, ohne zu rendern, die Dateien jedes Renders nach ihrem eigenen Pfad; zwei Frames auf einem Namen, zwei Renders auf einer Datei (would be written twice) oder zwei Dateien auf einem Pfad (die Basis einer Paper Doll und die des Licht-Kits, eine Palettenvariante und eine Ebene) sind hier ein Fehler statt später eine verlorene Datei
pxr graph list|set|add|drop|wire|save|swap|flatten|extra FILE --which scene|action|style|asset	jeden der vier Graphen aus einem Skript. --pipeline NAME wählt, welchen: eine Action nach ihrem Namen, eine Style- oder Asset-Pipeline, ohne Namen die erste. Gib ihn aus, ändere eine Einstellung, füge eine Node in die Kette ein (oder mit --alone daneben, andere mit --in SLOT=NODE hineinverbunden), entferne eine, verbinde zwei mit wire --from N --to M --slot S, speichere ihn als Kit (save -o KIT.pixorkit: den Style-Graphen als Ganzes, den Szenen-, Action- oder Asset-Graphen als eine Node, --as-pipeline eine ganze Asset-Pipeline, die ein anderes Projekt mit pxr project set --use-pipeline nutzt), setz ein Node-Kit als Gruppe ein (add --kit KIT) oder anstelle einer Node (swap --kit KIT), oder schreib einen Graphen mit aufgeklappten Gruppen heraus; extra --node N --name LAYER macht das Bild einer Style-Node auch zu einer Ebene der Exporte, und --drop beendet das. --node (und --set NODE.SETTING in pxr run) nennt eine Node über ihre Nummer, ihre Art, den Namen einer Gruppe, das, was ihr Namens sagt (eine Bilddatei, ein Sheet), oder den Namen, den sie in der App bekommen hat (F2); eine object-Node ist das Modell (of=model), und ein Item, eine Form oder ein Bild ist eine eigene Node. Die Nodes sprites, frame-range und hold eines Asset-Graphen werden wie jede andere eingestellt (--node sprites --set action=walk,Static – action=every-one-except-static ist die Vorgabe einer neuen Node, action= jede Action, auch Statisch – --set smart=6, --node frame-range --set from=2 --set to=5, --node hold --set times=2); die einer Action – clip, bob, spin, merge… – nach Art oder Nummer, und eine ohne --alone hinzugefügte spielt sofort, mit dem Vorhandenen zusammengeführt. Im Style-Graphen kommt eine Node unverbunden hinein, --in SLOT=NODE und wire binden sie ein. Eine Änderung, die einen Graphen lauffähigkeitsunfähig machen würde, wird abgelehnt und die Datei bleibt, wie sie war (siehe den Szenen-Graphen, den Asset-Graphen und Nodes)
pxr shapes [PROJECT] -o OUT.glb	die in der App gebauten Formen als Geometrie herausschreiben, für ein Modellierprogramm oder eine Engine
pxr icons MODELS... -o DIR	Inventar-Icons mit einem Atlas pro Größe; Seltenheit aus dem Namen jeder Datei, und --save behält ein Rezept für einen erneuten Lauf (siehe Exportieren)
pxr audit FILE|FOLDER... [--style KIT]	prüfen, ob exportierte Sheets zusammenpassen: Preset, Licht-Rig, Ansicht, Neigung, Licht, Stufen, Linien, Palette und Pixel pro Meter, aus dem Rezept jeder Datei, und mit einem Style-Kit, ob jede Farbe in seiner Palette ist (Exit 1, falls nicht)
pxr watch PROJECT.pixor	erneut exportieren, wann immer sich das Projekt, sein Modell oder seine Palette ändert
pxr effect KIND[:FRAMES]	ein eigenständiger Pixel-Effekt: explosion, hit-spark, slash, magic-burst, heal, portal, smoke-puff, dust, fire-loop, rain, snow, fireflies, falling-leaves
pxr console list|check SHEET.png	die Konsolenmodi oder ob ein Sheet in einen passt (Exit 1, falls nicht); die Konsole kommt aus --console oder dem Rezept des Sheets

Render-Optionen

Option	Standard
--view VIEW	die des Presets	Seite, Dreiviertel, isometrisch oder Top-down
--pitch DEG	die der Ansicht	Grad unter dem Horizont
--yaw DEG	0	ein einzelnes Sprite drehen oder die eine Seite eines Sheets aus einem
--camera GENRE		die Kamera eines Spiels: platformer, fighting, beat-em-up, adventure, top-down-rpg, action-adventure, isometric, tactics, strategy, racing, top-down-shooter, shmup, icon (Ansicht, Neigung, Drehung; Größe und Seiten, sofern nicht angegeben)
--camera-yaw DEG	0	die Kamera um das Modell drehen, jede Seite
--size N	64	in N x N einpassen, 4 bis 2048; --size 960x540 passt in eine Arbeitsfläche dieser Breite und Höhe ein (ein Titelbild, ein Hintergrund)
--pixels-per-metre F		feste Pixel pro Meter statt --size, 0.5 bis 4096 (in der App Pixel/m)
--up AXIS	beim Import entschieden	die Achse, die in der Datei nach oben zeigt (y, z, -z, x, -x, -y): für ein liegend exportiertes Modell
--import-scale F, --import-offset X,Y,Z	beim Import entschieden	die Einheit und die Bewegung, von Hand angegeben
--no-import-fix		die Datei genau so rendern, wie sie ist, ohne Korrekturen
--samples N	4	Samples pro Pixel entlang jeder Seite, 1 bis 8 (in der App Samples)
--light AZ,EL	-45,45	Hauptlicht relativ zur Kamera
--light-space S	Kamera	Welt: Das Licht bleibt in der Szene, statt der Kamera zu folgen
--fill F	die des Presets	Stärke des Fülllichts, 0 bis 1
--no-shadow		keine Schlagschatten
--bands N	die des Presets	Lichtstufen, 1 bis 4
--palette P		eine .hex-, .gpl- oder .png-Datei oder eine eingebaute Palette: pixor-16, pixor-8, dusk-12, forest-12, desert-12, ice-10, mono-8
--aa N	0	Kantenglättung: 0 aus, 1 Silhouette, 2 jede Linie
--match-space S	oklab	wie Farben ihre nächstliegende in einer festen Palette finden: oklab, srgb oder weighted
--dither-pattern P	Bayer	bayer (das Kreuzmuster) oder blue-noise (gleichmäßig verstreut); beide bleiben auf der Oberfläche, während sich das Modell bewegt
--even-stairs	aus	gerade Silhouettenkanten mit gleichmäßigen Stufen (2, 2, 2 statt 3, 1, 2)
--smear PX	0	Smear-Frames, 0 bis 64: Was sich seit dem vorigen Frame um PX Pixel oder mehr bewegt hat, zieht eine Spur
--nudge X,Y	0,0	das Modell um einen Bruchteil eines Pixels auf dem Raster verschieben (jeweils -0.5 bis 0.5); nur die Abtastung ändert sich
--foot-plant	aus	die aufgesetzten Füße eines Humanoiden in jedem Frame eines Clips auf derselben Pixelzeile
--preset NAME	sauber	clean, selout, retro4, flat, wireframe oder ein gespeichertes Preset-Kit (.pixorkit)
--style KIT		ein Style-Kit (.pixorkit): ein ganzer Style (pxr style new, Kit speichern… eines Styles), auch sein Style-Graph, oder nur ein Style-Graph (pxr graph save --which style); spätere Flags ändern es weiterhin. In einer Golden-Case-Datei relativ zu ihr. pxr icons und pxr audit nehmen dasselbe
--dither F	0	geordnetes Dithering zwischen benachbarten Lichtstufen, 0 bis 1
--line-colour HEX	die des Presets	Farbe der Dunkel-Linien, #rrggbb (nur automatische Paletten)
--no-lines MATERIAL		keine Linien um dieses Material (wiederholbar; pxr inspect listet sie)
--crease-angle DEG	55	wie scharf eine Falte eine Faltenlinie zeichnet, 1 bis 179
--depth-step PX	2.5	die Tiefenstufe in Pixeln, die eine innere Linie zeichnet, 0.1 bis 40 (in der App Tiefenstufe)
--shortest-line N	3	die kürzeste behaltene innere oder Faltenlinie, 0 bis 16 Pixel (in der App Kürzeste Linie)
--no-part-lines		keine Linien zwischen sich berührenden Teilen ohne Tiefensprung
--outline-inside		die Silhouette am eigenen Rand des Sprites
--convex LINE	keine	eine helle Linie auf Falten, die sich zur Kamera wölben: none, dark oder highlightN
--no-material-channels		Metall, Rauheit, Emission, Unlit und Durchsichtigkeit eines glTF-Materials ignorieren und nur nach seiner Farbe schattieren
--backend B	Auto	auto, vulkan, metal, dx12, gl, webgpu oder cpu (siehe Einen Renderer wählen)

Licht- und Farboptionen

Option
--rig NAME	ein Licht-Rig: noon, dusk, torchlight, moonlight oder studio
--cycle MATERIAL	die Farben dieses Materials in einer --colour-cycle-Action durchlaufen lassen (wiederholbar)
--team MATERIAL|#RRGGBB	die Teamfarbe: ein Material oder jede Rampe im Farbton dieser Farbe (wiederholbar); --variant team:blue färbt nur sie um
--console C	ein Konsolenmodus: gameboy, nes, pico8, tic80, c64 (siehe Konsolenmodi)

Animationsoptionen

Option
--clip NAME	ein zu rendernder Clip (für mehr wiederholen) oder all
--anim FILE	auch die Clips von FILE nutzen
--ring N	Seiten, gegen den Uhrzeigersinn von vorne (1 bis 64, Vorgabe 1), benannt South, Southeast, East…: jeweils eine Kamera, alle in einer Größe, in einem Sheet
--sides A1,A2,...	stattdessen eine Seite pro Winkel, in Grad (0 = vorne, 90 = nach rechts gewandt)
--fps F	Frames pro Sekunde Clip-Zeit (Vorgabe 12), der Schnitt jeder Sprites-Node
--keys T1,T2,...	von Hand gewählte Clip-Zeiten, in Sekunden, der Schnitt jeder Sprites-Node
--clip lib:NAME	ein Clip der Bewegungsbibliothek, an das Skelett des Modells angepasst: idle, walk, run, jump, attack, hit, death
--parallax N	das Bild nach Tiefe in N Ebenen aufteilen (2–8) für scrollende Hintergründe (siehe Szenen aus mehreren Modellen)
--haze #RRGGBB	die Farbe, zu der ferne Parallaxe-Ebenen hin verblassen; none lässt jede Ebene so auf der Palette, wie sie ist
--spring NODE[:S,D,G]	NODE und was darunter liegt, schwingt mit der Bewegung: Steifheit, Dämpfung, Schwerkraft (wiederholbar); in einem Projekt eine Feder-Node des Szenen-Graphen
--smart-frames N	N Frames jedes Clips behalten, aus seinen Posen gewählt (jeder bis zum nächsten gehalten), der Schnitt jeder Sprites-Node
--root-motion M	keep (Standard), in-place (den Wurzelknochen horizontal festheften) oder in-place-sway (nur die Netto-Fortbewegung des Clips entfernen)
--turntable N	eine Action mit N Frames hinzufügen, die das Modell einmal dreht
--turntable-seconds S	wie lange diese Drehung dauert (Vorgabe: N Frames bei --fps)
--motion M[:N[:A]]	eine Schleife hinzufügen: spin, bob, swing, pulse, squash oder flicker, N Frames, Stärke A (bei spin der Anteil einer Umdrehung, den die Schleife macht: spin:8:0.125 dreht einen Edelstein mit acht Facetten um eine Facette, eine nahtlose Schleife)
--colour-cycle N	eine Action mit N Frames hinzufügen, die die Schattierungen der zyklischen Materialien weiterdreht
--prop FILE:BONE[@at=X,Y,Z][@turn=X,Y,Z][@scale=S][@grip=NODE]	ein anderes Modell an einen Knochen hängen, an seinem Griff gehalten, entlang der Achsen des Knochens verschoben und gedreht (siehe Requisiten an Knochen)
--shape SPEC	eine Form hinzufügen: [NAME=]KIND[:SIZE[:AT[:#RRGGBB[:TURN]]]], z. B. box:1,0.5,1:0,0.25,0:#c86432 oder wheel=cylinder:0.5,0.2,0.5:0.7,0.25,0.5:#14101c:90,0,0 für ein benanntes, auf der Seite liegendes Rad (wiederholbar). KIND ist box, sphere, cylinder, cone, torus, plane, capsule, wedge, pyramid, prism, stairs, arch oder letters (pxr help render listet sie aus derselben Liste, die das Flag liest): letters sind die Pixel der Schrift, zu Blöcken extrudiert, die PIXOR buchstabieren, oder der Text eines Projekts, pxr project set --add-shape letters --words WORDS --font NAME (render nimmt kein --words)
--volume SPEC	ein Volumen hinzufügen: puff, flame, cloud, mist oder ein .vdb-Pfad, dann [:SIZE[:AT]], dann [:FRAMES[,EVERY[,LOOP]]] für eine nummerierte .vdb-Sequenz, dann @BONE, um von einem Knochen getragen zu werden, oder @effect:N vom Emitter des N-ten Effekts (Volumen)
--wire LINE	der Drahtgitter-Look: none, dark oder seloutN, mit --wire-fill, --wire-hidden, --wire-angle (0 bis 180), --wire-all-edges und --wire-glow MATERIAL (Einstellungen)
--light-sweep N	eine Action mit N Frames hinzufügen, die das Licht bewegt
--effect KIND[:N]	eine Pixel-Effekt-Action mit N Frames hinzufügen (siehe pxr effect), mit --effect-size, --effect-energy, --effect-seed, --effect-at X,Y,Z, --effect-bone BONE, --effect-clip CLIP, --effect-hit FRAME und --effect-alone
--hitbox PART, --hurtbox PART, --socket BONE	Boxen und Knochenpositionen pro Frame im JSON (wiederholbar; siehe Exportieren)
--paper-doll, --piece NAME:PARTS	Paper-Doll-Ebenen (siehe Exportieren)
--item MODEL@X,Z[,YAW,SCALE[,LAYER]][:CLIP[,PHASE]], --ground W,D[,#RRGGBB]	weitere Modelle neben dem ersten, jedes eine Item-Node des Szenen-Graphen in einem Projekt, und eine Bodenebene darunter (siehe Exportieren)
--chunks COLSxROWS	eine große Karte als Chunks mit exakten Nähten schreiben; --chunk-margin N (Vorgabe 8)
--max-flicker F	über diesem Flackeranteil warnen (z. B. 0.01); in einem Golden Case fehlschlagen
--require-visible OBJECT	warnen, wenn OBJECT in irgendeinem Frame verschwindet

Exportoptionen

Option
--export LIST	durch Kommas getrennt oder wiederholt: png, json, aseprite, normal, depth, emission, layers, palette, godot, gif, apng, light-kit, p8, report, video oder all (alle außer p8 und video, die nur geschrieben werden, wenn sie genannt sind); das PNG wird immer geschrieben (siehe Exportieren). render, batch, run, watch, project set und tiles (mit eigenen Formaten) lesen es genauso
--layout L	Raster (eine Zeile pro Action und Seite, die Vorgabe) oder Streifen
--padding N	transparente Pixel zwischen Zellen, 0 bis 256 (Vorgabe 0)
--extrude N	Zellenkanten N Pixel nach außen wiederholen, 0 bis 64 (Vorgabe 0)
--pot	Sheet-Größe als Zweierpotenz
--godot-path RES	wo Godot das Sheet findet (Vorgabe res://<png name>)
--anim-scale K	ganzzahlige Skalierung der GIF- und APNG-Dateien, 1 bis 16 (Vorgabe 1)
--video-scale K, --video-fps N, --video-background #RRGGBB	wie die Videos geschrieben werden: Skalierung 1 bis 16 (Vorgabe 4), 1 bis 100 Frames pro Sekunde (Vorgabe 30), worüber das Sprite gezeichnet wird (Vorgabe Schwarz)
--trim	jede Zelle auf ihre Pixel zuschneiden (JSON und Godot-Datei behalten die Platzierung)
--dedupe	identische Frames nur einmal speichern
--max-width N	eine neue Zeile beginnen, bevor das Sheet breiter als N Pixel wird (0 bis 65536; 0: keine Grenze)
--columns N	N Frames pro Reihe, jeder Clip läuft nach dem letzten weiter: ein Kontaktabzug
--max-height N	ein Sheet, das höher als N Pixel ist, in Seiten aufteilen, ganze Clips pro Seite (NAME_1.png, NAME_2.png; 0 bis 65536)
--variant NAME	zusätzlich eine Palettenvariante exportieren (wiederholbar): ein Effekt wie hit-flash oder night, hue:DEG, team:COLOUR (ein Name oder #rrggbb; braucht --team) oder palette:NAME|FILE; fügt ein Index-Sheet und eine Lookup-Textur hinzu
--shadow KIND	zusätzlich name_shadow.png schreiben: contact oder drop
--names TEMPLATE	wie die Dateien und die JSON-Schlüssel benannt werden: ein Muster aus {project}, {object}, {action}, {side}, {layer}, {set}, {size}, {index} und {ext}, mit {index:3} auf drei Stellen aufgefüllt (siehe Exportieren)
--no-recipe	das Rezept (wie das Sheet entstand) nicht im PNG und in der .aseprite speichern
--scale K	das PNG K-fach hochskalieren (nur Vorschauen; nicht mit anderen Formaten)
--save-project FILE.pixor	diese Kommandozeile zusätzlich als Projekt schreiben
--debug DIR	Render-Ziele, Palette, Lint- und Flackerbilder

Golden Tests für deine eigene Pipeline

Eine Falldatei listet einen Render pro Zeile: einen Namen, einen Modell- oder Projektpfad (relativ zur Datei) und Optionen.

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

pxr golden cases.txt --bless speichert die Ergebnisse als NAME.png neben der Datei; später schlägt pxr golden cases.txt fehl, wenn sich ein Pixel ändert, wenn ein Sprite Lint-Befunde hat (Einzelpixel, L-förmige Linienecken, 2-px-Linien) oder wenn eine --max-flicker- oder --require-visible-Prüfung fehlschlägt; der Fehler sagt, bei welchen Fällen sich Pixel unterscheiden (ihre NAME.actual.png und NAME.diff.png liegen in target/golden) und welche ihre Prüfungen nicht bestanden haben. --bless speichert die Bilder auch, wenn eine Prüfung fehlschlägt, und beendet sich mit 1, wobei es diese Fälle nennt. Nutze es, um zu bemerken, wenn eine Modelländerung deine Sprites verändert.

Eine Bibliothek, kein Durchlauf

Ein Studio rendert dieselben fünftausend Sprites erneut, weil sich eine Rampe verschoben hat. Drei Dinge machen daraus eine Entscheidung statt eines Jobs über Nacht.

Ein Cache, der den Prozess überdauert. --cache DIR bei pxr batch und pxr run behält jeden Render, den es erzeugt, mit den gelesenen Dateien und einem Hash ihres Inhalts: das Modell, die Clip-Dateien daneben, die Texturen, auf die eine .gltf verweist, Paletten, Kits, Bilder und Volumen. Der nächste Lauf liefert jeden Render, dessen Dateien noch denselben Hash haben, und rendert den Rest.

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

Der Cache ist nie die maßgebliche Quelle: --no-cache liefert dieselben Bytes, eine gespeicherte Datei, deren Hash nicht zu ihrem Namen passt, wird neu gerendert statt ausgeliefert, und ein neuer Build von Pixor beginnt einen neuen Cache, statt dem alten zu trauen.

Eine Auftragsdatei. Eine Tabelle mit einer Zeile pro Render, einer Spalte pro Slot des Blueprints und wahlweise den Spalten name (der Ordner der Zeile), out (ihr Sheet unter --out) und NODE.SETTING (ein --set für diese Zeile):

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

Hier kommt sheet.pixorblueprint aus pxr project blueprint sheet.pixor, einem Projekt aus heroes/knight.glb mit einer Palette, also sind seine Slots model und palette; der Ritter wird mit 8 Frames pro Sekunde geschnitten und der Magier, dessen Zelle leer ist, mit der eigenen Rate des Blueprints. Jede Zeile schreibt 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

Pfade sind relativ zur Tabelle. Eine Zeile ist genau pxr run mit dem --in und --set der Zeile, sodass sich eine fehlerhafte Zeile einzeln ausführen lässt. Eine fehlschlagende Zeile hält die anderen nie auf: Der Bericht listet jede Zeile damit, ob sie gerendert, aus dem Cache bedient wurde oder fehlschlug und warum, und der Job endet am Schluss mit 1, falls eine fehlschlug.

Budgets als Flags. --max-pixels N, --max-memory SIZE und --max-time DURATION gelten pro Render (pro Zeile, pro Modell). Was der Plan schon weiß – wie viele Pixel ein Sheet haben wird, etwa wie viel Speicher es belegen wird –, wird geprüft, bevor irgendetwas gezeichnet wird; Zeit und Speicher werden zwischen Frames geprüft. Eine Überschreitung endet mit 6, mit dem Wert und wo es angehalten hat; in einem Auftrag scheitert die Zeile mit diesem Grund, und die anderen laufen weiter.

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

Lange Clips. Die Frames eines Clips werden gezeichnet und dann gemeinsam fertiggestellt, da die Durchgänge, die einen Clip vor dem Flackern bewahren, an ihm entlangschauen. Was sie lesen, wird innerhalb von 512 MiB gehalten (die Hälfte von --max-memory, wenn angegeben), ein paar Seiten auf einmal; ein Clip, der selbst für eine Seite zu lang ist, wird beim Zeichnen auf der Festplatte gehalten – unter ~/.cache/pixor/spill oder PXR_SPILL_DIR – und bei Bedarf zurückgelesen: dieselben Pixel, langsamer, und der Ordner verschwindet mit dem Render.

Exit-Codes

Code
0	Erfolg
1	ein fehlgeschlagener Render, Export, Stapel-Modell, Job-Zeile oder Golden Case
2	ein Bedienungsfehler: die Meldung, die Verwendung des Befehls und see pxr help COMMAND auf stderr
3	eine Eingabe, die nicht gelesen werden konnte: ein Modell, Projekt, eine Palette, ein Kit, eine Case-Datei oder ein Dump
4	ein namentlich verlangtes Backend, das nicht vorhanden ist
5	eine Ausgabe, die nicht geschrieben werden konnte: eine Datei oder ein Ordner
6	über einem Budget von --max-pixels, --max-memory oder --max-time
7	ein Re-Bake, das Malerei behalten hat, über die es nicht allein entscheidet (--resolve keep|pixor)

Gar keine GPU ist kein Fehler: Pixor zeichnet dann mit seinem eigenen Rasterizer. Ein Fehler sagt überall auf dieselbe Weise, was nicht stimmte: --flag takes A to B, got X.

Einen Renderer wählen

--backend auto|vulkan|metal|dx12|gl|webgpu|cpu legt fest, wer die Geometrie zeichnet. Der Look – jeder Pixeldurchgang – wird auf der CPU berechnet, egal was hier steht.

• auto (der Standard) nimmt, was der Rechner hat, und weicht auf die CPU aus, wenn kein Adapter funktioniert.
• cpu ist Pixors eigener Rasterizer. Er braucht keinen Adapter und keinen Treiber, steckt im Binary und zeichnet auf jedem Rechner dieselben Pixel — die portable Wahl für ein Asset-Pack oder einen CI-Build.
• Ein genanntes Backend, das nicht vorhanden ist, ist ein Fehler (Exit 4), denn stillschweigend woanders zu rendern ist schlimmer, als es zu sagen.

Das Rezept jedes Exports hält fest, welches Backend ihn gezeichnet hat. pxr doctor gibt die gefundenen Adapter aus, den, den Pixor wählen würde, die Treiberversionen und ob dieses Backend dasselbe Bild zeichnet wie die CPU-Referenz:

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

In der App ist dieselbe Wahl Einstellungen › Renderer › Sprites auf der CPU zeichnen oder für eine Sitzung pixor --backend B mit denselben Namen wie bei pxr (cpu, auto oder ein GPU-Backend beim Namen), was die Einstellung lässt, wie sie ist. Jedes behält, was es gezeichnet hat: Ein Wechsel zum anderen rendert die Frames neu, und ein Wechsel zurück bringt die Frames des ersten ohne Render zurück, solange sich an der Szene nichts geändert hat.

Für Tools und Skripte

Füge --json an jeden Befehl an: Die Standardausgabe trägt dann ein JSON-Ereignis pro Zeile (progress, wrote, warning, error, done), und das lesbare Log wandert in die Standardfehlerausgabe. Die Befehle, die lesen statt schreiben, geben das, was sie ausgeben, ebenfalls als ein Ereignis aus: inspect, adapters, tiles --list (terrains), graph list und graph flatten sowie diff zweier Dumps.