!!!独り言日記 !!地球シミュレータ（2006/10/29） テレビでちらっとやっていたので「へぇ〜」と思ってみてました。 http://www.es.jamstec.go.jp/esc/jp/index.html やっていることは格子に分割した仮想的な地球での 風や海のシミュレーションみたいですが（グループが細かく分かれているので それ以外もいろいろ研究してそう）、じゃあ格子分割数はいくつ くらいなんだろう？と気になってしまいました。 参考までに地球の直径はというと、Wikipediaより「12,756.3 km」 http://ja.wikipedia.org/wiki/%E5%9C%B0%E7%90%83 以下のページにて「5.5km間隔という細かい格子で全体を分割し」 という文章がありました。 http://www.es.jamstec.go.jp/esc/jp/publications/esnews.html 以下のページだと「地球内部を54億個の格子点に分割し（格子点の間隔は、地球表面で約2.9km）」と書いてますね。ということは、実行するプログラムによって 実装を変えられるのかな。 http://www.jamstec.go.jp/jamstec-j/PR/0312/1205/ 図もありますが、地球表面のみを分割して管理しているみたい。 地球全体を囲む立方体を単純にXYZ方向に分割するわけではないようです（だと、 無駄が多すぎか(^_^;;）。 上のページでは地球を6 x 18 x 18のブロックに分けて（6は、立方体としてみた ときの各面の数かな？）、さらにブロックを48x48の格子に分けているみたいです。 ・・・ん？高さは考慮に入れなくてもいいのかな？これがちょっと気になりました。 二次元での流体計算？ 上のページは地震シミュなので、台風とかの場合は高さも考慮するのかもしれませんね。 3DCGでは当然ながら三次元表現で行う必要があるため、 さらにメモリ（地球シミュレータではその概念があるかすら分かりませんが） と並列数はいるかもしれませんね。う〜ん、素人ながら考えるのは 基本はPCで行うような流体計算を、さらに解像度の高い格子分割数と並列性を高めたのが地球シミュレータかな、と思った次第です。 意外と3DCGプログラミングとやってることは近いのかもしれません（私はまだまだ理解できてませんが(^_^;;）。 !!RealFlow（2006/10/28） http://www.nextlimit.com/realflow/ http://www.web3dnews.org/modules.php?name=Content&pa=showpage&pid=80 なんかを読んでみると、パーティクルベースでも流体っぽいですね。 PhysXのサンプルでも似たようなのがあったのですが、レンダリング次第（反射とか透過を入れたり）ではそれっぽくなるのかな？ 普通の球での剛体による衝突とは分けて考えたほうがいいのかも。 しかし、このへんは掘ってみると面白そうですね。 !!流体（2006/10/27） 球のパーティクル衝突を使った流体っぽい表現（PhysXのサンプルにあるようなもの） を試してみたのですが、流体らしくないのが目についてしまいました。 動きについては、一般的な流体力学を取り入れたほうがいいですね（オフラインonlyになってしまいそうではありますが）。 後、パーティクル球の表現（レンダリング時にはmarching tetrahedraを使用）だと、 空間の分割サイズを小さくしないと他の障害物との接触部分ではみ出てしまうため、 流体表現に関しては実用的ではないように感じました。 フェイクならそれでいいのですが、もっと精度がほしいです。 もっと上流工程から掘るか、ってことで流体ですが「日本流体力学会」というのがあるんですね。 http://www.nagare.or.jp/ どのような流体の表現アルゴリズムがあるのか、と思って調べてみたら http://www.nagare.or.jp/jscfd/j-jscfd/113/113p4.pdf が比較的分かりやすかったです（日本語で流体アルゴリズムに関する歴史を解説されてますので）。 「SOLA-VOF」は知っていたのですが「MARS」という手法もあるんですね。 両方とも三次元格子を元にした表現ではあるのですが、前者は「SLIC（Simple Linear Interface Calculation）」と呼ばれ、MARSは「PLIC（Piecewise Linear Interface Calculation）」という種別に分かれるみたいです。 論文を読む限りは、格子にとらわれないようにスムージングするのがPLIC系、と いったところでしょうか。 格子表現を使うのはイメージはわくのですが、なんというかメモリはやっぱり 食いそうではありますね。 !!大神のサイトにて（2006/10/26） 一部のBGMがレトロバージョン（PSGっぽい感じ）で公開されているのと その楽譜がダウンロードできるようになってますね。 http://www.o-kami.jp/ 上記のレトロシリーズでGetできます。アレンジもいいなぁ。 しかし、クローバースタジオが解散とは残念。 ひさびさにいいゲームとしての大神に出会ったのもあって、 今後に期待していたのですが・・・。 !!ドキュメント（2006/10/26） このサイトもページによってはものすごい重いので、もうたまらん、 ということで徐々に修正することにします。 原因は「FreeStyleWikiによるrefによるファイル添付」です。 これを外部に出してしまって、それをURL参照するようにすると ずいぶんとマシになりました。 とりあえず、[[Shade]]の部分が重かったのでここの添付ファイルを すべて置き換えました。 仕事場でも3DCG（というかレンダラ開発）などを将来的に広めていくという 可能性が出てきたので、3DCGプログラミングやその他もろもろ、早めに 更新したいですなぁ。 技術的なTipsドキュメントをひたすら書く仕事（それに投資してくれる 太っ腹なエンジェル）ってないんだろうか・・・、 分かりやすいかは置いておいて大得意ではありますが(^_^;;。 しかし、今はなかなか仕事じゃないといろんなことを進める気力が出てこない、 というのは甚だもったいないかなぁと。 今持っている知識は一度じっくりと腰をすえてまとめたいもんです。 自分ではこれとこれはできるけど、他の人には難しすぎて振れないから、、、 ってことで仕事ではキャパをなかなかアピールできなかったり 一人で抱え込んでしまわざるを得ないってのは打開したいところ。 このサイトでは仕事場のことはあえて書かないようにしているのですが、 今年はいろいろ幅が広がりました（というか、人が増えました）。 そういや、会社のサイトも更新しないとね（正直、HTML書くのめんどくさい(^_^;;。あぁ、Wikiは楽だわ・・・）。 !!リファクタリング（2006/10/18） 仕事のソースの構成が気になったので整理していたら結構いろいろ 直したいところがあって、結局安定させるまでに時間がかかってしまいました。 おかげさまで前よりは見やすくなりました。 しかし、なかなかスタイルというか「これで完璧！」というところまで はじめっから設計する（後々で修正を入れない）のは難しいですねぇ。 数ヶ月前の自分のソースでも後になってから整理したくなります。 とかいろいろ考えると、私にとっての作品作りはプログラムかな、と。 Poserの作品をいろいろ見て回ったりしてますが、 髪の毛の表現ってPoser独自のヘア機能（ヘアルーム）を使ってないものが結構あるように 感じました。あれって何で作ってるのだろう？ ポリゴン化しているところから見て、メタセコでモデリングしたりしてるのだろうか？ こちらのDigital Babesさんの髪品質が非常にきれいです。Poser界では有名なサイトのようです。 http://digitalbabes2.com/ 髪データもダウンロードできるのですが、ポリゴンで表現されてますね。 スペキュラもテクスチャに描いてますねぇ。いやはや、勉強になります。 !!スパムメール（2006/10/17） 毎日50通以上はスパムメールが来るのですが 気になったものがあります。 「○○さん、はじめまして(>_<)」 なんていうSubjectのスパムが来てたのですが、○○の部分は 私の名前です。この系統のが複数（すべて同じfromのメールアドレスでした）。 ランダムで名前を選んでいるだけならいいのですが・・・ （とはいえ、私の場合はネット上でも本名で活動してますので探せばすぐ分かりますけど）。 もしかしたら、どこかの登録した際のユーザリストが 漏れてる可能性も捨てがたいです、、、 企業は特に、個人情報の管理は注意しましょう。 Poser5Jをダウンロードしたときに登録したコンテンツパラダイスが 原因か、とか思ったのですが、それ以前でも１件ありました（といっても１日前から）。でも、その時期には登録したものって何もないなぁ。 さてはて、原因はどれだろう？ !!Poserのヘア表現のアルゴリズムを掘ってみる （2006/10/15） 本を参考にPoserのヘア機能を掘ってみました。 平面の板を3Dアトリエで作成し、それをインポート。 Poserはポリゴンモデラーと相性がいいですね。無駄な頂点があるといろいろ 困るので正しい形で出せるものが好ましいのかもしれません。 でおもむろに毛を生やす準備を。ガイドラインは、どうやら頂点に１つ、 ということのようです（なんで無駄な頂点があると、１頂点から複数のガイドが 出てしまうことになり よろしくないです）。 {{ref_image poser_hair_20061015_00.jpg}} これをわざと太くしてレンダリングしました（根元と毛先の太さを変えられるのは、懐かしのShadeでのMarimoと同じです）。 {{ref_image poser_hair_20061015_01.jpg}} 影ですが、どうみてもシャドウマップですね。で、影の表示・非表示のパラメータは ライトごとに設定ができ、「レイトレース影」にすると毛の影は落ちなくなりました。 ということは、これでアルゴリズムが判明。 毛のポリゴン化はしていない、ということになります。線として描画している、もしくは線部分のビルボードとしての一枚板で描画している、の理論でたぶんOK。 毛のガイドを元に実際の毛を指定本数分補間します。大量にはやしてみました。 {{ref_image poser_hair_20061015_02.jpg}} ということで、毛のテストとしては定番（？）のティーポットに生やしてみる、です。 たとえば、１三角形で３頂点費やすという無駄な形状の場合は、 いくら生やす毛を多くしたとしても、以下のようになりポリゴン内部にまで 毛が浸透しません。 {{ref_image teapot_20061015.jpg}} 頂点はきっちりマージしてやると、以下のようにうまくいきます（Poser内部ではこれはできない？）。 {{ref_image teapot_20061015_2.jpg}} ちなみに上のティーポットはShadeからDXF出力したもの（三角形はバラバラ）をPoserに取り込みました。 下はそのDXFを一度3Dアトリエで読み込んで（頂点のマージが行われたものを）改めて DXFとして出力してPoserに読み込んでいます。 !!Rhapsody OF FIRE （2006/10/15） ライトなヘビメタ野郎にはおなじみのRhapsodyが、 いつのまにか「Rhapsody OF FIRE」に改名してアルバム出してました。 ということで「TRIUMPH OR AGONY」（英語版）を購入。 Rhapsodyは、というかファンタジーを題材にしたメタルものは RPGの戦闘BGMっぽいですね。Blind Guardianしかり。 で、メタルで共通しているのは、バラード曲はやたら民族音楽っぽいというのがあります。 Rhapsody OF FIREはこの傾向が強いですね。 後、Poser5Jがなかなかいじっていて面白いので もっと知識を深めたい、ということで「POSER Figure Studio」という 本を買ってしまいました。3つほどPoser関連の書籍があったのですが、 Poser5用のはこれだけだったのと、一番分かりやすいと感じました。 本を読むと・・・こりゃ髪はポリゴンではなくて線として描画してますな。 エフェクト処理（だけどレンダラと絡めている）っぽい絵柄がありました。 影については、レンダラ設定にてレイトレ影とシャドウマップを選べるようです。 !!Poser 5J （2006/10/14） 10/19まで無料でダウンロードできるようになってましたので、 早速ダウンロードして遊んでみました。 http://www.contentparadise.com/jp/user/static.php?jp_poser5free かなり昔に体験版を使ったことがあるのですが、よもや製品版が フリー公開されるとは。 髪の毛を作る機能・クロスがいかしてますね。操作性がちょっと難しい気がしますが・・。おおざっぱにスタイリング、ってことなのかな。 ところで、この髪って後処理描画なんだろうか。レンダリング処理経過を見ると、なにかしらの変換処理（毛のポリゴン化？）が行われてるようにも見えなくもないなぁ。 で、DXFで出力して他ソフトで見てみたのですが、髪は吐き出されてないですねー。 いろいろフリーデータも出回っているみたいですので、デフォルトの あめりかんなモデルじゃなくて日本人好みのものを探したり コンテンツパラダイスで買い物するのも面白いかも。 しばらくはこれにはまりそうです。 ライブラリより、体と髪の毛を入れてレンダリングしてみました。 レンダリングだけで15分くらいはかかってます。 これくらいの毛の量になると、プレビュー時の移動・回転処理がつらいです(^_^;;。 {{ref_image HairTest_20061014.jpg}} 髪の毛はおそらく自分でスタイリングしても作れるはず。 なんとなくですが、前処理のメッセージとレンダリング後の画像を見てみると 、シャドウマップを先に生成している感じですね。 毛の太さの表現を見ると、エフェクトがどうか分かりやすいのですが はたして毛を描いているのかポリゴン化しているのか・・・。 ポリゴン化してるとすると、１本１本をこまめに変換してそうではありますね（時間がかかるのから推測すると）。 しかし、フリー状態でこの品質が出るのはすごいですねぇ。 Poser7が発表されているのでその布石なのかな。 http://www.e-frontier.com/article/articleview/1970/1/823 ちなみに、自由度がベラボーに高いオンラインゲーム（といえるのかな？ゲームじゃないかもしれない・・・） のSecondLifeではPoserのデータ（モーションデータだけかな？）を読み込めるみたいですね。 http://secondlife.com/ 日本語版ももうすぐ公開とのこと。 !!Implicit Meshes （2006/10/12） PhysXのドキュメントでは流体表現で「Implicit Meshes」を使ってる文章があるのですが、これってアルゴリズム名そのものなのでしょうか？単なる「内包メッシュ」的な一般用語かと思ってたのですが。 http://cvlab.epfl.ch/research/body/upper/index.html も、もしかして輪郭検出に使えるのかな？ これは夢が広がる・・・・。前にやったDirectShowでのWebカメラ関連でぜひ取り入れたい・・・。しかし、技術ものをあさると「あれもしたい、これもしたい」病が出てしまう・・・。 !!marching tetrahedra （2006/10/12） marching cubesに変わる、特許の絡まないアルゴリズムを調査。 教えていただいた「marching tetrahedra」がクリーンなものかどうか 調べてました。 以下にやりとりがありますが大丈夫そうです（他のサイトでも同じように、 marching cubes特許の問答がありました。やっぱりみんな考えることは同じか(^_^;;）。 http://www.gamedev.net/community/forums/topic.asp?topic_id=333107 では、「marching tetrahedra」ってどんな理論なんでしょう？ 以下、そのアルゴリズムを解説したサイトです。 http://local.wasp.uwa.edu.au/~pbourke/modelling/polytetra/ http://s94694854.onlinehome.us/projects/ucsb/graphicsProject/ なんか、そのままですね(^_^;;。 考え方はmarching cubesと同じじゃないの（接触しないの）？と思ったりしたのですが、 http://www.siont.com/Marching-Tetrahedra-and-patent-issues-5539320x637.htm を見ると、「なんかmarching cubesと似てるんだけど、どうよ？」「問題ないんじゃね？」みたいなやりとりに伺えますのでOKかな。 で、このサイトで「AFAIK」という単語があって翻訳でも出なかったのですが「私の知る限り」という俗語のようです。へぇ、英語って面白いね。 !!marching cubesの特許（2006/10/11） marching cubes法に関して貴重なメールをいただきました。 どうやらmarching cubes法は特許を取られているらしく、1987年からGeneral Electric 社にて守られているようです。 結構スマートなアルゴリズムなのでいろいろ応用できそう、と喜んでいたところでは ありますが（汗）。 http://www.exaflop.org/docs/marchcubes/ の「What is the status of the patent on the "marching cubes" algorithm? 」に書いてましたね。英語読めないのはつくづくいかんな、と思ってしまいます。 MCでの256パターンのポリゴンテーブルが完成したので、早速実験してみました。 作成した形状をShadeで取り込んで、ワイヤーフレームでレンダリングしました。 {{ref_image mc_metaball_20061011.png}} 左が20x20x20グリッドで分割したときの補正なしのメタボール表現、 右が同じく20x20x20グリッドで分割したときの頂点補正を行ったメタボール表現です。 スムージングもしているのですが、実は微妙なデコボコができてしまってます（たぶん、頂点補間でしくってるかも）。 と、ググってみたらすでにソースごと公開しているサイトがありました。 全部自前でやる必要もなかった・・・。 http://local.wasp.uwa.edu.au/~pbourke/modelling/polygonise/ 個人で遊ぶ分にはMC法は使えるのですが、仕事とかでは 特許の都合で使えないですね。さて、話を戻して、、、ではPhysXの流体では 別の方法で実装してるんだろうか・・・。 !!marching cubes viewer（2006/10/10） 256パターン（といっても半分は反転なので128パターン）の marching cubesのポリゴンをチェックするために、 ノートにセコセコ組み合わせを書いていたのですが、回転してみないとどこがどう つながっているのか訳分からん状態になってきました。 ということで、効率化するためにwxWidgetsでビュワーを作成。 {{ref_image MCView_20061010.png}} しかし、wxWidgetsの使い方を忘れてますな、開発に半日もかかってしまいました。 でもこれで間違いなく実装できるはず。 はやく流体っぽい表現まで到達したいもんです。 !!marching cubes（2006/10/08） marching cubes法（以下MC）での実装方針は固まりました。 ノーマルなアルゴリズムでは作成するグリッドのゴツゴツが出てしまうのですが （セルの辺の中点を採用するため）、 改良することでスムーズな構成にできそうです。 まぁ、以下の実装をするわけですけども。 http://www.exaflop.org/docs/marchcubes/ で、MCにてボクセルからポリゴンを作るには2^8=256パターンを 考える必要があります。基本の15パターンから 回転や反転させるアルゴリズムを考えるよりも実際に列挙してテーブル化 したほうが頭も使わないので楽かな、ということでノートに 立方体を書いて点を打って中点をもとめてポリゴンインデックスを書き溜めてます。 たかだか256パターンしれてるだろう、ってことで。 いずれにせよ、高速に処理させるにはあらかじめ256個のパターンを メモリに保持しておく必要がありますね。 連休中にMC実装できるかな。 しかし、ドット絵を16進数に直していく作業みたいで、、、懐かしい作業です（＜MCのポリゴンのテーブルを作る）。 !!メタボールとmarching cubes（2006/10/06） PhysXで流体的な表現ができるのですが、 そもそもいわゆるメタボール的なものをポリゴン化するには どうすればいいのだろう？というのが分かりませんでした。 で、ググってみました。 http://www.syuhitu.org/other/meta/meta.html このサイトを参考に実装してみたのですが、 融合部分の品質がどうしても低くなります。 このアルゴリズムではきれいにというのは難しそうですね（というか、これを 掘るのに１日費やしました(^_^;;）。 で、次に「DigiMeta」というので遊んでみました。 http://www.studio-pon.com/jp/products/digimeta/features.html ほう、これはきれいです （Shadeのメタボール（メタポリゴンのほうね）は、なんかもっと汚な・・・、と 失礼しましたm(_ _)m）。 で、ここにずばりアルゴリズムが書いてありました。 ボクセルでポリゴンを生成すればいいらしい。 で、思い出しました「marching cubes」です。 これは、濃度分布などを視覚化するときに使えるのですが、 これを使うとメタボールもきれいに出るではないか、と。 ワイヤーフレームではありますが、以下にJavaのアプレットとソースが ありました。 http://drumsoft.com/hrk/visualization/ で、海外のサイト。 http://www.exaflop.org/docs/marchcubes/ もうここまで来ると答えは見えてきましたね。 流体系もこれでできそうな予感です。 今ちょっと話題の流体のすごいCGのサイト。 http://www.flowlines.info/ ムービーはただただスゲーの一言です。 波の欠けている部分（妙に規則的なグリッドにも見えます）からして、 これもmarching cubesで仕上げてるんでしょうかね。 !!PhysX SystemSoftware 2.5.1 ==> 6.09.28（2006/10/05） PhysXのドライバは6.09.28（2006/09/28バージョン、2.6系？）が公開されています。 http://www.ageia.com/drivers/drivers.html 2.5.1のSDKとドライバで試したところ、2.5で追加された新機能 「Hardware Scene Manager(HSM)」がハードウェア使用時に 極端に遅くなる、というのが直ってるように感じました。 後、4000個のアクターも2.5.1のドライバでは4000アクター発生付近で エラーが出る部分があったのですが、6.09.28では4000個でも 安定していました。 !!PhysX SDK 2.5.1（2006/10/05） いつのまにかダウンロードできるようになっていたので 試しています。 いろんなものが修正されているようです。 ハードウェアでの剛体（アクター）の最大数が、2.4.4では2000個強まで しか生成できなかったのですが、倍の4000個強生成できるようになっています。 また、ソフトウェアでの最大は（数万アクターで落ちていたバグが2.4.4ではあったのですが）64Kまで可能なようです。 Supported ・Compound shapes (multiple shapes attached to an actor) やりました！！複数形状で１アクターを構築するのがハードウェア対応しています。 ほか、いろいろリミッター解除って感じで改善されてる予感です。 しかし・・・今までのソースがハードウェアを使用すると動かん・・・・。 ちょっと調べてみなければ。 でも、ようやく2.5系でハードウェアを生かし切ることができそうですね。 !!1つのアクターに複数のshapeを割り当てる（2006/10/04） PhysXSDKにて、 NxActor *pActor; NxActorDesc actorDesc; NxBodyDesc bodyDesc; NxBoxShapeDesc boxDesc; actorDesc.setToDefault(); bodyDesc.setToDefault(); boxDesc.setToDefault(); bodyDesc.angularDamping = 0.5f; boxDesc.dimensions = NxVec3(10.0f, 10.0f, 10.0f); actorDesc.shapes.pushBack(&boxDesc); actorDesc.body = &bodyDesc; actorDesc.density = 1.0f; // 質量密度(kg / m^3) actorDesc.globalPose.t = NxVec3(0, 10, 0); // ワールド座標位置 pActor = g_pScene->createActor(actorDesc); な感じにして、ボックス形状をアクターとして物理空間に追加するわけですが、 「actorDesc.shapes.pushBack(&boxDesc);」としている箇所のshapesはNxArray型で NxShapeDescポインタの配列になっています。 このときに、 NxShapeDesc *pShapeDesc; NxBoxShapeDesc boxDesc2; // 1つめのボックスをプッシュ boxDesc.setToDefault(); boxDesc.dimensions = NxVec3(10.0f, 10.0f, 10.0f); actorDesc.shapes.pushBack(&boxDesc); // 2つめのボックスをプッシュ（boxDescは使い回せない模様） boxDesc2.setToDefault(); boxDesc2.dimensions = NxVec3(8.0f, 8.0f, 8.0f); actorDesc.shapes.pushBack(&boxDesc2); // 2つめのボックスのローカル位置を変更 pShapeDesc = (NxShapeDesc *)actorDesc.shapes[1]; pShapeDesc->localPose.t = NxVec3(-5.0f, 5.0f, 0.0f); みたいにして、配列要素を取得して「pShapeDesc->localPose」のように NxMat34に値を指定することができます。 これで、１アクターに複数のボックスなり球を合成することができます。 トライアングルメッシュ対応できない場合は 複数OBBなりで形状を表すことでハードウェア対応できるか、と思ったのですが・・・ はい、ハードウェアでの制限事項です。 Not supported ・Compound shapes (multiple shapes attached to an actor) 意外とハードウェアでできることが限られているなぁ(^_^;;。 複雑な形状を衝突させたい場合でも、ハードウェアの恩恵を受けるには 球・ボックス・カプセルなどの単一プリミティブで囲うような構成じゃないと いけないようです。Convex Meshesも可能なようですが、32頂点・32面まで。 ソフトウェア・ハードウェアに完全対応するゲームを作るとしても、 現状は特殊効果としての物理演算のみ実装、という規模でしかできないのかも ですね。PS3とかXBOX360ではどうなんだろう・・・。 意外と前処理演算の物理シミュもどきのほうが、実装も楽だったりして(^_^;;。 !!PMapsとConvex Meshes（2006/10/04） PhysX SDKのドキュメントより。 「PMaps are no longer a recommended collision primitive and in future support may be dropped.」というのがありました。 ようは、お勧めできないし将来消すかもね、ってことのようです。 どうりで使い勝手が悪いわけだ・・・。 今まで謎だった「Cooking」というものは、ポリゴンメッシュを構成する 頂点と頂点インデックスを渡すと、それをPhysSDKで扱えるような形に コンバートしてくれる機能のようです。 その他「Convex Meshes」というのがあるのですが、直訳すると「凸メッシュ」です。 bunnyで試してみたのですが、こっちのほうがいいですね（初期化も発生しませんし、なによりも構築が簡単）。 残念ながら、やはりハードウェアには対応できませんでした。 {{ref_image physx_trimesh_20061004.jpg}} 80 bunnyで物理演算のみの計算時間は1フレーム8-12msほど。OpenGL描画も加えて16msほど。ちなみにODEだとこれくらいすると100ms/フレームは軽くかかってしまいます。 上記キャプチャのサンプルプロジェクト（ソース込み）一式（382KB）： [PhysXTest2_src_20061004.zip|http://ft-lab.ne.jp/files/physx/PhysXTest2_src_20061004.zip] 実行には、PhysX SDKでの「glut32.dll」「NxCooking.dll」が必要になります。 CookingSDKに一度形状情報を渡す必要があるのですが、この部分は関数で まとめてしまって再利用できるようにすると、ODEのようにすっきりするかも しれませんね。 片面だけで閉じられていないポリゴンメッシュの場合はどうなるのだろう（たとえば、半球の皿にて球を受ける、とか）？ なんとかハードウェアにて衝突判定できるように簡易化できないか（OBBの集まりで表現するには）、などなどまだまだやることはありそうです。 !!PhysXでのハードウェア制限部分（2006/10/03） 改めて掘ってみたのですが、ドキュメントに「TheAGEIA PhysX hardware currently supports a maximum of 3 concurrent scenes. Each scene can hold up to 2048 (D6) joints and 2000 actors. 」の文章がありました。 2000個強のアクター制限はどうやらこれっぽいですね。 ハードウェアごとに違うのではなくて、全体的にこの制限はある予感です。 後、致命的に思ったのがトライアングルメッシュの扱い。 「The hardware support a maximum of 32 faces and 32 vertices for convex mesh objects.」ってほとんど何もできないような(^_^;;。ページングがうんたらの断り書きがあったので、何かしら回避策はあるのかもしれませんが・・・ {{ref_image physx_20061003.jpg}} 上画像のような形状が全部トライアングルメッシュで衝突判定したい場合、ハードウェアが活用できないのはちとつらいなぁ。 （ボックスで囲むようにすれば問題ないわけではありますが・・・ 軽い部分にてハードウェアを果たして使う必要があるのかどうか・・・） PhysX SDKのソフトウェアでも上記くらいならリアルタイムで衝突判定できるのですが、 どうもこれの（高速化の）種明かしが「PMap」という仕組みのようです。 前処理で計算したおそらくアタリ判定用の情報がPMapと呼ばれており、 これをトライアングルメッシュに割り当ててます。 このPMapの計算・構築時間がbunnyの場合は10秒くらい待たされます。形状が特定されているもの（あらかじめPMap情報をファイルとして保持できるもの）であればいいのですが、ダイナミックに生成された形状を使う場合はどうなんでしょうね。 なんとな〜くですが、レンダラで言うPRTみたいなもんか、と思ってしまいました。 「PMap以外」の文章もあったので、速度は落ちるけど前処理はいらない、という回避策があるのかもしれません。 でも、PMapを使ったらハードウェアの恩恵は受けられないような気も（まだ詳しくは掘ってません）。衝突判定でハードウェアを使いたい場合は、静的な平面と動的ボックス・球・カプセルでいくのが無難なのかな(トライアングルメッシュは無理っぽい)。 結果として、トライアングルメッシュは明らかにODEのほうが扱いやすいと感じました。 PhysXのトライアングルメッシュは初期化が複雑ではありますね。 ところでBunny形状、ODEとまったく同じ頂点座標・ポリゴンの頂点インデックスを 使用してました。 物理処理用のStanford Bunnyでもあるのかな。 !!FreeStyleWikiが重くなる原因（2006/10/02） ファイル添付をしていて原因の１つが分かりました。 refでファイル添付してそれを参照させると、そのファイルサイズ分の 読み込みがHTMLページ作成時に発生しているような予感がします。 とりあえず、下記のファイルリンクはWikiからでなくてURLで参照できるように しておきました。 !!Bunnyプラグイン（2006/10/02） テスト用の形状が急遽必要になったため、 Shade8.5にてバニーちゃん生成プラグインを小一時間で開発してみました。 Shadeで作ったら、後はここからDXFなり他の形式にはき出せますので 便利かもしれません。 CreateBunnyプロジェクト（ソース）一式(405KB)： [CreateBunny_src_20061002.zip|http://ft-lab.ne.jp/files/shade/CreateBunny_src_20061002.zip] CreateBunnyのWin/OSXのプラグイン（バイナリ 100KB）： [CreateBunny_plugin_win_osx_20061002.zip|http://ft-lab.ne.jp/files/shade/CreateBunny_plugin_win_osx_20061002.zip] 詳しくは解凍後のreadme.txtをご参照ください。 さくっとサンプル形状が作成できないものか、 球や直方体では話にならんわ！というせっかちさんにはうってつけです。 好きな位置・好きな大きさでまるで球を作成するかのごとく、 バニーちゃんを複製できます。 {{ref_image bunny_20061002.jpg}} 形状はODEのサンプルソースから座標と頂点情報を持ってきてます。 思うんですが、Shadeって直方体（というか基本プリミティブ）作るだけでも 手間がかかりますよね。 初心者としては、さくっと基本形状はできてほしいなぁ、と思ったりもします。 ちなみにOSX版はプラグインをビルドはしたものの、動作チェックはしていない シロモノだったりします（動作するかどうかは不明）。 使われる場合は、適当にソースリビルドしてくださいませ（Xcodeはタダですので、誰でもできるはず、という他人任せ(^_^;;）。 !!dWorldSetContactMaxCorrectingVel（2006/10/01） ODEでのすり抜け問題を解決する方法として、どうも「dWorldSetContactMaxCorrectingVel」がキーになりそうです。 この関数は、オブジェクト同士が接触した場合の反発する（接触時の進行方向と逆向きの）速度を指定するものです。 めり込んだ場合の補正もこれを利用するみたいです。 すべてのシーンで同一の値を割り当てます。 デフォルトでは無限大になりますので、通り抜けは起こりません。 が、これに大きい値を指定していると、普通に接触している積み上げた 直方体も反発しあって飛び散ってしまいます。 うまいこと調整して適値を指定してあげるのがいいのか、別の方法で 接地に関しては飛び散らないようにできるのか・・・。 !!暴れる剛体（2006/10/01） 以前の日記にて、すり抜け問題を解決するために ODEのトライアングルメッシュを両面対応すればどうだろう、 と思って実験してみたのですが・・・、これはいけない！ 衝突したとたんにオブジェクト同士が激しく暴れます。 よくよく考えると面の法線を見ているようですね。 ソースを追うと、衝突時にのめりこんだ他オブジェクトを押し出すために 法線を計算して処理に利用してました（トライアングルメッシュを生成するときに、 明示的に法線を指定することができます。指定しない場合は、衝突判定時にその都度法線計算をしていました）。 それで、仮に両面があるとすると、押し出して面を境にして反対側にいった、 けど裏面でも判定するのでまた元に戻ろうとする、 と、結果的に激しく動くことになります。 結局は、トライアングルメッシュは中身が詰ってなくて 張りボテで判定してるんでしょうね。 面の向きはきっちりとオブジェクト構築時に片面にしてあげる必要がありそうです。 で、これでもすり抜けが起こることがあります。 原因はというと、他のオブジェクト同士に挟まれた場合に行き場を失う、っていうのが ありそう。 半球上の皿（トライアングルメッシュの物理衝突オブジェクト）に球をドボドボ落としていったのをテストしてみたのですが（画像が見せられなくてすみません）、下のほうに溜まった球が皿から「漏れる」というのが発生。 トライアングルメッシュは１枚板ですので、下向きの押し出す速度が大きくなってすり抜けたのかなと推測。 ODE本体を修正しなくても改善は可能かどうか、、、トライアングルメッシュの面を「またいだ」というのを監視して法線方向に押し戻す、というのを実装してみようかな。 PhysXではCEDECでの説明会にて、このあたりの問題はずいぶん気にしていたようで改善はしている、と聞きました。ODEでもアップデート情報のテキストを見る限りは「Added program to test trimesh vs sphere」があるので、何かしら気には留めてるのだと思いますが・・・。 ちなみに、トライアングルメッシュと直方体の場合はすり抜けが起こらないんだよなぁ。トライアングルメッシュ vs 球が鬼門なんだろうか・・・。