前回の更新から丸々１年以上ブランクが空いてしまったのですが、やっと今回のLOD(Load of Detail)実装編です。

まず、これまでの１年間何やってたんだ！？というところからご説明しましょう・・。

このサイトの全体を見た方は理解していることと思いますが、自分はこのゲーム制作と平行して漫画制作もやっており、シナリオを考えるところからネーム・ペン入れ・デジタル処理・サイト更新、全て茶文湯治一人の個人制作でやっております。もちろんこの茶プロジェクトのコード開発・モデリング・テクスチャ作成作業等も全て個人制作です。

それぞれの作業労力の内訳を説明しますと、漫画を１話仕上げるのに大体２か月程度要します。大体３か月に１話更新しているので１年の３分の２はほぼ漫画を描く作業に追われている訳です。この１年間でゲーム制作の実質的な作業時間は大体４か月程度となります。その4か月の作業のうち、今回は９割以上がモデリングとテクスチャ作成の労力となりました。実際LODのコードを書き始めたのは前回のハーモニーヒルズ第１１話のサイト更新を終わらせた２週間前、つまりコードを書いていたのは大体２週間程度だった訳です。単純にプログラムを書くという作業とは別に膨大なリソースを使っていたということになります。

・・で、今後の茶プロジェクトの更新はどの程度の速度で展開できるのか？という見通しですが、今回でメインフィールドの地表部分は稚拙ながら大体作れたと思います。今後はこの地表部分に様々な建物や木々のモデルを建てていく訳ですが、作業労力はおそらくこれまで同様、数年単位でかかるだろうと思われます。悠長なもんだなー・・と思われるかも知れませんが、自分はこの茶プロジェクトを始める前に未公開の自作ＧＩＳアプリを開発しておりまして、そのアプリの開発を始めたのが２００８年。現状の大体満足できる仕上がりになるまでに１４年近くも費やしています。今回のプロジェクトも最終的にはそれくらいの期間を要してもおかしくはないな・・と見積もっています。まあ・・当初の３～５年程度という見積もりはこの１年間のモデリング作業で大変さを理解してだいぶ修正しましたが・・。

なぜそんな長期間開発を続けられるのか？という問いに対しては”全て個人制作だから”とお答えしておきます。企業や組織でゲームを作るとなるとスタッフを雇って毎月人件費が発生する訳です。開発期間が長引くとスタッフに支払う月給が膨大に膨らんで採算の見通しが立たなくなりプロジェクトは破綻します。自分の創作活動は仕事ではないので誰かから資金を投資してもらって活動している訳ではありません。つまり、タダ働きなので全く儲からないのですが、逆にどれだけ時間を費やしてもプロジェクトが資金的な問題で破綻することはない訳です。

じゃあ最悪１０年程度放置しておけばそのうちゲームは完成するんだな？信じていいんだな？という問いに対しては正直”分からない”と答えておきます。・・というのも、先にプロジェクトが資金的な問題で破綻することはない、と書きましたが半分は嘘です。実は開発コストはほぼタダなのだけれども、開発設備が老朽化するという問題に直面しています。先ほども書いたように全てタダ働きなので現状ＰＣなどの開発設備にお金を投資できるだけの余裕がないのが現実です。世の中はどんどんデジタル環境が進化していて、３Ｄゲーム等は最近はＲＴＸによるレイトレース等の技術が当たり前になっています。自分の開発環境はＧＰＵが未だにＧＴＸ９６０なのでそれだけでも３Ｄの表現能力に限界がある訳です。つまり、開発環境が古くなって最新のゲーム業界の水準に追いつけなくなり作品がぽしゃる・・ということはあり得ます。加えて・・今後の懸念は１年後にWindows10のサポート期間が切れるという問題が待っています。ご存じのようにWindows11はＰＣのスペックによってインストールすらできないという足切りが行われていて、当然自分の開発ＰＣもWindows11はインストールできません。じゃあ、１年後Win10のサポートが切れたらどうすんの？という問題がすぐ目の前に迫っているのです。この問題に対してはマイクロソフトが今後どのようなＯＳサポートをするかによって変わってきます。Win10のサポート期間が延長されるとかになればもう少しプロジェクトを続けられると思いますが、最悪ＰＣが使えなくなってこのプロジェクトを続けられなくなるということも十分あり得ると思っています。

さて・・長々と言い訳めいた長文が続きましたが、やっと今回の本題です。まあ、LODの仕組み云々については今更丁寧に説明する必要もないでしょう。GPUのメモリには制限があるので詳細なテクスチャやモデルを広範囲で読み込むとGPUリソースが足りなくなってアプリが動かなくなるのです。それに対処するために、カメラの近い位置のモデルだけ高精細なモデルとテクスチャを読み込んで表示し、遠くに見えるモデルは簡易モデルを使用することで広いフィールドを表現しようという訳です。キャラクターが動くことにより、キャラクターの近くのモデルをダイナミックにロード・デリートしています。どうやってこれを実現するか・・ということですが、これはコードのソースを読んでください・・としか言えませんね。下の方に今回のソースファイルをまとめたzipを張っておきますのでコードに興味がある人はダウンロードしてください。（今回、zipの容量が１G以上あります！）

前回のテストフィールドではフィールドを７×７のブロックに分割していましたがモデルの解像度が低かったので今回１ブロックを更に４×４のブロックに分割しました。フィールド全体では26×26=676のブロックがあります。このブロック一つ一つをUV展開してPhotoshopでテクスチャを作る訳です。ここにスマートな解決方法などありません。力技で676ブロック作るのです！

676ブロック作りましたよ。

モデルが完成したらそれぞれのブロックをdaeファイルにに書き出します。今回フォルダ内のdaeファイルを一括してmdlファイルに変換するツールを作りました（dae2mdl.exe）。ツールのソースはzipの中に置いておきます。

続いて遠くに表示するlowモデルを作ります。今回フィールドのサイズ的に１つのモデルで大丈夫そうだったのでlowモデルはフィールド全体を結合した１つのモデルのみになります。lowモデルの作成に関してはいくつか見つけたテクニックがあったので説明します。lowモデルに張り付けるテクスチャをどうやって作るかということなんですが・・。

まずフィールド全体を表示した視点を保存しておきます。これはStored ViewというBlenderの標準アドオンにありますのでインストールしておきます。ViewのサイドバーからStored Viewを呼び出してカメラ位置を保存します。

次に、Blenderにはペイントモードで現在のビューを外部アプリに書き出してくれる機能がありまして、これを利用してPhotoshopにテクスチャを書き出します。プリファレンスの外部パスにフォトショップのパスを設定し、ペイントモードのクイック編集ボタンをクリックします。この時に先ほどのStored Viewで保存したカメラ位置を呼び出してテクスチャを書き出します。

テクスチャが完成したらレイアウトモードに戻ってブロックをまとめて結合した後、頂点を距離でマージしてブロック分割境界の頂点を結合します。次にデシメートでモデル全体の頂点数を減らします。モデルが完成したらUVマッピングですが、UVエディタで先ほどのStored Viewで保存した視点に切り替えてViewから投影を選択してUV展開します。後はテクスチャと位置を合わせて完成です。

以上、モデルの作成終了です。今回テクスチャを4096pxのpng画像で作成したらjpgと比較して容量が１０倍以上に膨れ上がってたのでビビりました。最終的には2048pxのjpg画像を使うことにしました。pngをjpgに一括返還する方法は色んなソフトがあるのでご自由にお考え下さい。今回のアプリの挙動は以下の動画のようになりました。まあ・・素人の作ったテクスチャなので最新の洋ゲーのグラフィックと比べると赤子のような稚拙さではありますが・・。以上、ノルマ完了！

実行ファイル、ソースのダウンロードは以下から。

さて・・次回の課題ですが、ここからしばらくはコードの課題というよりもモデリングの進捗状況報告になると思います。とにかく労力がかかりそうなので心が折れない限り力業で進捗を進めていくことになると思います。