Slank of klassiek wordt bepaald door 24 pixels, en je kunt precies zien welke

Een skin is slank als minder dan 6 van de 24 pixels op (46,20)–(47,31) dekkend zijn. Plus de volledige UV-map, waarom verouderde 64×32-skins worden gespiegeld en waarom Bedrock's 128×128 nooit in Java zal laden.

2026-08-01

Niets in een skin-PNG zegt "slank". Er is geen vlag, geen metadata en geen bestandsnaamconventie — het model wordt afgeleid van de afbeelding zelf, door te kijken naar een specifieke 2 × 12-rechthoek en te tellen hoeveel pixels er daadwerkelijk aanwezig zijn.

De test

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

Klassieke armen zijn 4 pixels breed; slanke armen 3. Een slanke skin laat daarom de vierde armkolom leeg, en die kolom is waar het monster overheen ligt. Vierentwintig pixels bepalen welk model je personage draagt.

De drempelwaarde is 6 van de 24, niet 1 — een kwart van de kolom moet gevuld zijn voordat het als klassiek telt. Die tolerantie maakt uit: een slanke skin met een paar verdwaalde pixels in de dode kolom wordt nog steeds als slank gelezen, wat precies de bedoeling is, omdat die verdwaalde pixels bijna altijd een bewerkingsfoutje zijn in plaats van opzet.

Het betekent ook dat het stilzwijgend fout gaat. Als je een klassieke skin tekent maar de vierde kolom slechts licht gebruikt — een dunne omlijning, een paar schaduwpixels — kun je onder de 6 uitkomen en automatisch als slank worden gedetecteerd, waardoor je een pixel armbreedte verliest zonder duidelijke reden. Als een skin als het verkeerde model uitvalt, is die kolom de plek om te kijken.

De UV-map, volledig

Elk onderdeel van de skin is een vaste rechthoek, en elk heeft ergens anders op het vel een overlay-laag:

Vijf van de zes overlays bevinden zich precies 16 pixels van hun basis — maar niet in dezelfde richting. De drie oorspronkelijke onderdelen gaan 16 omlaag. De linkerarm en het linkerbeen, later toegevoegd en in de onderste helft gepropt waar er geen ruimte onder was, gaan in plaats daarvan 16 zijwaarts — en in tegengestelde richtingen van elkaar.

De hoed is de enige die helemaal niet 16 verwijderd is: deze bevindt zich 32 naar rechts, op dezelfde rij als het hoofd.

Dus "de overlay staat onder de basis" is een regel die voor precies de helft van het vel geldt. Het kopiëren van een basisrechthoek en deze naar beneden verschuiven om de overlay te vinden werkt voor het lichaam, de rechterarm en het rechterbeen, en komt bij de andere drie geruisloos op het verkeerde onderdeel uit.

Bij een slanke skin wordt elke 4-brede armrechthoek gelezen als 3 breed in plaats daarvan. De rechthoeken verplaatsen zich niet; alleen de breedte die eruit wordt gelezen verandert.

Verouderde 64 × 32 heeft helemaal geen linkerkant

Een pre-1.8 skin is 64 × 32 — de onderste helft van het vel bestaat simpelweg niet, en dat is waar de linkerarm en het linkerbeen zich bevinden. Er is niets om ze van af te leiden.

De oplossing is spiegelen: het rechterbeen (0, 16) wordt gekopieerd naar (16, 48) en de rechterarm (40, 16) naar (32, 48), beide horizontaal gespiegeld. Daarom zijn oude skins perfect symmetrisch en hoeven moderne dat niet te zijn — asymmetrie is het enige dat het 64 × 32-formaat niet kan uitdrukken, en elke oude skin die je converteert krijgt symmetrie opgelegd, gewild of niet.

Bedrock's 128 × 128 is een ander formaat, niet een groter formaat

Java accepteert 64 × 64 of verouderde 64 × 32. Bedrock accepteert 128 × 128 en niets anders. De viewer van geen van beide edities kan het bestand van de ander weergeven — dit is geen resolutieverschil dat schaalt, het is een andere UV-indeling met een andere grootte.

Dat is een harde grens in plaats van een ongemak. Een Java-skin "upscalet" niet naar Bedrock, en een Bedrock-skin die in een Java-viewer wordt geladen, wordt niet op halve grootte gerenderd — hij wordt geweigerd. De editor op deze pagina behandelt de twee precies om die reden als afzonderlijke builds.