MC Toolkit

Anleitungen / Bauen & Ressourcen

Slim oder klassisch: Das Spiel liest dein Konto aus, und ein Tool muss aus 24 Pixeln raten

Das Spiel entnimmt slim oder klassisch der Skin-Einstellung deines Kontos, nicht der PNG. Ein Tool, das nur eine nackte PNG bekommt, muss aus zwei Spalten raten, die ein schlanker Arm leer lässt. Dazu die vollständige UV-Karte und warum alte 64×32-Skins gespiegelt werden.

Nichts in einer Skin-PNG sagt „slim". Es gibt kein Flag und keine Dateinamen-Konvention – und das Spiel schaut sich die Pixel nie an, um es herauszufinden. Es nimmt das Modell aus der model-Einstellung, die dein Konto an den Skin hängt (die Wahl, die du beim Hochladen triffst), und ein Profil ohne Skin bekommt einen von 18 Standard-Skins, 9 slim und 9 klassisch, ausgewählt anhand seiner UUID.

Nur ein Tool, dem eine nackte PNG übergeben wird – ein Editor, ein Pack-Builder, ein Viewer –, muss das Modell erschließen, und das tut es, indem es ein bestimmtes 2 × 12-Rechteck betrachtet und zählt, wie viele seiner Pixel tatsächlich vorhanden sind.

Der Test

sample  x 54–55, y 20–31        — 2 wide, 12 tall = 24 pixels
count   pixels with alpha > 0
slim    if fewer than 6 are opaque

Klassische Arme sind 4 Pixel breit; schlanke Arme sind 3. Die Flächen eines schlanken Arms sind einen Pixel schmaler gepackt, also verschieben sich die Seiten- und die Rückfläche nach links, und die letzten beiden Spalten des Armblocks, x 54–55, bleiben leer. Bei Mojangs eigenen Standard-Skins ist dieses Rechteck bei allen neun schlanken 0 von 24 undurchsichtig und bei allen neun klassischen 24 von 24 – vierundzwanzig Pixel reichen aus, um es zu erkennen.

Der Schwellenwert liegt bei 6 von 24, nicht bei 1 – ein Viertel der Spalte muss gefüllt sein, bevor sie als klassisch zählt. Diese Toleranz ist wichtig: Ein schlanker Skin mit ein paar verirrten Pixeln in der toten Spalte wird trotzdem als schlank gelesen, und das ist genau das, was du willst, denn diese Ausreißer sind fast immer ein Bearbeitungsunfall und keine Absicht.

Das bedeutet aber auch, dass der Fehlerfall leise ist. Wenn du einen klassischen Skin zeichnest, diese Spalten aber nur sparsam nutzt – eine dünne Kontur, ein paar Schattierungspixel –, kannst du unter 6 landen und wirst automatisch als schlank erkannt, verlierst einen Pixel Armbreite, und nichts erklärt dir, warum. Wenn ein Skin in einem Tool als das falsche Modell herauskommt, sind diese Spalten die Stelle, an der du nachsehen solltest – und im Spiel ist es die Einstellung an deinem Konto.

Die UV-Karte, vollständig

Jeder Teil des Skins ist ein festes Rechteck, und jedes hat eine Overlay-Ebene irgendwo anders auf dem Blatt:

TeilBasisOverlayVersatzGröße
Kopf(8, 8)Hut (40, 8)32 nach rechts8 × 8
Körper(20, 20)Jacke (20, 36)16 nach unten8 × 12
rechter Arm(44, 20)Ärmel (44, 36)16 nach unten4 × 12
rechtes Bein(4, 20)Hose (4, 36)16 nach unten4 × 12
linker Arm(36, 52)Ärmel (52, 52)16 nach rechts4 × 12
linkes Bein(20, 52)Hose (4, 52)16 nach links4 × 12

Fünf der sechs Overlays liegen genau 16 Pixel von ihrer Basis entfernt – aber nicht in dieselbe Richtung. Die drei ursprünglichen Teile gehen 16 nach unten. Der linke Arm und das linke Bein, später hinzugefügt und in die untere Hälfte gequetscht, wo unter ihnen kein Platz war, gehen stattdessen 16 zur Seite – und zwar in entgegengesetzte Richtungen zueinander.

Der Hut ist der einzige, der überhaupt nicht 16 entfernt liegt: Er ist 32 nach rechts, in derselben Zeile wie der Kopf.

„Das Overlay liegt unter der Basis" ist also eine Regel, die für genau die Hälfte des Blatts gilt. Ein Basisrechteck zu kopieren und nach unten zu verschieben, um sein Overlay zu finden, funktioniert für den Körper, den rechten Arm und das rechte Bein und landet bei den anderen drei still und leise auf dem falschen Teil.

Bei einem schlanken Skin wird jedes 4 breite Armrechteck stattdessen als 3 breit gelesen. Die Vorderflächen verschieben sich nicht, aber alles danach schon: Die Seitenfläche und die Rückfläche beginnen jeweils einen Pixel weiter links, und die Rückfläche ist einen Pixel schmaler, wodurch x 54–55 leer bleibt.

Altes 64 × 32 hat überhaupt keine linke Seite

Ein Skin von vor 1.8 ist 64 × 32 – die untere Hälfte des Blatts existiert schlicht nicht, und genau dort liegen der linke Arm und das linke Bein. Es gibt nichts, woraus man sie zeichnen könnte.

Die Lösung ist Spiegelung: Das rechte Bein (0, 16) wird nach (16, 48) kopiert und der rechte Arm (40, 16) nach (32, 48), beide horizontal gespiegelt. Deshalb sind alte Skins vollkommen symmetrisch und moderne müssen es nicht sein – Asymmetrie ist das Einzige, was das 64 × 32-Format nicht ausdrücken kann, und jedem alten Skin, den du konvertierst, wird Symmetrie aufgezwungen, ob er will oder nicht.

Eine 128 × 128-Editordatei ist dasselbe Layout, doppelt so groß

Java akzeptiert 64 × 64 oder das alte 64 × 32 und lehnt alles andere ab. Der Bedrock-Skin-Editor dieser Seite arbeitet mit 128 × 128 und akzeptiert nichts anderes – aber diese Datei ist dasselbe UV-Layout in doppelter Auflösung, jeder Teil bei doppelten Java-Koordinaten, kein anderes Format.

Die Hürde liegt in den Tools, nicht im Layout. Die Textur-Pipeline jedes Editor-Builds ist auf ihre eigene Zahl ausgelegt, also öffnet keiner die Datei des anderen, und eine 128 × 128-PNG, die man Java übergibt, wird abgelehnt statt auf halber Größe angezeigt. Die Konvertierung ist ein mechanischer 2×-Maßstab (Scale), weshalb der Skin-Editor die beiden als getrennte Builds behandelt und nicht als eine Leinwand.

Avatar-Ersteller →

Weitere Anleitungen

Alle ansehen →