独り言日記
wxAUI
（
2008/05/29
）
今まで wxWidgets 2.6.2 を使ってたのですが、wxWidgets 2.8.7 にアップしてみました（ただ単に面 倒くさかったので更新してませんでした）。 で「wxAUI」というのを使うことで、いとも簡単にドッキングウィンドウが実現できますね。以 下のような感じ。実装方法は以下な感じ（ノーマルな static ライブラリの場合は「wxmsw28_aui.lib」、Unicode での
staticライブラリの場合は「wxmsw28u_aui.lib」がビルド時に必要です。）。 // ヘッダの指定 #include "wx/aui/aui.h" ... // ドッキング用のマネージャクラス。これはヘッダ部に定義のこと。 wxAuiManager m_auiMgr; ... // 初期化処理（this のコンストラクタで呼ぶとよい） // ドッキングの土台となる wxWindow 派生クラスを指定 m_auiMgr.SetManagedWindow(this); // パ ネ ル 1 を 中 心 位 置 に 配 置 す る。 こ れ は フ ロ ー テ ィ ン グ に は な ら な い。 m_auiMgr.AddPane(pPanel1, wxCENTER, wxT(" ビュー部 ")); // パネル 2 を下部に配置する。フローティング対象。 // ただし、this のウィンドウの下部以外はくっつかないように制限。 wxAuiPaneInfo info; info.Name(wxT("tb2")); // 名称 info.Caption(wxT(" ログ表示 ")); // キャプション文字列を指定 info.Bottom(); // 配置は下 info.LeftDockable(false); // 左へのドック収納を禁止 info.RightDockable(false); // 右へのドック収納を禁止 info.TopDockable(false); // 上へのドック収納を禁止 m_auiMgr.AddPane(pPanel2, info); // 更新処理 m_auiMgr.Update(); なお、この m_auiMgr を解放するには this のデストラクタのタイミングで m_auiMgr.UnInit(); を呼ぶようにします。
pPanel1、pPanel2 はそれぞれ wxWindow 派生クラス（wxPanel など）のポインタです。ここでは、
pPanel1はプレビュー用の OpenGL 領域、pPanel2 はログのテキスト表示領域（wxTextCtrl）としま した。結果は上のムービーの通り。
「AddPane」の第二引数に wxAuiPaneInfo に格納した情報を渡すことにより、フローティングでき ないようにしたりくっつく位置の禁止を行ったりできます。
たったこれだけ。なんという簡単さなんでしょう。昔々、MFC でこの実装をしてかなり苦労した 覚えがあります。これでかなり GUI 開発をショートカットできそうですね。wxWidgets 2.6 系で
はついてなかった機能なので、これだけでも 2.8 系にする価値がありますねぇ。
OpenGL
でのミップマップ（
2008/05/28
）
OpenGLでのミップマップを触ってみました。
glTexImage2 D(GL_TEXTURE_2 D, 0 , GL_RGBA,
width, // テクスチャの幅 height, // テクスチャの高さ 0, GL_RGBA, GL_UNSIGNED_BYTE,
(GLubyte *)pData // RGBA 情報の入ったバッファの先頭ポインタ ); のようにバインドされたテクスチャに色情報を指定する部分を glu 関数で gluBuild2DMipmaps(GL_TEXTURE_2D, GL_RGBA, width, // テクスチャの幅 height, // テクスチャの高さ GL_RGBA, GL_UNSIGNED_BYTE,
(GLubyte *)pData // RGBA 情報の入ったバッファの先頭ポインタ );
とすると、バインドされたテクスチャに自動的に縮小されたイメージが格納されます（この関数 の中身では glTexImage2D の第二引数を 0、1、2、、、のようにして縮小していった画像を順に格納 していってる模様）。ただし、テクスチャ画像は幅・高さともに 2 の累乗であること。
そして、テクスチャを描画するときに
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
の代わりに
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_NEAREST);
を指定するだけ。 結果は
のようになって効果絶大ですね。元画像は 256 x 512 pixel のものです。これは「毛」の表現をして まして、一本一本は 1 ピクセルの細いものです。テクスチャサイズが大きいと上の画像のように ジャギってしまうというもの。こういうパターンではミップマップとは相性がよさそうです。 というか、今のレンダラにこのミップマップ機能も内蔵したいと思いました。 後は、グラフィックカード依存がどこまであるのかの調査もいりそうではあります。
肌テクスチャを作ってみる（
2008/05/24
）
実際の写真の人の顔から肌のテクスチャを作る、という何やってるのかわからないことをここ数 日やってます。以下のような感じで生成できました。 しかし、手術をしているかような作業ですねぇ。ちなみに上記はプログラムにて自動化してま す。 顔写真から肌と思われる部分をサンプリングし、それを重ねて重ねてぼかして、重ねて、、、でつ なぎ目を目立たないようにしてようやく汎用的に使えそうな肌テクスチャに。ただ、人によって または光の当たり方によって肌の感じは違うわけですのでそのあたりに柔軟に対応できるか、が 焦点であります。おそらく個人個人で肌は違うので、オーダーメイドにはなりそうですね。PC
戻ってきました（
2008/05/24
）
修理に出していた自宅ノート PC が返ってきました。これで、自宅でもようやく PC がいじれるよ うに。いろいろ中断していたものも徐々に再開できればと思ってます（でも、今月∼来月は締め 切りがあるのがあるので鈍いのは変わらないですが。この件でちょっとお願いしたいことが あって、、、これはまたこの日記に書きます）。 後、放置していたメールのレスもしていきますので今しばらくお待ちくださいませ。え∼、3 週間 で 3000 件くらいあるのですが・・・ほとんどはスパムなので今メールゲット＆フィルタリング中 です。 PCが戻ってこない間は仕事場で仕事をしているか、自宅ではずっとペルソナ 3（フェスのほうの 本編）で再度遊んでました。ペルソナ 4 は 7/10 発売とのことで楽しみです。
メタセコの
Python
（
2008/05/21
）
3D関連のプログラムでちょっとしたことを調査する場合にメタセコは大活躍中です（メタセコ＋ SAI で私はもうモデリングは何もいらないかもしれん。両方ともユーザ登録済みですが元は十分 取れてますねぇ）。 選択されている頂点番号を知りたいのですが、これくらいなら Python でできるかということで、 Pythonを一寸たりとも触ったことがなかったのですがいじってます。いや∼、forのルールが違う んすね。 # ドキュメントを取得 doc = MQSystem.getDocument() # オブジェクト数を取得 objCou = doc.numObject MQSystem.println(" オブジェクト数 : " + str(objCou)) # 0 番目のオブジェクトを取得 obj = doc.object[0] # オブジェクトの頂点数を取得 verCou = obj.numVertex MQSystem.println(" 頂点数 : " + str(verCou)) # オブジェクトの面数を取得 polyCou = obj.numFace MQSystem.println(" 面数 : " + str(polyCou)) #1 つめのオブジェクトにおける選択頂点を調べる for i in range(len(obj.vertex)): if obj.vertex[i].select: MQSystem.println(" 選択頂点番号 " + str(i)) こんな感じで OK かな？ プログラミング言語は 3 日もあればある程度使えるようになる、というのは持論ですが、基本は 変数の扱いと制御文（for や if など）をおさえると後はどれも同じ、というのは助かります。ただ、Pythonは若干違いますね (Perl や smallTalk 的な違和感が (^_^;;。覚えりゃなんでも同じではありま すけど )。
す。 でも、Python は割とすんなり使えそうです。ということで初心者向けの本を買ってこよう。
wxWidgets
の
wxGLCanvas
（
2008/05/19
）
wxWidgetsにて、複数の OpenGL 領域を持たせる、ということをしているとどうも終了時に不安定 に な り ま し た。wxGLCanvas を オ ー バ ー ラ イ ド し て い た の で す が、ソ ー ス を 見 て み る と glcanvas.cpp内の wxGLContext デストラクタにて wxGLContext::‾wxGLContext() { if (m_glContext) { wglMakeCurrent(NULL, NULL); wglDeleteContext(m_glContext); } } のように実装しています。OpenGL の解放処理はデストラクタでやるのは危険ですねぇ。ここの 2回目の「wglDeleteContext」で死んでしまうようで。後、個人的に NULL チェックをしているの であれば、Delete後に m_glContext に NULL を入れるほうが好みだったり。デストラクタなんで 2 回は呼ばれないですけども。1 つの OpenGL 領域だけなら問題ないのですが、複数のものを使う場合はこの部分は鬼門かも。
wxWidgetsに手を加えるのもおっくうなので、自前で実装するほうが安定しそうな気がします（そ
れよりも、複数の OpenGL 領域を使わない設計のほうがいいかもしれませんね）。 ちなみに、wxWidgets の場合は wxWindow クラスを this とした場合に
HWND hwnd = (HWND)(this->GetHandle()); とすると、ネイティブな Window ハンドルをゲットできます。これがあればなんとか OpenGL 領域 を独自実装できるので、このような いざというときの救済策はうれしいところ。 追記： この問題はどうもドライバも関係しているらしく「ドライバを新しいのに変える（GeForce6600GT のボードです）」「マシン再起動」で発生しなくなりました。う∼んグラフィックカード依存か、こ いつはやっかいですねぇ。wxGLCanvas を破棄して、独自実装に置き換えちゃったよ（汗）。
まだパソコン修理中（
2008/05/15
）
壊れた VAIO ノートの療養中なんですが、SONY のサポートセンターから電話がありまして「動 いてますよ？」とのこと。動かないのを確認してたんですが、原因はなんなのでしょうね。でも、 無事でなにより。それよりも、たまたま家にいたときの電話だったのでよかったのですが、ほと んど外出しているので連絡取れないのがちとすれ違いになりそうで怖いです (^_^;;。でも、丁寧に 対応してくれて助かりました。かれこれ自宅では PC のない環境で一週間は経過したのですが、意外と問題はないです（仕事中に PCとにらめっこしてるってのもあるけど）。自宅では新聞を取っているのですが、新聞は今まで よりよく見るようになりましたねぇ。いつもは起きてすぐに PC を立ち上げる、という廃人状態 だったので（朝一番にすることはメールチェックが多いです） PC が壊れたことにより一般人に近 づいたかもしれない。 仕事では wxWidgets と戯れていますが、一部にて画像認識を行いたいところがあります。ここに て OpenCV を使うことにしました。しかし、レンダラが一時中断中ですので手がほしいところで す（レンダラは別プロジェクト）。もうちょっとで整理がつくと思いますので、どうするかを ジャッジできればと。仕事の優先度があるので難しいですが、せっかく時間を作ってもタイムリ ミットがくればストップしてしまう体制をなんとかしたいもんです。こりゃキャパ不足です ねぇ。 とりあえず、レンダラは自宅 PC が復帰すれば若干進展すると思いますので、そのタイミングでな んとかまとめておきたいです。
感動した（
2008/05/09
）
modoってモデラーかと思ってたんですが、ギャラリー見てみたらレンダラもすごいっすね。 8スレッド（8 コア）のレンダリングで 27 秒だそうな。 http://www.luxology.com/common/qt/LuxQT.aspx?u=http://content.luxology.com/modo/302 /video/C9 -rendering.mp4&w=724&h=532 これは無理だろうけど追いつきたいです (^_^;;。レンダリングでの走査方法なんですが、ブロック として扱うのはいろいろ利点があります。今作ってるレンダラはライン（上から下の走査）なん ですが、別途 Maxwell みたいに何回もスクリーンを走査するモードも設けてます。けど、後者は 最適化が難しい部分があって、私が実装するのに限ってかもしれませんが、ブロックやラインで レンダリングするよりも速度が落ちてしまいます。 ところで、modo のレンダリングムービーではガンマが 1.2 のようなんですがどれがデフォルト値 として適切なんだろうか（カメラ（hdr 撮影時）で言うと、1.8 か 2.2 が多いと聞いたんですが・・・）。PhysX SDK v2.8.1
（
2008/05/09
）
nVIDIA からメール来てました。今まで特にユーザ登録してないのになぜ？と思ったら、AGEIA （今は nVIDIA に買収されてます）から引き継いだんでしょうね。PhysX SDK の案内がありまし た。 http://developer.nvidia.com/object/physx_downloads.html 久しく触ってないのですが、今は 2.8.1 だそうです。 ソフトウェアだけでも十分速いですので、遊ぶのにはいろいろ使えそうです（ハードを持ってる けど、これは失敗だと思う。流れ的に GPU での物理演算に移行するのかもしれないですね）。ですが、ライセンス体系はどう移行したのでしょうか（まだ確認してません）。
パソコン修理中（
2008/05/08
）
壊れたノート PC を修理に出してきました。直るまで 3 ∼ 4 週間かかるそうです。ということで、 家ではパソコンなし、仕事場ではフルに使ってますが終電までという制限あり、な状態です。 メールは仕事場から見ることはできますが、修理中の自宅ノートとごっちゃになると困りますの でレスは 1ヶ月後になりそうです。お手数をおかけしますがご了承くださいませ。しかし、迷惑 メールが多いです。9.9 割方迷惑メールなんですが・・・。フィルタリングして自動分類していま すが、たまに迷惑でないメールが迷惑に入っていたりと完全ではないですね。 後、急遽な仕事があるので wxWidgets と格闘中。さくっとアプリを作り上げるのにはかなり助 かってます。しかし、人手が足りないです。仕事の絞り込みも行っているのですが、どうも依頼 のある内容は自分でしかできないことが多いので作業が集中してしまいます（ありがたいことで はあるのですが、分散できない (^_^;;）。サンプリングの最適化？（
2008/05/06
）
偶然ではあるのですが、ノイジーなものを緩和する方法というかサンプリング手段が実装できま した。 と思ったらウソついてました、すみません（汗）。サンプリング数が 3 倍になっただけでした・・・。 おぅっ。パソコンがぶっ壊れた（
2008/05/06
）
レンダリングのしすぎか寿命か、いつも使っているノート PC が起動しなくなってしまいました。 しばらくは治療に出さねば。でも、5年以上活躍してもらいましたので感謝してます。VAIO ノー トです。例のバッテリーが発火対象になっているやつ (^_^;。ご丁寧に SONY の方から電話連絡 をいただきまして、いつでもバッテリー交換しますよとおっしゃってました。ネットも so-net だ し、テレビも SONY 製だし、PS2 持ってるし、自宅から SONY 本社まで歩いていけるし（関係な いか）、と一ユーザではあるのですがお世話様々です。 幸い、大事なプログラムのソースは分散させておいてますのでレンダラソースや仕事のソース類 は無事です（遠距離環境にアップロードした後にパソコンを再起動したら、起動しなくなったの でギリギリセーフ）。バックアップはとっておくもんですね。 それと、本日はまだ GW 中でした（気づいてなかった）。連絡を送っちゃったお客さんごめん、GW 明けにでもゆっくりお返事いただければと。 日記が連絡網になってしまった・・・まぁいいや。アルベド（
2008/05/04
）
http://kobam.hp.infoseek.co.jp/meteor/albedo.htmlを見ると、どうも色だけでアルベドが判断できるとは限らない感じ。砂や砂漠で 25 ∼ 40％だと （白っぽいのでもっと高いもんだと思ってましたが）、色判断では厳しいか。 後、ちと用語が難解なんですが SSS で使う（＜実装予定）「吸収」は absorption となってるので用 語の整理をしないといけなかなぁ。マテリアルを何気に整理してみると（一応関係ありそうなパ ラメータだけ仮でつけてます、機能してないけど）、SSS 関連で吸収、散乱、吸収の色、吸収の距 離、なんてとてもじゃないけど調整し辛そうでカオス化してます (^_^;;。SSS ではアルベドマップ というのを使う、なんてのが CG Magic に書いてましたので とりあえずは SSS 到達までは時間が かかりそうです。パストレのごり押しでは SSS の実験をしてみたのですが、たしかに時間がかか りますね、というかトラバース回数が増えること増えること。 普通のパストレでの吸収の挙動も、SSS でのアルベドマップとなんとか一緒に扱えるといいので すが・・・。 ここで書いている内容は 自分の健忘録という意味もありますが、（おせっかいかもしれませんが） Shade でもぜひ！という意味合いもあります。過去掘っていたポリゴンモデリングに関してや ボーンなどの「これだけはほしい」といった内容は、自分の調べたことで現状不便だと感じたこ とに関して、開発のほうに（手渡しで）渡してあったりします。採用してくれるかどうかは開発 チーム次第ではありますが。もちろん、メールにて個人的にいただいた「これもついでにお願 い！」は伝えさせていただきました。 レンダラに関しては、たまたま仕事と私事がちょうどバッティングしているネタだったので書い てます（今は守秘義務もない状態のプロジェクトなんである程度は公開して OK なんですよ）。技 術としてはたいしたことはしてないので、これらもフィードバック予定にしてます（ウソ書いて たらゴメン、というかさすがにそれは自己判断でなんとか見抜いてくださいませ。あくまで自分 の「独り言」ですので）。 誰かがやらないと、、、と思って何年もたってるので、まぁちとおせっかいがてら。クリエイター としての作品を通しての突っつきは、誰かやって（汗）
閉鎖空間でのテスト（
2008/05/03
）
光が届きにくい閉鎖空間でのレンダリングテスト。Celeron 1GHz/Mem512MB の WinXP（ノート
PC）にて。スクリーン左上の小さい窓と右上の横長の窓以外は閉鎖しています。背景は hdr を 使った IBL です。それ以外に光源はありません。壁や床・天井は鏡面反射 0、反射 0 です（純粋に 拡散反射のみになるようにしてます）。
Shade ではやはり光が届きませんね。球が発光しているように見えるのは拡散反射の色を青に近 づけているため。拡散反射を黒くしていないのはわざとです。独自レンダラでどうも透明体の 場合の色の反映が弱いので、、、このへんの理論をもうちょっと整理する必要がありそうです。球 は左から透明度 1.0 / 0.8 / 0.6 / 0.3。
これではノイジーなのでサンプリング数を 1000 にしてみました。 ↓独自レンダラ 追跡レベル 20 / 1000samples/pixel にて、3101 秒（約 51 分）。 後、フレネル効果を忘れてました。実装せねば。それと、透明体の場合の色についてもっと直感 的になるように調整。 後、これも思い違いしてましたが Shade の場合は追跡レベルを上げればサンプリング数も増加す るような動きをしていますね、トレースの再帰による影響だけではないみたい。もちろん、それ で時間を食うのですがこれだと純粋にサンプリング数で比較する、といったことはできないのか も。
デフューズアルベド（デフューズリフレクタンス）について（
2008/05/01
）
アルベドとは光がある一点に入射したときにどれだけの光が反射するかの比率ですが、「デ フューズアルベド」というと名前の通りデフューズでの「反射する光の量 / 入射する光の量」です。 単純に言えば、白い服は光をかなりの確率で跳ね返します。黒い服は吸収します（反射しにくい です）。 というのをレンダラに取り入れているのですが、例によって Shade との比較です。Pentium4 2.8 GHz/Mem512MBお WinXP マシンにて。以下は、透明度マッピングの実験も兼ねてます。どうも Shadeの「トリム」という考えは個人的には「透明度」であらわせばいいやん的なイメージがある ので、透明度で表現してます（透明度 1.0 の部分は通り抜けることになります）。ということで独 自レンダラでは、トリムという概念はないです（DirectX なら透明度の逆のアルファであらわしま すよね）。↓ Shade にてレンダリング。品質 50 でレンダリング時間 39 秒。
↓独自レンダラにてレンダリング。50samples/pixel でレンダリング時間 24 秒。
という概念は非常に大事だと思ってます。それがリアルにつながるんでないかなと。 単純計算では、デフューズの色が (Red, Green, Blue) で与えられているとすると
(Red + Green + Blue) / 3
として、これをデフューズアルベドとしてます（が、正しくは明度を求めた方がいいかも）。ただ、 原色バリバリで表現したい場合もあるでしょうからアルベド自身をデフューズと切り離したほ うがいいのだろうか。 ただ、実はこの部分はマニュアル（PhotonMap 本や CGMagic など）とは違う考え方を行ってます。 RGB によって吸収の挙動が変わるというのは独自ではあるのですが、なんで論じてないのだろ う・・・（フォトンの説明では書いてますね）。間違ってるのかな、でも、こっちのほうがリアルっ ぽいんだよなぁ。どれが正しいか分からなくなれば現実と比較するしかないですが、いずれは恒 例のコーレルボックスでも試してみるかな。
