!!!独り言日記 !!OPTICORE OPUS Realizer（2007/06/28） 「産業用バーチャルリアリティ展（IVR展）」というのがビッグサイトにて開催されてまして、ナイスなソフトウェアを見つけました。 OPTICOREの「OPUS Realizer」というソフトで、リアルタイムレイトレーシングを行ってました（Autodeskのブースにて）。 http://www.opticore.com/ 16コアのマシンで力業でやってましたが、GIにも対応。さすがにリアルタイムにGIを行うわけではないのですが、レイトレでぐりぐり動かした後に数秒待つとGIの結果が出てくるというもの。プレゼンで使えるツールとのことでした。 オールCPUでレイトレしている、というのも好感を持てますが、さすがにコア数が半端でないので、まだまだ普及するのは先の話でしょうね。 かなり処理をはしょっているため、映画とかではリアルタイムのOPUS Realizerは厳しいということを言ってました。 他もなかなか面白かったです。CAD/CAM関連は去年よりも輝いているように見えました（先月くらいのソフトウェア開発産業展は、縮小の感じが見えてのですが）。明日06/29まで開催中ですので、近場の方は見に行くのも面白いかもしれません（ただし、仕事の交渉のためのイベントなので学生は不可。名刺があればいけるかもしれませんが）。 !!lucy（2007/06/26） 829046ポリゴンのlucyをShade9.1でレンダリング。ここまでたどり着くまでが苦難の連続でした(^_^;;。実際は仕事場にて試行錯誤してもらっていました。 {{ref_image lucy_test.jpg}} *1オブジェクトに追加できる頂点数、ポリゴン数に制限がある。環境によって変わる。なので、複数オブジェクトに分割するプログラムを書く（10個くらいに分割してます）。 *レンダリング時にメモリが足りない！！512MBだと無理、1GBでも無理。なので、2.5GBに増設。 *1回レンダリングすると、2回目レンダリングしようとしたら「メモリ不足です」と怒られることあり。以降はいくらレンダリングしてもダメなのでShadeを再起動。それでもダメなときもあり、OS再起動。 *「メモリ不足です」と出るので、カメラを微妙にずらすとなぜかいけた。 *途中でレンダリングを放棄してしまうことあり。原因は不明です（ちなみに上のレンダリングでは、残り1/5くらいを残して必ずレンダリングをやめてしまってました。なので、部分レンダリングで残りを再レンダリングしてます）。 上記の1つめのものは格納時の問題、2つめ以降はレンダラでの問題かなぁと思ったりもします。実際に仕事で使っている人の苦労が分かったというか、重い形状には弱い点がありますね。 ちなみに「メモリ不足です」の警告メッセージは、メモリ不足で出てるわけじゃないのではと思います。2.5GBのメモリを積んで1GBちょっとの物理メモリをオーバーしたときに出ていたですので。OSの出しているメッセージかなぁと思いますけど（6/19の日記のメッセージウィンドウが出ます）。 !!テストレンダラ調整（2007/06/24） テストレンダラを速度アップしました。 変更点は *空間分割のアルゴリズム変更（UniformGrid ==> kd-tree(spacial-median)） *メモリ周り *DXF読み込み {{ref_image TestRenderer_img_20070624.jpg}} Windows XP/Celeron 1GHz/Mem 512 MBの環境にて。 dragon.dxf（三角形総数 108590）にて、光源を2つ配置しています。 また、1ピクセルを4x4の解像度でアンチエイリアスしています。 ,---,UniformGrid時,kd-tree時 ,DXFからの読み込み,2784 ms,2223 ms ,三角形の格納,1802 ms,260 ms ,空間分割,200 ms,921 ms ,トラバース含むレンダリング時間,28672 ms,9604 ms UniformGrid時は空間分割の前処理は速いのですが、トラバースではkd-treeには劣るため、全体ではkd-treeのほうが3倍近く速くなってます。 「三角形の格納」がやたらと速くなっているのはメモリ確保を見直したため（malloc/reallocが極力発生しないようにした）。 ちなみにShade9.1のレイトレだと、このシーンにて16秒くらいでした。 Shadeよりは速くできますな、さすがはkd-tree。Shadeの場合は（上のシーンでは） 前処理で10秒近くかかっているので、その部分を高速化するともうちょっと速くなるかと思います。 !!続・Shade 9.1でのポリゴンメッシュはどこまでポリゴンを追加できるか（2007/06/22） せっかくなんで、Shade9.1にて1ポリゴンメッシュでどこまでポリゴン（三角形）を追加できるか仕事場で調べてもらったのですが、環境によって違うみたい。 また、頂点数も上限があるようでした。 その場合は、複数のポリゴンメッシュに分割して格納していくと物理メモリの空きがある限りは表現が可能なようでした（トータルで100万ポリゴンのシーンでもやろうと思えばいけるっぽい）。が、829046ポリゴンのlucyは、1GBのメモリのマシンではレンダリングをしたら一度Shadeを終了させて再起動しないと２回目以降のレンダリングはメモリ不足で不可能。結局メモリを増設しないとダメっぽいので、買ってこようかな。 これはちょっとした実験としてやってるものです（パフォーマンステストの意味合いもあります）。 ただ、こんだけポリゴン数が多いシーンだと、ツールによって性能の差が出るんだろうなぁと。負荷テストの素材としてはいいかもしれません。理想はオリジナルのlucyですが・・・、OpenGLでどこまでプレビューすることができるのだろう・・。うまいことバウンディングボックスやプログレッシブメッシュで管理するといいのかもしれませんね。 !!Shade 9.1でのポリゴンメッシュはどこまでポリゴンを追加できるか（2007/06/20） ようやく糸口をつかんだのでメモ。まず、先日の重い形状がレイトレレンダリングできない問題ですが、メモリ1GBのマシンでもダメでした。 スキャンラインでは行けたため、レイトレの空間分割でさばけてないようですね。でも、ヒープメモリというよりもスタック不足のような気もします。再帰で深く深くどこまでも自己呼び出ししてスタックを食い尽くしてるんだと思われますが・・・CPUはさほど食わずにメモリ不足になってるし。 ただ、奇跡的に１回だけレンダリングが出来てました。再現性が乏しいのからみても、再帰でのメモリか演算誤差っぽいっす。 別途、スキャンラインレンダリング確認してみましたがポリゴン欠けが発生してました。「レンダリングでメモリ不足」とは別の問題のようです。 まず、頂点は414541頂点すべてShadeに渡せてました。ただ、三角形（頂点インデックス）は829046個のうち538018個までは渡せていてそれ以降はエラーになってました。 「scene_interface::append_polygon_mesh_face」が、538018ポリゴン以上は格納できないのかな？と思って三角形の順番を入れ替えて入れてみてもやはり538018ポリゴンで例外処理に飛びました。 この部分はメモリに関係なさそうですので、どうやらShadeの一形状のポリゴン数（三角形数）上限は「538018ポリゴン」という疑いが濃厚です。おぅ、lucy（のポリゴン数少ないバージョン）が表現できない・・・。もうちょっとポリゴン数を増やさせてくれないですかのう・・・。もっとリダクションされたlucyを探すか・・・。 !!重い形状のレンダリング（2007/06/19） Shade9.1でやってみたかったのですが、、、メモリ不足。 下記はワイヤーフレーム表示なんですが真っ黒です(^_^;;。 {{ref_image lucy_20070619.jpg}} 414541頂点、829046三角形で空間分割にてアウト。今時メモリ512MBじゃあ厳しいのかなぁ。 stanford大学の「lucy」は1000万ポリゴンオーバーではあるのですが、これをリダクションしたデータがありました。 http://www-c.inria.fr/Eric.Saltel//download/affichage.php?dir=CHARPEOP&name=lucy3_cut_cut.d meshという形式だったので、インポータを作ってShadeに読み込んでみたけど、、、。 新たな形状の追加・削除がえらい遅くなりますね。OpenGLではかろうじてリアルタイムに回転とかできるのですが。う〜ん、メモリ買いに行こうかなぁ。 !!時をかける少女（2007/06/17） DVDを買ってきてみました。評判通りいいですねぇ、ひさびさに余韻を引きずる内容でした。学園青春ものは自分のツボだったり。 昔々にスーパーの家電屋のテレビにてドラマ版をチラッと見た記憶が鮮明に残ってたりします（それと主題歌と）。 Wikipediaで調べるとドラマ版は1983年ですね。ということは小学生低学年ごろか・・・。 このころ、我が家は白黒テレビだったはず。そのときの記憶と絡むものがあるので、その年代の人は時代とあいまって懐かしいでしょうねぇ。 ということで、DVDを買いに秋葉原にひさびさに行ってきまして、念のため物理演算ボードがあるか探してみました。・・・ないですね・・・結局流行らずに終わるのかなぁ。 後、DVDでは今敏監督の「パプリカ」も気になる（これも筒井康隆氏の原作）・・・・。洋楽でBlindGuardianのミニアルバムが出ていた、これも気になる・・・。Dream Theaterの新譜が・・・これも気になる・・・。と、物欲が果てしなくなるので、しばらくはおとなしくしておこう。 !!DXFImporter for Shade9（2007/06/17） Shade9のDXFImporter高速版をバージョンアップしました。 「[[DXFImporter|DXFImporter_shade]]」のページより、プラグインとソースコードをダウンロードできます。 後、Mac OS Xにも対応してみました。 *dxfファイルによっては読み込みが出来ない場合があったため、修正 *処理速度をわずかにアップ サンプル形状として「dragon.dxf(14,441 KB / 108,590 polygon)」。 Pentium4 2.8GHzのWinXP環境のShade9.1にてテストしてみました。 ,DXFインポータ,読み込み時間 ,Shade9標準,55 秒 ,高速版,6 秒 実はまだ速くできるのですが、とりあえず今のやつで一区切り。 今のところ3DFACEはあんまり速くはないのですが、結局はこれもメモリ確保で 「まとめてガッ」で、ある程度快適になります。 !!AIR（2007/06/12） もう鳥の詩しか思いつかない人も多いかと思いますが（絶対ブログ系でその手の書き出しで紹介してるところが多いだろうなぁ（笑））、AIRです。 http://labs.adobe.com/technologies/air/ かつて、AdobeのApolloと呼ばれていたものが「AIR」という名称で正式決定、 AIRのベータ版が先日6/11に公開されました。 ついでにFlex3ベータ1も公開されてます。 AIRではローカルDBであるSQLiteやドラッグ＆ドロップ機能が追加された、などの進展があり、脱ブラウザのポストを狙っているのはありありとわかりますね。最近Googleがローカルを視野に入れていたのである意味対抗もあるのかと思われますが、どっちかというとクライアントサイドのSun(Java)の立ち居地を狙ってるのかな、と思ってます。 個人的に好きな言語（ActionScript）であるので、柱の影から応援しています。無味乾燥なブラウザというHTMLの呪縛から解放されるインフラを作ってくれることを期待しています。 これからの進化が楽しみです。現状、WinとMac版を耳をそろえて出すというところにも個人的には高感度アップです。 !!続・kd-treeでのspacial-median（2007/06/11） 186000の要素がある場合で、空間の構築にて「3.5秒」くらいから「1.9秒」くらいに短縮（同じくCeleron 1GHzのノートPCにて）。ということで、私がかつて実装したUniformGridよりも速くなりました（ってことは、UniformGridはもっと高速化できる？）。 結局は数日前よりも空間構築が10倍速に。メモリをもう少し贅沢に使えばもうちょっと速くなるとは思いますが、とりあえずはこれでよいかな。 !!kd-treeでのspacial-median（2007/06/10） 186000の要素がある場合で、空間構築は先日の「5秒くらい」から「3.5秒くらい」に短縮（Celeron 1GHzのノートPCにて）。 結局はメモリ確保がボトルネックだったので、最適化。また、メモリの消費を約半分に抑えました。 後はトラバースの最適化に絡むSAHです。その前に空間分割以外のところも実装していかねば。 !!kd-treeとBSP（2007/06/10） 根本的にえらい勘違いしていたので、メモ的に記載。 藤田さんのWikiより。 http://lucille.atso-net.jp/wiki/index.php?kd-tree 基本的にBSPは空間を二分していく軸は任意なのに対して、kd-treeの場合は軸並行という制限を加えていて、私が今までBSPと読んでいたのは「軸並行で、かつspacial-median」ってことらしい。 spacial-medianは、二分木構造を作るときに真ん中ですぱっと分ける（私がずっとBSPと思い込んでいた）方法論をあらわし、軸位置を軸並行で0.5（中点）以外の値を判定するのはSAH（Surface Area Heuristics）などを用いる。 ですが、前処理を速くしたい場合は、単純なspacial-medianのほうがよさげな気もする。ただ、シーンとして広大な一枚板の上に小さなオブジェクトが乗っている場合は、当然ながら大部分のオブジェクトが一枚板との交差判定を行う必要も出てきて、効率が悪い。ので、当分はこれが（私自身の）ハードルとしてあるかな。 後、データ構造（ノード）の持たせ方としても、個々のノード内の情報以外は32ビットに収めてしまおう、というのがありますね。 というかCEDEC2006での内容でした（しかも聞いていたはずの藤田さんの講演）。 http://journal.mycom.co.jp/articles/2006/09/14/cedec3/menu.html ・・・なんだ、spacial-medianはすでに自分が実装していたやつだったのか・・・。 ということで、SAHがどれだけトラバースに効率的に貢献するのかテストが必要なようです。 うむ、いろんな勘違いとkd-treeについて、自分自身理解してきた予感。 !!BSP（2007/06/09） 空間分割で使っていたBSPを見直して再実装したら過去より空間構築が4倍速に。トラバース含めた全体で2倍速くらい。 速度基準としてBSPで実験しているのですが、もう少し最適化できそうな部分があるので前処理部分はもう少し短時間でできそうです。 Celeron 1GHzのノートPCにて、16万の要素（あえてポリゴンとはかかない(^_^;;）で空間構築は5秒くらい（以前は20秒以上かかってました）。 最近のマシンだと、2秒くらいでいけるでしょう。 で、これを拡張してkd-treeでどこまで最適化できるか試す予定。 前処理の計算で複雑なことをしてしまうと厳しいので、ここでBSPよりも速度を確保したいところ。後は、トラバースも早ければなお良し。 どこで使うのかは今はいえませんが、リアルタイム系の空間分割としてBSP/kd-treeのものもいけるかもしれませんね（前処理で時間食うと思ってたのもありましたので）。 たしか、GPUレイトレでkd-treeを使っていた論文があったと思うのでそれも解読してみよう。 あと、物理エンジンでの空間とかはどのように扱っているのでしょうね？衝突が発生したらその衝突したものだけを計算できるように、近くのオブジェクトの存在は当然ながらすばやく検索できる必要があります。 このへん、空間を管理するアイデアはあるので実装はしてみたいところ。以前から暖めていた「差分」って考えは使えるんじゃないかなぁと思ったりしてます。でも、BSP/kd-treeとの相性は厳しいか・・・。 !!物理再び（2007/06/07） 日記に書くということは、いつもどおりの流れだと水面下で何かしらごにょごにょしているわけですが、PhysXはおざなりになってました（仕事では使ってませんが、ハードウェアは仕事場のマシンに入ってます）。2.7系のドライバは出てますね。ですが・・・ハードウェアって今出てるの？ ググったところでは、2006年の半ばのASUSの「PhysX P1 GRAW Edition」以来出てないような気がしないでもないですが（最近は秋葉にいけてないので、未調査ではあります）。なんとな〜く、下火雰囲気を感じるのは気のせいか・・・。 はたして、今はどこまで物理エンジン（とPPU）は進化してるのだろうか。 ODEは結構いじり倒したのですが、欲を言うといろいろまだほしい機能があったりもします。う〜ん、ピンポイントの機能だと自分で物理処理したほうが手っ取り早い（これは処理速度も含む）かもしれない。 !!Shade 9.1（2007/06/05） Shade9.1のアップデータがようやく公開されました。 http://shade.e-frontier.co.jp/support/910fixed.html パーティクルフィジックス、ヘアーサロンの速度向上やポリゴンが欠ける問題も 修正されてます。 ので、不都合があった方は今すぐにアップデートすることをお勧めします。 後、Shade本体でのレンダリングもかなり速度アップしてます。 !!東京に戻ってきました（2007/06/04） 6/1〜6/4まで北海道函館に行ってきました。 朝市前ホテルに泊まったのですが、海鮮がえらいおいしかったです。 「朝市」とは海の幸を販売している市場です。カニやらウニやらイカやら。見るだけでも楽しいです。後、さすがに現地価格だけあってお手ごろです。 で、観光名所も結構あるので、どこまでも歩いて散歩 in 函館、をしてきました。 ここにそのときの携帯写真を置いています。今見て思ったのですが、教会がなかなかグローバルイルミネーションが利いているっぽくて趣がありますねぇ。 http://ft-lab.ne.jp/photo/hakodate.html 4時間くらいは歩いたかと・・・。五稜郭まで歩いていこうとしたのですが、さすがに遠すぎて無理だったです（苦笑）。 半分仕事半分観光で函館に行ったわけですが、雰囲気といい食事といい、ナイスな場所でした。海沿いということで新潟に似ているなぁとも思いました。