あなたのデスクを3Dサーキットに:写真撮影からモデリング、画面録画までの完全実践ガイド
Desk Racerの制作手順を、写真の準備からモデリング、走行操作、画面録画まで解説。Gemini、Blender MCP、Three.jsを使う手順に、中国語・英語字幕の制作過程動画と15組の日英対訳プロンプトを添えました。
GoogleのデベロッパーリレーションズエンジニアであるGeneviève Huskens氏が、Gemini 4 Argonを活用して自身のデスクをサーキットへと変貌させた刺激的な事例を公開しました。スマートフォンで自分のデスクを複数枚撮影し、Google Antigravity環境内でGemini 4 Argonモデルを呼び出し、エージェントによるタスクオーケストレーションを通じてBlender MCPとThree.jsを連携させることで、キーボードやディスプレイ、卓上小物をブラウザ上で実際に走行可能な3Dデスクトップレースゲーム『Desk Racer』へと作り上げました。
このようなゲームを手作業で制作する場合、小物の配置やスケール調整、モデリング、マテリアル設定を行った上で、操縦・衝突判定・カメラ制御のコードをすべて記述する必要があります。しかし今回のワークフローでは、AIが多角的な写真からデスク上の空間レイアウトを直接解析し、Model Context Protocol(MCP)経由で3DモデリングソフトにPythonスクリプトを注入してジオメトリを生成します。さらに、フロントエンドの描画や車両制御のコードを自動生成し、ブラウザの実行環境からスクリーンショットを撮って視覚的な欠陥を自己批評しながら、マテリアルやライティングを段階的にブラッシュアップしていきます。
彼女にとって、本格的な3Dプロジェクトの制作は今回が初めてでした。実践にあたっては、写真がレイアウトの基準となり、あなたがコースの取り回しやビジュアルスタイルを決定し、AIがそれらの指示をモデル、コード、そしてプレイ可能なシーンへと落とし込みます。
制作ルートの選択:オンライン版のリミックスか、ローカルでの独自コース構築か
まず各ツールの役割を把握しておきましょう:
| ツール | このプロジェクトでの役割 |
|---|---|
| Gemini 4 Argon | 写真の解析、要件のヒアリング、計画策定、コードの記述と修正 |
| Nano Banana | コンセプトアートや木目・路面などのテクスチャ生成 |
| Blender MCP | エージェントがPythonスクリプト経由でモデリングを行い、GLBプロップ(小物)を出力 |
| Three.js | ブラウザ上でシーンを読み込み、グラフィックを描画して操縦操作に応答 |
シンプルなローポリゴンシーンだけで十分な場合は、Three.jsの基本ジオメトリのみを使い、Blenderを省略することも可能です。より細かなプロップ構造が必要になった段階でモデリング工程を追加してください。
【ルートA:オンラインでのクイック体験&リミックス (AI Studio)】
ローカル環境不要 ──> ブラウザでDesk Racerを開く ──>「Remix」をクリック ──> マシンの速度やコースカラーを直接編集
対象:操作感をいち早く試したい方、既存のコード構造を観察したい方、ローカル環境をまだ整えていない方。
【ルートB:自分のデスクをコース化 (ローカル完全パイプライン)】
スマホでデスクを撮影 ──> Antigravity / エージェントオーケストレーション ──> Blender MCP (モデリング) ──> Three.js (プレイ可能なゲーム)
対象:自分の作業環境や自室のデスクを専用の3Dシーンに変換し、ハイクオリティなデモ動画を録画したい方。
1. ルートA:オンライン体験とリミックス(インストール不要)
Google AI Studioのアプリギャラリーにて、『Desk Racer』のオンライン実行ページが公開されています。このページでは以下の機能がすぐに利用可能です:
- プレビューと操作:ゲーム画面をクリックして開始し、
Wで加速、A/Dでステアリング、Sでブレーキ。数字キーの1(追従視点)、2(コックピット視点)、3(デスク全体俯瞰)、4(ドローン巡回)でカメラアングルを自由に切り替え可能。Enterで3ラップのタイムアタックが始まります。 - ソースコードとアセットへのアクセス:ページ上部に
Preview(リアルタイム画面)、Code(Three.jsおよび物理挙動のスクリプト)、Artifacts(モデルやテクスチャアセット)、そしてRemix(自身のクラウドプロジェクトとしてフォーク複製)が用意されています。 - リミックスの手順:Remixをクリックして既存プロジェクトを自身の環境に複製後、アシスタントに修正指示を出せます。速度やカラーの変更なら効果をすぐに確認できます。自分のデスク環境に置き換えるには、プロップ配置やアセットの再設計が必要です。
2. ルートB:ゼロから構築する専用デスクサーキット
独自に構築する場合、AIモデルに現実の空間ジオメトリを把握させる必要があります。原作者のデモでは、Gemini 4 Argonで制御されるBlender MCPパイプラインが使用されました。なお、作者が利用したヘッドレス(Headless)Blender MCPの具体的な導入設定は公開されていないため、本ガイドでは公開の導入ドキュメントがあり、Blenderを起動したまま使用する公開版デスクトップ用mcp-for-blenderを代替ルートとして採用し、ローカル実行のThree.jsプロジェクトと組み合わせて写真からゲームまでのサイクルを完結させます。
アカウントおよび環境の前提条件:
公式デモ環境において、Gemini 4 ArgonはAntigravity内ではGoogle AI Ultra登録者向けに提供され、AI Studio Build内ではUltraまたは請求先登録済みの有料Gemini APIユーザー向けに提供されています。各プラットフォームのモデル選択肢やクォータポリシーは変動するため、現在お使いのワークスペースで実際に利用可能なモデルをご確認ください。Cursor、VS Code、Claude Desktopなど、他のMCP対応コーディング環境で実践する場合も、自然言語で該当MCPプロトコルを呼び出すことでモデリングやプロジェクト構築が可能です。その際は、使用するツールがファイル編集、MCP呼び出し、スクリーンショット取得、タスクの自律継続実行に対応しているかをそれぞれ確認してください。
フェーズ1:Blender MCPとThree.jsのローカル開発環境のセットアップ
AIに3Dソフトウェアを操作させ、ウェブゲームを動かすには、PC内に「コードアシスタント ↔ 3Dモデリングツール ↔ ウェブレンダリング環境」という連携パイプラインを確立する必要があります。
制作プロセス動画の15秒付近。白木調の天板、ディスプレイスタンド、キーボード、デスクライトなど、変換対象となる実物のプロップが示されています。
本記事のプロンプトは、実践向けに書き直した学習用テンプレートです。寸法、ライティング数値、目標フレームレートは学習用の初期値ですので、実際のデスクの計測値やPCの性能に合わせて調整してください。なお、原動画の録画・編集ソフトは公表されていないため、後半の録画手順は本ガイドによる補足内容です。
1. 基本依存関係とソフトウェアの導入
開始する前に、各公式サイトから以下の4つの基本ツールをダウンロードし、インストールしてください:
- Google Antigravity(またはCursor、VS Code、Claude DesktopなどMCPクライアントに対応したエディタ)。
- Blender 3.0以上:オープンソースの3Dモデリング統合環境。インストール後、正常に起動して3Dビューポートが表示されることを確認してください。
- Node.js LTS:JavaScriptランタイム環境。ローカルフロントエンドサーバーの起動に使用するnpmパッケージマネージャーが同梱されています。
- uvパッケージマネージャー:システム全体のPython環境を汚染することなく、Pythonツールパッケージを迅速に実行するためのツール。
- macOS ターミナルでのインストール:システムにHomebrewが導入されている場合は
brew install uvを実行。Homebrew未導入の場合は公式スクリプトを直接実行します:curl -LsSf https://astral.sh/uv/install.sh | sh - Linux ターミナルでのインストール:
curl -LsSf https://astral.sh/uv/install.sh | sh - Windows PowerShellでのインストール:
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
- macOS ターミナルでのインストール:システムにHomebrewが導入されている場合は
2. Blender MCPアドオンのインストールと有効化
ここではコミュニティのオープンソースプロジェクトであるmcp-for-blenderを使用します。ローカルのTCPソケット通信を通じて、外部のエージェントからBlenderへPythonスクリプトを注入し、形状データを取得できるようにします。
ターミナルで以下のコマンドを実行し、Blenderにアドオンを自動インストールします:
uvx mcp-for-blender install-addon
インストール完了後、以下の設定を行います:
- Blenderを起動し、上部メニューの Edit(編集)→ Preferences(プリファレンス)→ Add-ons(アドオン) を開きます。
- 右上の検索窓に
MCP for Blenderと入力し、チェックボックスをオンにしてアドオンを有効化します。 - 3Dビューポートに戻り、半角英数入力の状態でキーボードの
Nキーを押し、右側のサイドバーを展開します。 - タブを選択し、ステータスが起動中(Started)になっていることを確認するか、Start MCP Serverをクリックします(デフォルトの監視ポートは
9876)。 - 以後のすべての生成処理中、Blenderのウィンドウは常に開いたままにしてください。
3. Antigravity MCP接続の設定
Antigravityでは、プロジェクト単位またはグローバルの設定ファイルから本サービスへ接続できます:
- グローバル設定パス:
~/.gemini/config/mcp_config.json - プロジェクト専用パス:プロジェクトルート直下の
.agents/mcp_config.json
既存のmcpServersキー内に以下を追記します(他の既存サービス設定を誤って削除しないよう注意してください):
{
"mcpServers": {
"blender": {
"command": "uvx",
"args": ["mcp-for-blender"],
"env": {
"BLENDER_HOST": "localhost",
"BLENDER_PORT": "9876"
}
}
}
}
トラブルシューティング:起動時にspawn uvx ENOENTというコマンド未検出エラーが出る場合、GUIエディタがシステムターミナルの環境変数を引き継げていません。macOS/Linuxターミナルでwhich uvx(Windows PowerShellではwhere.exe uvx)を実行し、出力された絶対パス(例:/opt/homebrew/bin/uvxやC:\Users\username\.local\bin\uvx.exe)で設定内の"command": "uvx"を置き換えてください。
接続確認チェックポイント:
AIエディタを完全に再起動し、エージェントにテスト指示を送信します:「blenderツールを呼び出し、現在のシーン情報を読み取った上で、TestCubeという名前の赤い立方体を新規作成してください」。Blenderのビューポート内に即座に赤い立方体が生成され、AIがオブジェクト名を正しく報告すれば、3D制御パイプラインは開通しています。
4. プロジェクトディレクトリの作成とThree.jsのインストール
まずはプロジェクトディレクトリと依存関係を構築します。コンセプトと計画を確定させた後、フェーズ4でHTMLとゲームコードを生成します。
OSに合わせてディレクトリ作成と依存関係のインストールを実行します:
- macOS / Linux ターミナル:
mkdir desk-racer cd desk-racer npm init -y npm install three npm install --save-dev vite mkdir -p public/models mkdir -p public/textures mkdir src - Windows コマンドプロンプト / PowerShell:
mkdir desk-racer cd desk-racer npm init -y npm install three npm install --save-dev vite mkdir public\models mkdir public\textures mkdir src
npm installで書き込まれた依存パッケージのバージョンを保持しつつ、package.jsonに以下のフィールドをマージします。既存のdependenciesやdevDependenciesをファイルごと上書きしてしまわないようにしてください:
{
"type": "module",
"scripts": {
"dev": "vite",
"build": "vite build",
"preview": "vite preview"
}
}
ツールのセットアップが完了し、Blenderとの連携が確認できたら、写真撮影とビジュアル方針の検討へと進みます。本格的なゲームコードの生成はフェーズ4で行います。
フェーズ2:写真撮影、コースの外観と寸法の確定
まずNano Bananaでコンセプトアートを生成し、コースがどの物体を周回するか、照明のトーン(暖色系か寒色系か)、マシンのミニチュア感の度合いなどを比較検討します。ひとつの方向性を定めておくことで、その後のモデリングやライティング調整において共通の指針が得られます。
1. 実物の写真撮影とマルチモーダル参照素材の準備
参照素材には写真、スケッチ、あるいは物体周辺を写した約15秒の動画が利用できます。今回はデスクの全体像と主要なプロップを鮮明に捉えた写真があれば十分なスタート地点となります。
写真を撮影する際は、以下の4つのポイントを意識してください:
- 均一で十分な明るさ:屋内の均一で明るい照明下で撮影し、極端に濃い影によって物体の輪郭抽出が妨げられないようにします。
- 全体レイアウトの写真:デスクの前に立ち、天板全体が収まるアングルの写真を1〜2枚撮影します。ディスプレイスタンド、キーボード、マウス、マグカップなどの相対的な距離や向きを明確にします。
- 主要アイテムのクローズアップ:キーボードのキーやデスクライトの支柱に近づいて各1枚撮影し、厚みや素材の光沢・反射の質感を記録します。
- 不要な小物の片付け:乱雑な配線やティッシュなどは片付け、明確な幾何学的特徴を持つ文具や置物のみを残します。
コンセプトアートの生成後は、まずAIとともに2Dコンセプト画像をレビューして納得のいくビジュアル方針を選定し、確定してから3Dコードの記述に移ります。
公式のコンセプト立案プロセスの参考例(クリックで展開)
2. コンセプトアート生成プロンプト
撮影した写真をマルチモーダル画像生成インターフェースにアップロードし、以下のプロンプトを送信してコンセプトアートを生成します:
テンプレート1:実写デスク写真からのミニチュアレースコース概念図生成
日本語版(コピー用):
アップロードしたデスク写真に写っているアイテムの配置(ディスプレイ、メカニカルキーボード、マウス、デスクライトなどの小物)を解析してください。これらの実物を地形や障害物に見立て、ティルトシフトマクロ撮影のような強いミニチュアトイの質感を備えた3Dレースコースのコンセプトアートを1枚生成してください。
視覚的な要件:
1. 鮮やかな赤い小型カートがキーボードの前を疾走しており、車体サイズはメカニカルキーボードのキーキャップ1個と同程度であること。
2. コースは高架状のカーブ軌道で、赤白の減速縁石と柔らかく光る防護フェンスを備え、ディスプレイスタンドの下を軽快にくぐり抜け、マウスの周囲を周回していること。
3. ドラマチックな照明のコントラスト:暗めの部屋を背景に、画面奥からの深い紫のアンビエントライト、キーボードの隙間から漏れ出るシアンのバックライト、デスクライトが投げかけるコントラストの高い暖白のメイン光。
4. 全体として、精緻で小ぶりなミニチュアトイの世界観を表現すること。
英語版(本ガイドの学習用テンプレート):
Analyze the desktop layout in the uploaded photos (monitor, mechanical keyboard, mouse, desk lamp). Using these real objects as miniature terrain obstacles, generate a 3D racing concept art with strong tilt-shift macro toy aesthetic.
Key requirements:
1. A vibrant red miniature go-kart racing in front of the keyboard, scaled proportionally to single keycaps.
2. An elevated curved track with red-and-white rumble strips and glowing barriers, looping under the monitor stand and around the mouse.
3. Dramatic lighting contrast: dim room ambience, deep purple backlight behind monitor, cyan glow between keycaps, and warm white key light from desk lamp.
4. Premium stylized game aesthetics reminiscent of a micro miniature toy universe.
3. 複雑な配置や遮蔽物が多いデスク向けの2D空間設計(標準的なデスクでは省略可)
小物をシンプルに配置したデスクであれば、コンセプトアートの完成後すぐに次の段階へ進めます。ただし、多段ラックやデュアルモニタースタンドなど入り組んだ配置の場合や、マシンの走行ルートを実物の寸法に厳密に合わせたい場合は、実測寸法を基準スケールとして用意する必要があります。
まず天板の幅・奥行きと、主要なプロップの縦横・高さを計測します。次にArgonにメートル単位の寸法を入れた上面図PLAN/layout.svgを出力させ、写真に番号付きグリッドを重ね合わせます。オブジェクトの位置とコースのクリアランスを確認してからモデリングに入ることで、ディテールを作り込んだ後にコースがキーボードを貫通してしまうような手戻りを防ぎます。
テンプレート2:複雑なデスク向けの2D上面平面図とメートル座標生成(本ガイド改編)
日本語版(コピー用):
アップロードしたデスクの写真と実測寸法を確認してください。以下では幅1.2m、奥行き0.6mを例として記載していますが、まずは私のデスクやプロップの実際の寸法に置き換えてください。不足している数値があれば私に質問してください。
本シーンでは物体の隙間を正確に縫う必要があるため、現段階では3Dメッシュのコードは一切生成しないでください:
1. **2Dベクター平面図の生成**:メートル単位を用いて上面図の2Dベクター図を作成し、`PLAN/layout.svg`に保存してください。ディスプレイスタンド、キーボード、マウス、外枠の余白について、絶対的な縦横寸法と中心座標(原点は天板の幾何中心)を明記してください。
2. **参照番号グリッドの重畳**:軽量スクリプトを作成するかSVG内に直接、番号付きのX/Yメートルグリッド(0.05m間隔)を描画し、計画している周回コースのラインと主要なコーナリング制御点を明示してください。
3. **通行クリアランスの検証**:キーボードとディスプレイスタンドの間に確保されたクリアランスが、コース幅(0.08m)を超えているか確認し、干渉がないことを検証してから座標のまとめを出力してください。
上記の2D寸法検証が完了した後に、確定した絶対座標をもとに3D幾何メッシュを構築します。
英語版(本ガイドの学習用テンプレート):
Review my desk photos and measured dimensions. The example tabletop is 1.2m wide and 0.6m deep; ask me to replace these and supply the measured prop sizes before fixing coordinates.
Since this build requires spatial accuracy, do NOT generate any 3D meshes yet:
1. **Generate 2D Vector Plan**: Create a top-down 2D floorplan in metric units and save it to `PLAN/layout.svg`. Map out the exact bounding boxes and center coordinates for the monitor base, keyboard, mouse, and margins (origin at desk center).
2. **Numbered Reference Grid**: Overlay a numbered X/Y metric grid (0.05m spacing) across the layout, plotting the planned closed track loop and key spline control points.
3. **Clearance Verification**: Verify that the gap between the keyboard and monitor base exceeds the road width (0.08m) without collisions before outputting coordinate tables.
Once we verify these 2D spatial dimensions, we will use these locked coordinates to build the 3D scene.
フェーズ3:要件のヒアリングとタスクの分担実行
Antigravityで/grill-meコマンドを送信し、操作感やカメラ視点、プロップのモデリング方針についてモデル側から詳細を問い掛けさせます。フェーズ2のコンセプトアートを承認した後、PLAN.mdとそれに対応する/goalコマンドを生成させ、本格的な実行へと移行します。
1. ゲーム性・カメラ視点・モデリング手法の確認
実装に大きく影響する以下の質問に回答していきます:
- 「マシンの物理挙動は、軽快でクイックなアーケード寄りか、それとも慣性やドリフトを伴うシミュレーション寄りか?」
- 「デスク上のプロップはThree.jsの標準ジオメトリを組み合わせるか、それともBlender MCPを通じて面取りや独立座標を持ったGLBモデルとして構築するか?」
- 「高架コースとキーボードやディスプレイスタンドとの間にどう支柱の接地クリアランスを設け、モデルの突き抜けを防ぐか?」
標準的な実行手順:
- 素材入力とヒアリング開始:Antigravityで
/grill-meと入力し、デスクの参考写真をアップロードした上で、この時点ではまだ3Dコードを一切書かないよう指示します。 - コンセプトアートの確定:フェーズ2で選定したNano Bananaの画像を採用します。調整が必要な場合は候補を再生成させ、チャット画面またはMarkdown内で確認します。
- 計画の固定と長期ゴールの定義:開発者がコンセプトアートを承認しヒアリングに回答した後、モデルに段階的な実行計画を
PLAN.mdへ書き出させ、そのまま実行可能な/goalコマンドを生成させます。 - 自律ループの開始:その
/goalコマンドを実行します。モデルは「マシンがスムーズに周回できる」「マルチカメラが動作する」「アセットがエラーなく読み込まれる」といった具体的な検証基準に沿ってタスクを自律的に進めます。
2. 3つの専門ロールの役割分担と競合防止策
画像に示されているのは原作者の3つのサブエージェントです。実践時には、以下のファイル分担に沿ってタスクを割り振ることができます:
- 3D Desk & Props Architect(プロップ&シーン設計):Blender MCP経由でPythonスクリプトを実行し、ディスプレイスタンド、キーボード、マウスのローポリゴンメッシュを自動モデリングして
public/models/desk-props.glbに出力する。 - Nano Banana Texture & Logo Artist(テクスチャアーティスト):Nano Bananaを呼び出してシームレスな木目、アスファルト、コースの縁石テクスチャを生成し、Three.js用のマテリアル画像を提供する。
- Atmosphere & HUD Engineer(ライティング&UIエンジニア):Three.jsのスポットライト、環境ポイントライト、複数カメラの追従コントローラー、基本UIの設定を担当する。
コンフリクトを防ぐための共通規約: 並行処理を行うだけでは競合は防げません。以下の3つのルールを計画に明記し、総合統括エージェントがマージ結果を検証します:
- 共有の単位系と座標系:全ロールで単位をメートル(meters)に統一し、Three.jsのY軸上向き座標規約に準拠(Blender側ではZ=0を天板平面に対応)。天板の幾何中心を共通のワールド原点とします。
- 明確なファイル境界:サブエージェントはそれぞれ専用のファイル(
props.js、textures.js、lights.js)を独立して管理し、モジュールをまたぐ修正は統括役に調整させます。 - 統括エージェントによる統合:メインエージェントが
main.jsとtrack.js内で各アセットを取りまとめ、レイキャストによる当たり判定や支柱のアライメントを実行して、すべてのパーツが矛盾なく組み合わさるようにします。
テンプレート3:プロジェクト計画とアーキテクチャのキックオフ
日本語版(コピー用):
/grill-me 現在の `desk-racer` プロジェクトにおいて、私がアップロードしたデスク写真をベースに、3Dウェブ版ミニチュアカートレースゲームを構築します。
注意:この時点ではまだ3Dコードを一切書かないでください。
以下の手順で進めてください:
1. **要件のリバースヒアリング**:操作感(アーケードかシミュレーターか)、ライティングの雰囲気、デスク上の小物のモデリング手法について、重要な論点を質問してください。
2. **コンセプトアートの確認**:私が選定済みのNano Bananaコンセプトアートを優先して使用してください。未確定の場合はコースの取り回しと主要プロップの候補画像を生成し、チャット内で提示してください。あなたの最終的な3D制作目標は、このコンセプトアートのスタイルと配置を可能な限り精密に再現することです。私の明確な承認を得るまで、コーディングフェーズに入らないでください。
3. **計画策定と /goal の生成**:私がコンセプトアートを承認し質問に回答した後、明確なマイルストーンを含む完全な `PLAN.md` を作成し、長時間の自律構築ループを開始できる実行可能な `/goal` コマンドを提示してください。
現在の環境がサブエージェントに対応している場合は、プロップ(Props)、テクスチャ(Texture)、ライティング・UI(Lighting)の各並行ロールに分割してください。非対応の場合はフェーズ順に逐次実行してください。
主要な受け入れ基準:
- モジュール構成:Three.js + Viteを採用し、`main.js`、`track.js`、`car.js`、`lights.js`、`props.js` に分割すること。
- 操作とカメラ:W/A/S/Dによる車両操作、数字キー1〜4でのスムーズなカメラアングル切り替え。
- アセットと衝突判定:Blender MCP経由で `public/models/desk-props.glb` を出力してウェブ上で読み込み、リボン状の高架コースには落下や突き抜けを防ぐコライダーと接地支柱を備えること。
英語版(本ガイドの学習用テンプレート):
/grill-me Help me plan a miniature browser kart racer based on my desk photos in the `desk-racer` workspace. Hold off on generating 3D code until we agree on the design.
1. Ask about driving feel, camera modes, lighting, and which objects need custom models.
2. Use the Nano Banana concept I have already selected. If none is selected, produce track and prop concepts and show them in chat. Wait for my choice before coding.
3. After I answer the questions and confirm a concept, save a milestone-based plan as `PLAN.md` and propose an executable `/goal` instruction for completing it.
Delegate props, textures, and lighting where subagents are supported; otherwise work through these milestones in sequence.
Deliver a Vite + Three.js project organized into `main.js`, `track.js`, `car.js`, `lights.js`, and `props.js`. Include WASD driving, four smooth camera modes, Blender props exported to `public/models/desk-props.glb`, and an elevated ribbon track with grounded supports and collision boundaries.
フェーズ4:まずマシンを走らせ、後からデスクと高架コースを組み込む
確定した計画に沿って、まずは実際に走行可能な簡易モデルを作り、次にデスクのプロップを読み込み、最後に高架コースと衝突判定を検証します。
1. 最初のプレイアブルプロトタイプの作成
作成したばかりのdesk-racerフォルダをAntigravityで開き、ワークスペースのルートとターミナルのカレントディレクトリが一致していることを確認します。新規チャットのモデル選択から、自身のアカウントで利用可能なGemini 4 Argonを選択します。最初のプロトタイプでは基本ジオメトリのみを使用し、後から写真の実際のレイアウトへ置き換えていきます。
初回にnpx viteを実行する前に、以下のプロンプトを使用して、エージェントに最初の完全なプレイアブルコードを出力させます。コース設計は、マシンが安定して走行できるよう、リング状の細いパイプではなく十分な幅を持った平坦なリボン状の道路にする必要があります。
テンプレート4:最初のプレイアブルコードの構築(サーバー起動前に実行)
日本語版(コピー用):
現在の `desk-racer` フロントエンドプロジェクト内に、最初の完全なプレイアブルプロトタイプのコードを作成してください。以下のファイルを直接生成してください:
1. `index.html`:全画面余白なしスタイルの標準HTML5ページ。`#app` コンテナを配置し、`/src/main.js` をESモジュールとして読み込む。
2. `src/main.js`:Three.jsのメインエントリーポイント。シーン、透視カメラ(FOV 60、near 0.02、far 50)、WebGLRenderer(シャドウとアンチエイリアス有効)を初期化し、ウィンドウリサイズ対応を実装。
3. `src/car.js`:簡易ホワイトボックスカークラス。直方体の組み合わせによる車体(赤ベースに白ルーフ、サイズ約0.05m×0.025m×0.02m)。前進速度、角速度、摩擦減衰に基づく剛体移動ロジックを実装。キー入力の監視:Wで加速、Sでブレーキ・後退、A/Dで左右操縦、Rで位置と向きをリセット。
4. `src/track.js`:基礎的な周回コース。平坦なリボン状メッシュ(Ribbon Mesh、道路幅0.08m、厚み0.005m)を生成し、デスク中央を囲む滑らかな連続ループを形成。簡易スタートラインと赤白の縁石パターンを付与。
5. `src/camera.js`:カメラシステム。4つの視点の滑らかな追従切り替えを実装:キー1(後方追従)、キー2(ボンネット視点)、キー3(デスク全体俯瞰)、キー4(コース低速巡回)。
6. `src/lights.js`:基礎照明。デスク用のメインスポットライト(影の投影あり)1灯と、暗めの環境光1灯を配置。
生成完了後、コードに構文エラーがないか確認し、追加の依存関係なしで即座にインポートして実行できる状態にしてください。
英語版(本ガイドの学習用テンプレート):
Please scaffold the first playable prototype in the current `desk-racer` project by creating the following files:
1. `index.html`: Standard HTML5 boilerplate, reset CSS for fullscreen canvas, `#app` mount container, importing `/src/main.js` as an ES module.
2. `src/main.js`: Main Three.js entry point. Set up scene, perspective camera (FOV 60, near 0.02, far 50), WebGLRenderer with shadows and antialiasing enabled, and a responsive resize handler.
3. `src/car.js`: Whitebox vehicle class. Construct a modular box car (red body, white roof, ~0.05m × 0.025m × 0.02m). Implement basic arcade physics with acceleration, steering yaw, braking, and damping. Bind key inputs: W (throttle), S (brake/reverse), A/D (steer), R (reset position and rotation).
4. `src/track.js`: Basic closed ribbon track. Build a flat drivable ribbon road mesh (width 0.08m, thickness 0.005m) forming a continuous loop around the desk center, complete with a checkered start line and red/white curb striping.
5. `src/camera.js`: Multi-camera rig. Implement smooth lerped switching across 4 modes: Key 1 (Chase Cam), Key 2 (Hood/Cockpit Cam), Key 3 (Top-down Overview), Key 4 (Orbiting Drone).
6. `src/lights.js`: Initial lighting. Add a shadow-casting spotlight and dim ambient light.
Verify clean module exports and syntax correctness so the project runs immediately upon server start.
ファイルの作成が完了したら、ターミナルでローカル開発サーバーを起動します:
npx vite --host 127.0.0.1
ターミナルにhttp://127.0.0.1:5173/のようなローカルアドレスが出力されます(5173番ポートが使用中の場合は自動でインクリメントされます)。ブラウザでこのURLを開き、リボン状の軌道上に赤白のマシンが配置され、W/A/S/Dキーでスムーズに走行でき、数字キーの1~4でカメラアングルが切り替わることを確認してください。このターミナルは起動したままにしておきます。
テンプレート5:初回起動時の画面真っ白・エラー発生時のトラブルシューティング(予備)
日本語版(コピー用):
`npx vite` を起動後、ブラウザの開発者コンソールに異常が発生しています(画面が真っ白、`#app` が見つからない、Three.jsモジュールのインポート失敗、またはシェーダーエラーなど)。
以下の手順に沿ってコードを確認し、修正してください:
1. `index.html` に `<div id="app"></div>` と `<script type="module" src="/src/main.js"></script>` が正しく含まれているか確認。
2. `src/main.js` や各サブモジュールの `import` パスで、相対パス(`./car.js` や `./track.js` など)が正確に使用されているか確認。
3. レンダリングループの `requestAnimationFrame` 内で、車両位置とカメラの補間処理が正しく更新されているか確認。
4. エラー原因を特定し、修正後のファイル内容を提示してください。
英語版(本ガイドの学習用テンプレート):
Upon running `npx vite`, the browser console reports an error (blank screen, missing `#app` container, module resolution failure, or WebGL context error).
Please inspect and patch the codebase according to these checkpoints:
1. Verify `index.html` contains `<div id="app"></div>` and `<script type="module" src="/src/main.js"></script>`.
2. Ensure all module imports in `src/main.js` use proper relative specifiers (e.g., `./car.js`, `./track.js`).
3. Ensure the `requestAnimationFrame` render loop actively updates car kinematics and camera lerp transformations each frame.
4. State the root cause and provide patched code files directly.
2. Blender MCPを制御して個別のデスクプロップをモデリング
ホワイトボックスのマシンが画面上で意図通りに動くようになったら、エージェントに指示を出し、execute_blender_codeを介してBlenderを操作してプロップのモデルを自動生成させます。
スクリプトを作成する際、すべてのオブジェクトを「原点中心に整列」させないよう注意してください。そうしてしまうと、ディスプレイスタンド、キーボード、マウスが一箇所に重なってしまいます。参考写真とデスクの実測寸法に基づき、各オブジェクトに独立したワールド座標を割り当てる必要があります。
テンプレート6:Blender MCPによる独立座標を持ったデスク小物の自動構築
日本語版(コピー用):
ローカルのBlender MCPサービスの `execute_blender_code` ツールを呼び出し、Pythonスクリプトを実行してレースゲーム用のローポリゴン(Low-Poly)デスク障害物プロップ一式を生成してください:
1. **オブジェクトの配置と寸法計画(メートル単位、サンプル値は実測に合わせて変更可)**:
- **メカニカルキーボード(Keyboard)**:位置 `(0, 0.01, 0.12)`、土台サイズ約0.36m × 0.14m × 0.02m、上面に簡易キーキャップ配列を並べ、ダークグレーのマットマテリアルを適用。
- **ディスプレイスタンドと支柱(Monitor)**:位置 `(0, 0, -0.22)`、平たいスタンドに垂直支柱、上部にスクリーンパネル(0.55m × 0.32m)を配置し、画面には暗色の反射マテリアルを適用。
- **マウス(Mouse)**:位置 `(0.24, 0.015, 0.12)`、丸みを帯びた流線型メッシュ、長さ約0.11m、幅0.06m。
2. **構造と座標の規約**:各オブジェクトの名前を独立して維持し(`Keyboard`、`Monitor`、`Mouse`)、1つのメッシュに結合して重ねないこと。上記の位置はThree.jsのY軸上向き座標です。Blenderスクリプト内では (x,y,z) を (x,-z,y) にマッピングし、BlenderのZ=0を天板に対応させてください。
3. **エクスポート要件**:現在のプロジェクトの絶対パスを指定し、上記モデル群をバイナリGLB形式でプロジェクトの `public/models/desk-props.glb` にエクスポートしてください。
4. **完了確認**:スクリプト実行後、出力ファイルがディスク上に存在し、ファイルサイズが0バイトより大きいことを確認した上で、各オブジェクトの最終ワールド座標を報告してください。
英語版(本ガイドの学習用テンプレート):
Please invoke `execute_blender_code` via local Blender MCP to generate low-poly desktop props with independent world coordinates using Python:
1. **Layout & Dimensions (meters, adjustable defaults)**:
- **Keyboard**: Center `(0, 0.01, 0.12)`, base ~0.36m × 0.14m × 0.02m with simplified keycap array, matte dark plastic material.
- **Monitor**: Center `(0, 0, -0.22)`, thin rectangular base, upright riser, widescreen bezel (0.55m × 0.32m) with glossy dark glass material.
- **Mouse**: Center `(0.24, 0.015, 0.12)`, ergonomic low-poly contour (~0.11m × 0.06m).
2. **Scene Hierarchy**: Keep distinct object names (`Keyboard`, `Monitor`, `Mouse`) without collapsing all meshes onto origin. The listed coordinates use Three.js Y-up; map (x,y,z) to Blender (x,-z,y), with Blender Z=0 as the tabletop.
3. **Export Specification**: Use the project's absolute filesystem path to export the props collection as binary GLB directly to `public/models/desk-props.glb`.
4. **Verification**: Confirm file existence on disk, verify file size is greater than 0 bytes, and output the final object transform coordinates.
3. Three.jsでのGLTFLoaderによるアセット読み込み
Vite環境では、ビルド後にpublicディレクトリ直下の静的アセットがルート直下にマッピングされるため、JavaScriptコード内での読み込みパスは/publicを付けずに/models/desk-props.glbと記述します。
同時に座標系のマッピングにも注意が必要です。BlenderからglTF/GLBをエクスポートする際、通常はZ軸上向きのシーンがglTFの規約であるY軸上向きへと変換されます。Three.jsのGLTFLoaderもこの規約に沿って読み込みます。読み込み後にトップレベルのモデルへ手動でprops.rotation.x = -Math.PI / 2といった追加の回転を無理に加えると、二重回転の不具合が生じるため不要です。
src/props.jsに読み込み関数を記述し、src/main.jsから呼び出します:
import * as THREE from 'three';
import { GLTFLoader } from 'three/addons/loaders/GLTFLoader.js';
export function loadDeskProps(scene, onLoaded) {
const loader = new GLTFLoader();
loader.load(
'/models/desk-props.glb',
(gltf) => {
const props = gltf.scene;
props.traverse((child) => {
if (child.isMesh) {
child.castShadow = true;
child.receiveShadow = true;
// 若有材质,适当微调粗糙度
const materials = Array.isArray(child.material) ? child.material : [child.material];
materials.forEach((material) => {
if (material && typeof material.roughness === 'number') {
material.roughness = Math.max(material.roughness, 0.4);
}
});
}
});
scene.add(props);
console.log('桌面道具加载成功,包含物体数量:', props.children.length);
if (onLoaded) onLoaded(props);
},
undefined,
(error) => {
console.error('加载桌面模型失败,请检查 public/models/desk-props.glb 是否存在:', error);
}
);
}
src/main.jsでsceneを作成した直後にこの読み込み関数を組み込みます。プロップの位置情報に依存するコースの更新処理はコールバック内に配置し、モデルのロード完了前に支柱の接地判定が走ってしまうのを防ぎます:
import { loadDeskProps } from './props.js';
loadDeskProps(scene, (props) => {
console.log('道具就绪,现在可以按其实际边界检查赛道与支柱', props);
// 在这里调用项目中已实现的赛道布局/支柱更新函数
});
4. 周回リボンコースの構築と衝突判定
コースを天板の上に直接平置きしてしまうと、見た目として天板のテクスチャとの間でZファイティング(Z-fighting:深度バッファの精度不足により近接する2つの面がちらつく現象)が発生しやすくなるだけでなく、キーボードや配線などの障害物を越えられなくなります。
立体的な高品質コースを構築するためのポイント:
- 平坦なリボン道路(Ribbon Road):
CatmullRomCurve3を用いて3次元スプラインの中心線を作成し、曲線の各ポイントから左右の横方向へ幅を持たせた平面メッシュを展開します。赤白の縁石とわずかな側壁の突起を設けます。 - 高低差と立体交差:実際のプロップの高さに合わせてコントロールポイントの高さを動的に調整します。たとえばディスプレイスタンドの上を通る際は天板近くまで降下させ、メカニカルキーボードを跨ぐ際は十分な高さまで滑らかに持ち上げます。
- 支柱の接地判定(Raycasting / Geometry Query):原作者のGeneviève氏は実験段階で高架コースを支えるために68本もの支柱を生成しました。実践時にはスプラインの長さに応じて支柱の本数を動的に決定し、各支柱の生成時に軌道の底面から真下へレイキャストを飛ばして実際の接地位置を判定します。これにより、支柱が天板やディスプレイスタンドの表面にぴったりと接地し、空中に浮いたり物体を突き抜けたりするのを防ぎます。
- セグメントごとの物理判定と突き抜け防止:高架が上下に重なり合う立体交差部分では、2次元の平面座標だけでコース上にいるかを判定すると誤認識が起きます。コースセグメントID(Segment ID)と局所的な高さ許容値を組み合わせ、最近傍点との距離判定を行う必要があります。ガードレールを越えた場合は反発力を与え、
Rキーを押した瞬間に現在位置から最も近い有効なコース中心線上にマシンを復帰させます。
テンプレート7:周回リボンコース生成と多層物理判定の実装
日本語版(コピー用):
`src/track.js` 内に、デスク上の小物を周回する立体高架リボンコースシステムを構築してください:
1. **ジオメトリ形状**:3次元スプライン曲線(`CatmullRomCurve3`)をベースに周回リボンメッシュ(幅0.08m、厚み0.004m)を生成。コントロールポイントはキーボード中央の高いエリアを避け、キーボードの端で上昇し、ディスプレイの前をかすめるルートにすること。
2. **面の重なりとチラつき(Z-fighting)防止**:コース全体の最も低い位置でも天板から最低0.003m浮かせ、天板との共面によるZファイティングを防止すること。
3. **支持用支柱**:高架コースの下側に沿って一定間隔で円柱状の支柱を生成。各支柱は垂直下向きのレイキャスト(Raycaster)で天板上の実際の接地位置を取得し、レールと天板表面をしっかりと接続すること。
4. **ルールとタイム計測**:コース上にスタート・フィニッシュライン(市松模様)を配置し、3周のラップタイム計測ロジック、現在およびベストラップ表示、逆走警告、リセット復帰機能を実装すること。
5. **階層別の衝突判定**:立体交差エリアでは、車両の現在の高さに応じて対応する階層の衝突判定プロキシを照合し、上層の立体橋から下層の路面へ不自然に吸着したり落下したりするのを防ぐこと。
実装後、ブラウザで1周テスト走行し、すべてのコーナーや立体橋をスムーズに走行できることを確認してください。
英語版(本ガイドの学習用テンプレート):
Please develop an elevated closed ribbon track in `src/track.js` that navigates around desktop obstacles:
1. **Geometry**: Build a closed ribbon road mesh (width 0.08m, thickness 0.004m) driven by a 3D CatmullRom spline. Route control points to elevate over keyboard edges and dip gently near the monitor base.
2. **Coplanar Anti-Z-Fighting**: Offset track elevation at least 0.003m above tabletop surfaces to prevent depth-buffer fighting artifacts.
3. **Support Pillars**: Distribute vertical cylindrical pillars under elevated spans. Use downward raycasting against desk meshes to clamp each pillar base securely onto supporting surfaces.
4. **Lap Rules**: Add a checkered start/finish threshold, a 3-lap countdown timer, current/best lap tracking, wrong-way detection, and an instant reset trigger (`R` key).
5. **Layered Collision Handling**: Implement height-gated collision matching at overpass intersections so the vehicle does not snap onto underlying road segments.
Drive a complete test lap in the browser to ensure smooth cornering across elevated bridges.
フェーズ5:マシンを縮小する際、なぜカメラも近づけるのか
初心者が制作したデスクシーンは、「巨大で平坦な段ボールの上でミニカーが滑っている」ような印象になりがちで、動画のような迫力あるミニチュアの没入感が出ないことがよくあります。その鍵を握るのが、実寸比率の計算と近接カメラによるパースペクティブです。
完成動画の45秒付近。地面すれすれを疾走する車体の背後で、キーボードのキーがそびえ立つ巨石のように見えます。
1. 実寸スケーリングの計算(1:87から1:150へ)
作者は初期の画面を見てマシンが道路に対して大きすぎると感じ、マシンのスケールを1:87から1:150へと変更し、同時に追従カメラを近づけました。ここで真に再現すべきなのは相対的な縮小比率です。87/150は約0.58であり、すべてのプロジェクトに固定の車長を当てはめる必要はありません。
この比率変更に伴う幾何学と光学の原理を正しく理解しましょう:
- 環境の物理寸法は固定:デスク、ディスプレイ、キーボード、コースの3D空間内の絶対サイズはそのまま維持します(例:キーボード長0.36m、コース幅0.08m)。
- マシンと衝突判定の等比縮小:マシン本体と当たり判定のバウンディングボックスを1:87から1:150に変更すると、元の寸法の87/150 ≒ 58%へと縮小されます。
- 追従カメラの相対オフセットも連動して縮小:カメラのマシンに対する相対オフセットベクトル(後方距離や上方の高さ)にも同様に58%の係数を掛けます。カメラの画角(FOV)が変わらないため、画面全体に占めるマシンのピクセル比率はほぼ一定に保たれます。
- 走行可能な路面の相対的な広がり:縮小されたマシンから見ると、コースの相対的な幅は元の150/87 ≒ 約1.72倍に広がります。道路のジオメトリ自体は変更していませんが、マシンの走行空間にゆとりが生まれます。
- 近クリップ面(camera.near)の連動調整:カメラをミニチュア車両に近づけた際、
camera.nearが0.1mのままだと、マシンのテールやボンネットが近平面でクリップされて欠けてしまいます。0.01〜0.02m程度から試し始め、実際のカメラ距離に合わせて調整しつつ、遠景の深度精度も確認してください。
光学の原理において、画面内での物体の視覚的張角は次の式で表されます: θ = 2 arctan(S ÷ 2D) ここでSは物体の物理サイズ、Dは物体からレンズまでの距離です。カメラをマイクロマシンに近づけると、その距離はわずか数センチメートルになります。同時にカメラの絶対位置も低くなるため、デスク上に並んでいるだけのキーボードのキーが、低い仰角によって目の前に迫りくる巨大な壁のように感じられます。低い視点によって、日常の小物が大きく見えます。最後に実際のカメラ位置から構図と遮蔽を確認してください。
以下のインタラクティブシミュレータでパラメータを動かし、カメラ距離、物体のスケール、描画視野の動的な関係性を直感的に確認できます:
左側の 1:87 を基準として残し、右側のスケールを変更します。まずマシンのみを縮小し、次に「カメラ補正」にチェックを入れて、画面内でのマシンの占有率を観察してください。図中のコースとマシンは理想的な透視投影による模式図です。
車体とカメラオフセットが共に元の 58.0% になり、画面上のマシンサイズは維持されます。コースのマシンに対する相対幅は 1.72 倍になります。
解説上の前提:画角(FOV)は固定、マシンとカメラは同軸上にあり、投影される車幅は「実寸幅 ÷ カメラ距離」に比例します。パーセンテージは調整前を基準としています。コース図は同一深度平面での模式図であり、実際のゲームでは追従アングル、遮蔽、当たり判定の確認も必要です。
テンプレート8:車両スケール・コライダー・近クリップ面の連動微調整
日本語版(コピー用):
`src/car.js` と `src/camera.js` のスケールを最適化し、マシンモデルのスケールを1:87から1:150のミニチュア規格へ調整してください:
1. **車体サイズとコライダー**:現在の車体バウンディングボックスを読み込み、元のサイズの 87/150 に、1回だけ等比縮小してください。衝突バウンディングボックスとホイールの接地判定距離も同様に 87/150 を掛け、変更前後の数値を記録してください。
2. **追従カメラのオフセット**:カメラ1の相対オフセットベクトルとカメラ2の車体ローカル座標の両方に 87/150 を掛けてください。FOVは変更せず、調整前後のスクリーンショットでマシンの画面占有率を比較してください。
3. **クリップ面の最適化**:`src/main.js` でカメラの `camera.near` を `0.01` に設定し、クローズアップ時に車体メッシュが欠損するのを防止してください。
4. **速度パラメータの適合**:最高前進速度(約0.8 m/s)とステアリング角速度を微調整し、車体縮小によって体感速度が速すぎて操作不能になるのを防いでください。
スクリーンショットでキーボードに接近した際の構図と操作感を検証してください。
英語版(本ガイドの学習用テンプレート):
Please refine scale parameters across `src/car.js` and `src/camera.js`, adapting the vehicle from 1:87 down to 1:150 micro scale:
1. **Vehicle & Colliders**: Read the current bounds and multiply vehicle dimensions, collision bounds, and ground-check distances by 87/150 exactly once. Record before/after dimensions.
2. **Camera Offsets**: Multiply the chase-camera offset vector and cockpit local coordinates by 87/150. Keep FOV fixed and compare vehicle screen occupancy before/after.
3. **Near Clipping**: In `src/main.js`, configure `camera.near = 0.01` to prevent clipping artifacts during tight macro shots.
4. **Kinematic Tuning**: Recalibrate top speed (~0.8 m/s) and turn rates to ensure realistic acceleration without visual teleportation at micro scales.
Verify visual framing against keycaps and validate handling responsiveness via test screenshots.
フェーズ6:マテリアルとライティングの調整、スクリーンショットによる自己診断
3Dウェブシーンからプラスチックのようなチープさを排除するには、物理法則に即したPBRマテリアルテクスチャの適用、メイン光と環境光による陰影の階層作り、そして独立したビジュアル批評エージェント(Adversarial Critic)がスクリーンショットから欠陥を指摘してコードを修正するという、3つの連携が不可欠です。
制作プロセス動画の105秒付近。Criticがハイライトの白飛び、木目の黄橙色の過飽和、追従視点での背景の暗すぎを指摘し、修正案を提示しています。
1. リアルなマテリアルテクスチャ(Texture Mapping)
単一のベタ塗りカラーだけでは、シーン全体がどうしても安っぽく見えてしまいます。まずは木目と路面のシームレスなカラーテクスチャを生成・準備し、必要に応じてラフネスマップやノーマルマップを補います。PBRマテリアルでは、これらの異なる画像を用いてカラー、表面の粗さ、微細な凹凸をそれぞれ表現します。通常のカラー画像をそのままノーマルマップとして流用することはできません。
Antigravityの画像生成ツールでNano Bananaを呼び出すか(またはAI Studioの画像生成画面に写真をアップロードして)、「シームレスにタイル配置可能な木目」と「シームレスにタイル配置可能な路面の粒状感」の2枚のテクスチャ画像の生成を指示します。コースのパースや文字を含めず、真上からの均一なライティングで指定してください。それぞれdesk_wood.pngとtrack_asphalt.pngとして保存します。エージェント側に直接の画像生成ツールがない場合は、まず画像生成画面からファイルをダウンロードし、プロジェクトフォルダに配置してから作業を続行してください。
注意点として、テクスチャ画像はpublic/textures/ディレクトリ内に配置し(例:desk_wood.png、track_asphalt.png)、Three.js側からはTextureLoader経由で読み込みます。テクスチャはあくまで3Dメッシュの微細な凹凸や反射感を表現するための手段であり、2D平面画像を立体形状の代わりとして混同しないようにしてください。
テンプレート9:PBRテクスチャの読み込みとマテリアルの割り当て
日本語版(コピー用):
`src/textures.js` 内にテクスチャ読み込みモジュールを作成し、ゲームオブジェクトにリアルなPBRマテリアルを割り当ててください:
1. **テクスチャパス**:まず `/textures/desk_wood.png` と `/textures/track_asphalt.png` から保存済みのシームレスカラーマップを読み込み、カラー画像に合わせてsRGB色空間を設定してください。ラフネスマップ、ノーマルマップ、メタルネスマップはファイルが実際に存在する場合にのみ読み込み、存在しない場合はマテリアルの数値パラメータを使用し、無効なパスを追加しないでください。
2. **テクスチャのリピートとラップ**:テクスチャに `wrapS = wrapT = THREE.RepeatWrapping` を設定し、細長いコースに対しては進行方向に適切にタイリング(例:進行方向に沿って40回リピート)を設定して、テクスチャが不自然に引き伸ばされないようにしてください。
3. **マテリアルパラメータ**:
- デスク天板:`MeshStandardMaterial`、深いブラウンの木目調、ラフネス0.65、わずかな鏡面反射。
- コース:ダークグレーのアスファルト調、ラフネス0.8。正しいノーマルマップがある場合は粒状感を追加。
- マシン:光沢のあるレッド塗装、ラフネス0.25、メタルネス0.4。
`applyMaterials(scene)` 関数をエクスポートし、`src/main.js` から呼び出してください。
英語版(本ガイドの学習用テンプレート):
Please implement a texture loading module in `src/textures.js` to assign PBR materials across scene meshes:
1. **Asset Paths**: Load the saved color textures `/textures/desk_wood.png` and `/textures/track_asphalt.png` with sRGB color space. Load roughness, normal, or metal maps only when their files exist; otherwise use material values and avoid missing URLs.
2. **Wrapping & Repeat**: Configure `wrapS = wrapT = THREE.RepeatWrapping`. Adjust UV repetition along the elongated track mesh (e.g., repeat 40 times longitudinally) to eliminate pixel stretching.
3. **Material Tuning**:
- Tabletop: `MeshStandardMaterial`, warm walnut tint, roughness: 0.65, subtle specular sheen.
- Track: Charcoal asphalt, roughness: 0.8; add normal detail only when a valid map is available.
- Go-kart: Glossy racing red coat, roughness: 0.25, metalness: 0.4.
Export `applyMaterials(scene)` and hook it into `src/main.js`.
2. 3層の複合アンビエントライティング、デバッグ用パネル、マイルストーンギャラリー
公式デモの温かみのあるデスクライト、紫の環境光、青白く光るキーボードを参考に、自分のプロジェクトでも以下の3系統の照明から調整を始めると効果的です:
- 主光源(Key Light):デスクライトを模した温白色のスポットライト(
SpotLight、色温度約3200K)。天板の中央エリアを斜め上から照らし、影の投影を有効にします。 - ディスプレイバックライト(Rim / Ambient Light):ディスプレイの背面に深い紫または寒色系シアンのポイントライト(
PointLight)を配置。画面の輪郭を浮き立たせ、暗い壁面を照らして奥行きを出します。 - ライティング装飾(Accent Light):キーボードのキーの隙間にほのかな発光マテリアルまたは面光源(Emissive Glow)を配置し、トイサーキットらしいサイバー感を演出します。
ビジュアルの進化過程を把握しやすくするため、公式ガイドでは2つの軽量ツールの導入が推奨されています:
- スクリーンショットギャラリー:マイルストーンごとにバージョン番号付きの画像を保存します。エージェントに
progress.htmlをプロジェクトルートに配置させ、画像はpublic/progress/に保存します。開発サーバーの起動中に同じアドレス・ポートで/progress.htmlを開くことで変化を確認できます。 - リアルタイムパラメータ調整パネルとJSONエクスポート:スライダーを備えた軽量コントロールパネルをページ上に埋め込み、光量、シャドウバイアス、ラフネスなどをリアルタイムに調整します。納得のいく数値が得られたら、「JSON設定をコピー」ボタンでクリップボードに取得し、エージェントに
src/lights.jsへ書き戻させて固定します。録画前にはこのパネルを非表示または削除します。
テンプレート10:光源設定・インタラクティブデバッグパネル・進捗ギャラリー
日本語版(コピー用):
`src/lights.js` 内で3層の複合光源システムを完成させ、ページ上にデバッグ用コントロールパネルと進捗記録ギャラリーを追加してください:
1. **光源の構成**:
- メインライト:`THREE.SpotLight`(暖白色 `#fff4e0`、強度2.5、影を落とす設定、適切なshadow.camera範囲)。
- ディスプレイ環境光:`THREE.PointLight`(深紫色 `#6b21a8`、強度1.2、ディスプレイ背面に配置)。
- キーボードの隙間ライト:低強度のポイントライトまたは自己発光マテリアル(シアン `#06b6d4`)。
2. **進捗ギャラリー(`progress.html`)**:開発マイルストーン達成ごとに、4枚の主要スクリーンショット(全体俯瞰、ディテールの接写、地面すれすれの低アングル、ワイヤーフレーム)を自動キャプチャして `public/progress/` に保存し、`progress.html` 上にバージョン番号と生成日時付きのタイムラインとして表示すること。
3. **インタラクティブ調整パネルと実クリップボードコピー**:画面右上に軽量パネルを配置(主灯強度、スポット角度、シャドウbias、色温度、露出)。パネル下部に「JSON設定をコピー」ボタンを設置し、クリック時に `navigator.clipboard.writeText(JSON.stringify(config, null, 2))` を呼び出して、コンソール出力だけでなくクリップボードへ確実にコピーすること。
4. **設定の反映手順**:調整後のJSONをチャットに貼り付けた際、それを直接 `src/lights.js` のデフォルト値として上書き反映し、動画録画前にはパネルを非表示または削除できるトグルを用意すること。
英語版(本ガイドの学習用テンプレート):
Please build a composite three-tier lighting setup, an interactive debug GUI, and a progress gallery in `src/lights.js`:
1. **Hierarchy**:
- Desk Spotlight: `THREE.SpotLight` (warm tone `#fff4e0`, intensity: 2.5, castShadow: true, properly bounded shadow camera frustum).
- Monitor Rim Light: `THREE.PointLight` (deep violet `#6b21a8`, intensity: 1.2, placed behind monitor panel).
- Keyboard Glow: Cyan accent point light (`#06b6d4`) or material emissive highlights.
2. **Progress Gallery (`progress.html`)**: After each milestone, capture 4 viewport screenshots (overview, detail close-up, low-angle ground check, wireframe view) into `public/progress/` and index them in `progress.html` with version numbers and timestamps.
3. **Interactive GUI & Real Clipboard Copy**: Embed lightweight on-screen sliders for spot intensity, penumbra, shadow bias, exposure, and color. Add a "Copy Settings as JSON" button that invokes `navigator.clipboard.writeText(JSON.stringify(config, null, 2))` to truly copy active settings to the system clipboard (not just console.log).
4. **Bake Defaults**: Establish a clear workflow: once I paste back the exported JSON, bake those values into `src/lights.js` as permanent defaults, and provide a toggle to hide or remove the debug GUI before final recording.
3. 独立した「敵対的ビジュアル批評家」(Adversarial Critic)による自己検証ループ
別のCriticサブエージェントに実際の実行画面のスクリーンショットを観察させ、見つかった課題をコード作成エージェントへフィードバックして修正させます。人間と一緒に以下の4つの画面を精査します:
- 全体俯瞰:構図、コースのレイアウト、遮蔽関係。
- クローズアップ:木目、路面、ハイライトの白飛び、テクスチャの歪み。
- 低アングル:ホイールや支柱がしっかり接地しているか。
- ワイヤーフレーム:メッシュ構造とポリゴンの交差。衝突判定については実際の走行と幾何判定で再確認。
元のガイドでは初期のイテレーションを加速させるために「最低3つの欠陥を挙げ、スコアが9/10に達するまで繰り返す」という基準が使われていました。実践時には、Criticに実際の課題と対象ファイルを報告させ、修正後に再度スクリーンショットを撮らせます。合意したビジュアル方針に達し、周回走行・カメラ切り替え・アセット読み込みがエラーなく行えるようになった時点でそのイテレーションを完了とします。AI Studio Buildを使用している場合は、これらのスクリーンショットをチャットに直接送信してGeminiに批評と修正を求めることも可能です。
公式 Adversarial Critic レビュープロセスの参考例(クリックで展開)
テンプレート11:独立Criticサブエージェントによるマルチアングル審査とコード修正
日本語版(コピー用):
独立した敵対的アートディレクター批評家(Adversarial Visual Critic)サブエージェントによるレビュープロセスを開始してください:
1. **4枚の検証用スクリーンショットのレンダリング**:
- 3/4俯瞰全体図:空間全体の構図とコースの取り回しを確認。
- ディテールの接写:キーボードのキーキャップとアスファルト表面のテクスチャを検証。
- 地面すれすれの低アングル:マシンや支柱の接地状態を確認し、宙に浮いていないか検証。
- ジオメトリワイヤーフレーム:3Dトポロジー構造と潜在的なモデル干渉をチェック。
2. **厳格な指摘リスト**:批評家サブエージェントは4枚のスクリーンショットすべてを精査し、実際に確認された具体的な視覚的欠陥(ハイライトの白飛び、影のエッジのジャギーや途切れ、モデルの浮遊、マテリアルの質感不足など)をリストアップし、修正提案を提示すること。
3. **原因箇所の修正と終了条件**:
- `src/lights.js`、`src/textures.js`、または `src/track.js` を特定してコードを修正。
- 再度スクリーンショットを取得して再検証。問題が見当たらない場合は無理に指摘を捏造しないこと。画面が合意済みのコンセプトに合致し、コースを完走でき、カメラ遷移がスムーズでアセット読み込みエラーが解消された時点で本ラウンドを終了すること。
英語版(本ガイドの学習用テンプレート):
Please invoke an independent Adversarial Visual Critic subagent review pass for the current scene:
1. **Render 4 Verification Screenshots**:
- 3/4 Overview: Demonstrating overall layout and track composition.
- Close-up: Inspecting keycap textures and asphalt grain.
- Low Angle: Inspecting vehicle contact and pillar bases to eradicate floating objects.
- Wireframe View: Verifying clean 3D topology and potential collision intersections.
2. **Defect List**: Have the Critic subagent inspect all 4 screenshots, itemizing the visual flaws actually present (e.g., specular blowouts, shadow acne/detachment, floating meshes, or flat materials) with targeted remediation advice.
3. **Targeted Patching & Exit Criteria**:
- Apply fixes directly across `src/lights.js`, `src/textures.js`, or `src/track.js`.
- Re-capture screenshots for verification. Do not invent defects once they are fixed. End the round when the image matches our approved direction and multi-lap driving, camera modes, and asset loading pass.
4. ライティング調整で行き詰まったら、同一アングルの目標画像を先に生成する
パラメータを何度も修正しても方向性が定まらない場合は、現在のシーンのスクリーンショットをNano Bananaに渡し、同じカメラアングルとオブジェクト配置を維持した2K解像度の目標画像を生成させます。その際、UIボタンやスライダー、HUD(速度やラップ数などの画面テキスト)をあらかじめ非表示にしておき、画面上の文字がシーン内の看板として描き込まれるのを防ぎます。
その後、現在のスクリーンショットと目標画像の両方をArgonに渡し、影、木目、光の反射、暗部の階調などを比較させ、実際の3Dジオメトリ、マテリアル、ライティングを修正します。目標画像はあくまで目指すべき方向性を示すためのものであり、カメラを回転させたりマシンを走らせたりしても、その改善効果がリアルタイム3Dとして破綻しないように仕上げる必要があります。
テンプレート12:同一アングルでの目標画像生成(事前準備)
日本語版(コピー用):
UIボタン、デバッグスライダー、HUDを非表示にし、現在のプロジェクトの重要な3〜5箇所のカメラアングルから鮮明な3Dスクリーンショットを保存し、アングル名とバージョンを明記してください。
各スクリーンショットをNano Bananaに渡し、2K解像度の目標画像を生成させてください:自然な光の陰影、天板の木目、路面の質感、反射、空間の奥行きを強調しつつ、元のカメラアングル、構図、オブジェクトの配置は厳密に維持すること。
アングルごとに元のスクリーンショットと目標画像をペアで保存し、実際のファイルパスとプレビューを提示してください。もし配置にズレが生じた場合は再生成してからコード修正に進んでください。
英語版(本ガイドの学習用テンプレート):
Switch off the interface buttons, debug GUI, and HUD. Save clear screenshots from 3–5 useful camera positions, labeling the camera and revision.
For each view, ask Nano Banana for a 2K reference image with improved lighting, desk grain, road texture, reflections, and depth. Preserve the camera framing and object arrangement.
Save each source/reference pair and show me previews with their actual paths. Regenerate references that alter the layout before changing the game code.
テンプレート13:目標画像と照合した3Dコードの修正(目標画像承認後に実行)
日本語版(コピー用):
同一アングルにおける現在のThree.jsスクリーンショットと、承認済みのNano Banana 2K目標画像を比較し、影の落ち方、天板の木目、車体の反射、背景の暗部における具体的な差異をリストアップしてください。
その差異に基づき、既存プロジェクトのジオメトリ、マテリアル、ライティングを修正してください(修正対象:`src/lights.js`、`src/textures.js`、`src/main.js`、または実際に使用しているモデルファイル)。
目標画像を平面の背景画像として貼り付けるような安易な対処は避けてください。完了後、元のカメラアングルでスクリーンショットを再取得し、カメラを回転させコースを1周走行して、リアルタイム3D空間として効果が成立していることを確認してください。変更内容とビフォーアフターの画像を提示してください。
英語版(本ガイドの学習用テンプレート):
Use matching camera views to compare our live Three.js captures with the approved Nano Banana 2K references. Identify differences in shadows, wood grain, kart reflections, and the darker background.
Update the existing geometry, materials, and lights in src/lights.js, src/textures.js, src/main.js, or the model files actually used by this project.
Keep the reference image out of the scene background. Capture the original views again, rotate the camera, and drive a lap to confirm the improvement survives in real-time 3D. Show the edits and before/after captures.
フェーズ7:フレームレートの測定と部屋全体の作り込み範囲の判断
マシンがデスクの上を快適に走行できるようになると、「このまま部屋全体の窓や本棚、ソファまで3Dシーンに作り込みたい」と考えがちです。
しかしリアルタイム3Dレンダリングにおいては、プレイヤーの視界に入らない非コア領域にハイポリゴンのジオメトリを詰め込むことは避けるべきです。最適化に着手する前に、現在のパフォーマンスのボトルネック(フレーム時間、DrawCall描画呼び出し回数、シャドウパス、テクスチャVRAM)を特定し、ボトルネックの種類に応じた対策を講じます。一般的なPC環境では、まず30fpsを安定したプレイアブル基準とし、計測したボトルネックを解消しながらより高いフレームレートを目指します。
最適化戦略のポイント:
- コア領域へのディテール集中:マシンと周回コースが存在する中心的なデスクエリア(直径1.2m以内)にPBRマテリアルとメインライトの動的シャドウを集中させます。
- 背景・遠景の暗部処理:部屋の壁や本棚などはシンプルな板状のジオメトリで輪郭を作るにとどめ、影の投影・受影は完全にオフにします。メインライトの自然な減衰によって暗闇に溶け込ませることで、余分なシャドウ計算負荷を回避します。
- 静的メッシュの結合(DrawCallの削減):キーボードの膨大なキーキャップがそれぞれ独立したMeshになっていると、毎フレーム数百回もの描画呼び出しが発生します。Blenderでのモデリング時、またはThree.jsの初期化時に、
InstancedMeshを利用するかメッシュの結合(BufferGeometryUtils.mergeGeometries)を行って1つのメッシュにまとめます。 - 個別プロップのポリゴン数管理:デスク上の小さなプロップは1点あたり500〜2,000ポリゴン前後に抑え、天板全体の総ポリゴン数は5万ポリゴン以下を目安とします。ポリゴン数の管理はシャドウパスやテクスチャ解像度と合わせて総合的に検証してください。
テンプレート14:パフォーマンス指標の測定とボトルネックの重点的最適化
日本語版(コピー用):
現在の `desk-racer` フロントエンドの描画パフォーマンスについて、指標の測定と重点的な最適化を実施してください:
1. **指標の計測**:ページ内に軽量なパフォーマンスモニターを導入し、現在のFPS、フレーム時間(ms)、`renderer.info.render.calls`(DrawCall回数)をリアルタイム表示すること。
2. **ボトルネック特定と光源の負荷軽減**:負荷の主因がCPUのDrawCall限界にあるのか、GPUのフィルレート/シャドウ処理にあるのかを特定すること。シーン内で `castShadow = true` に設定する光源はメインのスポットライト1灯のみに限定し、ディスプレイの環境光による余分なシャドウパスは無効化すること。
3. **静的メッシュの結合**:メカニカルキーボードのモデルを点検すること。キーキャップが多数の独立したメッシュで構成されている場合は、結合するか `InstancedMesh` に変換し、結合前後のDrawCall測定値を比較すること。
4. **実機検証**:ブラウザ上で周回走行を繰り返しテストし、安定動作の基準として30fpsを確保(専用GPU環境では60fpsを目指して調整)した上で、急カーブや視点切り替え時のフレーム落ちやカクつきを解消すること。
英語版(本ガイドの学習用テンプレート):
Please profile rendering performance for `desk-racer` and apply targeted optimizations:
1. **Telemetry**: Add a lightweight stats overlay tracking FPS, frame delta (ms), and `renderer.info.render.calls` (DrawCalls).
2. **Bottleneck Audit & Shadow Pruning**: Determine whether performance is bounded by CPU DrawCalls or GPU fill-rate/shadow passes. Ensure strictly ONE primary spotlight casts dynamic shadows; disable shadow casting on auxiliary monitor fill lights.
3. **Mesh Merging**: Inspect keyboard keycaps. If composed of dozens of individual meshes, batch them via `BufferGeometryUtils.mergeGeometries` or `InstancedMesh`, comparing DrawCall measurements before and after.
4. **Acceptance Test**: Run a continuous multi-lap driving benchmark to verify smooth performance above the 30fps baseline (targeting 60fps on capable GPUs) without stutter during high-speed cornering.
フェーズ8:カメラワークの切り替えとデモ動画の録画
魅力的なデモ動画を作るのに、複雑なポストエフェクトは必要ありません。最も重要なのは、カメラワークのリズムと視点の効果的な切り替えです。
完成デモ動画の0秒付近。ディスプレイ、デスクライト、美しく光るキーボードが一体となって卓上サーキットを形成しています。
1. ゲーム内に実装すべき4つの必須カメラ制御
コード内で数字キーの入力を検知し、カメラが異なるターゲット位置の間を滑らかに補間移動するように実装します:
- カメラ1(後方追従視点 / Chase Cam):マシンの直上後方を滑らかに補間(Lerp)追従。ハイスピードなコーナリングや縁石の振動をリアルに体感できます。
- カメラ2(地面すれすれのコックピット視点 / Cockpit Cam):マシンの先端ルーフ部にカメラを固定。巨大なキーボードのキーやライトの支柱が間近に迫り、ミニチュア世界ならではの迫力を演出します。
- カメラ3(デスク全体俯瞰 / Tabletop View):高い位置からデスク全体を見下ろし、旋回する高架コースの全体像と空間レイアウトを提示します。
- カメラ4(旋回ドローン視点 / Drone Cam):大きな半径で円周上をゆっくりと旋回し、立体的な陰影と高低差のある高架構造を美しく見せます。
ステップアップ情報(原作の完全な操作体系):原作のコントロールパネルには1〜9番のカメラプリセットに加え、
Enterでタイムアタック開始、WASDで走行、Spaceでハンドブレーキドリフト、Shiftでブースト加速、Rでマシンリセット、ESCで設定表示、Mでエンジン音切り替え、Pでレール上の自動巡航モードなど多彩な機能が備わっていました。初めて実践する際は、テンプレートにある基本的な1〜4番カメラと基本操作の実装から始めれば十分であり、初版から自動巡航などの高度な機能をすべて盛り込む必要はありません。
テンプレート15:スムーズなマルチカメラ切り替えコントローラー
日本語版(コピー用):
`src/camera.js` 内に滑らかなカメラコントローラーを実装し、数字キー1、2、3、4によって各視点間を滑らかに補間遷移(Vector3.lerp および Quaternion.slerp を使用)できるようにしてください:
1. **キー1 - 追従視点**:目標位置はマシンの後方0.08m・上方0.035m、注視点はマシンの前方0.05m。
2. **キー2 - コックピット一人称**:目標位置はフロントフード上方0.008mに固定、正面を注視。
3. **キー3 - デスク全体俯瞰**:デスク中心の上方0.8m・斜め0.5mの位置に固定し、デスク全体を静止俯瞰。
4. **キー4 - ドローン旋回**:デスク中心を回転中心とし、0.15 rad/s の角速度でゆっくり自転巡回。
視点切り替え時に不自然な瞬間移動が発生しないようにし、0.6〜0.8秒程度でスムーズに遷移を完了させてください。
英語版(本ガイドの学習用テンプレート):
Implement a smooth camera controller in `src/camera.js` supporting keys 1, 2, 3, 4 with lerped transitions (Vector3.lerp and Quaternion.slerp):
1. **Key 1 - Chase Cam**: Offset 0.08m behind, 0.035m above the vehicle, looking 0.05m ahead.
2. **Key 2 - Cockpit View**: Mounted directly 0.008m above vehicle hood, looking straight forward.
3. **Key 3 - Overview**: Stationary vantage point 0.8m above and 0.5m offset from desk center, overlooking the track.
4. **Key 4 - Orbit Drone**: Slow orbit around desk center at 0.15 rad/s.
Smooth transitions across states within ~0.6–0.8s without sudden position snaps.
2. ローカルでの本番ビルド検証(一般公開なしでの録画準備)
録画を始める前に、本番環境向けのパッケージビルドをテストし、アセットパスが正しく、開発サーバーなしでも安定動作することを確認しておくことを推奨します:
# 1. 编译生产代码至 dist/ 目录
npx vite build
# 2. 预览生产版本
npx vite preview --host 127.0.0.1
ブラウザでプレビューURL(通常はhttp://127.0.0.1:4173/)を開き、入念なテスト走行を行ってください。モデル、テクスチャ、走行挙動を一つひとつチェックし、本番ビルドにおけるパス指定や動作に問題がないことを確認します。公開ドメインやサーバーの設定を行わなくても、ローカル環境だけで動画の録画まで完結できます。
3. OBS Studioを用いた画面録画手順ガイド
オープンソースのOBS Studioを利用できます:
- デバッグUIの非表示:録画前に、デモの目的に応じて画面上のスライダーパネルやHUDテキストを非表示にし(
HやESCなどのキーで切り替えられるようにしておくと便利です)、すっきりとした画面を保ちます。 - キャプチャソースの追加:
- OBSを開き、下部の「ソース」パネルで
+をクリックします。 - ウィンドウキャプチャ(Window Capture) を選択し、ドロップダウンメニューからゲームを実行しているブラウザウィンドウを指定します。画面が真っ暗になる場合は、画面キャプチャ(Display Capture) に切り替えて対象のディスプレイ全体を取り込みます。
- OBSを開き、下部の「ソース」パネルで
- キャンバスとフレームレートの設定:
- OBSの設定 → 映像 タブを開きます。
- 「基本(キャンバス)解像度」と「出力(スケーリング)解像度」をともに
1920×1080に設定します。 - 「FPS共通値」はまず 30 に設定することを推奨します。PCのGPU性能に十分な余裕がありコマ落ちが発生しない場合は、60 に引き上げてください。
- 音声ソースとレベルの確認:
- 原作ではGemini Omni Flashによって生成されたエンジン音も組み込まれていました。Google公式発表ブログ
- 「音声ミキサー」で入力があることを確認します。BGMやエンジン音を録音する場合は、「アプリケーション音声キャプチャ」または「デスクトップ音声」を追加します。
- 緑色のインジケーターが振れていることを確認し、赤色のクリッピング(音割れ)が起きないよう音量を調整します。
- 重要な注意点:macOS標準の
Shift + Command + 5機能では「オプション」からマイクを選択できますが、これをシステム内部音声の入力として使うことはできません。ゲーム内の音声を録音したい場合は、OBS内でOSのバージョンに合わせたシステム/アプリ音声キャプチャソースを追加し、レベルメーターを確認してください。
- 10秒間のテスト録画:
- 「録画開始」をクリックし、ブラウザ上でマシンを操縦しながらカメラアングルを切り替え、10秒ほど録画したら「録画終了」を押します。
- 保存先フォルダを開いてテスト動画を再生し、画面のブラックアウト、カクつきやコマ落ち、音ズレがないかを点検します。
- 録画フォーマットと再多重化(Remux):
- OBSの設定 → 出力 で、録画フォーマットを
MKVに設定します(万一PCがクラッシュしてもファイル全体が破損するのを防げます)。 - 録画完了後、OBSの上部メニューから ファイル → 録画の再多重化(Remux Recordings) を開き、録画したMKVファイルを選択して変換することで、各動画編集ソフトが直接読み込める汎用的な
MP4形式に変換できます。
- OBSの設定 → 出力 で、録画フォーマットを
4. 60〜80秒の完成デモ動画向け絵コンテ案
ゲームの魅力を引き出すためのおすすめのカット割り構成です:
- 0〜10秒(全体オープニング):カメラ3(デスク全体俯瞰)。光るキーボードの傍らに佇むミニチュアカーと、デスク全体の陰影を静かに映し出し、タイトルロゴを表示。
- 10〜35秒(加速・疾走):カメラ1(後方追従視点)。スタートダッシュからマウスパッドをドリフトで回り込み、キーボードを跨ぐ高架橋へと駆け上がる一連のダイナミックな走りを描写。
- 35〜55秒(マクロ接写):カメラ2(地面すれすれのコックピット視点)。メカニカルキーボードのキーキャップやディスプレイの支柱すれすれを猛スピードで通り抜け、ミニチュアスケールならではの速度感を強調。
- 55〜75秒(ゴール&フィニッシュ):フィニッシュラインを駆け抜けて3ラップ完了を表示(リザルト画面を実装していれば表示し、なければゴールアクションで締めくくり)、滑らかにカメラ4(ドローン巡回)へと遷移してデスク全体を旋回しながら余韻を残して終了。
- 書き出し仕様:動画編集ソフト(CapCut、DaVinci Resolve、Premiereなど)で、H.264コーデック、AAC音声、1080p解像度のMP4動画として書き出します。
トラブルシューティング:よくあるエラーと対処法
本ガイドの実践中につまずきやすい典型的な問題と解決策をまとめました:
| 現象とエラー | 主な原因 | 正しい対処法 |
|---|---|---|
MCP接続エラーConnection refused / port 9876 |
Blender側のアドオンサービスが未起動、またはBlenderのウィンドウが閉じられている。 | Blenderを開き、Nキーでサイドバーを表示してMCP for Blenderタブを確認。「Started」と表示されているか確認するか、Start MCP Serverをクリックし、ウィンドウを開いたまま作業してください。 |
コマンドラインエラーspawn uvx ENOENT |
エディタやIDEのGUI環境がシステムターミナルのPATH環境変数を認識できていない。 | システムのターミナルでwhich uvx(Windowsではwhere.exe uvx)を実行して絶対パスを取得し、mcp_config.json内のuvxをその絶対パスで書き換えてください。 |
モデル読み込みの404エラー404 Not Found /models/... |
Three.js側のパス指定に誤って/publicが含まれているか、静的ファイルがpublic/models/に配置されていない。 |
Viteプロジェクトでは、読み込みパスを/models/desk-props.glbに統一してください。プロジェクトのpublic/models/配下に実体が存在し、ファイルサイズが0より大きいことを確認してください。 |
| 画面のチラつき(Z-fighting) コースや天板にまだらな縞模様が出る |
コースの底面が天板の平面と完全に重なり合っている(深度バッファの精度限界によるレンダリング競合)。 | src/track.jsでコースの基準高さを天板から0.003m以上持ち上げるか、マテリアル設定でpolygonOffset: trueを有効にしてください。 |
| 影の途切れや浮き(Acne / Peter Panning) | シャドウバイアス(shadow.bias)の設定値が不適切。小さすぎると自己影のノイズが生じ、大きすぎると影が浮いてしまう。 | デバッグパネルで実際に投影している光源のlight.shadow.biasを微調整してください。また、影の解像度とカバレッジ範囲を点検し、スポットライトでは角度やnear/far、平行光では正射投影の範囲を調整します。 |
| 起動時のブラックアウト・ホワイトアウト コンソールに #appが見つからないと警告 |
index.htmlにマウント用要素が欠けているか、npx vite実行前にsrc/main.jsが生成されていない。 |
フェーズ4の「最初のプレイアブルコードの構築」テンプレートを使ってHTMLとJavaScriptファイルを正しく生成し、モジュールの読み込みパスを確認してからサーバーを起動してください。 |
| 録画にゲーム内音声が入らない 録画した動画に周囲の雑音しか入っていない |
macOS標準の画面録画を使用していて、システム音声取り込み用の仮想ドライバが設定されていない。 | OBS Studioを使用し、「アプリケーション音声キャプチャ」または「デスクトップ音声」を追加してください。ミキサーのレベルメーターが反応していることを確認してから録画を開始します。 |
まずは1周完走できるバージョンから始めよう
まずは自分のデスクを撮影し、コンセプトアートと制作計画を固めた上で、しっかりと周回走行できるシンプルなプロトタイプを作成しましょう。そのベースが安定したら、プロップ、テクスチャ、ライティングを一つずつ追加し、その都度スクリーンショットとコードのバージョンを記録していきます。最後に10秒間のテスト録画を行ってから、本格的なデモ動画の撮影に挑戦してみてください。
実践用持ち帰り資料
Markdown をスクロールして確認し、コピーしてチーム向けに調整できます。
Markdown を読み込み中…
