独り言日記（2006/09）

独り言日記

ODEでのトライアングルメッシュ（2006/09/29）

より複雑な形状との衝突を判定するのにODEでは「トライアングルメッシュ」があります。これは、三角形で構成されたポリゴンメッシュです。で、入れ物をトライアングルメッシュで作って球をボコボコ放り込む、というのをやっていたのですが、なんかすり抜けが起こりました。それも一部抜けたりと微妙。う〜ん、実装が悪いんだろうか。

どうも、面の法線は見ているようですので、もしかしたら表裏は明確に区別しないといけないのかなぁ。面を裏返すと問題なかったりしたので、こりゃ両面対応しないと。1枚板は厳しい予感。

ODE 0.7（2006/09/25）

メモリ管理部分に関しては今回のバージョンアップではノータッチですね。dWorldQuickStepを使って時間を進める場合に10000個以上の衝突を安定して行う、とする場合は「collision_space.cpp/util.cpp/quickstep.cpp」のalloca部分をすべてスタックからヒープに改造してあげるとうまくいきます。

今回の0.6→0.7で追加されたファイルとして「heightfield.cpp/heightfield.h」があります。これは凹凸のある地面を「dCreateHeightfield」にて生成するための機能を提供しているようです（球やボックスと同じ並びの衝突用物理オブジェクト）。速度に関しては変わらず、といったところ。

ODEはPhysXと違ってソースがいじれますので、バグが見つかった場合も安心できますね。他のプラットフォームにも簡単に移植できますし。

改・PhysX ハードウェアのベンチマーク（2006/09/20）

改めまして「ELSA PHYNITE X100」の動作チェックです。念のため、、、現在テストしているのは試作機（リファレンス用）でして実際の製品販売は10月末ということになっているようです。たぶん試作機ゆえの制限なんだろう、と期待してあまり意味がないかもしれない結果報告です。

2043個の制限ですが、NxScene::createActorにて生成するアクターの数が球に限らずボックスを含めても「合計で2043個まで」でした。ただし、SDKにてそれをチェックするAPIがないため、あくまでもcreateActorで失敗するまで調べてみての上限です。

次に500個単位でアクター（球とボックスをランダムに選んで）を物理空間にランダムな位置に配置し、自然落下させる場合の時間をソフトウェアとハードウェア(PPU)で計測です。画面の描画はしないで純粋な物理計算時間です。

これを実際にOpenGL(GLUT)レンダリングした場合は以下な感じになります。

え〜〜、ほとんど差がないですね（汗）。アクターの上限が2043個だとすると2倍速も行ってないです。もっと複雑な拘束などを使ったりトライアングルメッシュを使うと差が出るのかもしれませんが、2000個ほどだと速度差がはたして出るだろうか、、、。またチェックしてみます。

そのときに使ったプログラムとソース（VC++7のプロジェクト一式）を置いておきます。プロジェクトの設定はPhysXSDKのインストールディレクトリにあわせて変更するようにしてください。なお、GLUTを使ってます（PhysX SDKに同梱されてます）。

PhysXTest_src_20060920.zip(173) (454KB)

PhysXのハードウェアがない場合は、10000個の形状が出ます。ハードウェアが存在する場合は最大で10000個までですが、ハードウェア（PPU）によって差があるかもしれません。ソースをいじることで純粋な物理演算だけの計測もできますので（引数で変更できるようにすればよかったですね(^_^;;）。

また、いろいろ分かったことは日記の落書きでなくてまとめるようにしておきます。

ODE 0.7（2006/09/20）

ODEの最新版である0.7が公開されていました。

http://ode.org/

変更点は、ロボカップな方のサイトにてまとめてありました（今、ODE本を執筆されているみたいです）。

http://demura.net/archives/2006/09/ode0.7.html

私が使っている機能では単純なことしかしていないため、あまり恩恵を受けられないのですが移行したほうがいいですね。トライアングルメッシュと平面の衝突判定が追加されたのはありがたいです。

PhysX ハードウェアの上限（2006/09/19）

PhysX SDKでハードウェアを使った場合、「NxScene::createActor」で球を作成したときの上限が結構低い結果に。すみません、以前のベンチマークがそもそもエラーチェックが抜けていて大きく間違ってました。「ELSA PHYNITE X100」にて球を作成したときの上限数が2043個で、以降の「NxScene::createActor」はすべて失敗していました（それをカウントしてました）。視覚的なものもチェックしつつ、正確なベンチを再試行するようにします。HavokFX(GPU)でのデモを見たときはもっと多くのオブジェクトとも衝突をしていたように見えたのですが、PhysX(PPU)のデモではそういえば大量のオブジェクトを出す、というのがなかったです。使い方の問題かHW上限かは現状分かりませんので、しばらくお待ちを。（2000個程度だったら速度的にもHWいらないわけですし、まさかこれがPPUの上限とは思いたくはないです(^_^;;）

吉野家（2006/09/18）

牛丼が１日限定販売だったそうで。昨日吉野家に行ってきたばかりなんですが、でかでかと「あと１日」のポスターが貼られてました、でそれで復活を知りました。個人的には牛焼肉丼+みそ汁のコンボが最近お気に入りです（笑）。

どこも混んでいるということで、今回の牛丼は見送りました（というか、私は牛丼よりも牛焼肉丼のほうが好きなもんで）。牛焼肉丼はオーストラリア産のを使ってるんですね。これを牛丼に使わないのはやはり味が変わるからだろうか・・・。

ところで、吉野家の以前の代表の方は学校を経営されていた、ということをご存知の方いますでしょうか。私の実家の近くの初芝高校の理事長をされている方が過去に吉野家の社長をされてました。どっちを先に経営していたのかは分からないですが。いかにも大阪商人、ですね。それもあって吉野家は身近に感じます。今や全国展開してますので「大阪人はここでもがんばってるなぁ」と励みになります。ちなみに「吉野家の牛丼」を世に定着させたともいわれる「きん肉マン」の作者であるゆでたまご先生（２人組みです）も初芝高校出身者です。何かしら牛丼に愛着があったのかもしれないですね。

PhysX SDKテスト（2006/09/18）

球を1000個落下させるのと10000個落下させるものを視覚化。

1000個の球を出した場合

10000個の球を出した場合

非力なノートパソコンでPhysXSDKのソフトウェアで実装しているため、以前に日記で書いていた計測結果とは比べれらないのですが（また、同じマシンにて計測してみます）。初期状態ではオブジェクト同士が重なるときがありますので、このときには時間がかかってしまいます。この場合、互いのオブジェクト同士が押し合って離れようとします。で、重なりが少なくなることで徐々に軽くなっていくのですが、ソフトウェアだとさすがに10000個の球でもリアルタイムでは厳しいですね。1フレーム分の描画で2.5秒から1.0秒ほどかかりました（Celeron 1000MHzマシンにて）。ただ、見て分かる通り、大量の球だとまじめにレンダリングしたところでビルボードで描画したものと大差はない気もします。nVIDIAのHavokFXのデモではビルボードで表現した大量の球をプールに蓄える、みたいなのをやってましたが、このあたりのフェイクも有効なのかもしれませんね。

[CEDEC 2006＃19] GPUパワー炸裂，Havok FXの解説ムービーを掲載

http://www.4gamer.net/news/history/2006.09/20060906222114detail.html

の「流体状パーティクルデモ」。

ちなみに、PhysX SDKのソフトウェアでは30000個よりさらに多くの球を作成したらアプリが落ちてしまいました。ハードウェアでは100000個でも問題なし。ODEでは、そのままの状態では1000個でも落ちたりするのですが改造したものは30000個でも耐えることができてます（遅いけど）。

これらについてはハードウェアでも動作チェックしてから、ソースごと公開します（たいしたことはしてないですが・・・）。こんな単純なことだけではなくて、拘束やクロス・流体も試さなければ。

A twist in the Muth - Blind Guardian（2006/09/15）

Blind Guardianの4.5年ぶりのアルバムが発売されていたので購入。ファンの一人としてず〜〜っと待ってました。ブラガらしいコーラスとメロディーラインだったので安心しました（先行発売されたミニアルバムでは、ちょっと方向性の変化が感じられましたので）。しかし、「xxxらしい曲を望むファン」がいる一方でアーティストのほうは変化を求めたがることも起こりえるのかもしれないですね。これは音楽でなくてもどんなことに対してもそうでしょうけど。

後、「Game Programming Gems5」というゲームプログラミング技術の書籍も購入。物理が目的だったんですが、私の注目した点は以下のとおり。

• 高速なBSPのためのスフィアツリー
• 錐台カリングの改良
• 「物理」の章全般
• GPU上での雲レンダリング
• 爆発効果
• 継ぎ目のない世界サーバーの実装

ほか、人工知能・数学などなどいろいろあって非常に濃いです。「錐台カリング」はシャドウマップ(LiSPSM)の最適化で使えるかと。しかし、技術本は分厚いのが多いですね。そろそろ家に置く場所も少なくなってきたので、会社に寄贈（というか本棚の場所確保）するかな（笑）。

Doxygen（2006/09/15）

仕事場でソースを管理する都合上、統一されたコメントの書き方がこれから必要っぽい気がしたので（というか仕事場の仲間がドキュメントを意識したコメントを書いていたので）、今の仕事のソースのコメント部をDoxygenで食わせることができる形に移植中。

さすがにコード量が多いので時間がかかりそうです。しかし、日ごろから統一化するクセはつけていかないとダメだな、と再認識しました。ドキュメントとしてそのまま使うわけではないのですけどね。個人スタイルを通す、というのもそろそろ直さないといけないですし。Javaの場合はJavaDocを意識して書くようにはしていたのですが、C/C++ではフリースタイルだったなぁ。それも矯正中。

PhysXハードウェア ベンチマーク（2006/09/14）

「ELSA PHYNITE X100」のハードウェアと、PhysXのソフトウェアでベンチマークを行いました。

ちなみに、下の日記に書いていたODEでのメモリ確保問題は修正完了。

テスト内容

Y = 0の位置に地面を配置し、空間上にn個の球をランダムな半径・位置でちらばらせます。これを重力加速度9.8(m/s^2)に従って自由落下させるときの、1/60秒ごとのシミュレーション時間を7回取り、それの平均を求めて計測値とします。あくまでも「物理演算」の計算時間のみを調べたかったので、グラフィックは出さずに調べています。純粋なボードの実力のみを計測です。

PhysXでは「g_pScene->setTiming((float)(1.0 / 60.0), 20);」として分割数を20で固定にしました。ODEでも「dWorldSetQuickStepNumIterations(world, 20);」として20分割するようにしています。これで条件は同じかな？

ODE/PhysX(SW:ソフトウェア)/PhysX(HW:ハードウェア)の比較

10000個の球での計測です。

物理エンジン	球の生成時間(ms)	0/60秒(ms)	1/60秒(ms)	2/60秒(ms)	3/60秒(ms)	4/60秒(ms)	5/60秒(ms)	6/60秒(ms)
ODE	72	130	107	111	107	112	107	108
PhysX(SW)	171	5	63	32	30	27	28	26
PhysX(HW)	102	0	27	5	4	5	4	4

球を生成する時間は、10000個の球を生成する時間です。生成部に関してはランダム関数なども呼んでいるため、あまり参考にならないかもです。

結果として、PhysXソフトウェアに比べてODEは約3-4倍遅い、ということになりました。PhysXソフトウェア自身も速いです（というか、ODEが遅いのかな？）。生成処理に関してはODEに軍配があがりました。

で、PhysXのハードウェアですが、球を生成する時間はソフトウェアよりも短縮できてます。個々の計算時間は、ほぼ0に近いです。ただし、1/60秒経過時点で何かしらの初期化が走るからか、2/60秒以降よりも少し時間がかかるようです。たしかにハードウェアが効いてますね。

5000〜30000個の球に増やして計測

ODEは置いておいて、PhysXのソフトウェアとハードウェアで5000個区切りで球を増やして実験です。

数値は割愛して結果のグラフのみ。縦軸が経過時間（ms）、横軸が生成した球の数です。

ハードウェアでは一向に減速する気配がありません。

なお、100000個まで球を増やしてテストしようとしたのですが、PhysXソフトウェアのほうが落ちてしまいました。30000個の球を超えたあたりでどうやら限界が来ていました。で、ハードウェアは100000個の球でも耐えました。なんと、計測時間は5000個の球を散らしたときと同じでした。これでも減速なし。グラフを見ると、ソフトウェアは波がありますが球の個数が増えるにつれて線形に時間がかかっていってます。対して、ハードウェアのほうは平行です。このまま100000個までソフトウェアが計測可能だったとすると（線形増加と仮定して）、ハードウェア対応で実に66倍は出ることになります。まだ減速するまでは球を増やしてないですが、もっと速度アップ出来る可能性もありそうです。

「あんまりハードウェア化しても速度が変わらないんじゃないの？」と思ったのですが、これはすごい！！2ケタから3ケタは速くなる、とageia社の方がおっしゃってたのもあながち誇張じゃなかったんですね。

ODEでのメモリ管理（2006/09/14）

自分用メモです。ODEではメモリ確保にて、なぜかallocaを多用しています。これを使うということは、ヒープでなくてスタックにオブジェクト情報が格納されることになります。作業領域で一時的に（小さいサイズで）スタックを使うのはいいのですが、静的データでスタックを常用、はちょっと設計上まずいように感じます。

以前日記でも書いた以外で、スタックオーバーフローする場所がいくつか見つかりました（ODE 0.6にて）。ODEにて物理空間に球を10000個くらい配置すると落ちます。これは、衝突判定処理（AABBをリスト化しているところ）「collision_space.cpp」内。問題は一時データでなくておそらく静的なデータでallocaしてるんですよね。これはちょっとやっかいだなぁ。

以下にて、同じような経験されてる方がやはり同じような解決策でソースを改変してるログがあります。

http://q12.org/pipermail/ode/2002-February/004927.html

解決策のレスが、「Windowsだったらスタックサイズを大きくすればいいじゃない」ってのは解決策じゃないような(^_^;;。10000個の球だとスタック8MBとかでも足りないですし。メモリはヒープに確保するべきじゃないかなぁ。

PhysXはこのへんは安定してました（実はスピード比較をしたかった）。う〜む、、、時間がかかりそうですが、いずれにしてもODEのソース改変が必要そうです。

ELSA PHYNITE X100（2006/09/14）

PhysXの物理演算アクセラレータ（評価機）が到着。今週末は3連休あるので掘ってみようかと思ってます。結果などは、このサイトにていろいろ情報公開していきます。

PhysXについて掘る（2006/09/11）

仕事のお客さん待ち状態で、ほぼ丸一日あきましたのでPhysXについて改めて掘ってみました。ドキュメントなんですが、結構出来がいいです。ただし、ドキュメントでDoxygenを使ってるみたいですが、なんか途中であきらめたっぽい形跡が見えるんですが・・・（某ドキュメント、というかリファレンスのようだ(^_^;;）。ドキュメントマニアからすると、やはり物足りない部分も少しあったりします。後、ごめんなさい、ハードウェア(PPU)対応している部分とソフトウェアとの区別は各APIごとに細かく書かれてました。ブラックボックスであるように日記では書いていたのですが、結構ホワイトボックスかもしれません（まだまだ全部は目を通せてないので判断はできないわけですが）。まじめに読んだらほとんどの情報はPhysX SDKのドキュメントとサンプルソースで事足りそうです。

PhysXのページにて、調べたことを蓄えていってます。この部分は完全に仕事とは無関係ですので、いろいろオープンに情報公開できそうです。個人的にはPPUはこれから延びていってほしいですので、それの応援もかねて。が、いつもどおりに途中で放置プレイになる可能性も(^_^;;。そういや、日記でのシャドウマップの説明もまだ途中でしたね、というかあらゆるところが途中ですね（汗）。

PhysXのPPUについては、ELSA社の「ELSA PHYNITE X100」もCEDECでいただいた用紙で申し込んでみました。一応物理演算については会社レベルで掘ってみようとは思ってます（私はそれの人柱というか広める役ができれば）。2週間もあればPhysXの機能は一通り調査できそうです。現段階では、ODEとさほど変わらないといった手ごたえ（ただし、細かいところの親切心がPhysXのほうが上のようにも感じます）。

ということで、お客さん待ちが続いてくれるといじる時間ができるぞ。と思ったら、もうすでに先方のバグが修正されたようで・・・(^_^;;。う〜ん、また余裕を作ってPhysX調査に取り掛からねば。めざせ、エセ流体＆クロスシミュ。

残像効果でのマルチサンプリング（2006/09/07）

いろいろ試行錯誤してたわけですが、いやはや申し訳ない、従来のマルチサンプリングでの手法のほうが速度的にも質的にも落ち着いた感じになった、という情けない結果に(^_^;;。

以前日記に書いていた方法だと、たしかに速度は確保できるのですが質があまりよくない（というかブラーっぽくない）んですよね。後、なんだかんだ調整していくと結局処理時間もかかってしまいました。で、マルチサンプリング手法にて移動距離によってサンプリング数を変える、ということを行うようにするほうがはるかにいいような気がしてきました。

上記の画像はマルチサンプリングなんですが、速度を犠牲してでもやっぱし枯れた手法であるこっちのほうがいいや。ということで、いろいろな実験は無駄になったわけですが（汗）、いろいろ勉強にもなりました。

物理演算（2006/09/06）

http://www.4gamer.net/

の「CEDEC 2006＃18」にてPhysXのムービーが公開されてますね。「CEDEC 2006＃19」ではHavok FX（GPUを使った物理演算を行うエンジン）のムービーが。両方ともCEDECにて聞きにいってました。

双方とも流体っぽい表現がされてますが、どちらも大量の球での剛体で流れを計算して、全体を（メタボール的に）覆っている、ってのがたぶんトリックっぽい気がします。Havok FXの場合は、講演の説明によると流体っぽいのは2Dパーティクル（ようはビルボード）での2D上でのメタボールレンダリングみたいですね。この部分はPhysXのほうが上手かな。ただし、PhysXのハードウェア自身は剛体と、クロスの場合は四角形のみハードウェア化されている、とのことでしたのでまだまだソフトウェア実装部が大半なのかな、と考えられます。

物理演算ボードの記事でよく出ることで「ソフトウェアとハードウェア(PPU)での違い」がありますが、ちょっと勘違いすることを書いてることが多いのでは、と思ったりします。ハードウェアで「派手になる」んじゃなくて、アクセラレートされるにすぎない（ソフトウェアで実装しても絵としては同じものを当然ながら出せます）、というのを書いてほしいなぁと思ったり。ソフトウェア実装で何FPS、ハードウェア実装で何FPSって記載するほうが演算力の違いが見れていいように感じます（可能ならば、グラフィックも除外して純粋な物理演算を行って個々の数値表記があれば）。

ELSA社の物理演算ボードの優待（１社に限り無償提供）という用紙をCEDECでいただいたので、いい機会ですし申し込んでみようかと思ってます。じっくりいじってみたいなぁ。ハードウェアは置いておいたとしても、結構いろんなことができそうですよ(＜PhysX)。

後、物理演算だけでアニメーションを使う、ということはゲームでも作品作りでも少ないかと思います。たとえば、ピッチャーが野球のボールを投げることを例として示すと、ピッチャーが腕を振るのは普通のキーフレームを伴ったモーション付けで、ボールが手から離れて初速度を与えられて飛ぶのは物理運動、といった感じで合成が必要になる場面が出てくるかと。この点（アニメーションの合成）についても、PhysXの講演では説明されてました。しかし、モーション付けをするのはデザイナ、物理は・・・だれがどう制御するのが妥当なんだろう？と、今はどこでもいろいろ試行錯誤する時期なのかもしれないですね。さて、物理演算エンジンがどこまで知名度を得るのか個人的には楽しみであり、どれに絞っていこうか、と悩むところでもあります(^_^;;。私としては、PhysXに焦点を絞ろうかなと（ソフトウェアonlyでいくと、ODE愛用ですけどね。速度に関しては、PhysXのソフトウェアのほうがODEよりも速かったです。これもまたテストせねば）。

PhysXの開発元であるageia社自身は まだ日本語ドキュメントを出すキャパはないようでしたので、当分は英語で調べなきゃ・・・（でも、サンプルソースがあるのでそんな難しくはないのですが）。

CEDEC 2006の感想（2006/09/01）

３日間、CEDEC 2006で講演を聞いてきました。主に物理演算関連に興味があったのでこれを中心に、Vista+Direct3D10、Game Programming Gems5の情報など講義を受けに。

物理演算ではHavok FX(GPUでの物理演算)とPhysXの両方を聞いてきたのですが、なかなか濃くて面白かったです。私が現在一番興味を持ってる分野（＜にわか）でもありますので、PhysXは真剣にいじってみようかな、とか思ったりしました。

http://www.4gamer.net/

の「CEDEC 2006＃09」がPhysXについてのレポート、「CEDEC 2006＃11」がGPUによる物理のレポート、ですでに記事があがってますね。

Gems5の講演は「早送り」ということで内容を高速でひたすらスピーカの方がしゃべり続けるというもの。なんというか、参考になりそうなものが結構あるみたいで購入しようかなぁと考えてます（特に物理系が充実してそうなので）。

Direct3D10とVista関連のは、MS社の川西さん（DirectX関連、Gemsの監修などで著名な方です）が話されてました。「Direct3D 10 Shader Workshop」に参加したのですが、内容をよく読まずにタイトルだけで受講した私としては少しあせった内容。１人１台のマシンがある環境にて授業形式でDirect3D10のシェーダーのお勉強をする、というセッションでした。受講スキルが「HLSLのシェーダーを書いたことがある方」ということで当日初めて知りました(^_^;;。＜ちゃんと確認しとけよ、ワシ（汗）

幸い、私はHLSLはいじっていたので内容はよく把握できたのですが、もうちょっとじっくり追いかけてみたかったなぁと。一部だけみてプログラムをちょっと書く、というのにはどうも抵抗があるたちでして、全体的にソースを流し読みしたりしてましたが全部は見れませんでした。しかし、その場でプログラムを授業形式で書くってのは新鮮ですね。よく考えると、プログラムはすべて独学（といいつつ、最近はネットでサンプル拾ったり解説を読んで理解したりしてますが）なもんで教えてもらったり授業で受けたりなんてことはなかったですし。

しかし、Direct3D10で何ができるのかというのはよく把握できました。ジオメトリシェーダーってディスプレイスメントマップにも使えそうじゃないすか、と思ってたのですが、最終講演のホールでのVista + Direct3D10 + Windows Presentation Foundationの講演にてサンプルで見せてくれてました。でも、Vistaは結構ハードウェアスペックが要求されますねぇ。

で、３日間で受講料4万円分以上の知識は得られたかなと。半分は仕事で使える知識、半分は趣味の延長で聞きたいもの、だったわけですが(^_^;;。正直なところ、受講料を払ってのセミナーっぽいのはあんまり知識が得られない、という偏見があったもので（実際過去そんなのに参加したりもしました）期待せずに軽く受けたのですが・・・。CEDECの場合は「理解していること前提」で話をどんどん進めるセッションも多かった気がします。これは私には新しい知識として有益な情報になった気がします。しかし、参加されてる方も講師の方もレベル高い方が多いなぁ。いい時間をすごさせてもらいました。

裏（打ち上げ）にも参加してきました。ということで、みなさまおつかれさまでした。さて、溜まっている仕事に取り掛からねばっ！