スリムかクラシックか:ゲームはアカウントを読み、ツールは24ピクセルから推測するしかない
ゲームはスリムかクラシックかをPNGではなくアカウントのスキン設定から取得します。素のPNGだけを渡されたツールは、スリムの腕が空ける2列から推測するしかありません。さらにUVマップの全体像と、旧式の64×32スキンがミラーリングされる理由を解説します。
スキンの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ピクセル狭く詰められるため、側面と背面が左にずれ、腕ブロックの最後の2列、x 54~55が空きます。Mojang公式のデフォルトスキンでは、この矩形はスリム9種すべてで24ピクセル中0個が不透明、クラシック9種すべてで24個中24個が不透明です——24ピクセルあれば判別できます。
しきい値は24個中6個であり、1個ではありません——列の4分の1が埋まって初めてクラシックと判定されます。この許容範囲は重要です。空き列に少数の余分なピクセルがあるスリムスキンは依然としてスリムと判定されますが、これは望ましい挙動です。そうした余分なピクセルはほぼ常に編集上の事故であり、意図ではないからです。
これはまた、失敗が静かに起きることも意味します。クラシックのスキンを描いたのにそれらの列をわずかしか使わない場合——細い輪郭線や数個の陰影ピクセルだけ——6個を下回ってスリムと自動判定され、理由の説明もなく腕の幅が1ピクセル失われます。ツールでスキンが誤ったモデルになる場合は、まずそれらの列を確認してください——そしてゲーム内では、アカウントの設定を確認してください。
UVマップの全体像
スキンの各部分は固定された矩形で、それぞれシート上の別の場所にオーバーレイ層があります:
| 部位 | ベース | オーバーレイ | オフセット | 大きさ |
|---|---|---|---|---|
| 頭 | (8, 8) | 帽子 (40, 8) | 右に32 | 8 × 8 |
| 胴体 | (20, 20) | ジャケット (20, 36) | 下に16 | 8 × 12 |
| 右腕 | (44, 20) | 袖 (44, 36) | 下に16 | 4 × 12 |
| 右脚 | (4, 20) | ズボン (4, 36) | 下に16 | 4 × 12 |
| 左腕 | (36, 52) | 袖 (52, 52) | 右に16 | 4 × 12 |
| 左脚 | (20, 52) | ズボン (4, 52) | 左に16 | 4 × 12 |
6つのオーバーレイのうち5つはベースからちょうど16ピクセルの位置にあります——しかし同じ方向ではありません。 元からある3つの部位は下に16です。後から追加され、下にスペースのない下半分に押し込まれた左腕と左脚は、代わりに横に16——しかも互いに逆方向です。
帽子だけは16の距離にまったくありません:頭と同じ行で右に32です。
つまり「オーバーレイはベースの下にある」というルールは、シートのちょうど半分にしか当てはまりません。ベースの矩形をコピーして下にオフセットしてオーバーレイを探す方法は、胴体・右腕・右脚では機能しますが、残りの3つでは静かに間違った部位にたどり着きます。
スリムスキンでは、幅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のエディターファイルは同じレイアウトの2倍の大きさ
Javaは64×64または旧式の64×32を受け付け、それ以外は拒否します。このサイトのBedrockスキンエディターは128×128で動作し、それ以外は受け付けません——しかしそのファイルは同じUVレイアウトを2倍の解像度で描いたもので、すべての部位がJavaの座標の2倍になっており、別の形式ではありません。
壁はツール側にあり、レイアウト側にはありません。各エディタービルドのテクスチャパイプラインはそれぞれの数値に合わせて設計されているため、どちらも相手のファイルを開けません。また、128×128のPNGをJavaに渡すと、半分の大きさで表示されるのではなく拒否されます。変換は機械的な2倍の大きさ変更であり、だからこそスキンエディターは両者を1つのキャンバスではなく別々のビルドとして扱うのです。