パフォーマンスの最適化 (Direct3D 9)

ただ、こういった情報は計算量が多い 3D のようなゲームを想定してのものかと思われます。１フレーム（ 1/30 くらい）中に描画するポリゴン数が 30 で 256×256 程度のテクスチャ数が５枚くらいだったら、必要になったタイミングでステートやテクスチャを切り替えて差し支えないかと思います（どうやら今のゲームがそれくらいになりそうで…）。

これを確かめるためにはページ中にある「アプリケーションのパフォーマンスを絶えずテストする」が重要だと考えているのですが、解説の途中に結論みたいなお話が出てきてちょっと面白く感じました。

一応、制作中のクラス設計に反映しております。

ちょっと、初心者向けの記事には向かないかもしれないのですが、以前、モンスターハンターのキャラクターが起伏のある地面を歩いている映像を同僚と見ていたときに、「こういうの作るの結構大変なんだよね」みたいな話をしたら「そうなの？」という反応をいただきました。

普段、 WEB システムしか作らないので、ポリゴンがめりこむというのを知らなかったとのことですが、ポリゴンのめりこみについて説明すると、「なるほど、進入先が上り坂だったらキャラクターの座標を上に移動させないといけないんだ」と言っていました。

間違ってないです、むしろ正解なのですが、自分の感覚からするとちょっと実装案にたどり着きづらい見方のような気がしました。

というのも…

if (/* 進入先が上り坂 */) {
  // キャラクターを上に移動
}

こうやってコードを書いたときのコメントに入る内容が思いつけるかどうかなのですが、自分の場合はうまい方法が思いつきませんでした。 if 文による分岐ではなく、常にキャラクターの縦軸と地面との交点を求めて、キャラクターがその上を歩いている風に見えるように、座標を上下するのがいいのかなと思います。実際にはそこまで単純にはいかないかと思いますが、コードは想像しやすいです。

このあたりの難しさの本質を見つけたいところなのですが、なかなかうまくいきません。躓くところのような気がするだけになんとかしたいです。

どんなにリアルになってもゲームが絵を描画して動いているように見せています。「壁にぶつかったのでこれ以上進めない」などは計算によってシミュレーションするわけですが、これを移動範囲を決めるための見えないポリゴンで計算することがあります。つまり、「このポリゴンの上ならキャラクターが移動できる。ポリゴン外には出られない」という作りにするのです。

疑問に思っているのは、「”カメラがそこに移動できるか？”を判定する際にも同じデータを使わなければならないのか？」という点です。建物内など、壁が多いところでは同じで良いかもしれません。…が、屋外などですと「そこはカメラが入っても良いだろう？」というところも避けたりして、結果、カメラが急にキャラクターに接近して見づらくなることが良くあります（インフィニットアンディスカバリーを例にすると、モンタナ村のルカとロカの家付近の丘など。あそこはカメラが空中を飛んでも問題ないように思います）。

もはやこれは実際に作ってみないと問題を共有できないと思いますので、なんとか一回やってみたいです。

まったくの想像で思い当たるのは、カメラの移動判定をする際、地面との距離を考慮しているような仕様になっている可能性です。カメラを実際にカメラマンが持って撮影しているイメージとでも申しましょうか。たとえば、坂を上ったりするときは、カメラはキャラクターの後ろをついていきますので、自動的に見上げるようなアングルになります（下る場合は見下ろすアングル）。これをやるためには地面との距離を見なければなりません。地面との距離を見なければならないということは、キャラクターの移動範囲と同じデータを参照しなければなりません。「同じじゃなくても良いだろう？」と思われるかもしれませんが、カメラが踏み外しても良い足場とだめな足場を効率よく区別する方法が思いつきませんでした。カメラの動きがカメラマンによる撮影のイメージで計算し、かつ、空も飛べるようにするとなると、踏み外して良い足場というのが必要です（「どうせ見えないポリゴンなんだから、キャラクターにとっては空中でも、カメラにとってはそこが地面であるかのようにすれば良いのでは？」というのは問題があります。そうすると空中であるにもかかわらず、カメラが下に移動できなくなります）。

もうひとつ考えられるのが、「移動範囲のポリゴンを作ってもらう人にカメラの移動範囲を考慮してもらうのは酷かもしれない」という可能性です。…が、これはちょっと他人を馬鹿にしすぎのような気もします。

「楽しさを発信するのって基本にしてかなり重要ですよ」と教えられたので、がんばってみましたが、あんまり楽しくなくなってきました。難しい…

たとえばポリゴン内判定などは、本当ならポリゴンを三角形に分割して、外積で判定する必要があるような気がするのですが、 MySQL なら関数が用意されているとのことです。

しかしながら、 MySQL を使うようなゲームを作る予定がありません。オンラインゲームなら利用用途はあるでしょうか。

3D の難しいところは 2D よりも基礎知識が必要なことでしょうか。更に言うと、解説サイトや解説本などは、その「基礎知識が必要なこと」を「知っている」ことが前提で書かれているという点です。

「基礎知識があること」ではなく、「基礎知識の必要性を知っている」という意味です。難しいですね。ですから、「基礎知識」は「今現在持っていない」状態でも良いのです。ただ、「基礎知識が必要」ということを「認識」していればいいのです。ですが、本当の入門者はそれすらわからない状態から始めないといけないのです。これは入門者が途中で挫折してしまっても無理ありません。ほとんど勝ち目のない試合をしています。

メルマガでは 2D であれば、「点を描画する」というところから開始しています。それは、「あらゆるゲーム画面は点の集まりでできている」からであり、点の描き方さえわかってしまえば、理論上、どんなゲーム画面でも作れるからです。

でも、実は 3D も同じなのです。 3D の最小単位はポリゴンですが、１ポリゴンの描き方さえわかってしまえば、理論上、どんなゲーム画面でも作れるはずです。ただ、解説書などでは１ポリゴンの描き方を説明するのにとんでもない紙面を割きます。これは仕方ないことで、それだけ解説しないと「実用に耐えない」という理由があります。しかしながら、「俺にもがんばればできそうだ」と感じていただくために、１ポリゴンだけ手っ取り早く表示する方法があれば、それをお伝えした方が絶対良いと思います。ポリゴンは三角形ですが、その３頂点の座標さえあれば描けるはずなのです（事実、 Win32API にもポリゴンを描画する関数がありますが、その関数で必要なのは頂点の座標だけです）。

これは DirectX であれば簡単にできます。 DirectX でポリゴンを頂点座標だけで描くためには、頂点フォーマットを「座標変換しない」モードで作ります。とりあえず、これにて解説書の内容を無視してポリゴンを簡単に描くことができますので、まずはそれでゲームを作ってみることをおすすめします。もし、作っていく中で暗礁に乗り上げるようなことがありましたら、それを解決する方法が、「 3D の基礎知識」の可能性が高いです。

若い頃は「急がば回れ」という言葉に嫌悪感を持っていましたが、年を取ってその意味がわかるようになりました。もう、若くありません。

パイプラインとは、ジオメトリ情報（ポリゴン）を座標変換し、材質やライト（光源）やテクスチャといった要素を反映して画面にラスタライズ（表示）する一連の機能のことです。ジオメトリがベルトコンベアーに乗せられて入り口から入り、さまざまな加工を経て出口から出てくる様からパイプラインと呼ばれます。

ちなみに CPU 周辺にもパイプラインという用語があるので注意です。 DirectX の場合はレンダリングパイプラインと呼んで区別した方が間違いが少なくなります。

頂点バッファを使わないでポリゴンを表示するためには IDirect3DDevice9::DrawPrimitiveUP() メソッドを使います。

引数は頂点ポイントの描画方法と頂点数、頂点情報を格納した配列へのポインタ、１頂点あたりのバイト数などを渡します。