絵画はサイズではなく形で決まる
カスタム絵画パックの多くが失敗するのは、アートワークのアスペクト比がどのスロットにも合わないからです。ここではマッチングの実際の仕組みを説明します。
Minecraft 26.2には51種類の絵画があり、それらは互換性のあるキャンバスではありません。それぞれに固定のブロック占有面積があり、ゲームは見つけた壁のスペースに収まる絵画しか配置しません。比率を間違えると、あなたのアートワークは単純に選ばれることがありません。
存在するスロットの形
51種類の絵画を、幅×高さ（ブロック単位）で分類すると次のようになります：
| サイズ | 数 |
|---|---|
| 1x1 | 8 |
| 2x2 | 12 |
| 3x3 | 9 |
| 4x4 | 5 |
| 4x2 | 5 |
| 2x1 | 5 |
| 1x2 | 3 |
| 3x4 | 2 |
| 4x3 | 2 |
この非対称性に注目してください：4x2は存在しますが2x4は存在せず、1x2も2x1も別々に存在します。向きは自動で反転されません。
画像が弾かれる理由
絵画のテクスチャは、配置された壁に合わせて引き伸ばされるわけではありません。ゲームは宣言されたサイズが利用可能なスペースに一致する絵画を選び、そのサイズでテクスチャを描画します。つまり、元画像は対象スロットの正確なピクセル寸法で作成する必要があります。
1x1の絵画は16x16テクスチャ — 256ピクセルです。4x4の絵画は64x64です。これらはテクスチャ形式の定義上の特性であり、レジストリデータではないため、リサイズ時に実際に必要となる数値です。
横長のパノラマ画像を用意しても、壁に1x1スロットしか空いていなければ何も表示されません。パックは問題なくても、配置が合っていないのです。
JavaとBedrockでここが異なる
Javaのリソースパックは、バニラの絵画レジストリとテクスチャアトラスを通じて絵画を扱います。Bedrockは独自のパックマニフェスト構造と異なるフォルダレイアウトを使用します。アートワークファイル自体のPNG寸法は同じですが、一方のエディション用に作られたパックはもう一方では読み込まれません。別々に作成し、ダウンロードしてください。
Bedrock側はパックのバージョン管理もより厳格なため、今日動作するパックでも、絵画に変更がなくてもゲームアップデート後にフラグが立てられることがあります。
実践的なマッチング
画像からではなく、壁から逆算して考えてください：
- 壁をブロック単位で測ります。幅3、高さ2の隙間には3x2の絵画しか入りません — そして上のリストに3x2は存在しないため、その隙間は空のままです。
- 何かをリサイズする前に、元画像のアスペクト比を実際に存在するスロットに合わせてください。
- エディションごとに1つのパックを保ってください。JavaとBedrockのアセットを混ぜると、どちらでも読み込まれないパックになります。
このツールは、アップロードした画像をその形に合うスロットにマッチングし、完成したパックをCustom Paintings用に返します。