FIELD NOTES
NOTE 03 · FROM IMAGE TO MODEL
設定画から、ゲームに入るモデルへ
大規模モデルに 3D キャラクターを直接作らせる試みが失敗したあと、タスクをもっと狭い工程へ分解した。その経路の記録。
以下は開発者個人の記録で、内部マイルストーン、技術判断、失敗の経緯を含みます。現在の状態を述べるものであり、最終形でも、リリースの約束でもありません。
通らなかった近道
最初、私は設定画からそのままゲームに入れられるモデルを得たいと思っていた。
発想としては筋が通っている。設定画には造形も配色も武器も決まっている。 モデルはその三次元版にすぎない。ならば十分に強いモデルに図を渡してメッシュを推論させるのが 最短距離のはずだ。
問題はすぐに出た。
「見栄えが悪い」のではない。生成物はしばしば見栄えが良かった。問題はこうだ。
- 構造が成立しない。 正面図と上面図が同じ物体の二つの投影になっていない。
- 手が読めない。 握りはどこか。武器はどちらの手から出ているのか。説明できない。
- 武器のシルエットが潰れる。 斧刃の歯列、剣の幅、盾の厚み。全部が「だいたいそんな感じ」になる。
- そして致命的なのは、検証できないこと。 意味の曖昧なメッシュに向かって 「ここが違う」とは言えない。「ここ」がどこか説明できないからだ。 どこが間違っているか言えないものは、直しようもない。
だから止めた。モデルの性能が足りないからではなく、問いの立て方を間違えたからだ。
二、タスクを狭くする
そのあと、一段ずつ単独で合否判定できる狭い工程に分解した。
- ビジュアルの意図を固定する。 プロダクションシートは参考画像ではなく構造契約だ。 一枚に含むもの：一つのキャラクター身元、一貫した正投影/多角度ビュー、シルエット、 パレット、装備の分離、パーツ分解、寸法の手がかり。どのビューでも同じ身体、衣装、 パレット、利き手、武器寸法、アタッチ数を保つ。
- ゼロコストの事前チェック。 有料呼び出しの前に：単一被写体、同一身元、同一ポーズ、 四肢の完全性、正しい利き手、サイズとハッシュ、正/側/背と真の正投影上面図の一貫性監査。 上面図が食い違うときは、まず入力を直してバージョンを切る。 生成ツールに入力契約の責任を負わせない。
- Meshy はベース形状だけ。 image-to-3D / multi-image-to-3D。既定は
should_texture=false、should_remesh=falseのトポロジー優先タスクで、 一度に一つの形状仮説にだけ答える。 - ローカルの決定論的派生。 メッシュと構造の修復、比率補正、パーツ分割、色の束ね直し。
- リジッドパーツの装着とアニメーション適合。
- Godot へ取り込み、実機で検証。
- 人によるビジュアル承認。
3 段目だけが有料で、3 段目だけが不確定だ。それ以外はすべて決定論的なローカル工程になる。
三、ランタイムでボーンを使わない理由
Godot 側には、聞くと妙に思われるハードルールがある。
キャラクターは Skeleton3D、Skin、BoneAttachment3D を使わない。
ビジュアルアダプタはこれらのノードを含むリソースを能動的に拒否する。
キャラクターは rigid_parts だ。論理パーツごとに一つのマージ済み ArrayMesh で、
共通のボクセルピッチ（0.019 m）を共有する。ランタイムは生の GLB を決して読まない。
Meshy のソース GLB はアーカイブ資料として art/source/meshy/ の下にあり、
.gdignore、クレジット台帳、SHA-256 レジストリを伴い、決定論的な派生チェーンの入力としてのみ存在する。
なぜそうするのか。
- ボクセル調のキャラクターはもともとブロックの集まりで、リジッドパーツで見た目の損失がない；
- マージ済みメッシュはドローコールを制御できる。敵が 20 体並ぶときこれは効く；
- そして何より、検証できる。リジッドパーツは正しい位置にあるか、ないかのどちらかだ。 スキンウェイトの「ちょっと変」は検証器に書けない。
ゲームロジックは visual_id とアクション名しか知らない。
モデルがどのチェーン由来か、何パーツか、Meshy 派生か純 Godot のフォールバックかは知らない——
バックエンドの切り替えはランタイムオプション一つで済む。
四、キャラクターの比率は数字であって、感覚ではない
承認にはランタイムの身長比が明記されている。Goblin 0.68、Swordsman 1.00、
ordinary Minotaur 1.72、Boss 2.45。
これは重要だ。生成ラスタでは見かけのスケールが圧縮されていて、 その図はランタイム寸法に対して権威を持たない。承認は図の比率を明示的に無効化し、 この数値だけを認めている。
忠実度はレンダリングされたシルエットの IoU で測る。しきい値は一律 0.55。
| キャラクター | シルエット IoU |
| --- | --- |
| Swordsman | 0.611897 |
| Goblin | 0.600124 |
| ordinary Minotaur | 0.681249 |
| Boss | 0.560647 |
Boss はしきい値のすぐ上だ。「ぎりぎり通った」を正直に表しているので、この数字を残している。
五、ボスは一度差し戻した
邪悪なミノタウロスの作り直しはこう進んだ。
V4 は却下。 理由は二つで、どちらも正式な boss_roar フレームで見えたものだ。
解剖学的な左手首/腕に構造の断絶があること。三日月形の斧刃が十分に鋭くないこと。
この二つの性質に注意してほしい。これらは命名された構造欠陥であって、 「なんとなく良くない」ではない。この区別が次の一手を決める。 命名された欠陥は修正フローに入れるが、純粋な好みの不満はそこで STOP にできる。 どちらもランダムな振り直しにはしない。
V4 はバイト不変の却下履歴として残る。 削除も上書きもされない。
V5 はその二つの欠陥だけを対象にした、追加のローカル修正。
V6 で手首を作り直し（幅広から細身へ連続的に絞るアーマードブレーサー一本）、 武器頭を差し替えた——より大きな、七歯六谷、両面に牛角の目の部族紋様を持つ斧に。
V6 が通ってランタイム昇格に入った。この間、しきい値をこっそり緩めたことはない。 「限界的な失敗はまず派生を直す。formal で探りを繰り返さない。しきい値を逆に緩めない」は ルールとして書いてある。
Goblin と ordinary Minotaur の回復はもっと長かった。Phase A、Phase B Wave-1、 Wave2 の v2 から v6 まで。最終的に Wave2-v6 で現在の結果を受け入れ、 自分から打ち切った。完璧だからではなく、反復を続ける限界利益がコストを下回ったからだ。 この停止ルールも文書に入っている。v7、Phase C、有料の修正を再び開くには、 新しい明示的な再開の判断が要る。
Wave2-v6 の正式な機械封印は 192 個のアーティファクトを覆う。
ランタイム昇格そのものは、新しいネットワーク呼び出しも生成タスクもクレジット消費も生んでいない——
ポインタを差し替えただけだ。
六、いま名簿に載っているのは
正式に公開しているのは確認済みのものだけ。剣士、ヴァンパイア、ゴブリン、 ミノタウロス、邪悪なミノタウロス。
公式サイトのキャラクターページで CLASSIFIED と書かれたシルエットは、もったいぶりではない。 リポジトリに実在しつつ、まだ承認フローを終えていないものに対応している。 正式に確定するまで、名称も背景も造形も公開しないし、 現在のデザインが最終であるとも示唆しない——このプロジェクトの履歴を見るかぎり、 たぶん最終ではないからだ。
七、この経路から学んだこと
AI は「定義のはっきりした問題を最後までやる」ことに非常に強く、 「問題を定義してくれる」ことには非常に弱い。
最初の失敗はツールの性能ではなく、自分でも整理できていないタスクを渡したことが原因だった。 「ゲームに入るキャラクターをください」を 「この五枚の一貫した正投影ビューから、これらの占有率制約を満たすベース形状を出してください」に 言い換えた瞬間、成功率は変わった。
もう一つ、たぶんこちらのほうが大事だ。失敗のための場所を空けておくこと。 却下された V4 はバイト不変のままリポジトリにいる。Event ゼロのランも記録に残っている。 成功しか残さない工程が記録するのは、実際の開発過程ではなく、 あとから整えられた物語のほうだ。