マジックアクション 計画中4 描画方法の選択

　どんな描画手段があるのかを検討しています。

　左図はJavaアプレット上でソフトウェアレンダリングを行った様子です。
　ソフトウェアレンダリングとは、CPUの力で画像を1ドットずつ打っていく手法です。例えば360×360ドットのスクリーンのために129600個の配列を確保し、1つのポリゴンを描くのにどの要素を値変更すれば良いかを算出し、プチプチ埋めていきます。

　Javaアプレットからではハードウェアアクセラレータの力を借りられない上、MMXのような特殊なビット操作命令が使われることも期待できないため、実行するマシンには大きな負荷がかかります。

　処理が重いというデメリットはありますが3Dデータが扱えるのは大きな魅力ですので、もうしばらくこの手法についてテストしていきたいと思います。大体以下のようなレンダリングにしようと考えています。

　ちなみにトイパロウィングス も一応ソフトウェアレンダリングを使用しているのですが、ロジックが単純であるため負荷は抑えられています。

■光源は適用しない
　容量の軽い3Dデータは大きめのポリゴン(平面)を組み合わせて作りますので、光を照らすとガタガタに見えてしまいます。
　なめらかにするためにグローシェーディングを行うと、ポリゴン内部を同色で埋め尽くすわけにはいかなくなり、1ドット単位の演算量が増えます。
　トゥーンシェーディングを行う場合ベタ塗りでもよくなりますが、ポリゴン数の少ないモデルでは明部と暗部の境界があまり綺麗になりません。境界付近のポリゴンは分割出力する必要もあり、頂点単位の演算量が増えます。
　またどちらの手法にしても、キャラクターが向きを変えたりポーズをとったりしたとき、各面と頂点の法線ベクトル(光源に対する向き)を再計算せねばならず、やはり頂点単位の演算量が増えます。


■テクスチャは使用する
　光源が「だいたい上の方から光が当たっている」としておき、影になりやすい部分を考えてテクスチャに焼きこんでいく手法を使います。
　もっとも、私は今までテクスチャ付きのポリゴンモデルを作成したことはありませんので、一筋縄では行かないでしょう。

■境界線表示を使用する
　ベタ塗りのポリゴンは形状は把握しにくくなりますが、ポリゴンエッジに境界線を引くことである程度改善します。
　線を引くべきエッジはモデルの向きによって変わりますので、リアルタイムに再計算する必要があります。
　今回のテストでは、「接続するポリゴン2枚の裏と表が視点から見て逆になっている」とき、その間に線を引いています。Zバッファを再走査する方式よりドット単位の演算量が少なくてすみます。

■背景を3Dにするかは未定
　アクションゲームは周囲の状況を広くプレイヤーが認識していなければならないため、表示するキャラクタは小さめになり、描画面積の大部分を背景が占めることになります。
　背景描画を2Dで行ってしまえば大幅にマシンパワー消費を抑えることができますが……。せっかくなので3Dにしたい気も……。

---

　一般にゲームにポリゴンを使用される理由の1つに、画面の解像度が上がったため大量のセル画像を手書きで用意するのが困難になってきたという経過があります。しかし、今回のゲームはマシン負荷の関係上、またブラウザ上で動作させるということもあり、描画領域はあまり大きくありません。
　この場合、レンダリングエンジンが自動で出力する映像は手書きで1ドットずつ人為的に描き込んだドットバイドットの画像にくらべて大きく見劣りすることがあります。


　今のままでは3Dにしたデメリットばかりが大きく出てしまいますので、まともな素材製作・3Dならではのゲーム性の両面で改善していきたいと思います。