16.狐火と夏休み その7 田んぼの実装とエンジン改良
昨年までの進捗のご報告です。
本来昨年の12月に進捗をアップする予定だったのですが、年末突然GPUが故障したので修理に出して戻ってくるまで丸々２か月間作業が中断してしまいました。２か月遅れですが、とりあえずゲ制作の進捗報告です。
とりあえず前回のスプラットマップの実装から半年くらいですか・・この半年でフィールドの周囲を囲む森の配置を大まかですが終わらせて、田んぼに稲を敷き詰めるところまでできました。昨年の最初の頃は１年でフィールド完成させる！くらいの勢いだった気がしますが思う通りに順調にスケジュールは進みませんねえ・・。この半年でどの部分に時間がかかったのか報告しておきます。
本来昨年の12月に進捗をアップする予定だったのですが、年末突然GPUが故障したので修理に出して戻ってくるまで丸々２か月間作業が中断してしまいました。２か月遅れですが、とりあえずゲ制作の進捗報告です。
とりあえず前回のスプラットマップの実装から半年くらいですか・・この半年でフィールドの周囲を囲む森の配置を大まかですが終わらせて、田んぼに稲を敷き詰めるところまでできました。昨年の最初の頃は１年でフィールド完成させる！くらいの勢いだった気がしますが思う通りに順調にスケジュールは進みませんねえ・・。この半年でどの部分に時間がかかったのか報告しておきます。
まず前回までのプロジェクトの仕様から大きな変化として、モデルのpng、jpg画像を全てBC7(.dds)ファイルに置き換えることにしました。BC7フォーマットのファイルにすると元のpng、jpg画像よりディスク上のファイル容量は少し増えてしまうみたいですがメリットはいくつかあります。まずGPUの読み込み速度が上がるということと、GPUのVRAM消費容量を４分の１程度まで圧縮することができるのです。今後描画モデル数が増えてくるとGPUのVRAM容量を気にする必要があるので今のうちに仕様を変えてしまおうと決めました。
新しいバージョンのModelViewerではdaeファイルをmdlフォーマットのモデルに変換するとき、テクスチャのパスをこれまで.png、.jpg画像で書き出していた部分の拡張子が.ddsに置き換わって出力されます。そのため変換したmdlファイルを開く時に元の画像をBC7(.dds)ファイルに変換しておく必要があります。ツールの中にimg2dds.exeというツールを加えましたのでこのアプリに画像をドラッグすれば画像と同じフォルダに.ddsに変換したファイルが作成されますのでそれをmdlファイルと同じフォルダに置いてください。
新しいバージョンのModelViewerではdaeファイルをmdlフォーマットのモデルに変換するとき、テクスチャのパスをこれまで.png、.jpg画像で書き出していた部分の拡張子が.ddsに置き換わって出力されます。そのため変換したmdlファイルを開く時に元の画像をBC7(.dds)ファイルに変換しておく必要があります。ツールの中にimg2dds.exeというツールを加えましたのでこのアプリに画像をドラッグすれば画像と同じフォルダに.ddsに変換したファイルが作成されますのでそれをmdlファイルと同じフォルダに置いてください。
次に森や田んぼを作るために木や茂み、稲のモデリング作業をやっていましたがBlenderでモデルを作るのに全部で２か月くらいかかっているのかなあ・・。
そして年末にコードの大きな改良が必要となるボトルネックが発覚したのでこの対応に１か月くらいかかってしまいました。昨年１０月に新しいPCを組み直してGPUがRTX3060に変わったのですが、フィールドに大量の木や田んぼを敷き詰めた結果、GPUの使用率自体は４０％程度なのにフレームレートが３０fps程度しか出なくてGPUのパフォーマンスが十分に出ないという事態が発生しました。原因はエンジンの設計にあって、これまでの設計では１フレーム描く時に、
①CPUでモデルのトランスフォームやカメラ座標などを計算→②GPUで描画処理→③GPUの処理が終わるまで待つ
という処理の流れになっていました。この設計ではGPUが処理を終えても次のフレームのCPUの計算が終わらないとGPUが作業をできずアイドル状態になってしまいます。このためにGPUの負荷はそれほど高くないのにフレームレートが出ないという結果になっていました。
この問題を解決するため、モデルやカメラのパラメータやリソースを複数フレーム分用意し、GPUがi番目の描画処理をしている間にCPUでi+1番目のフレームの計算をさせることでCPUとGPUを並列に処理させる仕様に変更しました。この処理が結構やっかいで、CPUがGPU処理中のリソースにアクセスして変更を加えたりすると即座にGPUがストールするという実にデリケートなコード修正が必要となりました。まあ、結果としてGPUのパフォーマンスをフルに出せるようになったので一応６０fpsは達成することはできました。デスクトップでは現状動作は安定しているようですが、ノートPCで動かしてみたら時折アプリが落ちるみたいなのでコードの不備が原因なのか、他の外部アプリのインジェクションが関係しているのかしばらく様子を見て判断します。
そして年末にコードの大きな改良が必要となるボトルネックが発覚したのでこの対応に１か月くらいかかってしまいました。昨年１０月に新しいPCを組み直してGPUがRTX3060に変わったのですが、フィールドに大量の木や田んぼを敷き詰めた結果、GPUの使用率自体は４０％程度なのにフレームレートが３０fps程度しか出なくてGPUのパフォーマンスが十分に出ないという事態が発生しました。原因はエンジンの設計にあって、これまでの設計では１フレーム描く時に、
①CPUでモデルのトランスフォームやカメラ座標などを計算→②GPUで描画処理→③GPUの処理が終わるまで待つ
という処理の流れになっていました。この設計ではGPUが処理を終えても次のフレームのCPUの計算が終わらないとGPUが作業をできずアイドル状態になってしまいます。このためにGPUの負荷はそれほど高くないのにフレームレートが出ないという結果になっていました。
この問題を解決するため、モデルやカメラのパラメータやリソースを複数フレーム分用意し、GPUがi番目の描画処理をしている間にCPUでi+1番目のフレームの計算をさせることでCPUとGPUを並列に処理させる仕様に変更しました。この処理が結構やっかいで、CPUがGPU処理中のリソースにアクセスして変更を加えたりすると即座にGPUがストールするという実にデリケートなコード修正が必要となりました。まあ、結果としてGPUのパフォーマンスをフルに出せるようになったので一応６０fpsは達成することはできました。デスクトップでは現状動作は安定しているようですが、ノートPCで動かしてみたら時折アプリが落ちるみたいなのでコードの不備が原因なのか、他の外部アプリのインジェクションが関係しているのかしばらく様子を見て判断します。
まあ、これで今後はやっとモデル制作と配置に専念できるかなあ・・と思うのですが、実は今年からゲ制作に加えて漫画執筆のノルマを新たに加えてしまいました。年内に２００ページくらい漫画のペン画を仕上げるつもりなのでゲ制作のモデル作成に費やせる時間的リソースは大幅に削減される予定です。元からゲ制作は空いている時間に進める長期プロジェクトを想定しているので漫画の原稿の方を優先することになりますねえ・・。年末までにどこまでフィールドの進捗が進むのやら・・。
今回までの進捗分は以下からダウンロードできます。メインのゲームの進捗だけ確認したい人はkitunebi1.0.10(exe)だけダウンロードすれば十分です。アプリが起動しないとかバグがあるとか、何か不具合があればご報告頂ければ助かるのですが、どうも自分のXアカウントもサイトのメールも外部の何らかの意図によりフィルタリングされていて自分までメッセージが届いてきていないようです。メッセージが届けばありがたいんですけどね・・。
今回までの進捗分は以下からダウンロードできます。メインのゲームの進捗だけ確認したい人はkitunebi1.0.10(exe)だけダウンロードすれば十分です。アプリが起動しないとかバグがあるとか、何か不具合があればご報告頂ければ助かるのですが、どうも自分のXアカウントもサイトのメールも外部の何らかの意図によりフィルタリングされていて自分までメッセージが届いてきていないようです。メッセージが届けばありがたいんですけどね・・。
| kitunebi1.0.10[exe] | 2026/03/08 | download |
| kitunebi1.0.10[Source] | 2026/03/08 | download |
| kitunebi1.0.10_Tool_Source[exe, Source] | 2026/03/08 | download |
今年はゲ制作を進めたいのも山々なのですが、とりあえず漫画制作を優先して作業していきます。ペン画が仕上がったら一度出版社に話を聞いてみたいのですが、特別な展開にならなければ年末からデジタル処理をしてサイトにアップしていく予定です。漫画の方もよければ見てくださいね。
© 2018-2026 Chafumi Touji