REASON 01
できたらすぐ中を歩ける
Unityでは、モデルが最初からエンジンの中にありました。そのためASTRAの作業が終わった瞬間に、開発者は一人称視点で中へ歩いて入り、等身大の感覚で直すべき箇所を確かめられました。開発者の説明では、Blenderのモデルをキャラクターコントローラーでプレイテストするには、まずエクスポート、インポート、コライダーの設定が必要です。
制作事例 · GPT-6 ASTRA × UModeler X × PicoBerry
GPT-6 ASTRA：Blender vs Unity — 2度作られ、エンジンの中で仕上がった同じコロッセオ
ある開発者が、GPT-6 ASTRAに同じ仕事を2回頼みました。現在の姿のコロッセオを、Blenderで1回、UModeler Xを導入したUnityで1回モデリングすることです。2つの結果は一致したため、制作はUnityで続けることになりました。Unityでは、できたその場から一人称視点で中を歩けます。観客はPicoBerryが用意しました。以下の時刻はプロジェクトのログとリビジョンごとのメモに基づき、足りない部分は開発者本人の説明で補っています。
Unityの中の古代のコロッセオ。建物の大部分は、ASTRAの仕様をもとにしたUModeler Xのシェイプで、観客はPicoBerryのモデルです。
使用ツールGPT-6 ASTRABlenderUnityUModeler XPicoBerry API
GPT-6 ASTRAがうまくモデリングできるのは、BlenderとUnityのどちらですか？
このテストでは、差はつきませんでした。GPT-6 ASTRAは、図面を含む200枚のリファレンス画像を読み込んで、メートル単位の仕様1つにまとめました。その仕様から、Blenderと、UModeler Xを導入したUnityの両方でコロッセオを組み上げています。どちらのビルドもメッシュは6,254個、最も高い部分は48.5mです。ログでは、Blenderでのビルド開始から両者の突き合わせまでが28分でした。差が出たのは、ビルドのあとです。Unityでは、モデルができたその場から一人称視点で歩けました。しかもメッシュのうち4,926個がUModeler Xのパラメトリックシェイプで、編集できる状態のまま残っています。そこで開発者はUnityでシーンを仕上げ、PicoBerryのモデル20体から配置した3,917人の観客で、観客席を埋めました。
同じ仕様から、BlenderとUnityでは何ができあがりましたか？
初日、9月14日。ASTRAが数値を書いたのは一度だけで、それぞれのツールがその数値から、1 unit = 1 mで組み上げました。どちらのビルドも大部分が単純な形状なので細かなディテールはありませんが、形と比率は図面に沿っています。
| Blender | Unity + UModeler X | |
|---|---|---|
| メッシュ数 | 6,254 | 6,254 |
| UModeler Xのパラメトリックシェイプ数 | — | 4,926 |
| 三角形数 | 319,260 | ログに記録なし |
| 最も高い部分の高さ | 48.5 m | 48.5 m |
| 身長1.8mの人物でのスケール確認 | 通過 | 通過 |
| バージョン | Blender 5.1 | Unity 6000.3 (URP), UModeler X 1.3.0 |
ログより（KST）：19:00 Blenderでのビルド開始 · 19:09 仕様ファイルcolosseum_spec.json（2.2MB）とunity_spec.json（2.6MB）を出力 · 19:10 Blenderが18MBのFBXをエクスポート · 19:11 Blenderのチェックを通過 · 19:28 両者の比較が完了。開発者本人の見立てでは、ビルドはそれぞれ約11〜15分です。
なぜUnityで制作を続けたのですか？
数字では勝敗がつきませんでした。決め手になったのは、それぞれのツールで、開発者が次に何をできたかです。
REASON 02
数値を持ち続けるシェイプ
UModeler Xのシェイプは、パラメーターを保持します。アーチを選べばインスペクターにRadius1、Radius2、Depth、Angle、Sidesが表示され、階段を選べば段の設定が表示されます。数値を入れるのはASTRAですが、あとから誰でも変更できます。
REASON 03
リファレンスとモデルを同じ画面に
ディテールを詰める段階では、開発者がUnityのビューポートをリファレンス写真のアングルに合わせ、その写真をASTRAに渡しました。モデルと、照合の基準になる写真が同じ画面に並んでいて、ツール間の往復はありませんでした。
ASTRAの変更は、どうやってUnityのシーンに反映されたのですか？
開発者の説明では、ASTRAはエディターを一度も遠隔操作していません。ASTRAがファイルを書き、それをUnityがシーンに適用しました。
| ファイル | 中身 | このプロジェクトでの例 |
|---|---|---|
| 仕様 | モデル全体を数値で表したもの | colosseum_r2_spec.json … colosseum_r5_unity_spec.json |
| 差分 | 前のリビジョンから変わった部分 | unity_r2_delta.json, unity_r4_rebuild_delta.json |
| パッチ | 箇所を絞った修正 | unity_r2_patch.json, unity_r4_final_patch.json |
変更はすべてファイルになっています。そのため、どのリビジョンにも戻せますし、2つのリビジョンの違いも読み取れます。同じ仕様を、BlenderにもUnityにも渡せます。初日の比較が公平に保てたのも、この仕組みのおかげだと開発者は言います。
リビジョンを重ねた1日は、どう進みましたか？
9月15日（KST）。R2が11:35に完成し、8時間半後の20:05にR8が確定しました。R2〜R4は同じ仕様から両方のツールで作り、R5以降はUnityだけです。時刻が1つだけのものは、その工程が終わった時点を示します。
- R2：実際の遺跡に合わせて長軸を約19.94°回転。放射状の壁を抜けるアーチ、中間の回廊、アリーナ下の通路を追加。
- R3：地下を長手方向の壁14枚で作り直し、そこから1階へ、さらに3階まで上る階段を配置。
- R4：公開資料が示す位置へ階段を移動。根拠は、ポディウム（アリーナを囲む基壇）に関する2022年の研究、コロッセオ考古学公園による2023年の見学ルートの案内、アーチの補修に関する研究。
- R5：書き込み入りの断面図から階段13か所と、それらをつなぐ階段を追加。すべてUModeler XのStairシェイプ。最上層は、高さ31.8mの回廊と高さ37.9mのテラスに分割。
- R6：作業の場を建物の内部へ。
- R7：構造をリファレンスと照合し、内部を安全に歩ける状態に整備、床の継ぎ目を解消。
- R8に向けた階段の作業。所要14分。
- 436個に分かれていたアリーナの壁を、UModeler XのQuadStrip 4つに統合。
- R8を確定。
| リビジョン | メッシュ数 | パラメトリックシェイプ数 | 歩行チェック |
|---|---|---|---|
| R2 | 7,376 | 5,870 | 階段4区間を上り下り（1.8mのコライダー） |
| R3 | 11,890 | 8,493 | Unity：上り5,064回、下り5,063回の移動／Blender：921地点 |
| R4 | 11,787 | 8,315 | Unity：上り下りそれぞれ5,431回の移動／Blender：1,048地点 |
| R5 | 12,144 | 8,660 | Unity：37ルートを往復で計74回 |
R2〜R5のリビジョンのメモには、上の表の歩行チェックが記録されています。R3〜R5のUnityでのチェックでは、身長1.8mのCharacterControllerを各ルートの始点に置き、テレポートを使わずに移動させて、段差で行き詰まることはありませんでした。Blenderでは、ルート上の各地点で床との接地と体まわりの空間をチェックしています。ただし、どのチェックも建物のすべての部屋を対象にしたものではありません。
階段の作業は、なぜ14分で済んだのですか？
開発者の説明によれば、UModeler Xの階段は、削り出すジオメトリではなく、数値を持ったシェイプだからです。
UModeler XのStair（階段）は、幅、段の高さ、段数、全高、奥行きをパラメーターとして持っていて、ASTRAはその数値を図面から埋めていきました。開発者本人は「AIは形を削っているのではなく、数字を埋めている」と言います。完成したシーンには、Stairシェイプが253個あります。
14分9月15日の階段の作業（17:27〜17:41）
253完成したシーンのStairシェイプ
17,927完成したシーンのUModeler Xのパラメトリックシェイプ
最適化で、何が変わりましたか？
R8のシーンと、読み込みを最適化した9月16日のシーンについて、シーンファイルを比べて測りました。
| 最適化前 | 最適化後 | 増減 | |
|---|---|---|---|
| GameObject数 | 30,950 | 26,078 | −15.74% |
| MeshRenderer数 | 27,859 | 22,803 | −18.15% |
| シーンファイルのサイズ | 181.2 MB | 135.0 MB | −25.5% |
開発者がとくに挙げている工程は、この最適化より前、9月15日の夕方にありました。436個に分かれていたアリーナの壁を、捨てずに4つのQuadStripへまとめ直したことです。開発者の言葉を借りれば、曲線を1本引っぱれば壁がそれについてくるので、まとめたあとのシーンも編集できるままです。
遺跡はどうやって観光地になり、さらに古代の闘技場になったのですか？
そのあと、さらに2つのシーンが作られました。
現在の遺跡については、ローマの観光地らしい雰囲気を出すため、開発者が周りに店と通りを頼みました。昼、夜、朝のバージョンは9月16日の14:59から15:25のあいだにできあがり、3バージョンで26分でした。ここに載せた画像に写っているのは、広場に建つ遺跡と数本のカサマツで、店や通りは見えていません。
2つ目のコロッセオでは、開発者が公式サイトの内部構造データと実際の断面画像をリファレンスに加え、古代の姿の建物を頼みました。ASTRAは円環の4分の1を作り、それを複製して回転させることで全体を完成させています。天幕、すべての座席、皇帝席は、そのあとに加わりました。
なぜ観客はPicoBerryで作ったのですか？
観客席に人が入るとシーンは生き生きとしましたが、その人たちはASTRAが基本形状で作ったもので、近くで見るとそれが一目でわかりました。
そこで開発者はPicoBerry APIをつなぎ、ASTRAに観客の置き換えを頼みました。ASTRAは、座ったり歓声を上げたりするローマ人20体の依頼を送りました。顔ぶれは貴族、兵士、商人、子どもなどで、どれもPB Ultra向けのテキストプロンプトです。9月17日の15:29:46〜15:33:35、4分足らずのうちに20件すべてを送っています。プロンプトはそれぞれ、まず画像になり、次に3Dモデルになりました。シーンでは、その20体で観客席の3,917か所を埋めています。開発者の説明では、モデルはそのままシーンに入りました。それに先立つ同じ日の午後、15:04には、ASTRAが座った観客のプロンプト1つを、PicoBerryの3つのAIモデル（Hunyuan 3.1、PB Ultra、PB Slim 2）で試していました。下に並べたのは、PB Slim 2とPB Ultraの結果です。
20テキストプロンプトからPB Ultraで生成したPicoBerryのモデル
3,917その20体で埋めた観客席の数
4分未満ASTRAが20体すべてを依頼するまで（9月17日 15:29:46〜15:33:35 KST）
貴族の男性
元老院議員
兵士
商人
労働者
貴族の女性
年配の女性
母と子
歓声を上げる少女
座る少年PicoBerryの観客20体のうち10体（生成されたままの状態）。
内部から見ると、どんな様子ですか？
Unityのビルドには初日から、身長1.8m、目の高さ1.65mの一人称視点のコントローラーがありました。完成したコロッセオには、観客のあいだを歩いて出入りできるよう、開発者が一人称視点のコントローラーの追加を頼んでいます。
このモデルには、どんな限界がありますか？
リビジョンのメモがこの点に慎重なので、このページもそれにならいます。
LIMIT 01
デジタルツインではない
公開されている図面、写真、論文をもとに作った、実寸大の解釈モデルです。個々の石や崩れた境目までは一致しない場合があり、リビジョンのメモにもそう書かれています。
LIMIT 02
階段の位置は解釈
R4では公開資料が示す位置に階段を移しましたが、その座標はモデルへの入力値で、測量データではありません。1階と2階のあいだの階段は、詳細な平面図がないまま、考古学公園による区域の説明に沿っています。3階へ上る階段は、アーチの補修に関する研究の図をもとに配置されています。
LIMIT 03
fpsの数値は示さない
シーンの読み込み時間は、実測で5.4秒と5.1秒でした。パフォーマンスのプロファイリングは行われていないため、このページではfpsの数値を示しません。
LIMIT 04
勝負ではなく、パイプラインの比較
どちらのビルドも、ASTRAの仕様に従っています。このテストが示すのは、同じ仕様から各ツールで何ができるかであって、各ツールで到達できる最高の結果ではありません。
よくある質問
GPT-6 ASTRAは、平面図から建物をモデリングできますか？
今回は、プロトタイプとしてできました。開発者が図面を含む200枚のリファレンス画像を渡すと、ASTRAはそこから寸法を読み取り、メートル単位の仕様を書いて、それをもとに組み上げました。形と比率は図面に沿っていますが、細かなディテールまでは再現できていません。どちらのビルドも、大部分が単純な形状で作られているためです。プロジェクトのメモは、これを測量レベルの複製ではなく、実寸大の解釈モデルと呼んでいます。
AIでのモデリングでは、UModeler XはBlenderより優れていますか？
品質の面では、そうとは言えません。このテストでは、初日のビルドは両方に記録されたすべての数値で一致しました。一致したのはメッシュ6,254個と最も高い部分の48.5mで、身長1.8mの人物でのスケール確認も、どちらも通過しています。UModeler Xの利点は、実用面にありました。モデルはエンジンの中で、すぐにプレイして確かめられる状態でした。シェイプもパラメーターを保持したままなので、あとからの変更は、新しいジオメトリを作らずに数値を編集するだけで済みました。
UModeler Xのパラメトリックシェイプとは何ですか？
作ったあとも設定を持ち続けるシェイプです。アーチならRadius1、Radius2、Depth、Angle、Sides、階段なら幅、段の高さ、段数、QuadStripなら曲線を保持します。ASTRAはこれらの数値を図面から設定しましたが、今もUnityのインスペクターで編集できます。完成したシーンには17,927個あり、そのうち253個が階段です。
GPT-6 ASTRAは、Unityとどう連携しましたか？
ファイル経由です。ASTRAはモデルをJSONの仕様として書き、以降の変更はそのつど差分かパッチとして書いて、それをUnityが適用しました。最初のビルドは、ASTRAが書いたエディタースクリプトから作られています。開発者の説明では、ASTRAがエディターを直接操作したことはありません。開発者はPowerShellからASTRAを動かしていました。どのリビジョンも元に戻せて、1つの仕様をBlenderとUnityの両方に渡せたのは、変更をすべてファイルに残したからです。
PicoBerryは、観客をどうやって作ったのですか？
ASTRAがAPI経由で送った20件のテキストプロンプトを、PicoBerryはそれぞれ画像にしてから、PB Ultraで3Dモデルにしました。ASTRAは20件すべての依頼を、4分足らずのうちに送っています。シーンでは、それらで観客席の3,917か所を埋めています。これらは、ASTRAが基本形状で作っていた観客と入れ替えたものです。建物そのものは、大部分がASTRAの組んだUModeler Xのシェイプです。
コロッセオの制作には、どれくらいかかりましたか？
開発者本人の見立てでは、実際の作業時間は約12時間です。ログからわかるのは、次の区間の所要時間です。9月14日の初日の比較に28分、15日のR2完成からR8までに8時間半（うち階段の作業に14分）、16日の観光地の3バージョンに26分、そして17日には、ASTRAが観客20体を依頼するのに4分足らずです。
開発者は、手作業で何かモデリングしましたか？
ログに残っているのは、モデリングではなくディレクションです。開発者はリファレンスを用意し、ディテールを詰める段階ではビューポートをリファレンス写真に合わせました。店、古代版、完成したコロッセオでの一人称視点のコントローラー、PicoBerryの観客を頼み、リビジョンごとの確認もしています。開発者の説明では、シェイプそのものを配置したのはASTRAです。
Blender、Unity、UModeler Xは、どのバージョンを使いましたか？
Blender 5.1、URPを使ったUnity 6000.3、UModeler X 1.3.0です。遊べる公開ビルドはありません。