独り言日記（2004/07）

独り言日記

隅田川花火大会（2004/07/31）

ちょいと浅草まで花火を見に行ってきました。ついに夏真っ盛りですね。しかし・・・、ものすごい人で警察の方もたくさん来ていてバリケード張ってました。花火は、隅田川にかかる橋に向かってぞろぞろと歩いて見る（警察の方が誘導）、といった具合。ぶっちゃけ、周りのビルが高くて橋の上からしか花火の全体像をつかめなかったです。昔は普通に見えたのでしょうね。ベストスポットが少ないわりに（正直、橋の上しかない）ギャラリーは多いですので、誘導が必要だったのかも。

橋の上の誘導はなぜか「ピーポー君」で、「ピーポー君は足が遅いので追い越して進まないようにしてください〜〜」とかずっと（警察の方が）拡声器で叫んでいるのにはちょっと笑ってしまいました(^_^;;。10回くらいは「ピーポー君」って単語を聞きました。人気者のようです。着ぐるみを着ていたかどうかは残念ながら見えませんでした。プラカードは持っていたようですが。

橋の上で止まっても駄目ですので、結局じっくり見れたのは10分ちょっとくらい。なんとも落ち着かない花火でしたが、夏の１ページとして楽しめたかなぁと。でも、誘導列の最後のほうって結局橋の上までたどり着かずに花火が見えなかったんじゃないかと思ってしまいました。

都会の清涼剤、ですが、都会ならではでの障害があったりして、なんとも皮肉ではありますね。

バイエル（2004/07/30）

レンダラのほうは、ようやく幅優先がらしくなってきました。またアルゴリズムを固めている段階ですが、「まとめて」が実現化する手ごたえはありそうです。

空間分割としては、均一なグリッドに分けてます（ポリゴンをボクセル内に登録しています）。「レイシューティング」（3DDDA）を世代ごとにまとめてですがそれだけではおそらく高速化に貢献しなくて、3DDDAで走査するボクセル自身も分解する必要がありそうです。考えては再度見直して（場合によってはソースを捨てて）、と繰り返してますがなかなか骨が折れますねぇ。

さて、話変わって最近ピアノの練習を再開しています。基礎から出来てないので「バイエル」を購入しました。今は4日目で26番まで進みました（全部で106番まであります）。１日２時間くらい時間を作って進めていってます。こちらはRolandキーボードを使ってますが、曲演奏って別に基礎が出来てなくても弾けたりするんですね。学生時代は実際に弾いてましたし。ただ、基礎がない分練習期間がかかったり途中で止まったら再開が困難(^_^;;、などのデメリットもありますので改めて基礎が大切なのが身にしみて分かった次第です。半年〜１年かけてまったりとマスター予定です。

ただ、バイエルは初歩の初歩の教則本のため、この後に「チェルニー」「ソナチネ」などなど道は果てしないですね。ただ、趣味ですので「耳コピーできればいいなぁ」といったレベルですが。

それにしても、練習すれば練習するだけ上達するってのは楽しいですね。趣味の１つとして確立できればいいなぁと思ってます。

幅優先レイトレーシング（2004/07/26）

Flash関連がひと段落したので（サイトでは中途半端にとまってますが・・・これはまた整理して載せます）レンダラを本格的にいじってます。

すべてをメモリに保持した場合のレンダリング速度は20secくらいに短縮(レイトレにて。ただし、アンチエイリアスは最適化してなく、将来のGIも考えて5サンプリング/pixelをしています)。きっちりとレイトレのプログラムを最適化すると10secは切るかも（10万ポリゴンほどで）。

後、以前「スレッドで直列化して〜」といっていたのですが、これを実装すると、これがまた重い(^_^;;。結構時間かけて実装したのになぁ・・とほほっ(T_T)。どうもクリティカルセクションにて同時メモリアクセスを制御する、という行為自身が足を引っ張ってるようでした。

なんで「幅優先レイトレーシング」が再浮上です。「まとめて」とすることで普通に１レイを逐次処理でたどるよりも多少速度アップした感じです。

影を考えると、レイトレ処理を展開した場合「3DDDA（視点からの走査）」「3DDDA（影の走査）」「3DDDA（視線ベクトルの反射の走査）」「3DDDA（影の走査）」・・・のように交互になっている法則がありそうです。これを世代ごとに貯めてボクセル・ポリゴンとの交差判定を一挙に行う、の繰り返しで速度アップを図るというのが「幅優先レイトレ」の醍醐味であります。

なので、レイバッファ（レイの開始位置・方向ベクトルを保持するバッファ）とツリー構造を用いることで、「まとめて」という（ハードウェアにやさしい(^_^;;）トラバース処理に展開できそうな予感。

なんにせよ実験ですね。

レンダラにてデータを外部ファイル化（2004/07/21）

レンダラにて、空間分割およびその中の三角形の頂点情報を外部ファイル化してみました（全108590ポリゴン）。

ユニフォームな空間分割（グリッド状）を行っているのですが、最大80 x 80 x 80に区切るとして、インデックス用ファイルで約1.8MB、ポリゴン用ファイルで約8.1MB。意外とファイルサイズは小さいですね。数百万ポリゴンでしたら、メモリに簡単に乗るかもしれないです。

で、すべてをメモリに保持した場合はレンダリング速度は30sec、ボクセル情報をファイルにしてそれを取り出しとした場合は50sec、と思ったよりも劣化は少なかったです（Pentium4 2.8GHz）。上記は純粋にレイトレースした結果です。メイルボックス処理などもやっておらず、ファイルからの読み書き検証のみ。あと、これにキャッシュ機能を実装予定ですのでもうちょっとましになるかと思われます。

で、外部ファイルとしてデータを吐き出す・読み込みを扱うときに引っかかった点を数点。

はじめは単純にfopen/fread/fwrite/fcloseを使っていたのですが、スレッドを使っていろいろやる場合（これが原因ではないかもしれないですが）、関係ない書き出しが行われたりで苦労してしまいました（0x0Aの前に0x0D出たり・・・改行コードの補間？）

で純粋にバイナリで無駄なく読み書きしたい、ということで_open/_read/_write/_closeを使うことで解決できました。たしかに、スレッド処理でバッファリングをかましたfopen系を使うのは危険ではありますね(^_^;;。勉強になりました。

後は速度アップのために、できるだけ即使えるデータ構造（ファイルフォーマット）にすること。実は、ファイルに吐き出したデータを読み取るとき、はじめは500secくらいかかってました。これは、こまめにファイルポインタを移動して必要なのだけ取ってきて・・・とチマチマしていたのが原因です。

一括して処理できるように、各ボクセル内にファイルのオフセット値（将来を見越して64ビット幅）を保持してダイレクトにファイル位置を指定（_lseek）で、まとめてがさっと持ってくる、で10倍速くらいになりました。

この手のファイルにデータを待避させて必要に応じて取り出し、はグリッド式の空間分割が効率がいいんでしょうかねぇ。しばらくはこの方式で進めることにします。

レンダラのライブラリ化（2004/07/15）

レンダラはライブラリ形式（DLL形式）でも対応できるようにしよっかなぁ、と進めているのですが「C++（クラスの使用）」はDLL化での呼び出しに苦労する、ってのがあります。

いや、たいした苦労はしないのですが「関数のマッピングがVC++独自になってしまったりする」んですね。なんで、たとえばVC++でクラスを使った機能にアクセスする場合、Borland C++からはDLLの機能を引き出しにくいです。せっかくのDLLも本末転倒ですねぇ(^_^;;。この変な仕様が今でも改善されないのはC++（VC++、かな）の悪いところではあります。

ということで、機能を提供する場合のIN/OUTはC言語（クラスを使用しない）で記述する、が妥当でしょうか。

また、レイトレ（GI含む）だと仕様を固めるのが大変そうです。いやはや先は長い・・・

Flash（2004/07/14）

仕事にてFlashを使う機会がありましたのでFlashに関するTipsもひそかにまとめていってます「Flash」。

ゲームをターゲットにしているのは、昔の二次元のゲームアルゴリズムを伝える場がないからここでやってしまえ、という理由もあります（兼、私もメモ帳として(^_^;;）。IT系（？）のシステムとはまた違った知識がいるんですね。

でも、昨今のゲーム売り上げを見ても任天堂のファミコンミニが売れているということを考えても（第三弾が出ますね）、ゲームの本質が見直される時期に来てるんではないか、と傍から見て思ったりします。

まぁ、楽しんでいただければ（それの手段が提供できれば）それでいいかと。意外とFlashででも、ファミコン並のゲームが実現できますよ。

知っているのでは、ゼビウスやパックマン、ストリートファイター２もあったかと思います。

パックマン ： http://www.neave.com/games/pacman/

ゲームいろいろリンク ： http://www.geocities.co.jp/Playtown-Denei/4504/

夏（2004/07/06）

すっかり暑くなりましたね。おかげで作業に集中できんです(^_^;;。また、クーラーに頼る生活だとだらけてしまいます。むぅ〜〜っ。

集中力には波があって、時と場合により集中時比で10倍以上は差があるような・・・環境や状況によるのですがそんなときは思いっきり「何もしない（というよりも遊ぶ）」ことにしてます。

そんなこんなで（？）金八先生（PS2）をクリアしました。ほのぼの系かと思ってたのですが、最後の方でサスペンスストーリーもありました。また、ほぼすべてのストーリーに対して感動しました(全十数話)。特にロケットの話。構えずに見るとこんなゲームもいいものですね。ゲームというよりも、ドラマといったほうがいいかもしれません。

ボツになったらしいシナリオ、気になるなぁ(^_^;;。もう隠しシナリオもクリアして、たぶんこれで完全に制覇したと思います。でも世界観にどっぷり浸れたため、続編希望、って感じっす。

あ、そろそろコタツ片付けないとダメだなぁと思いつつ、ずっと出しっぱなしですわ。

スレッド対策（2004/07/05）

まだアルゴリズムだけですが、レンダラをスレッドで速度アップできないか模索中。大規模データを扱う場合、単にレイシューティング処理を複数スレッドに分けて管理する、では速度アップはできないような気がしています。また、キャッシュのヒット率も悪そう・・・

で、考案しているアルゴリズムがあるのですがこれだと貢献しそうです。ですが、まだ本当に速くなるのかは試していないので公開は控えます。

さて、億単位以上のポリゴンを処理するレンダラのサンプルで、同じオブジェクトを大量に敷き詰めている、というのがよくあります。聞くところによると、このようなシーンはズルをしているそうで、実際に億単位のポリゴンを対象にしたレイシューティングはしてないのでは、とのことです。（そのようなシーン専用のパラメータがあるらしい）間接的に聞いた話で、MAXは持ってないので真偽は確かではないのですが・・・

でも、大規模なシーンをレンダリングする場合はメモリにデータを乗せることができないので、別のテクニックがいりそうですね。

有名なのに「幅優先レイトレーシング」というのがあります。

http://www.on.cs.keio.ac.jp/~maru/thesis.pdf

これは、レイシューティングを世代ごとに管理してデータを「連続で」処理できるようにする方法なんですが、これでも待ち（Wait）が発生してしまいます。これをスレッドを使って緩和しようかなと。

レイトレーシング vs ラスタライズ方式で必ず出てくるレイトレの速度低下の難点としては、「連続で処理できない」って点なんですね。SaarCOR（http://graphics.cs.uni-sb.de/~jofis/SaarCOR/DynRT/DynRT.html）でも賛否両論なのはこの部分であるといわれています。後、SaarCORの方法だとレイトレは早くなりますが間接照明を含めた場合では新たな最適化が必要になる気もしています（FPGAとPCとのアクセスがボトルネックになると思ったりします）。

やっぱし、イラディアンスキャッシュ使用はいたしかたないかなぁ・・

差分を求めればいいラスタライズと、レイトレのようにレイ順番にたどって、という処理を見ると確かにレイトレは連続性がないです。これをスレッドを使って最終的にキューリストの形に直列化することで速度アップできるんでないか、と思ったりしてます。で「幅優先レイトレーシング」が一番近い方法のように感じました。

でも、アルゴリズムを考えるだけでどんどん時間が過ぎますなぁ。