가이드 / 건축 및 리소스

슬림인지 클래식인지: 게임은 계정을 읽고, 도구는 24픽셀에서 추측해야 한다

게임은 PNG가 아니라 계정의 스킨 설정에서 슬림 또는 클래식을 가져옵니다. PNG만 받은 도구는 슬림 팔이 비워두는 두 열을 보고 추측해야 합니다. 그리고 전체 UV 맵과 레거시 64×32 스킨이 좌우 반전되는 이유까지.

2026-08-01

스킨 PNG 어디에도 "슬림"이라고 적혀 있지 않습니다. 플래그도 없고 파일 이름 규칙도 없으며, 게임은 픽셀을 보고 알아내는 일 자체를 하지 않습니다. 게임은 계정이 스킨에 붙여주는 model 설정(스킨을 업로드할 때 고르는 그 선택)에서 모델을 가져오고, 스킨이 없는 프로필은 UUID를 기준으로 18개의 기본 스킨 중 하나(슬림 9개, 클래식 9개)를 받습니다.

PNG만 달랑 받은 도구 — 편집기, 리소스팩 제작기, 뷰어 — 만이 모델을 추론해야 하며, 특정한 2 × 12 직사각형을 보고 그 안에 픽셀이 실제로 몇 개 있는지 세는 방식으로 추론합니다.

판별법

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

클래식 팔은 너비가 4픽셀이고 슬림 팔은 3픽셀입니다. 슬림 팔은 각 면이 1픽셀씩 좁게 배치되므로 옆면과 뒷면이 왼쪽으로 밀리고, 팔 블록의 마지막 두 열인 x 54–55가 비어 있게 됩니다. Mojang의 기본 스킨에서 이 직사각형은 슬림 9개 모두 24픽셀 중 0픽셀이 불투명하고, 클래식 9개 모두 24픽셀 중 24픽셀이 불투명합니다. 24픽셀이면 구분하기에 충분합니다.

임계값은 1이 아니라 24픽셀 중 6픽셀입니다. 즉 해당 열의 4분의 1이 채워져야 클래식으로 인식됩니다. 이 허용 범위가 중요합니다. 죽은 열에 픽셀이 몇 개 튀어 있는 슬림 스킨도 여전히 슬림으로 읽히는데, 이게 바로 원하는 동작입니다. 그런 튀는 픽셀은 거의 항상 의도가 아니라 편집 실수이기 때문입니다.

이는 또한 실패 방식이 조용하다는 뜻이기도 합니다. 클래식 스킨을 그렸는데 그 열을 아주 살짝만 사용했다면 — 얇은 외곽선, 음영 픽셀 두어 개 — 6픽셀 아래로 떨어져 슬림으로 자동 감지될 수 있고, 팔 너비 1픽셀을 아무 설명도 없이 잃게 됩니다. 도구에서 스킨이 잘못된 모델로 나온다면 그 열을 살펴보세요. 그리고 게임 안에서는 계정의 설정을 보면 됩니다.

UV 맵 전체

스킨의 모든 부위는 고정된 직사각형이며, 각각은 시트 어딘가에 오버레이 레이어를 가지고 있습니다:

여섯 개 오버레이 중 다섯 개가 기본 위치에서 정확히 16픽셀 떨어져 있습니다 — 하지만 같은 방향이 아닙니다. 원래 세 부위는 아래로 16만큼 갑니다. 나중에 추가되어 아래쪽 공간이 없던 하단 절반에 밀어 넣은 왼팔과 왼다리는 대신 옆으로 16만큼 가며, 그것도 서로 반대 방향으로 갑니다.

모자는 유일하게 16만큼 떨어져 있지 않은 부위입니다. 머리와 같은 행에서 오른쪽으로 32만큼 떨어져 있습니다.

따라서 "오버레이는 기본 위치 아래에 있다"는 규칙은 시트의 딱 절반에만 들어맞습니다. 기본 직사각형을 복사해서 아래로 오프셋해 오버레이를 찾는 방식은 몸통, 오른팔, 오른다리에는 통하지만 나머지 셋에는 조용히 엉뚱한 부위에 착지합니다.

슬림 스킨에서는 너비 4인 모든 팔 직사각형이 대신 너비 3으로 읽힙니다. 앞면은 움직이지 않지만 그 뒤의 모든 것이 움직입니다. 옆면과 뒷면이 각각 1픽셀씩 더 왼쪽에서 시작하고, 뒷면은 1픽셀 더 좁아지는데, 이것이 x 54–55를 비워두는 원인입니다.

레거시 64 × 32에는 왼쪽이 아예 없다

1.8 이전 스킨은 64 × 32입니다. 시트의 하단 절반이 아예 존재하지 않는데, 바로 그곳에 왼팔과 왼다리가 있습니다. 그것들을 그려낼 원본이 없는 것입니다.

해결책은 좌우 반전입니다. 오른다리 (0, 16)를 (16, 48)로, 오른팔 (40, 16)을 (32, 48)로 복사하며, 둘 다 수평으로 뒤집습니다. 이것이 옛 스킨은 완벽하게 대칭이고 현대 스킨은 그럴 필요가 없는 이유입니다. 비대칭은 64 × 32 포맷이 표현할 수 없는 유일한 것이며, 변환하는 옛 스킨은 원하든 원치 않든 대칭이 강제로 적용됩니다.

128 × 128 편집기 파일은 같은 레이아웃의 두 배 크기다

Java는 64 × 64 또는 레거시 64 × 32를 받아들이고 그 외에는 모두 거부합니다. 이 사이트의 Bedrock 스킨 편집기는 128 × 128로 작동하며 그 외에는 아무것도 받지 않습니다. 하지만 그 파일은 같은 UV 레이아웃을 두 배 해상도로 그린 것, 즉 모든 부위가 Java 좌표의 두 배인 것이지 다른 포맷이 아닙니다.

벽은 레이아웃이 아니라 도구에 있습니다. 각 편집기 빌드의 텍스처 파이프라인은 자기 숫자에 맞춰져 있어서, 어느 쪽도 상대방의 파일을 열지 못하며, 128 × 128 PNG를 Java에 넘기면 절반 크기로 보여주는 대신 거부합니다. 변환은 기계적인 2배 크기 조정이며, 이것이 스킨 편집기가 둘을 하나의 캔버스가 아니라 별개의 빌드로 취급하는 이유입니다.

아바타 메이커 →