たけなか制作日誌

前回はポイントレンダリングでボクセルを描画しましたが、今度はMineCraftと似たような
描画方法を実装してみました（個人的にはボックスレンダリングと名付けてます）。

実装方法について少し説明すると、ボクセルの各頂点を頂点バッファに用意するとバッファ
の再生成に時間がかかるだろうなと思ったので、ボックス1つ分の頂点バッファと各ボック
スごとのインスタンスデータの頂点バッファの２つを作成し、ハードウェアインスタンシング
で描画するようにしました。インスタンスデータの頂点バッファは空間番号のインデックス
とカラー情報を持っていて、インデックス番号に合わせてボックスの位置を移動させて描画
という感じです。動画ではLMBクリックで生成、RMBクリックで削除という操作方法ですが、
色の選択はまだ実装していないのでとりあえずランダムな色で描画してみました。

それにしても、始めはByte型のインデックスをHLSLでfloatに変換して使おうとしたので
すが、シェーダ4.0じゃないと整数演算は出来ないみたいですね。なのでシェーダ2.0でも
使えるようにやむなくインデックスをfloatで作成しましたが。やっぱりGPUに転送するサイ
ズが小さい方が早いだろうな。

最近はあまりニコニコ動画で面白い動画が出てこないなぁと思っていましたが。ようやく
これは面白いと思う動画を見つけたのでちょっとメモしておきます。
落ちが読めているのに笑える。これ、いい作品に共通していえるなと、ふと思いました。
【ニコニコ動画】海外のボディソープのCMが狂ってる件

まぁコレ、ニコニコ発ではなくYou-Tubeの転載ですけどね苦笑；

【ニコニコ動画】風ノ旅ビト トロフィー取得目指しながら【1-1】HDムービー
後は以前から気になっていたゲーム「風ノ旅ビト」。IcoやMyst当たりに近い、フィールドを
楽しむタイプのゲームです。ただビジュアルがいいだけでなく、それを支えるゲーム性
の部分の非常に光ってるなと思いました。広大なフィールドにも関わらずキャラの歩いた
地面部分が凹む処理を行っていたり、キャラ全体を覆う衣服にクロスシミュレーションを
使用していたり、フィールド全体を粒子が飛び交っていたり。。取り立てて目新しい技術
ではないものの、それらの使い方に挑戦的な部分が見え隠れしていていいなと思いました。

それにしてもこの日誌のCGIと相性が悪いのか、ニコニコ動画の埋め込みタグを使用する
と日誌の埋め込みタグ移行の要素が全く表示されなくなる(IE9)。。そしてiframe版の埋め
込みもYouTubeの埋め込みと違いiframeの中身が表示されないし。仕方なくリンク版に
しましたが、原因をつきとめないとな。

今までボクセルの描画部分はマーチンキューブ法で描画していましたが、最近気になる
Point-Based Renderingに触発されてポイントレンダリングで描画してみたいなと思い、
さっそく試してみることにしましたが。。１日も立たずにサクッと出来てしまいました笑。

まぁ、ボクセル情報を頂点としてポイントで描画するだけなので簡単に出来て当然です。
で、動画を作るためにボクセルでマリオを作ってマウスでボクセルを削除するものを作ろう
かと思ったのですが、、ボクセルとマウスカーソル位置のレイの衝突判定の方がややこし
いという始末…；まぁこれも2日で出来たので良かったでした。

ちなみに、動画のマリオの肌の血色が悪いのは色情報を24,32bitではなく8bitで保持
しているためです。ボクセルは恐ろしくメモリを消費するものなので、なるべくメモリ消費
を抑えようと圧縮しているのですが。それでも100MBもメモリを使っています、恐ろしや。

それと他には剣の軌跡のエフェクトも実装してみたり。これも１日２日で出来ました。
ということで今回はサクサクと新しい実装が出来たので嬉しい反面、次はものすごく苦戦
したりするんじゃないかなぁと不安な部分もあったりします苦笑；

ようやくですが、イベントシステムを導入して会話を行えるようにしてみました。動画を見ると
分かりやすいですが、会話動作は1つの関数で固定的な表現をするより、イベントシステムで
組んだ方がより汎用的な表現ができるようになります。

ちなみに、動画内では大まかに以下のようなイベントの流れで会話を表現しています。
・会話モデルをプレイヤーモデルに向かせるイベント
・会話に必要なスプライトの描画フラグを変更するイベント
・テキスト表示するイベント
・会話に必要なスプライトの描画フラグを戻すイベント

これらのイベントのパラメータを変えたり追加することで、状況に応じて会話を変更したり、
会話ごとに会話スピードを変更したり会話の枠を外したりといった演出をしている訳です。

しかしながら、イベントシステムというのは少なからず無駄がでてくるのでそこが厄介です。
万能ってそうそう無いもんだなぁ、、なんてことを思いました。

最近はUDKとCryEngineで遊んでみたいなと思っていたので、ちょっとだけUDKとCry
Engineで遊んでみることにしました。上の画像がUDKで下の画像がCryEngineです。

ネットのチュートリアルを通して基本的なことだけざっくり押さえてみましたが。あえて少し
だけ比較してみると、UDKとCryEngineは基本的な部分は両者とも押さえていて特殊な
ことをしない限りはどちらのエンジンを使ってもいいかなという感じでしたが、CryEngine
はCrysis用に仕上げた部分が大きいので無限遠の海やボクセル,Enlightenといった目新
しい技術が目立つ感じでアセットも自然のモチーフが多いですが、UDKは近未来的なアセ
ットが非常に多くてCryEngineほど気になる技術はないかなぁといったところですが日本語
のチュートリアルや資料、フォーラムがあるのが明るい印象だなと思いました。

他にも有名どころの3DエンジンにUnityがありますが、まとめると…
・とりあえず最新技術に触れたい人ならCryEngine
・メジャーなプラットフォームでいきたいならUDK
・モバイル・ソーシャルを考えるならUnity
こんな感じで、うまい具合に住み分けされているなと感じたのでした。

あ、それとUDKについてですが。最新版のFebruary 2012だとSpeed Treeのコンパイル
ファイルが何故かUDKで読み込めないという不都合が発生しましたので一応メモしておき
ます。1つ手前のバージョンならば読み込めたので、もじ同じ症状で困っている方がいたら
バージョンを戻すことをお勧めします。

LW11の仮トライアル版(？)がダウンロードできるようだったのでちょっくらLW11をさわって
みました。モデラーに関しては、LW10同様特にこれといった大きな変更は無いです。あえて
挙げるならばPythonコードを読み込めるようになってました。Pythonコードの書き方が分か
らないので何とも言えませんが、Lightwave11のデモではレイアウト上でCOMとのチェス
対戦をやっていたので、使いこなせるとLW上でゲームとかできるようになるんでしょうね。
LW持ってる人同士でないと配布できませんが苦笑；

そしてレイアウトでの大きな変更点といえばBulletとインスタンシングの追加でしょうか。
Bulletは従来のHardFXを使えばいいし、インスタンシングは前からプラグインがあった
からいいじゃないって思っていましたが、まずインスタンシングは標準搭載ということで
VPR描画時の問題が起こる心配が無いですし、そして何よりBulletはすごく使いやすい
感じでいいなと思いました。以下、初めて触る方向けの段取りをメモします。

・Modeler ToolsタブのGeometryからBullet用にプレーンとボックスを作成します。
　モデラーからでもいいですが、少し楽してみました笑。
・Windows>Bullet DynamicsからBulletのエディタを開き、物理演算をしたいオブジェ
　クトの項目をONにして、地平面のように動かないオブジェクトはTypeをStaticに、動くオブ
　ジェクトはTypeをRigidにします。この辺の設定はBlenderと同じで分かりやすいですね。

で後はというと、、なんとこれだけです笑。再生ボタンを押せば後は勝手に物理演算で
動きます。HardFXのときは一旦Calculateで動きを計算しなければいけなかったし、何
よりCalculateの計算がそこそこ重かったですがBulletはゲームで使われているだけ
あって早いです。それに今まではラグドールをやるのにSoftFXとFX_HardlinkとCollision
を併用してといった面倒な手間が必要でしたが、Bulletを使えば簡単にラグドールが
できる…のかなと思いました(試してはいないので何ともいえないです)。

ちなみに画像はLW11のサンプルコンテンツのBulletのサンプルシーンを実行してみた
ものです。デフォルトだと何故かオブジェクトの重さが0になっていて動かないので重さ
(MassもしくはDensity)を設定することで動くようになります。それにしても、ここまで
サクッと作れてしまうと何だか色々試してみたくなるなとワクワクしてきました。

ほんと、見えないときは全く姿を現さないですが。見えるときになってからがやっかいですね、
デバイスロストさん。というのも自身のプログラムをWindows7+オンボードGPUの環境で
プレイしてみたのですが、プレイ自体は何も問題ないものの、スリープモードから復帰した
ときにデバイスロストの復旧が正常に行えないという問題に直面したわけです。
以下、メモ書き風に話がグダグダと続きます。プログラム周りに興味のある方だけどうぞ苦笑；

さて、コードを見渡しても復旧前に開放し忘れたりとかは無い…(まぁ、XPで動作出来てる
のでこれは当たり前だろうなと思ってましたが)。しょうがないのでネット上にあるマルペケ
さんの所のデバイスロストのサンプルを実行してみるとこれも復旧できず、、「んっ？」て
思いました。コードを削っていくとどうやらD3Dデバイス作成時にD3DCREATE_SOFT
WARE_VERTEXPROCESSINGを指定するとデバイスロストから復旧できるということが
分かり、オンボだとHARDWAREで指定しちゃいかんのかなとも考えましたが、指定でき
ないのにデバイスの作成が通るというのもおかしいのでもう少しだけ考えることにしました。

そこで、サンプルコードから一旦自身のプログラムに戻って修正してみると、デカール描画
の部分だけデバイスロストから復旧時に不自然な描画の仕方をする現象を見つけました。
デカール描画の部分だけDrawIndexedPrimitive()ではなくDrawIndexedPrimitiveUP()
で描画していたので、これはすぐにピンと来たわけです。
つまり、「Windows7は内部でDirectX10.1を使っているし、DirectX10ではUP系の
描画を廃止してるんだからこれはうまくエミュレートできていないってことだろうな」と思った
訳です。で試しにデバイス作成部分を元に戻してDrawIndexedPrimitiveUP()部分を
コメントアウトしてみるとデバイスロストの復旧が無事出来ました！(要追伸)

ちなみにマルペケさんのサンプルがデバイスロストから復旧出来なかったのはソース
コードの短縮のためにD3DXSPRITEやD3DXFONTを使っていたのでこれが原因みたい
でした(おそらく内部でUP系の処理をしているのかな)。デバイスをSOFTWAREで作成した
時にうまくいったのも、予想の域を超えませんがオンボではなくCPU側で頂点処理をエミュ
レートしたのがうまく働いたのかな。

この問題はオンボGPUのサポートの不手際が悪いとも言えそうですが、結論から言えば
「UP系描画はこの先どう描画されるか分からないから使うな」という警告だなと思いました。
いっそオンボは無視するというのもアリですが。最近のオンボは結構早いですからね。
、、それにしても結論までに結構時間かかったなぁ；

追伸：
UP系命令が原因と書きましたが、デカール描画だけはボリュームテクスチャで描画して
いたので、こっちが原因かもしれないなと思いDrawIndexedPrimitiveUP()を消さずに
ボリュームテクスチャをOFFにすると正常に描画されました。で試しにボリュームテクスチャ
のプールをD3DPOOL_MANAGEDだったのをD3DPOOL_DEFAULTにして自前復旧に
変更することでデバイスロストに対処できました。…ということで、間違った情報を流して
しまいました。そういいつつ、直った理由がいまいちよく分からない上にUP系との併用に
よるバグかもしれないし、デカールと一部分だけ固定パイプラインで描画していることによる
バグかもしれない。原因は何だか特定しきれないですが、、直ったからいいんです苦笑。

以前ボーンの向きコンストレイントをプログラムで実装しましたが、今回はそれの応用で
動きに合わせて揺れるボーンというのを実装してみました。

実装方法としては以前の機能の他にバネ・ダンパモデルというのを使っているので、少し
ばかり紹介したいと思います。バネ・ダンパモデルはバネ係数k・ダンパ係数dを利用して
現在の併進運動エネルギーFを求めるというもので、以下のようになります。
F(t) = F(t-1) * d + V * k;
V = PrevPos - Pos;
いやぁ、とってもシンプルです。あえてこれ以上説明するとすると、高１物理で教わるバネ
の弾性力の公式F=kxの式に追加エネルギーとなるF*dがくっついただけです(というより
ここではV*k部分が追加エネルギーですが)。Vは前フレーム位置に戻ろうとする相対速度
ベクトルなので係数kを大きくするほど前フレーム方向に戻ろうと振れる力は大きくなり、
そしてdはF(t-1)を徐々の弱める働きをするので動いていない場合は揺れがなくなる、
というわけです。

ちなみに自分で独自に調べたりしたので、「実はkとdは逆なんじゃないかな…」とか、まだ
良く分かっていない処がありますが、まぁkもeもつまるところスケーリング係数という点で
同じなので、学術的な定義があってるかどうかは特に気にしていません笑。

さて、これでボーンを揺らすことができるようになりましたが、、ボーンの角度制限をちゃんと
つけないと駄目みたいです。動画では入れていませんが、試しに攻撃モーションをさせて
みると髪が頭を思いっきり貫通してしまいました；

実はボーンの角度制限読み込みだけでなく、マルチUVやLWSを利用したオブジェクト
単位の背景読み込み等など。LW回りでやりたいことはまだまだあったりします。難しい
ので後回しにしてますが苦笑；

自作のプログラムではレジストリを使っていないものとばかり思っていましたが。。
DirectInputをDirectInput8Create()で初期化するとレジストリに勝手に登録する
みたいですね。詳しくは以下のサイトをどうぞ。
http://dodeka.net/~j2/wp/?p=163

レジストリエディタで自分のプログラムが登録されてないか確認してみると、なんと山のように
登録されていました；うわぁぁ何てこったい。

しかも今までプレイしたことのあるDirectX製ゲームも他にもずらりと登録されてるし。
…何だかなあと思ってしまいました。とりあえず、同サイトにCoCreateInstanceを
使うことでレジストリの登録を防ぐ方法が書いてあったので一安心です。

同じようにDirectInputを使っている方は一度チェックしてみることをお勧めします苦笑。

前回のモデルの流れでちょっと試行錯誤してみました。HyperVoxelでうっすらした
感じの雲を作ってみましたが…どうだろう、それなりな質感が出せたかな。

それと最近プログラムの方は目立たないような小さな機能ばかり進めています。
CPUの種類を調査できるようにしたり、レジストリについてアクセスできるようになったり、、
直接ゲームとは関係ない部分ばかりなのであった苦笑；

そういえば、0除算バグを見つけて気が付いたことですが。VC内でプログラムを起動する
と、初期化していない変数を勝手に0で初期化するみたいですね。で、VC外でプログラム
を起動すると勝手に0で初期化したりはしないので、VC内とVC外で動作が異なる現象が
起こる。これ、つい最近はじめて気がつきました。
で、0除算で発生したNANやINFの値を持つ行列をGPUに渡して描画した場合、これまた
GPUによって動作が異なる。自分で確認した限りでは全く描画されないか画面全体に大きく
ポリゴンが爆発するかの2パターンでした。

こういう現象、厳密にこう対処するっていうGPUの規格とかはないのかな。何にせよ、
こういったハードによる動作の違いは中々興味深いところだなと思いました。