もんしょの巣穴blog

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
  1. --/--/--(--) --:--:--|
  2. スポンサー広告

CEDEC2008 3日目

遅れましたが3日目。まずは1コマ目から。
え、基調講演?
ネット上で記事を見かけた人いますか?つまりそういうことなんです。

1コマ目はEpicのTim Sweeneyによる未来の技術についてです。これからの10年とか言ってましたが、2012年から2020年くらいの予想の話です。
Timは初代Unrealエンジンの製作者です。彼はUE3は2012年まで使用され、それからはUE4になると予測しているようです。
GoW2の開発人員としては、PGが15人。VAが46人。2年1200万ドルをかけており、C++コードは25万行とのこと。ただ、エンジン開発者も人員として数えているかどうかは不明です(多分数えていない)。
ハードウェアのこれからの10年ではCPUとGPUが統合されると考えています。IntelのLarrabeeとNVIDIAのGeforce8のアーキテクチャは似通ってきており、これはいずれ統一されるだろうとのこと。
コアの数はどんどんと増えていき、扱えるベクトルの幅も増えていく。多少のグラフィック機能は固定で残るものの、ほとんどはプログラマが書くようになるだろう。
現在でも7コアのプログラムを書くのに必死になっているが、10年後には50コアのプログラムを書く必要が出てくるかもしれない。マルチコアプログラムを簡単にしなければ貴重なプログラマの時間は減っていくばかりだ。
UE3ではタスクの並列化にマルチスレッドを使用している。しかし、同期は手動で行っており、正確性をコンパイル時に検証することは不可能です。コードは数十人で書く。
とにかく大量のコアに対応しなければならない。そのためには同期をとる手法を考える必要があります。
手動同期はオブジェクトを使う前に必ずロックすることから始めます。ただし、デッドロックやデータ競合の問題があり、デバッグが大変です。
メッセージパッシングの場合、オブジェクトは自分自身しか更新できず、他のオブジェクトへは変更メッセージを送ることしか出来ません。
各オブジェクトはかなり多くの(千以上)のメッセージプロトコルを書く必要がありますし、ある程度の手動同期を必要とします。
ソフトウェアトランザクショナルメモリはUNDOのような手法です。
スレッドはトランザクションブロックで動作し、処理としてはローカルメモリのみ変更可能です。
同じデータを変更しようとするような複数スレッドからのアクセスがあった場合はロールバックし、そうでなければグローバルを更新します。
コードに副作用があってはいけない、速度の30%が犠牲になる、C++ランタイムのサポートが必要になるなどの問題点があります。
で、このマルチスレッドプログラムを簡単にするには純関数型言語を使うのがいいとのこと。あんまり聞いたことのないものですが、どうやら定数と関数で処理する言語のようです。つまり変数がなく、代入もない。
たとえば a=b+c という代入文はよく見かけると思いますが、b, c, +という関数の3つがわかっているならわざわざaに代入する必要もないだろうということ、らしい。
純関数型言語の関数は副作用がなく、任意の順序で実行することが可能です。それゆえ、マルチスレッドに向いている、というわけ…らしい。
また、変数や処理のベクトル化も必要になります。C++コンパイラはスカラコードを生成しますが、GPUシェーダコンパイラはベクタコードを生成します。
ループや関数呼び出しをベクトル化できれば性能向上の可能性が広がります。
話は変わってグラフィックですが、現在のシェーダプログラムにはいくつかの制限があります。
ランダムなメモリ書き込みは出来ませんし、データのトラバースも出来ません。
結果としてすべてのゲームが同じようなグラフィックに見え、小手先の工夫で違いを出さなければいけない状態です。
次は100%ソフトウェアレンダリングとなる、と予想されていました。CPUとGPUの統合もそれを後押しするでしょう。
つまり、ハード側に設定されているレンダリングパスとは別のパスを作り出すことが可能になる、ということなのかと思います。DirectXなどがいきなりなくなるってわけではないでしょうけど。
将来のグラフィック技術としてはいくつかの候補があります。
レイトレーシングは昔からいつかは来るんじゃないかと言われていた代物ですが、次には来る可能性もあります。メニィコアとの相性はいいものの、全体的な効率は決してよくないものです。
ピクサーが使っているREYESレンダリングモデルも候補の1つで、モデルを微小三角形で形成する手法です。つまり、三角形1つが1ピクセルに対応するように分割するというわけ。
この利点としては、ディスプレースメントが簡単に実現できる、テクスチャが不要、400万ポリゴンのモデルが法線マップを使用せずに描画できるようにもなります。
ただし、高度なLODが必要となります。
ボリュームレンダリングも候補の1つ。ボクセルレンダリングを直接行うことが出来るようになる…かも。
あとはソフトウェアタイルレンダリングとかいくつかの複合レンダリングとか指摘されています。
しかし、これによりゲームごとに違う映像が作られるのかどうかというと…そんなこともないんじゃないかと私は思うんですけどね。
では、これらの技術をどのように勉強していけばいいのでしょうか?
とにかく生産性を上げればいいのですが、そんなにうまくいかないのも現実です。
ハードの性能が20倍になって開発難度がそれくらいに上がったとしても、予算はせいぜい2倍がいいところです。それすら無理かもしれません。
生産性を上げるには性能を犠牲にする、ハイレベルなプログラミング(C++はすでにローレベルだと)、簡単に使えるハード、凄いツールが重要になります。
とにかく、現在のハードウェアは難しすぎる。あんたが言うなとツッコミたい気持ちもありましたが、コストを低下させるには、ということなのでしょう。それでも困りものですが。
今までの環境と比べると、マルチスレッドのコストが2倍、PS3のコストが5倍、GPGPUとなると10倍かそれ以上となるだろうとのこと。2倍以上は大半の会社にとっては大きすぎるリスクです。
UE3は3年で開発しましたが、次は5年はかかるだろうと見積もっていました。今からやっても2013年出荷。今からやらなければ遅いのです。
とにかく、今後も大きな変革があるとのこと。今の仕事を考え直さなければ10年は生き残れない。…きついな、おい。
質問はいくつか興味深いものを書いておきます。
まず、開発環境とかは誰に期待すればいいのかという質問ですが、ハードウェアベンダー、ツールベンダーはEpicも含めて色々あるのでその辺に期待するのがいいのでは、とのこと。期待できるのかな?
フレームレートや解像度は2012年の段階では変わらないんじゃないかとのこと。
メインメモリはPS3みたいな歪な構成はこれからは無理。すべてのコアからすべてのメモリが同時にアクセスできるような状態じゃなきゃダメ。
C++はすでに限界が近い。マルチスレッドには向いていない。でも、言語が成熟するのに5年くらいはかかる。そして、現在C++に取って代わりそうな有力な言語もない。まだまだC++でやらなきゃダメだろうな、とのこと。

2コマ目は『ソニックワールドアドベンチャー』のグローバルイルミネーション(GI)の話です。
海外では『Sonic Unleashed』という名前になっていますので、そちらで覚えている人も多いかもしれません。まだ発売してませんが、年末か年始くらいには発売予定かな?
このゲームではGIが静的オブジェクトと動的オブジェクトに適用されています。
静的オブジェクトに対してはライトマップに近いやり方で実装されています。つまり、GIテクスチャを用意してそれと合成するというだけです。GIテクスチャは事前計算を行います。
当初、サンプルとして作成した500m*500mのマップでは100MBのテクスチャが必要となり、計算に2日かかっていたそうです。
ソニックは秒速100mで走るらしいので、実際のマップは1ステージ15kmくらい。テクスチャは1GB程度になるものも出てきそうだし、計算時間にいたっては数ヶ月かかる計算。
当然現実的ではないため、分散コンピューティングを利用して全員の作業用マシンを少しずつ使って計算するようにしたそうです。これにより、時間は数10?100分の1程度にまで低減したそうです。
とはいえテクスチャサイズはどうしようもないので、これはストリーミングで。BGMのストリーミングは出来ないので、こっちをオンメモリにしたそうです。
この際の問題としては、360で実際のテクスチャ容量より大きなサイズのメモリが取られている問題が1つ。これは360の仕様で、1枚のテクスチャはどんなに小さなサイズでも12kB使われるためでした。小さなテクスチャをやめて大き目のテクスチャに固めてもらうことにして回避。
ファイル数もそのサイズも大きすぎてサブバージョンでの管理が無理になった問題は社内ツールで対処。
PCと360とPS3の数を増やしたらブレーカーが落ちたらしい。会社でブレーカーが落ちるなんてうちではないですね。
一番のリスクはデータサイズが大きいため、組み込みに時間がかかること。この部分に関しては改善できていないようです。
かなりしんどい作業ながら、確実にいい絵になるためVAの士気が高いのが利点だそうです。
動的オブジェクトへのGIは簡単なもので、ゲームフィールド上にグリッドを置いて、その交差点に色をつける方法を取っています。
この時、色は6方向を持っておき、キャラクタの位置と交差点の位置の関係から方向を見るようにしているようです。6方向ということは、TF2のシェーダでもやっていたキューブライティングっぽいやり方だと思います。
当然、より詳細な方向を持つためにSHとかを使うことも出来ますが、そこまでやらなくても十分な品質は出せるようです。とはいえ、出来ればやりたいって感じではありました。
GIの計算はレイを数千?数万本飛ばして計算しているようです。衝突回数は1回だけっぽいです。ここはレンダリングをするという方法もありますが(放射照度環境マップを参照)、反射を考慮する場合はレイトレースした方がいいと思います。
360とPS3の特徴と問題点についても少々語られています。
360はとにかくDVD容量が小さいこととHDD標準じゃないのが痛いとのこと。マルチスレッドもうまく活用できていない様子。ただし、メモリが自由に使えるのは良い点であるようです。
PS3は逆にHDD標準搭載、BDの大容量がありがたいようです。また、PlayStation Edgeを1.5人月で組み込んだそうです。かなり速くなるのでお勧めらしい。SPUはまだまだうまく使えるようになるんじゃないかと考えているようです。
今後の課題としては背景も動的なGIを導入したいのと、方向を持たせたいのがあるようです。
ちなみに、サンプルを360開発機(だと思う)で動かしていたのですが、1度フリーズしてました。もうすぐマスターらしいのですが大丈夫でしょうか?

3コマ目は射影を用いた関節角度制限方法についてです。後半はトポロジーに関する雑学ですが、理解できなかったので割愛。
この技術は『鉄拳6』のゆれもの(マフラーとか鎖などのアクセサリー)に使われているそうです。これらは物理シミュレーションで動くものですが、普通のキャラクタのIKにも十分使用可能です。
通常、関節の角度制限は親ボーンのローカル軸に対しての角度で制限します。この方法はわかりやすいのですが、回転順番によっては角度の制限範囲が限定されてしまいます。
例えばヒジは90°以上曲げられますが、回転順番次第では曲げられなくなる可能性があります。
まず、子ボーンの根元(親ボーンの先端)に球があると考えてみてください。子ボーンが動くとこの球と子ボーンの交差点が動くわけですが、角度を制限する場合、この球に矩形等を貼り付けてその範囲内を点が移動するように見えるはずです。
で、90°以上曲がらないということはこの範囲が球の前方にしか存在しないということです。
この範囲を特異点を1つとした範囲に広げることが可能です。それが平面への射影になります。
射影平面λを s,t で表した場合、s=-z/(x+1), t=y/(x+1) となります。これだと特異点は x=-1 の時となり、これは親ボーンと子ボーンが重なった時の状態となります。
角度の範囲を球面上の点の範囲に変更し、これを平面上の範囲に変換できれば問題ないというわけです。
あと、色々と説明していただいたのですが、図や実例が多く使われたためにメモをきちんと取れていません。
スライド資料を見ればたいていの人はわかると思うので、そっちを参照してもらった方が早いんじゃないかと思ったり思わなかったり。
あと、質問で、クオータニオンの係数を制限する方法について聞かれていました。この方法だと球の裏面がおかしな形状になりやすいみたいです。
クオータニオンの係数を制限する方法は私もよくわからないので、今度調べてみようと思います。

4コマ目。最後はフロムソフトウェアの『NINJA BLADE』チームによるFlashを使ったゲームUIのお話。
ここで言うゲームUIはHUDやメニューの事を指します。
良いUIを作るには、とにかくトライ&エラーが大事。そのためには作りやすい環境が重要です。っていうか、それはUIに限った話ではないんですがね。
フロムでは元々自社開発ツールを使っていたようです。しかしこれだとレイアウトやアニメーションは作れても、アニメーションの遷移(ボタンを押された時にどうなるかとか)ができない、全体の動きを確認できない、フェードイン・アウトが出来ない、新規データはPGの手を介する必要があるなどの問題がありました。
そこでこのプロジェクトでは、途中からScaleformGFxというツールを使用したそうです。
このツールはFlashで作成したデータをゲーム機上、およびPC上で確認でき、ベクタフォントなんかも使えるスグレモノ。アクションスクリプトにも対応していて、MGS4で使ってた自社コンバータを凌駕する機能を有しているようです。
このツールを導入したことで、全体の確認をプログラマを介さずに確認できるようになり、デザイナとしてはかなり助かったようです。
デメリットはFlashの導入コスト、および学習コストです。ソフトは買わなければいけないし、学習も必要となります。
ただ、購入についてはどうしようもないものの、学習については本もWEBもたくさんあるのでそれほど困らないでしょう。ただし、Flashの一部の機能は対応していないので、その辺の学習も必要です。
ベクタフォントは解像度が変わっても綺麗に表示されるため、非常に便利です。問題はデータサイズ、描画コストですが、どちらもそれほど大きな影響を与えないようです。
ただ、他でGPUを圧迫しているとScaleformGFxの描画が重くなることもありますし、半透明の数、全体的な描画枚数なども注意が必要なようです。
全体のファイルサイズはSWFファイル(Flashのファイル)にすべてのデータ(画像データとか)を入れると重くなるので、汎用的に使われるものについては別途読み込む処理が必要になります。が、PCビューワは指定位置からのファイル読み込みにも対応しているため、ビューイングのコストは変わらないようです。
プログラマからしても利点はあります。トライ&エラーを自分たちを介さずに行えるので勝手にやらせることが出来ますし、それによってプログラマの責任が低下します。
Flashの使用方法としては、公開されているSWFフォーマットを調べて自前のコンバータを作成する、SWF ToolsなどのSWFファイルからデータを引っ張ってくるツールを使う、ScaleformGFxのような実機上で動かせるツールを使うという3つが考えられます。
フロムでは時間と確実性の観点からScaleformGFxを選んだようです。このツール、それなりに実績があったりします。
GFxでは現在、ムービーとサウンドの再生が出来ないようです。ただ、2009年春のアップデートで対応予定だそうです。
このツールの問題点として、メモリの使用量が確定しない(メモリの確保・解放が頻繁に行われる)、動作速度が不透明などがあります。
制限もあって、Flashからゲーム、ゲームからFlashの通信には制限があり、高コストの処理もあります(メッセージ交換とか)。
また、忘れてはいけないことですが、GFxはワークフローを決定するツールではありません。役割分担はきちんとチームで行う必要があります。
で、今回のプログラムの役割の中にはメニューの振る舞いに関するいくつかが担当されていたりします。結局、このボタンを押したらどうなる?とかはプログラマの手を介する必要が出てきてしまうというわけ。
課題としてはまず、Flashとゲームの同期を保障しなければなりません。
例えば、体力を表示するバーがあったとします。このバーとキャラの体力は同期していなければなりません。
この場合の最も簡単な解決方法は、ゲームシステムがFlashに常に体力の現在値を渡すか、Flashが常に体力の現在値を要求します。
しかしFlash-ゲームシステム間の通信には制限があります。しかも前者の場合は体力バーが表示されるメニューかどうかをゲームシステムが知っている必要があります。
そこで使われたのが Observerパターン。知らない人はググってね。
つまり、体力などのゲームシステムからデータをリアルタイムで引っ張ってくる必要があるデータはすべて Observer を介して処理されます。ゲームシステムも決められた Observer にデータを送ればよいのですから混乱することはなくなるでしょう。
他には Mediatorパターンも使われています。これは、ゲームシステム上で色々やってる処理をPCビューワ用に書き直したものです。
例えば体力を取得しようとしても、PCビューワではそれが出来ません。ゲームシステムがPC上に存在しないんだから当たり前でしょう。
そこでPCビューワ用にダミーを作成し、Mediatorパターンを用いて実機とPCでの処理を振り分けるわけです。この辺の話は実装に絡む部分だけに参考にしやすいです。
ローカライズは今までとあんまり変わらないみたいです。フォントデータは別に読み込んで、文字列データの管理はEXCELを使って行います。個人的にもその方がいいと思う。
フロムの皆さんのアドバイスとしては、導入理由の共有、ワークフローの決定は確実にやっておくこと。夢を見るのはやめようなどとも言われていました。
あと、あまり関係ないですが、講演の手際が極めて悪かったですね。あの辺は何とかしてほしいです。

最後に全体的な感想。
講演自体は有意義なものが多く、非常に良かったと思います。
ただ、講演を予約なしにしたのはやはり問題があったのではないかと思います。
会場が十分に大きければ問題ないのですが、立ち見ですら教室に入れないような状況では予約はあったほうがいいのではないかと思います。
1つの講演が終了したら並ばなければならず、後で質問ということが難しい状況でした。
某氏と話をした時にそんなことを言ってみたのですが、やはりこれだけの規模の会場を見つけるのが難しいらしいです。
もっと金を積めば何とかなるんでしょうけど、さすがに難しいですからねぇ…。
ただ、定員なしの予約制ならライブシアターの設置とか事前に色々準備できるんではないかとも思います。
でも、楽しかったです。ほんとに。

スポンサーサイト
  1. 2008/09/28(日) 12:44:31|
  2. プログラミング
  3. | トラックバック:0
  4. | コメント:0

三角形ストリップは有効か?

後輩が、三角形ストリップを使うと遅いって本当ですか?とか聞いてきた。
頂点キャッシュを使えば三角形リスト形式でも十分で、ストリップのほうがむしろ遅くなるとかネットで見たとか言うようなことをいってたわけで。
調べてみると、ひげねこさんの所にストリップはもう必要ないんでは?みたいな記事がありまして。
つまりこういうこと。
ロングストリップは頂点キャッシュの効きやすさという点では不利。それなら、キャッシュ効率を考慮したリストの方が速い。
しかもストリップ作成にはけっこう時間がかかる。その辺を考えてもリストでいいんじゃね?ってこと。
ショートストリップにすれば頂点キャッシュは効きやすくなるけど、ショートストリップならストリップ化するメリットは薄いんじゃね?
まあ、一理ある。というわけで、試してみました。

http://monsho.hp.infoseek.co.jp/files/TestTriStrip.zip

300ポリゴンを1万回描画してその速度をチェック。
どの頂点もインデックス付きで、三角形リスト、三角形ストリップ、ところどころに縮退三角形を仕込んだ三角形ストリップの3種類です。
結果としては、やはりストリップのほうが速いです。縮退三角形を仕込んだほうでもリストより速いですね。
ただ、検証としては少々問題もあって、データが意味のあるモデルではなく、ただの帯であること。
帯はストリップにもってこいの形状で、明らかにリストの方が不利です。
本当は適当でもゲームで使われそうなデータを使用するべきなんでしょうけど(その分縮退三角形は多めに入れておきましたが)。
速度面ではキャッシュを考慮したストリップ化をするのが一番なんじゃないかとは思います。
これについてはMSのHoppe先生のSIGGRAPHの資料が役に立つでしょう。
まだきちんと読んでませんが、これを実装するのが一番高速化できるような気がします。
ただ、以前うちのサイトでやったようなロングストリップを作成する手段の場合、キャッシュ効率は悪くなるかと思います。
この場合、キャッシュ効率を意識したリストの方がいいかもしれません。
ひげねこさんでも書かれていましたが、ストリップ化プログラムはけっこう時間がかかります。
今後、数100万ポリゴンとかを扱うことがあるようならストリップ化はデータコンパイルにおいて致命的になりかねません。
ただ、キャッシュを考慮したポリゴンのソートを行う必要があります。これっていい方法あるんでしょうかね?知ってる人がいたら教えてプリーズ。

まあ、一番いいのは自前の描画エンジンで試してみることでしょうね。
あと、頂点キャッシュがないPSPの場合はインデックス付き頂点は逆に不利にしかなりません。
私が試した時は、インデックス付き三角形ストリップはインデックスなし三角形ストリップの5?7割の速度しか出ませんでした。
まあ、暇があったらXSIのデータを自前の形式にコンバートできるようにして試してみようかとも思っています。

  1. 2008/09/21(日) 20:31:04|
  2. プログラミング
  3. | トラックバック:0
  4. | コメント:0

CEDEC2008 2日目

ちょっと色々事情があって実家に帰ってました。
何があったかとかは察してください。

それはともかく2日目。まずはカプコンの稲船氏の基調講演です。
すでに本職の人の記事が上がっているので書く必要もなさそうですが、とりあえず簡単にまとめて見ます。
稲船氏の講演の基本は”甘えるな!”ということ。クリエイターは甘えすぎだと。
クリエイティブとビジネスは相反する部分もあるけど、だからといって対立しててもいいものは出来ない。
矛盾するものを作れば売れるんだと。安くて美味いものなら売れるでしょ?
男にしても優しいけど頼り甲斐のある人のほうがもてるってのと同じだそうだ。
カプコンがどん底の時、経営者には8?9割は続編を作れといわれたそうですが、これにはいと答えたとか。でも実際には逆にして、8?9割は新作にしようとしたとか。
そもそも、どん底にいるときのクリエイターは疲れている。それに続編作れといっても疲れるだけ。新しいことを!という方がクリエイターは喜びます。
それでも上は絶対を求めてきます。絶対売れるものを作れ、と。そういう時は嘘をつく。嘘も方便。
とにかく経営者もユーザーと同じように考える。ユーザーのことを考えるように経営者のことも考えるべき。
たとえば上場企業なら自社の株価をみる。株が下がるのはどういう状態か、上がるのはどういう状態かを考える。上がるように努力すれば経営者の気持ちもわかるだろうと。
ただし任天堂の株は別。任天堂ははるか彼方の存在だと。ですよねぇ。
クリエイターも作るだけでなく経営の方に関わっていこうよ、というお話でした。

1コマ目はコーエーの津田さんによる物理エンジンのお話。
コーエーでは物理エンジンを自前で作成していて、これを作ったときの理論や高速化、安定化の話も最後のほうで少しやっています。
そもそも自前で作成している理由として、物理シミュレーションを使った特殊な処理を作成するために基盤技術をブラックボックスにしたくなかったからだそうです。
最初は拘束のない剛体運動について。これはうちのサイトでもやっている慣性テンソルとかの解説をさらっとやっただけです。
それから拘束のある運動について。これが今回のメイン。コーエーの物理シミュレーションも剛体運動のコードの9割はこれについてのものだそうです。
拘束の解き方にはいくつか方法がありますが、今回は解析法が解説されました。これはたぶんODEで使われているものと同じです。
拘束にはジョイントによる等式拘束とコリジョンによる不等式拘束があります。そして、その等式、不等式は何に対して適用されるのかというと、昔は加速度が用いられていましたが、現在は速度が多いようです。
ボールソケットジョイントで接合された点 a,b があり、その速度を Va,Vb とすると、Va=Vb となります。コリジョンの接触の場合、接触面の法線を n とすると n・(Va-Vb)≧0 となります。これが等式拘束、不等式拘束です。
でまあ、この辺りから一般化速度(速度と角速度を並べた6要素のベクトル)やら質量マトリクス(質量と慣性テンソルを組み合わせた6*6行列)やらヤコビアン(異なる座標系の間で速度を変換する演算子)やら出てきます。
数式なんかもいっぱい出てきてるんですが、この辺りから理解不能になってきました。多体の物理くらいまで来ると何を言ってるのかさっぱり。
というわけで、資料参照。見ても判らない人は仲間。判る人は物理エンジンくらい作れるんじゃないかと思います。
Gauss-Seidel法は聞いたことがありますが、聞いたことがあるだけ。困ったね。
安定化と高速化についてはSlop(許容貫通誤差)、Permutation(行入れ替え)、WarmStart(前ステップ解による初期化)、Shock Propagationなどが簡単に解説されました。なんとなくわかるものもあるのですが、そこに行く前の段階で問題があるのでほとんど理解できず。すまぬ。
というわけで、物理エンジンを自分で作るのは難しいんだなぁ、と強く感じた講演でした。

2コマ目はMGS4の各種技術についての話です。これも本職の記事が上がっているので少し簡潔にまとめます。
HDRレンダリングは当初FP16でやっていましたが、フィルレートが低いこととMSAAが使用できないことから断念。エンコードレンダリングに変更したそうです。
エンコードレンダリングは、32ビットのうちのα値に輝度の逆数を格納して実際に使用する際に計算によって必要な値を計算するようにしています。
計算負荷は軽いのですが、α値を使用しているために直接半透明描画が出来ないという問題も抱えています。
これを解決するため、半透明、および加算合成のオブジェクトをブレンドバッファという別バッファに描画してあとで合成するという方法を取っています。
ブレンドバッファはHDRレンダリングできず、また、減算合成なども出来ません。ただ、減算については何とかなるかもしれないとは言ってました。
また、エフェクトの一部(手前側のもの)については1/4の縮小ブレンドバッファに描画しています。フィルレートの低いPS3では画面いっぱいの半透明オブジェクトは負荷が高く、これを解決するのが主な目的です。
なぜ手前のエフェクトに限定されているかというと、深度バッファの判定をミスしやすいためだそうです(手前は深度バッファの精度が高いためミスが減る)。
ライティングは影ありの平行光源と点光源を平行光源に変換した光源などに加え、環境光、リムライト、分離プリライトなどがあるようです。
環境光は半球ライティングですが、方向と適用範囲を設定できるようにしています。ツールは専用ツール。
リムライトは順光と逆光で別の効果が出るようにしています。順光はソフトライト、逆光はハイライトが出るようになります。
順逆の向きは半球ライトの軸を使っているそうです。また、そのバウンディングボックスに色々なデータを入力できるようにしています。
分離プリライティングは頂点に基準3方向のライティング結果を格納しておく方法です。基本的に静的なデータですが、初期化時に計算されるため、なんらかのライティングの変化があったときに再計算することでライティング結果を変更することが出来ます。
また、ライト数制限がないので、デザイナの力で間接光も表現できます。
ただ、品質はあまりよくないのと、RSXと相性が悪いのが少し問題のようです。
エフェクトは色々ありますが、それぞれで別の処理を行っています。
まず、血や水濡れですが、これは今までと同様に頂点カラーを使っています。テクスチャでやることも考えたようですが、他で色々使っているので難しい。
半透明の被せモデルは乗算合成が使えないので断念。結局、頂点カラーの各成分にそれぞれ血や水濡れを割り当て、その値を使って計算しているようです。
積雪エフェクトは半透明の被せモデルです。これはα値に積雪量を書き込み、αテストして終了です。合成の必要がないため被せモデルでも問題ありません。また、風の方向によって積雪する場所も変わります。
水面の波紋はシミュレートではなくそのままの波紋エフェクトを使っています。しかし、ただ表示するのではなくハイトマップに波紋テクスチャを書き込むという方法です。
ここでの工夫はこれをビュー座標で行っていること。これによる恩恵としては、見えない部分は書く必要がなくなることです。
DOFは錯乱円の計算式を用いてシミュレートしています。ただし、ゲーム中用の簡易版もあり。
サンプリングは19点で、六角形の絞りの形になるようにサンプリングしています。
問題はエンコードバッファで、デコードしてサンプリングは重いのでデコードしていません。そのため、当初のトレーラーのような映像は出せなかったようです。
カメラの手前に流れるようなフォグや砂煙を出すときは1/16の縮小バッファに描画しています。描画順番による矛盾は無視。
深度バッファはWバッファに変換してテクスチャ化しています。ソフトパーティクルの他、デカールに使用したり(通常、ポリゴン切断で行う処理だが、深度バッファを見て深度に開きがあるなら描画しないという方法で処理している)、グレネードの着弾点の描画(実際に描画しているのはスプライトらしい)に使っているそうです。
スクリプト言語は独自のGCLという言語。パラメータの設定、およびゲーム進行管理に使用しています。
日本語対応、C++プログラムとの変数共有、使用されているリソースを収集して自動ビルドまで出来ます。
リアルタイムムービーはポリデモと呼ばれ、アニメーションデータは時間軸で圧縮、フレーム単位でスライスされパケット化されています。これによりストリーミングが可能です。プレビューは実機。
問題点はゲームとのシームレスな移行が難しいこと、カット切り替え時の物理シミュレーションがおかしくなるなどです。
リアルタイム2DムービーはFlashで作成し、独自のシステムへ変換しています。
ただ、Flashの機能は一部しか使えず、アクションスクリプトも使えないらしい。
…簡単なまとめになってないよ、これ。

3コマ目はムームーの森川氏による遺伝的アルゴリズム(GA)の解説です。
GAやNNといえば森川氏はまさに先駆者といっていい方で、AIに興味がある人間としては聞いておきたい講義だったので。
最初はGAの解説で、これについては以前の三宅さんの解説とほぼ同じです。違いがあるとすれば、スライドが三宅さんのものに比べて見やすいことくらいですかね。
次にGAを使ったゲーム『アストロノーカ』を用いて実例を交えての解説。
そのうち資料なんかも公開されると思いますが、『アストロノーカ』で実際に行っている処理方法についてきちんと解説されています。
たとえば、パラメータの計算方法。これは8ビットの各ビットに別々の数値を割り当て、すべて足すと100になるように考えられています。
しかも0?100までの数値のうち、表現できない数値は4つぐらいしかないそうです。
交叉は三宅さんは1回と予想していましたが、実際には2回らしいです。
子を生んだ親はそのまま残し、最も成績の悪かった2つを消去するようにしているそうです。世代交代は1回のゲームで10代交代だそうです。
最後に自分のゲームにAIを組み込むべきかどうかという診断テストみたいなものが行われましたが、森川氏の言うとおり適当っぽいないようでした。
質問も興味深いものがいくつか出ていました。
まず、GAを選んだ理由ですが、GAの事がよくわからなかったからと言ってました。GAのことがよくわかっている現在ならGAを持ち出すことをためらうかも、ということでした。
デバッグについてですが、やはりこれは経験則でやるしかないとのこと。もちろん、それを簡単にするためのツールなどはあった方がいいでしょうけど、バランス調整はゲームによるとしか言えそうにないようです。

4コマ目は長谷川先生による衝突判定法についての講演です。
衝突判定を細かく見ていくとポリゴンとポリゴンの衝突などになるわけですが、これを総当りで行うのは当然のことながら遅いです。
まずはBroadPhaseとして、バウンディングボリュームのチェックを行うでしょう。
このとき、バウンディングボリュームの総当りを行う方法もありますが、それより早くなる可能性のある方法としてSweet&Pruneという方法があります。
ある軸(たとえばX軸)に対して各バウンディングボリュームの最大値と最小値を求めます。
そしてすべての最小値の中から最も小さい値を探し出し、ここから処理を開始します。
その最小値は対応するバウンディングボックスとともに保存され、これと同じバウンディングボックスの最大値が出てくるまで保存しておきます。
その間に別のバウンディングボックスが入ってきた場合、その2つのオブジェクトは接触している可能性があります。
もし、同一オブジェクトの最大値が入ってきた場合、そのバウンディングボックスは保存場所から削除します。
すべてのオブジェクトが削除されると終了です。もちろん、すべてのオブジェクトがX軸に対して重なっているようでしたら高速化にはなりません。
Sweet&Pruneを総当りの場合、オーダーは O(n^2) となりますが、QuickSortをしている場合は O(nlogn) となります。
このオーダーの計算は n が∞に向かった場合の処理の速さを相対的に表現したものに過ぎません。O(n^2) と O(nlogn) なら O(nlogn) の方が速いわけです。
なので、どんな場合でも総当りがQuickSortより遅いというわけではありません。アプリケーションで扱うデータの量によっては総当りのほうが速い場合もあります。
また、Sweet&Pruneを物理シミュレーションで用いる場合はInsertSortが有利です。通常は速い方法ではないのですが、前回のソート結果を用いることが出来るため有利となります。物理シミュレーションではあまり大きく位置関係が動かないためです。
UniformGridとBucketSortを利用するのも悪くないですが、1箇所に集まるようであれば遅くなってしまいます。このような場合は、集まった場所でまたUniformGridを用いるのがよいでしょう。
BSPの切断面についても、ゲームによる、としか言えません。ただ、個人的にはBSPってそんなに速いという印象がありません。
BVHの構築法としてはトップダウン法、ボトムアップ法、改良ボトムアップ法などがあるとか。この辺も資料を参照した方がいいかと。
さて、BroadPhaseで刈り込みを行った後はNarrowPhaseとしてポリゴン形状同士の判定を行います。
ポリゴン形状同士の衝突判定を取るライブラリは結構色々ありますが、物理シミュレーションを行う場合は衝突後の処理を行うのに必要な情報を取得できるものを選ぶべきです。
解析法を使うのであれば、接触点、法線、接触面が取得できる必要があります。
また、ポリゴン形状が凸形状であるほうが望ましい理由は、凸形状の場合は極小値が最小値となるためです。一般に極小を求めるのは簡単ですが、最小を求めるのは難しいのです。
基本プリミティブ同士の判定であれば幾何計算で求まるものも多いのですが、凸形状のポリゴンモデルともなると話は別です。
これらの判定を取る手法としてGJKアルゴリズムなどがあります。簡単に解説もされたのですが、図なしで解説するのは難しいよね…。
あとはConvexHull(凸包体)を求める方法としてQuickHullやAndrewのアルゴリズムが紹介されていました。この辺りはそのうちプログラムを書いて公開するかも。
最後にこの辺がいいよ、という本をいくつか紹介されました。
出版者とかよくわかりませんが、『プログラミングのための線形代数』、『計算幾何入門』、『計算幾何工学』がいいようです。
また、数式萌えを知りたいならということで『数学ガール』という小説も紹介されています。ちょっと面白そうなので、他の本と一緒に注文してみるかな。

2日目はこんな感じです。
このあとデベロッパーズナイトという懇親会があったのですが、そこに宮本茂さんが来てました。
生で見たのは初めて。ほとんどアイドル状態で、名刺交換、写真撮影、握手と大変そうでした。
途中で新さんが止めてました。まあ、ゆっくり話したいこともあるでしょうしね。
知り合い曰く、「仕事で名刺交換するのが目標」。がんばれ。

  1. 2008/09/20(土) 19:54:39|
  2. プログラミング
  3. | トラックバック:0
  4. | コメント:0

CEDEC2008 1日目

さて、今回は個人参加のため会社にレポート提出の義務はありません。
というわけで忘れないようにこちらに書いておきます。

まず基調講演はコーエー社長の松原さんが自身のキャリアをちょっと話した後にCEDECの今までとこれからについて話をされました。
今後もCEDECは重要になるでしょうし、個人的にも頑張ってほしいところです。

次。1コマ目。というか、今回はImagireDayのみ行ってますので、ImagireDayの1コマ目です。
シリコンスタジオの川瀬さんと田村さんの講演でした。最初が田村さんの影に関する技術の話、次が川瀬さんのポストエフェクトの話です。
田村さんの講演は『Real-Time All-Frequency Shadow in Dynamic Scene』というSIGGRAPH08の論文の話でした。
これは環境マッピングを光源として動的シーンに影を落とす手法の1つです。
SHEXPを使用した同種の技法については以前田村さんが講演してましたが、この技術は影がソフトすぎてハードな影は出せません。
今回の方法はソフトな影もハードな影もOKな代物のようです。
理屈はけっこう簡単で、キューブ環境マップの各面において光源を複数の面光源に変換し、それらすべての面光源についてシャドウマップを行うという手法です。
まず、キューブ環境マップの各面において、最も明るい点をピックアップします。
これをある数式が満たされている限り近傍に矩形を広げてゆき、広げられなくなるまで広げたらそれを1つの面光源とします。
残りのピクセルについても同様に行ってゆき、最終的に面すべてについて検証したところで終了です。
これら面光源について影を落とす場合、”Convolution Shadow Map (CSM)”という技法を使います。
このCSMを説明する前に”Percent Closer Filter (PCF)”というソフトシャドウ生成技術について説明が行われました。
これは知ってる人も多いと思いますが、あるピクセルでの影判定を行う場合、その近傍のピクセルとの判定も行って影となる割合を求め、これを影の濃さとする手法です。
つまり、PCF はデプステスト→フィルタと処理するのですが、これをフィルタ→デプステストとするのが CSM です。
そういえば、以前やった VSM もフィルタ→デプステストですね。
これについては元の論文を読んだほうがいいかもしれません。数式もスライドで示されたのですが、座った位置が遠すぎて見えませんでした。
いや、わざとそんなところに座ったわけじゃありません。人が多くてその辺しか空いてなかっただけです。
また、CSMではフィルタのサイズを固定するのですが、今回紹介された方法ではフィルタサイズをピクセルごとに変化させるようです。
この辺の計算式も見えませんでした。後で論文で確認しましょう。
でまあ、この方法で面光源に対して影をつけてくわけですが、この辺の説明があんまりなくて詳しい実装法がよくわかりませんでした。やっぱり論文を読もう。
まとめとしては、力業だけどできる、でも重い。1つか2つならいいかもしれないけどそれ以上だときびしくね?ってことのようです。
次の川瀬さんの講演は去年もやったポストエフェクトで現実的に正しい(ものに近い)ボケの表現手法について。
まずはレンズの話ですが、これは去年もやったのかもしれません。私は聞いてないのでわかりませんが。
レンズは平行光源がまっすぐに入射した場合ある焦点を結びますが、点光源がレンズの真正面にあった場合、点光源が近づくほど焦点は遠くなります。
これがピンボケを作る理屈です。他にも色の波長によっても焦点位置が変わりますし、斜めに入射する光に対しても焦点距離がずれます。
例えばレンズが円形であり、収差がない場合、レンズの距離と焦点からのずれはボウリングのストライクのマークみたいになります。一番狭まっている部分がピントの合っている場所になります。
X軸をレンズからの距離(0.0?1.0)、Y軸をボケとして表現した2次元テクスチャが上記のようなマークに似た図になりますが、これをテクスチャとしてピンボケを表現できますよ、という話でした。
アニメなんかだと夜の街を表現する際に、ネオンの光が強いところに半透明の円を置いてみたりしてボケてるように見せかけることがありますが、これをポストエフェクトとして使おうというわけです。
さすがにすべてのピクセルに対してスプライトを置くわけにはいきませんが、それっぽくボカしたい一部のピクセルだけにこの対処を行うのであれば負荷はそれほど高くなりません。
テクスチャは事前生成できますし、複雑な収差を考慮にいれたボケも表現は十分可能です。
ただ、実際のカメラのボケはそんな正確で綺麗な形状にはならないため、その辺も考慮しないと不自然になるかもしれません。
個人的には、そこまでやらなくても大半のユーザはわからないんじゃないかと思ったりしますがね。

2コマ目はトライエースの五反田社長によるシェーダ管理の話でした。
これの資料はそのうち research.tri-ace.com の方で公開されるものと思われます。
ゲームのプロジェクト内でシェーダを作成する場合、いくつかの方法があります。
まず、大きなシェーダプログラムを書いて、そのプログラム内で分岐とかを利用する方法です。
基本的にシェーダプログラムは1つになるので管理は簡単ですが、シェーダ内の分岐というけっこう負荷の高いことをするためパフォーマンスは落ちます。
プリプロセッサを用いる方法もあると思います。分岐を行うよりこの方向を考えたほうがいいかもしれません。
次に1つ1つのシェーダを手で書く手法ですが、パフォーマンスチューニングはもっともやりやすいと思いますが、バリエーションが増えれば管理は非常に難しくなります。
3つ目はオフラインでシェーダを自動生成する方法です。プログラマの手を介さずにデザイナがシェーダをいじれますが、やはり管理が厳しくなります。
トライエースでは4つ目の方法である、ランタイムでの自動生成を行っています。この方法はバリエーションを簡単に作成できる反面、バリエーション爆発が起こりやすくなります。
シェーダはMAYA上で設定できるように独自のシェーダノードを作成しているようです。そのため、シェーダをかなり細分化しているそうです。
シェーダノードは1つ以上のシェーダキーを生成します。シェーダキーはヘッダと複数のチャンクから成っていて、関数の引数や出力変数などを指定します。
また、視線ベクトルや反射ベクトルは使用する・しないに限らず計算します。使用しなければコンパイラが最適化してくれるからです。
他にもシェーダ内で使用される定数をシェーダごとに設定できるようにしたりしているようです。
さて、当初シェーダ用のキャッシュメモリは20MBと設定しておいたらしいのですが、気付いたら50MBを超えていたそうです。
これではでかすぎるので色々やってみたけど、ほとんど減らない。というか、減ってもいつの間にかシェーダが増えてる。
それもそのはず、あるゲーム(ぶっちゃけインアン)では、5月の段階で34000個のシェーダが存在していたそうです。最終的にはもう少し増えてたかもね。
なぜそんなことになるのかというと、1つは同じマテリアルであってもライトの数などで処理が変わってくるからです。
シェーダでは if や for はコストが高くなります。ライトの数が n 個までだからといって n 回のライティング処理を行うわけにはいきません。
n 個が最大なら、0?n 個でそれぞれ別のシェーダを作成しないといけないわけです。
ほかにも、定数がちょっと違うとか落とされる影の数が違うとか、影処理方法に違いがあるとかでそんな数になってしまったようです。
別のプロジェクト(多分SO4)ではエリア1つで2万個以上のシェーダを使っているようです。ちなみに、インアンのエリアは1つで1万個くらい。
この辺をどう解決したかはメモを取れなかったので、資料配布されたら読んでみましょう。
まあ、なんというか、トライエースでもこんなに苦労してるのか、と思うとちょっと滅入ってきますね。
しかし、例えばいくつかの技術についてはシェーダパスを統一するなどである程度の対処は出来ると思います。
そのためにはデザイナを統括するような人物は必要になるのではないかと思います。難しいことかもしれませんがね。

3コマ目はフロムソフトの三宅さんの話。プロシージャル関係ですが、AIセミナーとかで話してる内容がほとんど。
新規の話題はSPOREくらいかな。何度か聞いてる話なので、ここで書く必要もなさそうです。
ただ、シューティングにプロシージャル技術を利用するのはシューティング復活の1つの方法ではないかという話は半分納得できます。
スクロール系のシューティングは地形の変化、敵の出現などが洗練された演出として存在しています。
それこそ演出を自動生成できなければ面白くないゲームにしかならないのではないかと思っています。
ですが、1画面ゲームはプロシージャル技術と相性がいいかもしれません。ランダムで出現するより予測できないけど何らかの法則性があるように見えたほうが面白くなるかもしれません。
また、ギャラガレギオンズやスペースインベーダーエクストリームはステージ分けされていない無限モードがありません。
もし、プロシージャルにギャラガやインベーダーの隊列をいい具合に生成できるのであれば、より面白いゲームに為るんじゃないかと思います。
しかし残念ながら、三宅さんの作ってきたプロシージャル生成している3Dシューティングは面白そうには見えなかったですね。

最後はバイナムのImagireさんによるプロシージャルグラフィック関係の講演でした。
まず、シェーダに必要なデータの中には自動生成できるものはけっこうあります。
様々なテクスチャはまさにそれで、デカールマップだけでなく、位置マップ、法線マップ、アンビエントオクルージョンマップなんかが自動生成可能です。
また、面白い方法として逆アンビエントオクルージョンなんかも作れます。オブジェクトのエッジや曲率を調べるのに最適かもしれません。
これらを利用して作成されたのが、傷やほこりの積もりなどによる経年劣化。
シェーダパスについてはメモを取れなかったので資料が上がったらチェックする方向で。
サンプルの映像ですが、パッと見、経年劣化っぽくは見えなかったです。全体的に色をくすませてみるとか、ほこりにノイズを使ってみるとかすればもう少しよくなるような気もします。
まあ、その辺はデザイナが協力すればきっといいものが出来るでしょうし、モデル作成(UVマッピング含む)とシェーダ作成以外のリソースは自動作成できるわけで、これが非常に重要かと思います。
インベントリ内のアイテムが経年劣化していくのがわかる、とかってなるとゲームの見た目もかなり良くなるんではないでしょうか。
次に紹介されたのが移流テクスチャ。ノイズを流して流体っぽく見せる手法です。
たしかSIGGRAPH08での論文が簡単に紹介されていました。これはフラクタルノイズを組み合わせる手法らしいのですが、実際に紹介されたのはそれより簡単な手法です。
UV座標をブロックごとに違う方向に流してノイズを描画することで、それっぽく動く雲とかを実現することが出来ます。
しかし、ただUV座標を流しただけではある場所で停滞してしまうこともあるでしょう。
これを防ぐために適当なフレームでリセットすべきなのですが、いきなりリセットするとリセットしたのがばれてしまいます。
そこで、いくつかの時間をずらして流しているテクスチャを合成することで解決できます。
サンプルでは3枚でやってましたが、その合成の重みは複素平面でぐるぐる回る水車のようなベクトル群の実部を用います。3枚ならベクトルは3本。
後はひずみテンソルとか何とか…この辺はよくわからなかったです。すまぬ。
ノイズが動くと楽しいかもね、という技術でした。
最後にL-Systemを用いた樹木生成の解説が行われました。これは急遽付け加えたものらしく、1日で作ったらしい。すげぇ。
まず、1本の木の枝をモデリング。これを縮小・ひねりを加えてそのモデルにアタッチします。
縮小具合やひねり具合、アタッチする位置や方向などがプロシージャルに計算されます。
これを何度も再起していくと樹木っぽいものが作成できます。実際、それっぽくなってました(ちょっと横に長いけど、L-Systemの樹木サンプルってたいてい横に長いように見えますね)。
問題は再起の回数で、回数が多くなればなるほどしゃれにならないくらい重くなります。
そこで、ある程度の回数以降は通常の方法で作成したものをビルボードのテクスチャとして貼り付けるという手法を用いました。
ボリュームテクスチャも使ってけっこう楽しそうな手法でしたが、やはりビルボード部分がくるくる回ってしまって、角度次第ではおかしな具合になってしまっていたのが残念でした。
とはいえ、ビルボードを使っている以上避けられないしなぁ…。
でも、使い方を研究すればLODに使えそうな技術ではあります。海外では当たり前のようにやってるのかもしれませんがね。

今回のCEDECはスライド資料を紙で配布していなかったため、後ろのほうに座るとかなりきついですね。
スライドにない内容を出来るだけメモにとって、あとで公開される(はずの)資料と付き合わせる必要がありそうです。
あと、人多すぎ。一部に人気集中しすぎ。仕方ないことではありますが。

  1. 2008/09/09(火) 23:04:45|
  2. プログラミング
  3. | トラックバック:0
  4. | コメント:0

どこからでてきた、テクモとコーエー

来週はCEDEC2008ですね。
私は今年も参加しますが、今年は個人で出席します。
なので、個人的なメモや感想等はブログの方に書きます。
今年は面白そうなネタが多く、そのため出席希望が多かったわけで。
やはり若い子に行ってもらったほうがいいだろうという感じで若い人優先に。
でも私も行きたいので個人で金出して有給も取って行きます。
レポート書かなくて済むのでその分楽です。
…そういえば、Imagireさんの講師コメントがフランクで面白かったです。

さて、スクエニがテクモに友好的TOBを仕掛けて、その返答期限の今日。テクモはコーエーとの経営統合の交渉に入ることに決めたようです。
っていうか、テクモとコーエーってどこから出てきたんだ、この組み合わせ。
乳バレーと零が好きな同僚は、スクエニの方がまだましだった、と言ってました。コーエーは嫌いらしい。
もしかしたら他の会社も名乗りを上げるかもしれないとは思っていたのですが、まさかコーエーとは…。
裏CEDECに松原さん来ないかなぁ…。来たら間違いなくこのことを聞かれまくるだろうけど。
板垣氏もこれからどうするんでしょうねぇ。どこかが拾うのか、新しく会社を作るのか。
まあ、今後もこんな感じの統合は結構起こるんじゃないですかね。
スクエニが日本のEAみたいな企業になったりして。それはそれで面白そう。

  1. 2008/09/04(木) 21:14:42|
  2. ゲーム
  3. | トラックバック:0
  4. | コメント:0

プロフィール

Author:monsho
ゲームプログラマ?

最近の記事

最近のコメント

最近のトラックバック

月別アーカイブ

カテゴリー

ブロとも申請フォーム

この人とブロともになる

ブログ内検索

RSSフィード

リンク

このブログをリンクに追加する

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。