Curated by Ojo & Jemi (Antigravity)

3Dグラフィック・クリエイティブ完全大全

ドット絵の愛嬌を受け継ぐ「3D箱庭」から、スタイライズド・ミドルポリが拓く「10年色褪せないアニメの美学」、
外部ファイル0MBのプロシージャル・ローポリで疾走するカートレース、発注文9行から AI が設計・実装・ブラインド採点まで自律で回した1周5kmの温泉街カートGP、そしてスケルトン不要で命を宿した「app071の実機散策」まで。全表現手法の美学と実装を1つに統合。

🎮 app071 実際の3D散策をプレイ 🏎️ カートスプリント(プロシージャル・ローポリ実機)をプレイ ♨️ 湯けむりカートGP(1周5km・全コード生成)をプレイ 💎 最新理論:究極のミドルポリを見る
実機体験可能

app071-astra-japan-3d 散策デモ

● サーバー稼働中(常時60FPS)
app071 実際の散策画面
ここで3D散策デモを起動 クリックでページ内に直接読み込み・操作

実際のThree.js散策画面:スケルトンを使わないIK計算で歩く旅人と自律追従する柴犬

ブラウザで今すぐこの世界を歩く

Blender 5.2で造形された神社・社殿の厳かな空間を、旅人となって実際に散策できます。
柴犬は自律的に匂いを嗅ぎ、立ち止まり、離れると駆け寄って同行します!

⌨️ 操作方法ガイド

  • [W / A / S / D] または 矢印キー: 旅人の移動(左右の脚・腕が連動)
  • マウスクリック&ドラッグ: 3Dカメラの自由回転・視点変更
  • マウスホイール: ズームイン / ズームアウト
実機レース体験 表現手法:プロシージャル・ローポリ

KURO CITY SPRINT — 時計台と汽笛の港町

● 12台混走AI搭載・常時60FPS(Three.js)
KURO CITY SPRINT レース画面
ここでカートレースを起動 クリックでページ内に直接読み込み・即レース開始

昭和レトロな港町:Lap 1(夕暮れ)→ Lap 2(提灯一斉点灯)→ Lap 3(夜景と花火フィナーレ)

外部3Dモデル0MB!「完全コード生成」で建ち並ぶ港町

外部の3Dモデル(.glb)や画像テクスチャを一切使わず、すべての街並み・カート・コースをJavaScriptコードの計算だけで生み出した「プロシージャル・ローポリ(完全コード生成)」の実機デモ。
海を西に置いた坂の港町を舞台に、クロちゃんがエンジンの物理定数から逆算して設計した「深溜めドリフト成立帯(R14〜21)」と、3周の間に夕暮れ→提灯点灯→夜空の花火へとドラマティックに移ろう世界演出が融合しています。

⌨️ レース操作ガイド

  • [W / A / S / D] または 矢印キー: アクセル・ブレーキ・ステア
  • [Space]: ドリフト(ステアしながら溜めて離すと3段ミニターボ発動!)
  • [E]: アイテム使用(スリップストリーム・近道ルートあり)
  • [C]: カメラ視点切替(追走カメラ → 専属ドローン → 迫力の運転席ビュー)
  • [F]: 全画面表示切替 / [R]: リスタート
デモ動画

🎥 クロちゃんの公式実走デモ映像(32秒)

実際のゲームプレイ:12台混走スタートから夕暮れの港町を疾走する迫真の走り

💡 【深掘り技術解説】コードの宮大工・クロちゃんが施した「4つの職人技」(クリックで開く)

外部3Dモデル・画像ゼロ!「MeshBucket」によるプロシージャル造形

Blender等で作ったモデルファイル(.glb)や画像テクスチャ(.png/.jpg)を一切読み込まず、建物(石垣・木格子・トタン屋根・銅板緑青)、風車、時計台、提灯、そしてカート本体に至るまで、すべてJavaScriptのコード計算(直方体・角柱プリミティブ)だけで生成しています。
自作の「MeshBucket」機構で街の全パーツをゾーンごとに巨大な頂点バッファへ焼き込み、頂点カラー(Vertex Color)を埋め込むことで、街全体の描画負荷を驚異の44ドローコール(予算250以下)に圧縮。ブラウザ環境でも軽々と常時60FPSを叩き出します。

手描きテクスチャ不使用!「HTML5 Canvas」による動的ペイント

看板のフォント、提灯の「祭」の灯り、車のゼッケンや計器メーター、路面の白線や縁石の縞模様まで、すべてブラウザの内部メモリ上でCanvas API(2D描画)を使ってコードから動的にペイントし、Three.jsテクスチャへ変換しています。
さらにモジュール内キャッシュ(_texCache / _geoCache)により、12台混走のカートで共通部品を賢く共有し、メモリ消費を極限まで削減しています。

「紙にコースを描くのをやめた」——物理と数学からの逆算設計(クロソイド曲線)

お嬢がV1試走時に「コース単調」と評されたことを受け、手描きでのコース設計を全面撤廃。カートの最高速度(30m/s)や横加速度、ドリフトチャージ速度から逆算し、「深溜めドリフトが気持ちよく決まるコーナー半径は R14〜21 だけである」という数式を導出しました。
逆に「できそうでできない中途半端な半径(R24〜42)」をコースから完全に排除(禁止帯に指定)。道路工学のクロソイド曲線生成スクリプトと非線形ソルバー(LM法)を駆使し、1周約60秒(1,647m)で完璧に閉じるドラマティックな立体周回コースを自動生成させました。

お嬢の言葉から3回作り直した「本物の運転席ビュー」

当初の「自機をまるごと消す」簡易カメラに対し、お嬢から「これ運転席ビューとは言い難いよね」と本質を突いた指摘を受けたことで生まれた名機能です。
ドライバーの頭と胴体だけを非表示にし、「ステアリングを握る両手・フロントノーズ・前輪・計器」が視界に入る本格コックピット視点を3回作り直して完成させました。視点切替(Cキー)で運転席に入ると、海沿いストレートでブーストリングを踏む怒涛のスピード感を体感できます。

逆に欠点は?(お嬢の疑問:なぜ全部これにしないのか?)

「外部ファイル0MB・常時60FPSなら全部これで良いのでは?」という疑問に対する答えは「強烈な5大代償」にあります。
①GUIがなく数式でしか直せない「暗闇の数字コーディング」、②髪や肌など「人間・生物・自然物が作れない」、③生活感やバリエーションを増やすとコードが肥大化して自滅する、④服の揺れや表情変化などの変形アニメーションが原理的にできない、⑤世界中の既存3Dアセットから孤立する……という過酷な制約が存在します。
この作品が奇跡的に成立したのは、クロちゃんが「無機物の箱型建築・幾何学コース・軽量性が120%活きる世界観」をピンポイントで見抜いて設計したからこそです。

実機レース体験(PC・キーボード) 表現手法:全アセットをコード生成(three.js 本体のみ例外)

湯けむりカートGP — 1周5kmの温泉街

● 12台混走・観客22,000人・高低差118m(Three.js r185)
湯けむりカートGP レース画面(湯の街ストレート)
ここで湯けむりカートGPを起動 クリックでページ内に読み込み(4.7MB・PC推奨)

実走キャプチャ(無加工):湯の街 → 地獄谷 → 湯滝と渡し の3セクション・1周5,000m

タイトル画面 湯滝の混戦 赤い太鼓橋

発注文は9行。設計・実装・検証・採点まで AI が自律で回した「AAA級への挑戦」

画像・音声・フォント・3Dモデルのファイルは0個。テクスチャは GPU で焼き、音は WebAudio で合成し、観客 22,000 人は頂点シェーダで揺れる。コースは「紙に描く」代わりに曲率の関数として書き、非線形ソルバで 5,000.00m にぴったり閉じさせた立体周回コース。
そして本作の主役は絵より検証。実キー入力で 5km を完走する自動テスト、本物のマリオカート/Forza と出自を伏せて並べるブラインド採点、その判定器が信用できるかを測る「梯子」まで、すべて自前で組んでいます。結果は正直に載せます(下の技術解説 ⑤)。

⌨️ レース操作ガイド(ゲームパッド対応)

  • [W / A / S / D] または 矢印キー: アクセル・ブレーキ・ステア
  • [Space]: ホップ→ドリフト(溜めて離すとミニターボ)
  • [Shift] / [L]: アイテム使用
  • [C]: 後方確認 / [Enter]: 決定 / [Esc]: ポーズ・戻る
  • スマホはタッチ操作未対応です。画面と解説は見られますが、走るのは PC で。
💡 【技術解説】クロちゃんが組んだ「5つの仕組み」(クリックで開く)

コースは「曲率の関数」として書く——クロソイドと閉合ソルバ

コースを座標で描かず、58 本の区間それぞれに「半径・長さ・道幅・バンク・見通し」を書いた表から生成します。直線と円弧の間には道路工学のクロソイド(曲率が距離に比例して増える緩和曲線)を挟み、ハンドルが一定速度で切れる自然な進入を作ります。
表のままでは終点が始点に戻りません。そこで Levenberg–Marquardt 法で 58 パラメータを最小ノルムで微調整し、位置ずれ・向き・全長を同時に満たす解を求めました。結果は全長 5,000.00m・閉合誤差 0.098m。標高は PCHIP(単調 3 次補間)で滑らかにつなぎ、最高地点 118m の峠を越えます。
さらに「面白いコースの条件」を 22 項目の機械ゲートに落としました。半径の分布・幅の変化・見通しの明暗交互・ランドマーク間隔・勾配上限・そして実際のエンジン定数で積分した速度プロファイル(ラップ 155〜190 秒に収まるか)。22/22 を通すまで表を書き直しています。

ファイルは three.js だけ——テクスチャも音も観客もコードから

石畳・漆喰・杉板・湯の花の各テクスチャは、起動時に GPU のMRT(マルチレンダーターゲット)で「色」と「粗さ・金属・遮蔽」を 1 パスで同時に焼き、高さから Sobel フィルタで法線を起こしています。エンジン音・ドリフト音・観客の歓声・BGM は WebAudio のオシレータとノイズから合成。観客 22,000 人は InstancedMesh 1 つに乗せ、頂点シェーダの中で手を振り・跳ね・回頭するので CPU 負荷はほぼゼロです。
「本当にファイルが 0 か」は人が見張るのではなく 純度ゲートが機械で確認します(バイナリ資産・外部 URL・ローダ・Web フォント・そして再現性を壊す Math.random() の使用を禁止)。実際に 1 か所の Math.random() をこのゲートが捕まえました。

12 の担当に分けて並列実装——先に「契約」を書き、批評家に契約自体を壊させる

レンダラ・空と時刻・地形・コース・温泉街・カート・観客・AI・アイテム・音・UI・入力の 12 担当をサブエージェントに割り当て、ファイル所有表と関数シグネチャを書いた契約書(architecture.md)を先に固めてから一斉に書かせました。
ここで別の研究担当に契約書だけを辛口レビューさせたところ、矛盾 17 件が出ました(例:ポストプロセスの順番が色を静かに壊す、露出補正を 2 か所で二重にかける)。裁定して 22 件の修正条項にまとめ、「修正条項を読んだ印を置くまで lint が落ちる」仕組みで、走っている最中の担当にも確実に届くようにしています。

検証は安い順に 6 段——最後は「本物のキー入力」で 5km を完走させる

契約適合(27 項目)→ 純度 → スモーク(描画統計)→ 定点スクショ → 実ユーザー経路 E2E → 性能、の順に安いものから回します。E2E は WSL 上のヘッドレス Chromium に 実 GPU(D3D12 経由の ANGLE)を通し、内部関数を呼ばずキーボードイベントだけでタイトル→選択→カウントダウン→5km 完走→リザルト→タイトルまで戻る 19 手順を通します。壁に当たる・逆走する・タブを離れる・画面を縮めるといった「行儀の悪い操作」も含みます。
この E2E だけが見つけた不具合が「右を押すと左に曲がる」です。AI 車は入力層を通らないので AI 走行のテストでは一切出ませんでした。「テスト用の経路だけで合格にしない」という発注文の一行がそのまま効いた例です。

本物とブラインド比較——そして「判定器が信用できるか」を梯子で測る

自作の絵と、Web から取得した Mario Kart World・Forza Horizon 5 の絵を出自を伏せて 1 枚ずつ、9 項目(材質の多様性・接地と影・シルエット・色設計・情報密度・光・奥行き・生気・完成度)で 3 人の評価エージェントに採点させます。評価者は 1 巡目と 2 巡目で視点を総入れ替え(アートディレクター/遊び手/技術者 → 出荷 QA/店頭の客/撮影監督)。
判定器そのものの妥当性は「梯子」で確認します。自作を「影なし」「テクスチャなし」「陰影なし」と段階的に劣化させた絵を混ぜ、劣化が強いほど点が下がる単調性が崩れていれば判定器を信用しません。実際、3 巡とも「影なし」が「完成版」をわずかに上回りました(影を落とすと画面が暗く重くなり、パッと見では損をする)。物差し側に残っている課題として、隠さずに書いておきます。評価者を入れ替えた 2 巡目は、この劣化 3 段の点差から「パネルの辛さ」(実測 −0.50)を補正して比べます。
結果(6 巡目・同じ評価者内の差は −2.28 で 6 巡中いちばん小さい)。「マリオカートと並べて負けないで」に対してはまだ負けています。生の点を巡ごとに比べてはいけません。評価者の辛さが毎回違うからです(劣化版 3 段の平均で 3.22〜4.28 の幅がありました)。使える読み方は 2 つだけで、同じ評価者内の本物との差と、評価者の辛さで正規化した値。どちらも 6 巡目が最高でした。最大の弱点は「全部同じマットな粘土に見える」材質で、これは 6 巡で一度も動いていません。粗さを散らす修正も、逆に全部マットへ畳む修正も、実測で効きませんでした。

今の状態(2026-09-12 12 時時点・全部実測)

コース機械ゲート22 / 22 合格
契約適合 lint27 / 27 合格
アセット純度合格(画像・音声・フォント・モデルのファイル 0)
実ユーザー経路 E2E19 / 19 合格(実キーで 5km 完走・189 秒・12 台中 9 位)
ブラインド採点(6 巡目・6 組目の評価者)同じ評価者内の差 −2.28(6 巡で最高)。巡ごとに −2.89 → −3.22 → −2.44 → −2.78 → −2.89 → −2.28
ドローコール・fps(WSL ヘッドレス実 GPU)最大 593(予算 600 内)・最低 59.3fps
60fps 正式判定未(WSL のヘッドレス値は参考値。Windows Chrome で測る)
📝 【使用プロンプト】お嬢がクロちゃんに出した発注文・全文(これ 1 通だけ)

2026-09-06 に Claude Code(モデル: Claude Fable 5.1)へ渡した発注文です。途中の追加指示は「進捗は?」「見せて」だけ。設計・実装・検証・採点の全判断は AI 側です。

マリオカート風のレースゲームを作って。ブラウザで遊ぶ3D。アセットは全てコードで生成(three.js本体のみ例外)。
コースレイアウトは1周5kmの温泉街、観客いっぱいの、高低差あり
とにかくAAA級のものを作って。マリオカートと並べて負けないで。
ultracodeで、テクスチャから挙動まで思いつく全てを最高品質で実装して。
担当をサブエージェントへ分け、実装→実行→別の超辛口Evaluatorによる確認→修正のループを合格まで自律的に回して。
実際のユーザー経路を端から端まで検証して。テスト用・撮影用の経路だけで合格にしないで。
本物をWebで取得しブラインドで比較して。判定器の妥当性も確認し、修正後は別Evaluatorで再評価して。
自己検証や上限到達を完成扱いしないで。
検証は安い手段から順に使って。同じ理由で落ち続けたら方針を変えて。

プロジェクトは kuro-projects/active/kart-aaa-20260906。既存の kart-* は見ないで。

わざと書かなかったこと:コース長以外の数値、遊びの条件の列挙、参考資料の指定、承認ゲート。「指定を 1 つ増やすたびに AI の判断が 1 つ減る」という方針で、何を作るかは実行する側に委ねています。「ultracode」は Claude Code の多エージェント並列オーケストレーション(Workflow)を明示的に許可する合言葉です。

⏱️ 【制作時間とコスト】サブエージェント 217 体・約 1,720 万トークンの内訳
工程(Workflow) 中身 実時間
① リサーチ本物のコース設計・車両物理・レンダリング手法を調査し、契約書の矛盾 17 件を批評42.9 分
② 実装12 担当を並列実装 → スモーク統合 → 修正3 時間 29 分
③ ブラインド採点 1 巡目21 枚 × 3 人 = 63 件の独立採点4.0 分
④ 修正 1 巡目弱点 5 項目を担当別に修正94.8 分
⑤ ブラインド採点 2 巡目別の評価者 3 視点で再採点4.2 分
⑥ 修正 2 巡目5 担当中 1 担当が完走、4 担当は週の利用上限で停止(途中までのコミットは残った)59.4 分
⑦ ブラインド採点 3 巡目(9/12)3 組目の評価者(環境アーティスト/実況の視聴者/美術講師)で 63 件2.2 分
サブエージェント数217 体(7 本の Workflow 合計)
サブエージェント消費トークン17,176,634(約 1,720 万)
エージェント実働の合計約 6 時間 55 分(並列のため壁時計では約 4 時間 30 分)
人間の作業発注文 1 通と、途中の「進捗は?」「見せて」「これすごい」
成果物の規模29 ファイル・約 20,000 行・64 コミット・配信サイズ 4.7MB(うち three.js 3.7MB)
追加費用0 円(Claude Code の定額プラン内。ただし週の利用上限に到達し、修正 2 巡目の 4 担当が途中停止)
使ったモデル・道具Claude Fable 5.1(Claude Code)/three.js r185/Playwright+ヘッドレス Chromium(WSL2・実 GPU)

主要制作は 2026-09-06 の 1 日。9-12 に取り残しの修正(巨大な岩壁・空の紙吹雪・観客の遠近)、3 巡目の採点、E2E の再確認、配信、引き継ぎ文書を仕上げています。数字はすべて Workflow のログと git から取った実測値です。

00

【最高峰の王道】スタイライズド・ミドルポリという答え

お嬢の至高の着想 「スタイライズド=ローポリじゃない。ミドルポリ+鮮やかマテリアル+柔らかい形+誇張プロポーション+豪華ライティング&パーティクル」
スタイライズド・ミドルポリのドリフトレーシング

作例:キャンディ塗装の丸みあるボディから鮮烈なスパークが舞う、スタイライズド・ミドルポリの世界

なぜこれが「10年色褪せない世界最高峰」なのか?

「ローポリほど面を削らず、リアル系ほど細密化もしない中程度のメッシュを、意図的にデフォルメして仕上げる方向性」
『マリオカート8DX』やピクサー映画が証明し続ける、ゲームアートの完成形です。

  • 柔らかい形 & 少し誇張したプロポーション:
    ミドルポリだからこそ表現できる美しい曲面とグラマラスなフォルム。太いリアタイヤとキュッと締まったキャビンが「カッコよさと愛嬌」を同時に宿す。
  • 鮮やかなマテリアル(キャンディ塗装):
    濁りのないクリアな光沢(グロス塗装)と高彩度なネオンカラー。写実的な汚れではなく「清潔でポップなリッチさ」を追求。
  • 豪華なライティングと星屑パーティクル:
    ドリフト時にタイヤから飛び散るマゼンタ&シアンの鮮烈な火花、濡れたアスファルトのブルーム反射が画面全体を夢のような熱気で包み込む。

シェーダーの魔術 メッシュを複雑にせず「セルシェーディング+輪郭線」で極上アニメへ昇華

セルシェーディングのアニメ調レーシング

作例:パキッとした2階調の影と黒い輪郭線(アウトライン)が生み出す劇場版アニメの世界

お嬢のおっしゃる通り、「メッシュ自体はシンプルでも、シェーダー(マテリアル)とライティングをセル調にするだけで、一気に手描きアニメの作画になる」という3Dの最大のチート技です。

  • 2値のステップ影(Toon Ramp): 滑らかな光の減衰をあえて「明部と暗部の2段階」にカットすることで、セル画の質感を完全再現。
  • 反転法線アウトライン: メッシュの外側に黒い境界線を描画し、手描きのインクラインを付与。
  • 圧倒的な軽量性: 複雑なポリゴンを捏ね回す必要がないため、制作コストを抑えつつブラウザやスマホでもサクサク動かせる!

思想の転換と未来 「リアルを簡略化」ではなく「アニメ世界を3D化する」 — AI画像生成との奇跡の相性

AIコンセプトから3Dセルモデルへのパイプライン

開発パイプライン:2D AIアニメコンセプト ➡️ 3Dミドルポリメッシュ ➡️ セルシェード具現化

💡 引き算のモデリングから、具現化のモデリングへ

従来の3Dは「現実の車をモデリングして、スペックに合わせてポリゴンを削る(劣化させる)」という引き算の発想でした。
しかしお嬢の提唱する道は、「最初からアニメの世界に存在する理想のマシンとして設計し、3D化する」という足し算・具現化のアプローチです!

  • AI画像生成の最大の得意技: 2D AIはエッジが際立ったアニメ調のコンセプトアートを描くのが最も得意。
  • 3D生成AIでの破綻が最小: リアルスキャンのような微細ノイズがないため、ミドルポリのクリーンなメッシュが一発で生成しやすい。
  • セルシェーダーで完全着地: トゥーン影とアウトラインを重ねるだけで、2Dコンセプトアートがそのまま3Dゲーム内で動き出す!
01

【お嬢の慧眼】スタイライズド・ローポリという至高の落とし所

02

レースゲームにおける「3大アプローチ」徹底比較

「愛嬌と破壊」のボクセル、「洗練と高級感」のスタイライズド・ローポリ、そして「外部ファイル0MB・極限軽量」を切り拓くプロシージャル・ローポリ。
お嬢と導き出した、3つの手法が持つそれぞれの強み・欠点(トレードオフ)・適材適所を徹底比較します。

アプローチ A 愛嬌と破壊の熱気

箱庭3Dボクセルナイトレーシング

箱庭ボクセルレース

夜のネオン街 × 立体交差 × ピット × 観客席 × 花火 × ミニカー

  • ブロック物理破壊: クラッシュ時に車輪やフェンスがキューブ単位で派手に弾け飛ぶ!
  • 四角いパーティクル: ドリフトの煙、火花、夜空の花火がすべてブロックで舞う。
  • コミカルな演出: ピットクルーがタイヤブロックをスポンと抜いて即交換。
アプローチ C(実機実装) 極限軽量とコード生成

プロシージャル・ローポリレーシング

プロシージャル・ローポリ カートスプリント

外部ファイル0MB × 44ドローコール × 昭和港町 × 完全コード生成

  • 外部ファイル0MB・即起動: 3Dモデルも画像も読み込まずブラウザで即座に走れる!
  • 驚異の44ドローコール: 街全体を1メッシュへ一括焼き込み、常時60FPSを維持。
  • 物理と路面の完全同期: クロソイド曲線から直接路面を計算し、接地浮き0m。
🔍 【折り畳み解説】お嬢と探求した「プロシージャル・ローポリ」の5大欠点と適材適所 クリックで開閉 ▼

⚠️ 「全部これでいいのでは?」に対する5つの本質的欠点・トレードオフ

「通信0MB・超高速」という圧倒的なメリットがある反面、以下の制約があるため、プロジェクトの目的や表現に応じた使い分けが不可欠です。

  • ① 暗闇の数字コーディング(GUI不在): Blenderのような3D画面でドラッグ&ドロップ調整ができず、看板を2cm動かすのも頂点座標を数式で書き直す必要がある。
  • ② 人間・キャラクター・有機物が作れない: 髪の毛、服のシワ、表情、生物の滑らかな曲線をコードで数式化するのは原理的に極めて困難。
  • ③ 生活感やバリエーションを足すほどコードが肥大化: 街のディテール(路地裏のゴミ箱、配管、看板の種類)を増やせば増やすほど生成コードが数万行に膨れ上がり、保守が破綻しやすい。
  • ④ スキニング・ボーン変形アニメーションが使えない: メッシュを静的に結合するため、キャラクターの走行モーションや布の揺れなどの変形は不可。
  • ⑤ 既存の膨大な3Dアセット資産が使えない: 外部モデルを一切読み込まない前提のため、世の中の配布アセットやツールとの連携が断たれ、すべて自前コーディングになる。
💡 お嬢と導いた3大アプローチの適材適所:
ボクセル: 愛嬌、物理破壊、直感的な箱庭世界を作りたい時(企画・ビジュアル実証)
スタイライズド・ローポリ: シャープな車体、雨とネオンの本格アーケード、洗練された世界観を作りたい時(ガレージUI・世界観実証)
プロシージャル・ローポリ: Webブラウザでダウンロード待たずに即起動、昭和レトロ街並み、幾何学メカを作りたい時(KURO CITY SPRINT 実機稼働中!)

📊 レースゲーム3大アプローチ 総括比較マトリクス

比較指標 アプローチ A:ボクセル アプローチ B:スタイライズド・ローポリ アプローチ C:プロシージャル・ローポリ
主たる世界観・魅力 ブロック積木・物理破壊・愛嬌 鋭角流線型・雨とネオン・都会的洗練 昭和レトロ港町・完全コード生成
3Dアセット通信量 数MB〜十数MB 数十MB(.glb / テクスチャ) 完全ゼロ(0MB・即起動)
描画負荷(Draw Calls) 中〜大(キューブ面数で増大) 中(マテリアル・テクスチャ依存) 極小(わずか44 calls一括焼き込み)
最大の強み コミカルなブロック破壊と親しみやすさ 洗練されたスポーツカーの疾走美 ロード時間ゼロ・常時60FPSの超軽量性
最大の弱点・欠点 流線型が出せない・広大な世界で重い 手作業モデリング工数・アセット肥大化 数式直しの難度・人間や自然物が作れない
実機ステータス 企画・ビジュアル実証段階 ガレージUI・世界観実証段階 🎮 KURO CITY SPRINT(本ポータルで実走可能!)
実機実装の答え アプローチ C:プロシージャル・ローポリ

クロちゃん実装:プロシージャル・ローポリ「時計台と汽笛の港町」の美学と設計

🎮 上の実機デモで今すぐ走る

ボクセル(アプローチA)の軽量性と、スタイライズド・ローポリ(アプローチB)のシャープな疾走感をコード生成で融合させた「プロシージャル・ローポリ」の実装例
前作の大周回(15km)の反省を受け、「1周約60秒・全3周(約1.48km)」へ濃縮。外部3Dモデルや画像を一切使わず、自作のMeshBucket機構で建物・道路・カートをゾーンごとに1メッシュへ焼き込むことで、世界全体の描画負荷をわずか44ドローコールに抑え込みました。
クロソイド曲線の数学的設計により、深溜めドリフトが成立するコーナー帯(R14〜21)だけを配置。3周の間に世界が夕暮れから夜、そして花火へと移ろうドラマティックな体験が実現されています。

Lap1 夕暮れの商店街

Lap 1・夕暮れ: 提灯の下がる商店街を12台混走で駆け抜ける。夕日の斜光が美しいスタート区間。

Lap1 ドローン視点

専属ドローンカメラ: 丘の風車と夕暮れの空。5つの映画文法でレースの迫力を自動追従する飛行AI。

Lap2 提灯点灯

Lap 2・提灯一斉点灯: 時計台の鐘が響き渡り、街中の提灯がパッと灯る。空は赤紫のグラデーションへ。

Lap2 運転席ビュー

迫力の運転席ビュー: ハンドルと手元が見え、海沿いの全開ストレートでブーストリングを踏む臨場感!

Lap3 夜の海沿い

Lap 3・静かな夜の闇: 海沿い区間は街灯が消え、路肩の誘導灯と月明かりだけが先を照らす静寂。

Lap3 花火フィナーレ

花火フィナーレ: 港の夜空に大輪の花火が次々と打ち上がり、計時塔(時計台)が夜空に浮かび上がる。

03

ボクセルならではの真骨頂 — 物理破壊と愛嬌あふれる命

ゲームギミック

空中に弾け飛ぶ「ボクセル物理破壊」

ボクセルのクラッシュ物理破壊

激突の瞬間:何千ものカラーキューブが火花とともに宙に舞う大迫力のクラッシュ!

ポリゴンがペシャンコに潰れる一般的なリアルレースと違い、ボクセルは「ブロックがバラバラに飛び散る」ため、大事故でもどこかコミカルで爽快なエンタメ体験になります。

キャラクター

表情豊かな「ボクセルクルー&マスコット」

ボクセルキャラクターのラインナップ

表彰台のクルーたち:レーサー、整備士、フラッグガール、熱狂観客、ゴーグル猫マスコット

人間から動物マスコットまで、すべてブロックで統一!関節がキューブ単位で分かれているため、面倒なウェイト調整なしで誰でも簡単に可愛いアニメーションを付けられます。

04

ボクセルアートの神髄 — デジタル世界のレゴブロック

「Volume(体積)」+「Pixel(画素)」の魔法

2Dのドット絵が平面マス目に色を置くのに対し、ボクセルは**立体キューブ(立方体)**を積み上げたり削ったりして形を作ります。

デジタルレゴならではの圧倒的メリット
  • 夜中に踏んでも痛くない: 部屋中に散らかしても足裏の平和が保たれる。
  • パーツ・色が無限: パーツ不足で買い足しに行く必要がない。
  • 直感的操作: 複雑な頂点移動がなく、子供から大人まで彫刻感覚。
  • ライティングで化ける: 自発光ブロックと陰影で温もりあるジオラマに。
和室のボクセル箱庭ジオラマ

作例:和室の箱庭ジオラマ(行灯の温かな明かりとキューブで編まれた家具)

街並みと交通のモジュール

モジュールで広がる「都市全体」

車・人物・ビル・道路を小分けパーツ(モジュール)として作り、マップ上にコピペ配置するレゴ方式。広大な都市網も極めて効率的に構築できます。

超精細マイクロボクセルカフェ

大人の高級感「マイクロボクセル」

キューブの粒を砂粒のように細かくし、被写界深度(ボケ味)を効かせると、精巧な建築模型やドールハウスのような超オシャレな質感になります。

05

グラフィック表現の「3段進化」と位置づけ

ドット絵、ボクセル絵、通常の3Dメッシュ。この3者は競合ではなく、味わいと制作規模によって住み分けられた美しいグラデーションです。

表現形式 構成要素 得意なゲーム プレイヤーが感じる魅力 代表的作例
ドット絵 (Pixel) 2D 平面マス目 2Dレトロゲーム・RPG 記号的な愛嬌、想像力で補うノスタルジー マリオ / クロノトリガー
ボクセル絵 (Voxel) 3D 立方体キューブ 3D箱庭・カジュアル・破壊 「ドット絵の可愛さ」×「3Dの光・空間」のスイートスポット クロッシーロード / Teardown
通常の3D (Mesh) 3D 三角/四角メッシュ リアル系・オープンワールド 滑らかな曲面、圧倒的な実写再現、映画的没入感 グランツーリスモ / Cyberpunk
06

Blenderとメッシュの世界 — 3Dキャラに命を吹き込む手順

プロが実践するキャラクター制作パイプライン

お嬢が整理されたステップ通り、ただの3D形状から「歩き、動き回るキャラクター」へ仕上げるには5つの厳密な段階を経ます。

STEP 01
Mesh
ポリゴンで骨格・人体の外見をモデリング
STEP 02
Material / Texture
光の反射・テクスチャ画像を密着貼り
STEP 03
Skeleton (Armature)
体内に骨組み(首・腕・脚)を通す
STEP 04
Rigging
骨の動きに連動して肉が曲がるウェイト付け
STEP 05
Animation
歩行・走行のキーフレームループを作成
💡 制作を爆速化するプロの裏ワザ

ボクセルキャラの特権: 関節がブロック単位で分かれているため、皮膚の伸び縮み(ウェイトペイント)の泥沼調整が不要!
Mixamo(自動リギングAI): モデルをアップロードするだけで、AIが骨を自動挿入し、何千種類もの歩行・走行モーションを1秒で適用可能。

お嬢の凄腕実装

app071-astra-japan-3d

⚡「スケルトン(骨)すら入れない」プロシージャル歩行の極致!

重たいスケルトン(Armature)やスキンメッシュを一切使わず、柴犬は階層パーツの三角関数回転旅人は脚メッシュの頂点を直接IK(逆運動学)計算で曲げ伸ばしして歩行を実現!

  • ボーンのオーバーヘッドが完全ゼロ: データの軽量化とブラウザでの常時60FPS稼働を達成。
  • コードで命を吹き込む美学: 標準パイプラインの常識を破り、数学とプログラミングで足を前に進める驚異の実装。
app071 神社参道

実際のThree.js散策画面:スケルトン不要のプロシージャル計算で歩く旅人と柴犬

07

制作コスト・工数マップと最新パイプライン比較

完全最新版

お嬢と導き出した「3D制作コストと工数の序列」

伝統的な手作業から、お嬢の着眼点である「スタイライズド」「セルシェーダー」、そして「AI生成パイプライン」「プロシージャル歩行」までを網羅した完全マップです。

制作手法 モデリング工数 UV / テクスチャ アニメーション工数 総合制作速度 得られる表現価値
① ドット絵 (Pixel) 極小(平面打ち) 不要 地獄(全方向×全コマ手描き) 静止画:最速
アニメ:超低速
記号的愛嬌、2Dノスタルジー
② ボクセル (Voxel) 小(キューブ積木) 不要(色付きブロック) 極小(関節分割・変形なし) 超高速 箱庭、おもちゃの愛嬌、ブロック物理破壊
③ スタイライズド・ローポリ 小〜中(面貼り) 不要(単色+ネオン発光) 小(骨入れ連動のみ) 超高速 シャープな疾走感、安っぽさゼロの都会的アート
★ ④ AI ➡️ セルシェード・ミドルポリ (3D生成AIで一発生成) 不要(2値影+黒アウトライン) 極小(Mixamoで1秒骨入れ) 爆速(AI革命) 劇場版アニメの完全具現化、圧倒的華やかさ
⑤ 手動スタイライズド・ミドルポリ 中〜大(丁寧な曲面作成) 小〜中(キャンディグロス等) 中(滑らかなウェイト調整) 中速 マリオカート/ピクサー調、10年色褪せない最高峰
⚡ ⑥ app071式 プロシージャルメッシュ 中(建築・キャラ) 骨入れゼロ(コードIK・オイラー計算) 高速(実行時) 骨データ負荷ゼロ、ブラウザ常時60FPSの散策
🏎️ ⑦ プロシージャル・ローポリ(カートスプリント式) 外部作業ゼロ(コードによる幾何生成) 手描きゼロ(頂点カラー+Canvas動的生成) 極小(階層ピボット・物理式制御) 爆速(コード一撃) 外部ファイル0MB、44ドローコールの極限軽量、昭和レトロ港町の情緒
⑧ 一般ローポリ (PS1風) 中(手描きテクスチャ展開) 中速 あらいカクカク感、レトロホラー
⑨ リアル系ハイポリメッシュ 特大(スカルプト) 極大(5~6層PBR展開) 特大(職人技の皮膚シワ調整) 低速(数ヶ月〜年単位) 映画的臨場感、実写の完全再現
💡 アニメーションにおける「大逆転劇」

「静止画1枚」ならドット絵が一番早いですが、ゲームで動かすとなると8方向×全歩行コマの手描き地獄が発生します。
一方、3D(ボクセル・ローポリ・ミドルポリ)は一度モデルを作ればカメラを回すだけで360度全方向のアニメーションが自動で手に入るため、動かすゲーム開発では3Dのほうが圧倒的に低コストになります。

🚀 AIとシェーダーによる「工数の破壊」

かつて「ミドルポリ+アニメ調」は熟練のアニメーターが必要な高コスト領域でした。
しかしお嬢の提唱された「2D AIコンセプト ➡️ 3D生成AI ➡️ トゥーンシェーダー」を通すことで、モデリングとテクスチャの手作業がほぼ消滅し、ボクセル並みの超高速で劇場版アニメ品質が量産できる時代へ突入しました。

🏎️ お嬢の着眼点:「プロシージャル・ローポリ」という究極の軽量解法

お嬢が「初めて聞いた」と着目された「プロシージャル・ローポリ」は、一般的な3D開発(Blender等のDCCツールで手作業モデリングして.glbファイルを書き出し、テクスチャ画像を貼る方式)とは完全に異なるアプローチです。
「直方体(Box)や角柱といった最小の幾何学プリミティブを、JavaScriptコードのアルゴリズム計算によって直接その場で削り出して組み上げる」ことで、以下の3大革命を達成しています:

  • ① 通信容量とロード時間が完全ゼロ(外部ファイル0MB): 外部の3Dモデルや高解像度テクスチャのダウンロード待ちが一切発生せず、Webページを開いた瞬間にラグなしで即座にレースが始まります。
  • ② MeshBucket(頂点カラー焼き込み)によるドローコール極限圧縮: 街の建物や看板を個別に描画するのではなく、ゾーンごとに1つの巨大メッシュへ一括結合。街全体でわずか44ドローコール(通常は数百〜数千)に抑え込むことで、ブラウザ環境でも軽々と常時60FPSを叩き出します。
  • ③ 物理判定と視覚メッシュの完全一致: コースのクロソイド曲線(緩和曲線)や傾斜(バンク)と同じ数学的アルゴリズムから街や路面が生成されるため、車輪のめり込みや接地浮きが構造上0mになります。
⚠️ 【お嬢の疑問】「逆に欠点は何?全部これでいいのでは?」に対する5大弱点と適材適所の真実(クリックで展開)

「外部ファイル0MB・常時60FPSなら全部これで良いのでは?」という直感は極めて自然です。しかし、世の中のゲームが全てプロシージャルにならない背景には、以下の強烈な5大トレードオフ(代償)が存在します。

1. 目で見て直せない「暗闇の数字コーディング」:
Blenderのようにマウスで直感的に形を整えるGUIが一切なく、看板を2cm動かすだけでも3次元座標の数式を書き直してリロードする反復作業が必要。数学と3Dプログラミングの達人しか手を出せない高い制作ハードルがあります。
2. 人間・美少女・モンスター・自然物が作れない:
直方体や円柱の組み合わせで作れる無機物(ビル、石垣、レトロカート)は得意ですが、なびく髪、柔らかい皮膚、服のシワ、入り組んだ大樹など有機的な造形を数式コードだけで組むのは困難を極め、不自然になりがちです。
3. 雑多な生活感(バリエーション)を増やすと自滅する:
コード生成は「12種のパーツを規則正しく配置する」均一な街になりやすい性質があります。1棟ごとに異なる看板や小物を手作業風に作り込もうとするとコードが際限なく肥大化し、軽量性という最大の強みが失われます。
4. 柔らかい変形アニメーションができない:
骨入れ(スキニング)を行わないため、手足の回転はできても、服のたなびきや豊かな表情変化(モーフ)、衝突時に車体がリアルタイムにへこむ変形処理などは原理的に困難です。
5. 世界中の既存3Dアセットから孤立する:
Unity Asset StoreやSketchfab等に眠る何百万もの既存モデル素材を活用できず、街灯1本、小石1個に至るまで全て自前で数式化しなければなりません。
💡 結論(適材適所の黄金ルール):
プロシージャル・ローポリが最強: Webブラウザ、広告デモ、無機物・街並み・レース・SFメカなど「ロード時間ゼロと超軽量性が至上命題の作品」
一般的な3Dモデリングが最強: キャラクターが主役のRPG、アニメ調アクション、豊かな自然風景、大人数チームでの分業開発