2005年12月アーカイブ
PowerPointでTEXを使うプラグイン、texpointがなぜか使えません・・・。
TEXを書いて、いざBMPに出力しようとすると次のようなエラーを吐きます。
Shell command did not produce bitmap "画像のパス"
調べても載っていない、詳しい人に聞いても分からない。
仕方ないからノートパッドでTEX書いて、pdfにして画像にし、範囲選択で個別の画像に分ける。というとても遠回りな方法でやりました。
疲れた・・・。
今日はCAVEの掃除をしてきた。とはいえ、うん百万もする鏡とかスクリーンを僕らが雑巾とかで拭くと逝ってしまわれるので、床掃除機かけたりＰＣとか軽く拭く程度。
まぁ今年もご苦労様でした、来年もよろしくCAVEさん。頼むからあんまり壊れんでくれ・・・。
かなり久しぶりのCAVE。調子が悪かったり、教授の都合とかでぜんぜん使えませんでした。ほんと何とかしてほしいっすＴＴ。今日はＣＡＶＥの基本的な機能のテストとエノンマップ表示プログラムの教示実験でした。
＜今日やったこと＞
・ＣＡＶＥのプロセスに関するテストを実施、それにより以下のことが判明
１．frameUpdate関数内ではCAVEMasterDisplayでもCAVEMasterWallでも変数が共有されていてもされていなくても、すべてのスクリーンで同じ演算結果が表示される。
２．mainのwhileループ内でも変数が共有されていてもいなくてもすべてのディスプレイで同じ計算結果になる。
・CAVEのナビゲーション関数のテストを実施、以下の結果を得る。
１．NavLock, NavUnlock関数は使っても使わなくても結果が同じだった
２．NavLoadIdentityを使うやり方、使わないやり方の両方ができる。
３．ナビゲーション座標とワールド座標では微妙に位置が違った。
・エノンマップ表示プログラムを表示テスト、うまく表示できたが13周期でもフレームレートが遅くなっていた。FPSの表示がうまくいかなかったので詳しくは分からなかったが、シュミレーションモードでは13周期で約40フレーム毎秒,15周期では約１５フレーム毎秒だった。実際にCAVEで見るときにはもっと遅くなっていると思われる。
エノンマップの周期１５の周期点です。周期が１つ増えると点の数は大体２倍になるので、周期１５は周期１３の４倍の点が出てきます。プログラムの改良（ていうかデバック）によりかなり軽くなり、３万点でも３０フレーム毎秒ぐらいの描画速度になっています。
ここまで点が多くなると、少しづつ形がハッキリしてきます。静止画なので分かりにくいですが、プログラムで回転させながら見るともっとよく分かります。
以前のプログラムでは点が多すぎて処理がかなり重かったため、近くにある点などを排除して、データの最適化を行いました。
ちょっとスカスカになってしまいましたが、フレームレートは少し回復しました。
最適化の方法は、４次元の格子を用意してそれぞれの点がどのグリットの中に入っているのかを調べます。そして、既にそのグリットの中に点があったら、それ以上点を保存しないように、つまり一つのグリットに一つの点しか入らないようにします。
これが意外に難しかったです。なぜかと言うと、各座標100個のグリットの配列を取ったとしても２次元の場合なら100×100で10000個の配列ですみますが、４次元の場合だと実に100の４乗、１億=100Mもの配列を必要とします。もしint(４バイト)なんかで取ってしまうと全部で400Mバイトの配列になります。このぐらいならまだ最近のマシンだと大丈夫かもしれませんが、さらに200個とか取ろうとすると200^4=16億=1.6G、intだと6.4Gバイトです。
これを解決するために構造体のビットフィールドというものを使いました。具体的には
typedef struct
{
unsigned b0 : 1;
unsigned b1 : 1;
：
：
unsigned b30 : 1;
unsigned b31 : 1;
} BIT32;
このような構造体を用意し、これを使って配列を組むことで400Mバイトの配列でもその32倍の数の配列を確保できます。つまり100^4が800^4まで多くなるのです。もちろんこれはビットなので0か1しか保存できませんが、そこに点があるか・ないかということが分かればいいのでそれで十分です。
スペクトルをaで変え、４次元目の値は明るさに変更した画像です。
エノンマップの周期１３のやつを表示してみました。aの範囲は -0.5 ~ 6.95 までで 0.05刻みになってます。これがとっても面白い結果になりました。
まずはすべての点を表示した画像を見てみましょう。
さすがに重いです。見て分かるようにFPSが１秒ぐらいになってます。でもすごい、山みたい。
じゃあ次はa = 6.95からどんどん値を減らして見てみましょう。
a = 6.95
a = 5.75
a = 4.75
a = 3.50
a = 1.50
a = -0.05
a = -0.5
見てのとおり最初は周期が小さな時とあんまり変わりないですが、aの値が小さくなっていくにつれて点が近づいていき、次々に衝突していきます。そして、衝突後の変化が近い点であっても激しいものになっているので、こんなにも多彩なグラフになっているんだと思います。
a が近づいていくのは、２次関数の解での重解に近づいていくのと同じなんですが、その後の虚数解への散らばりぐらいを見ていると、まさに”衝突”って感じがします。すげぇ面白いっす！
複素数のエノンマップを３次元に投影したサンプルプログラムです。
プログラムを動かしていると、それぞれの点が近づいて、衝突して複素数に弾かれていくように見えます。とっても興味深いです。
最後の画像は、周期を線で結んだものです。
４次元の透視投影を追加しました。言ってみれば、４次元の遠近法です。難しそうに聞こえますが、これも３次元の場合とほぼ同じで、座標軸が一個多いだけです。
こうやって４次元立方体と一緒に表示して動かすと、４次元で回転しているのがなんとなく分かります。
＜操作方法＞
右クリックしながらマウス移動：４次元の回転
左クリックしながらマウス移動：３次元の回転
右クリックしながら上／下矢印ボタン：点サイズ拡大／縮小
左クリックしながら上／下矢印ボタン：座標の縮小／拡大
左クリックしながら右／左矢印ボタン：点の増加／減少
実行できない人は.NET frameworkとか入れるといけるかもしれません。
以前書いた、テクスチャを使った擬似ＲＧＢスペクトル表示プログラム。こうやってたくさん表示すると綺麗です。４次元の座標をテクスチャの横の位置座標にして、マッピングしてるだけです。
今日はＣＡＶＥだー、と思ったらまたメンテですＴＴ。ビデオカード(Wildcat)が不調らしい
まじ、デリケートだ・・・・・
視覚化プログラムなどでよくある、RGBスペクトル（温度とか、力のかかり具合とか）。どうすればあれを使えるか調べてました。
１．カラーキューブを使う
２．テクスチャにする
１の方法だと、正しいスペクトルにならないけど、色の種類が増えるので見やすくなる
サンプルプログラム
２の方法はテクスチャにしてしまう方法なので、どんなスペクトルでも問題なし（作れるなら）。しかも計算を必要とせず、ただテクスチャを参照すればいいので（１次元でいいし）高速なんではなかろうか。
２はセルシェーディングなどにも使われているので、面白い。
NeHe OpenGL Tutorial -> Cel shading
