8.x対応改修終わり、何とか当初の予定通り間に合ったカンジ.

i以前少々書いたけど、本質的な問題は解消されたものの、8.5ではグラディエントの最大・最小値設定がおかしな事になっている(DHMさんも書かれているけど多分LWのバグ)のでこの辺を使う場合は8.3bなどを推奨、また8.3(b含む)ではSpecial Bufferが機能していないバグがある、その前のバージョンはセルエッジとかで問題の報告があったりetc.、、、orz

、、、もう暫くは7.5との併用の日々が続きそう、色々見ていると8.5は表示がPixelシェーダ対応したせいｋ、表示周りの不具合の話なんかも耳にするし、それ以前のバージョンもダイナミクスの計算結果が変とか、、、9が出る前に8.xの安定版出して欲しいなぁ.

---------------

色々疲れた、、、(パタ

ちょっとしたメモ、Vue5でレンダリング解像度の縦横比を変えるとパースのかかり方が変わってしまうのが使い辛かったので (個人的には縦長のものを良く使う) Vueでの解像度変更後のパースのかかり方を一致させる方法を調べてみる.

解像度(w1,h1) 焦点距離 lenのカメラの解像度を(w2,h2)に変更した場合の新しい焦点距離 := (w1/h1)/(w2/h2)*len

またLWのカメラ設定の画角と同じものをVueのカメラで使う場合

LWでズームファクターzfのカメラをVueのレンダリング解像度 (w,h) のカメラでレンダリングする場合のVue側の焦点距離 := (640/480)*zf/(w/h)*1.064*12.7

まぁ電卓なんぞに登録して使うカンジ. Vueで完全にLWとシーン設定の同期を(LW主導で)自動化するのは少々難しそう(Pythonを見る限り)なんで最悪手計算でもという事でのメモ.

なおこれだけでは何の役にも立たないのでプログラマ向けの話になるけど、LWのズームファクターと焦点距離・アパチャーハイトの関係は以下の通り

ズームファクター := 焦点距離/アパチャーハイト/12.7

水平・垂直Fovについては省略. SDKではアパチャーハイトが取得できないので焦点距離から正確なFovを計算するのは不可能(ズームファクターから逆算すれば出るけど)なのでズームファクターを使う. というかRISpec調べてたらF-Stopと焦点距離からDoFを計算する上での錯乱円の径の式が出てたのでそれも調べておかねばという所.

、、、、というかまだ製品版届いてないんだけどorz

---------------

上の式を調べている時色々いじってて式の変形が面倒だったので自前の電卓に簡易ソルバーを付ける、既存言語の構文解析ルーチンに乗せたのでf(x)=0の非線形方程式を1変数について解くという話だが、試行錯誤しているとそれすら面倒に思う. やはり数式をそのまま a=bのような形で入力したい、というかHP200LXのソルバーがそういう事をやっていて学生時代に愛用していたのだけど、求解が振動してしまう個所などはグラフ機能と併用して上手くカバーできる作りになっていた. 所詮未知の変数が1個の非線形方程式だけしか解けないシロモノなんだけど、日常のある程度の用途はカバーできる事を考えるとオモチャと言えど良く出来ているなぁ. などと思う(というか多元の非線型連立方程式はある程度しっかりやらないと解が収束しないので、電卓でやる計算では無いかも(^^;;;

、、、それ用にパーサ起こして (といっても普通の数式入力のパーサで'='を特別扱いするだけの話) HP200LXのソルバー&関数電卓に準じるソフトを作るのが正解かもしれん、仕事も少々やらねばならない事が出てきているのだけど、やるべき事・やりたい事がどんどん増えて行く(苦笑)

# TIの数式処理電卓は良く出来てたし自分の用途の大半をカバーしてくれそうだったのだけど (HP電卓などではできないのだけど数式処理と展開は極めて重要、しかも自分で作れるレベルの分野では無いorz) 店で触らせて貰ったら入力が面倒だった、というかPCに慣れると電卓の妙なシフト規則なんて触りたくない、かといってMathmaticaまで行くと大規模でいかん. 何か良いソフト無いかなぁ、、、

この日記でも愚痴っていたLW8.xでベクトルテクスチャが動かない件、本日Newtekより回答をもらいました.

結論ですが(あれだけ騒いでおきながら)原因は私のミスという話になりそうです. とすればNewtekとDStromには色々と迷惑をかけた話になり(ごく一個人のページではありますがプラグインダウンロードのページは世界中からアクセスがある状況ですので)私に非がある為、謝罪すべき内容だと思います.

詳細については後少々検証が必要ですが、簡単に確かめた所ではちゃんとLW8.5で動作しているようで、動作の確証が出ればお詫びの掲載及びプラグインのLW8.x対応改修に入る予定で、1月中を目処に改修を行う予定です. 唯一TB_ShaderManに関しては私の方で使用しているバージョンと公開しているバージョンに開きがある為、仕様なども変更になる予定ですが、これについては多分このプラグインをまともに使っている人間も私以外に無い (正確に言うと今までのメールから各国に1人位はいるかもしれない) のではという事でご了承頂ければと思います.

またこれに絡みLW8.xの情報や開発の激励など色々メールを頂いたユーザーの方々に感謝しますm(_ _)m

---------------

上の内容についてはどうにかなるものの、DHMさんが日記で書かれているLW8.5でVParamのグラディエントの上下限がおかしくなる問題はこちらでも発生している模様orz

、、、8.3bでは大丈夫みたいなんで、当座そっちで行く予定.

---------------

先日書いたAPI HookがDEPで動作しない件、その後友人からVirtualProtectにてPAGE_READWRITEからPAGE_EXECUTE_READWRITEへの変更で通るらしいとの連絡がありました. あくまで伝聞でチェックできる環境が無い状況ですので保証はできないですが、もう暫くAPI Hookも生き延びそうです(ちよっと複雑な気分、確かにこの技術は便利この上無いのだけど仕事で下手にやるとどハマリする分野なので、作っているもの(セキュリティのユーザー監視アプリとか)によっては非常に不毛な気分にもなるし(苦笑)

前回の日記で書いたVue5、結構面白かったのでVue5 Infiniteを購入、買ってきて早速インストール、、、画面に表示されたのは、、、Vue5 Espritインストーラ??? 入力を促されるシリアルの桁数も何か違う、試しに入れてみても当然通らない.

、、、どうやらパッケージに間違ったアプリケーションCDが入っていた模様、、、というか幾らなんでもコレは無いだろうorz orz orz

休日明けに販売元のイーフロンティアに問い合わせ予定、、、購入早々限りなく萎えることしきり、、、勘弁してくれ(--;

# 諸用にて数日自宅に帰ってなかったので購入木曜の気づいたのが本日、あ゛ー

# 余談だけどVueはMIPマップをサポートしてないような気が、最終レンダリング結果のノイジーな仕上りはその辺が原因じゃなかろうか、、、GIはLWよりも良いカンジ、Global Ambience (アンビエントの色に環境マップの球面調和畳み込みの結果みたいなヤツを乗せる) や天空環境光 (指向性の環境光、厳密に言うとこれは新しくない、LWでもdaylightシェーダなどがやっていた筈だが、こういう設定は環境マッピングと一体になっている事にメリットがあるので) は面白い. LWでも照明シェーダ(not サーフェスシェーダ)欲しいなぁ.

適当にテスト版 (UV用じゃないほうのヤツ) 分かり難いオプションを全部削った代わりに少々設定の自由度が落ちる. 理解できるレベルに落とし込めてるか不明だけど取りあえず期間限定公開で様子見.

ちなみにやっぱり用途はバンプと同じ、凄いバンプだけどバンプ以上の使い方をすべきものじゃない、なおLW8では動かない(SDKのバグで回避策も無いのでこちらではどうにも出来ない)

---------------

先日書いたAPIHookがDEPで引っかかる件、KOJIさんから指摘もらった、確かに言われてみりゃそーだね、という話で検索したらそれっぽいネタもあったので詳細が判明次第修正するかも. 僕も伝聞なんでテストできないのだけど、結構間抜けな話を偉そうに書いていたかもしれない、まぁ自分が間抜けなのはいつもの事かもしれないけど(ダメじゃん.

---------------

Vue5の体験版をお試し中、肩の力を抜いて遊ぶツールが欲しかったので触り始めたつもりが、何故か気が付けばスクリプト(Python)を書いたり、実際のトランスレーションがどうなっているかを調べてLWと合成した時のワークフローを模索している、、、orz

しかし、カメラトランスレーションが完全に一致しない、付属のコミュニケーションプラグインはLW8でしか動作しないし(先月マシンクラッシュしてからLW8まだ入れてない(笑)) lws書き出しなどでカメラが完全に(画角・位置などが)一致するなら問題ないのだけど体験版なので書き出し機能が動かない、、、気にしているのも何だし、思い切って買ってみて合成し辛かったら諦めるってのもアリかも. あるいは厳密(1pixelのズレも無く一致する)事無しで良いなら カメラマッチでも良いのだけど、スクリプト書いてたら32bit floatで生の(グレイスケールでは無い)デプスが取れたので出来れば厳密な合成が欲しい、、、って原点回帰で能天気にトップダウンで遊ぶ目的のツールが欲しかった筈なのに、こんな事考えてたら本末転倒かもorz

Vue5のラジオシティでカラーの天空でスカイライト系のライティングをした時にLWと違って色がそのまま出るワケで無く結構いーかんじになるなぁ、などと思っててふと思い出したのが以前Cinema4Dの体験版を触った時、LWのGIとの大きな違いはGI実行時にアンビエントを加算するかどうか(LWはGI実行時はGIの間接反射の範囲ではambientを合成しない、C4Dは(少なくとも当時は)間接反射+ambientも合成する) 当時色が綺麗に出る気がして、LWの実行結果よりC4Dの方式の方が好みだったので、それを再現する為のシェーダツリーなんぞ組んでみる. (ちなみにラジオを無効にしているとambientが2倍になってしまうので注意(笑))

結構主観だし、個人的に余りラジオシティに慣れていない為何とも言えないのだけど、個人的にはこちらの結果の方が好み. 空の色も比較的彩度を強めにしても見れるようになったと思う(まぁ単に自分がそういうライティングに慣れてないせいもあるかもしれない(^^;;

おまけで最近お気に入りのシェーダ シーン内の半分位のサーフェスにくっ付けてるモノ、まぁこれも個人的主観だけど、誰かの役に立つといーな、でも全然役に立たないかもしれないなー(どっちやねん)というカンジ.

半ば業務連絡)

友人から連絡があった話なのだが、NX bit搭載プロセッサ + WinXP SP2のメモリ保護機能の組み合わせでAPI Hookのインポートデスクリプタの書き換えが失敗するらしい、現状ではXP SP2のみだがこれが今後の流れを決定付けるとするとAPI Hook自体は廃れる方向になるワケやね.

まぁ一応はパフォーマンスオプションで設定できるらしいのだけど、世間での使い所が使い所だけに(内部犯罪防止用のツールとか)廃れて行く方向にあるのではないかなぁ、という所. デバッグなんかをする時は非常に便利な機能なんだけど(かのBoundsCheckerなんかがこの機能を利用してカーネルリソースのリークなどをチェックしている;-)

まぁ先のSonyのrootkit問題もある事だし、この辺の技術は廃れるなら廃れた方が良い. コンピュータの本質は人間を制限するべきものでは無く、人間の機能をenhanceするものであるべきだと思うのであります. またこの辺のグダグダした所はプログラミングにおいても本質では無いしね(※1)

※1) 個人的にこういうトリッキーな技術をいじるのは余り好きじゃない(昔色々作ってたけど) プログラマに向いてないのかもしれないが、チマチマした箱庭で何かを実行するのは面倒なだけだと思っている. コンピュータなんて所詮道具でしか無いので、トリッキーでクールぶったコードなど必要無く、思考をダイレクトかつストレートにコーディングできれば何でも良いと思うのだよねぇ、まぁその為に回り道をする(例えば言語から作ったり(爆))というのはアリ (それ以降の手間とトレードオフにした時にメリットがあるのならば) だと思うけど(※2) まぁ出来ないよりは出来た方が良いワケで、トリッキー云々の話やOSの内部解析の話も、上のような話は下手すると出来ないことの言い訳になるワケで、最低限実装できる事が前提で、その上でメリットとのトレードオフを考慮して大局的に最もメリットの高い所に落とすべしという話なのだけど:-P

※2) といっても、実務的なもの以外受け入れないという話じゃなく、個人的にはコンピュータサイエンスとかの分野は大好きなのだけど (友人なんかは「だから学者ってのは馬鹿なんだ」なんて良く言っているけど(苦笑)) 今役に立たなくても10年、20年先に実用の目処が立つ可能性があるかもしれないなら、それはやっぱり研究されるべきだし、面白いと思うのだよね. 反面当座のOSやミドルウェア、言語などの機能の回避の為にトリッキーなコーディングをする(プログラマのクールなコードごっこ)ってのは正直不毛だと思うのだけど(例: C++のテンプレートでメタプログラミング、、、って素直に別言語作れば良いじゃん、と思ってしまうのは僕だけじゃないと思うのだけど(笑)

※3) そんなワケで最近のGPU系の論文とかテクニック自体は余り面白いと思わない、アウトプットの概念的には既に数十年前に通常のレンダラで確立している概念をGPU上という限定された空間で如何に(トリッキーな手法も含め)効率的に行うかという話でしか無い気がするので(概念的に新しいものや明確なメリット (ラジオシティvsフォトンマップ,MCRTなど) が入っているのは面白いと思うのだけどね ;-)

、、、やっぱプログラマに向いてないのかもなぁ(苦笑)

---------------

思いつきである機能を試してみる.

【新機能なし】

【新機能あり】

分かり難いかもしれないので2枚目の画像のアルファチャンネルを表示すると以下のようになる(背景があったほうが分かり易かったかも(^^;;

つまりはそういう所.

他にもこういうのトカ(ちなみに閉じたサーフェスでないと機能しない、平面では不可能(直方体なら可能) ;-)

IFW2 TexturesのDyno Skin、余談だけどこのプラグインは凄く良い、使っている殆どはDirt Shaderだけど(笑)

最終的にこの位まではDisplaceしても大丈夫 (真中の柱はジオメトリ上は単なるプリミティブそのままの円柱) 影や反射・屈折ももちろん大丈夫、この2倍でも大丈夫だったのだけど、余り強くかけると背面の突起が見えないのが気になるのでこの程度で. まぁDisplacementってのはモデリングの代わりになるものでは無いので (RenderManなんかもやろうと思えばかなり強くかけられるけど扱い辛いので余りそこまでかけるものじゃない)

---------------

ちなみに 最近の論文(ここのCurved Relief Mappingという論文) でHeightFieldをタンジェントスペースのZ=aX^2+bY^2曲面で近似(a,b)は周辺の頂点の情報から決定される係数で一般化逆行列を使用して求める. とは別物(LWのテクスチャとの併用は少々難しいので)で、どちらかというとレンダリングブーリアンに近い手法を取っている(多分これで勘の良い人は分かるんじゃないかな(^^;;) Displacementが極端な場合背面の突起などまでは再現できないものの木の幹などに数ピクセルの揺らぎを与えるレベルでは十分な近似だと思う.

とは言え誤解を与えるといけないので補足しておくと、この辺は扱い難い機能なので仮にレリーフマッププラグインをリリースする (かどうかすら未定、LWの限界を何とかする為、無理矢理実装した結果色々ややこしくてワケの分からんオプションが大量に有り、しかもそれを適切に設定しないと動かないというかなり破綻したシロモノになってしまっているので:-<) としてもこの辺の機能を付けるというワケでは無く、あくまでデモンストレーションで、自分が色々考えて面白いからという話題なのですが(要は自己満足(^^;;

しっかし、この辺って絵の完成度を詰める所のせいぜい数%の押し上げに過ぎないのですよねぇ、その数%を詰める所がプラグインの本質だと思うのだけど、少々不毛な気もしてみたりX-<

# displacementにこだわるのはクリーチャーが好きなのですな ;-)

現状(LWには乗ってないけど) SubPixel Displacementと比較するとメモリを全く消費しないのがメリット、逆にデメリットは背面の情報が無い為完全なシルエットとは言えない事と(これは自分のアルゴリズムに限定しての話、ただ上の論文の手法も結構シルエット自体は不安定な部分があるのも確か) 一部のアルゴリズムとの相性の悪さが予想される事、速度がテクスチャ探査律速なんで(単一画像ではそれ程では無いけど)複雑なテクスチャではかなり重くなる可能性がある事、といった所(まぁこのテクスチャの問題はLWに限定しての話でしか無いけど). まぁバンプの拡張としてはアリなのかもしれないと思ったり.

まぁ、SubPixel Displacementなんかも下手にレイトレやGIと併用するとレンダリング時間や消費メモリがとんでもない事になるのですが(笑)

、、、というかね、最近2GB(32bit Windowsでアプリが使える限界値)じゃメモリ足らないよorz

、、、遅延ライティングと合成を併用駆使すべしという話もアリ、レイトレが絡まなければ、の話だけど :-<

何かプリミティブだと使った時のイメージがわき難かったのでそれっぽいもので適用してイメージングしてみる(モデリングがショボいとか酷いとか以前の適当さなのは不問の方向で;-)

【レリーフマップなし(LWのバンプ)】

【レリーフマップあり】

、、、んー確かに頻繁に使うものでは無いにせよ、使い所によっては大きく絵のイメージ変わってくる可能性はあるのかもなぁ、逆に主題が引き立っていたらどうでも良い要素とも言えるし、、、あ゛ー(煮詰まり中

---------------

TANEさんのクロスシミュレータのデモ、日記に書いてある通りCygwinのdllとGLUT入れてみる、おーちゃんと動いた動いた(嬉)

で、感想ですが、、、率直な所これどう考えても乳揺れ用だろう(マジ、というかそうとしか見えない (※1)

というのは半分だけ冗談ですが、結構面白い動きしますね、旗のオブジェクトの方も伸びる事無く良い具合に形状保って非常にらしい動きしているし、オブジェクトの各頂点を仮想フックで吊るしている奴は動き自体ユニークで色々面白そうな使い方出来そう、デモのものは若干カートゥーンライクな気もするけど調整次第では筋肉モデルみたいな事もできないかなぁ(※3)

これでソレ系のプラグイン作ったらすごく面白そうなんだけど、動きやすい・動きにくい頂点でウェイト付けれるようにして、、、TANEさんが作るとPOV用とかになりそうだorz

※1) 氏の名誉の為にフォローしておくと、決して乳だけでは無く尻の事もちゃんと考えている(本人談 ※2)だそうです. いやマジいろんな意味ですげー人です(いや誉めてるんですよ(^^;;;

※2) でもKOJIさんとこの飲み会で半分冗談で「乳揺れ専用シミュレータを」と話してたら、、、ホントにそのものズバリ(まだ言うか)作っちゃうんだもんなぁ(^^;;

※3) しかし使い方を間違えると曙シミュレータになってしまうので注意(笑)

今日の運勢

うちあわせばしょをまちがえる...3点

、、、orz

---------------

という事でレリーフマップのUV対応、一応出来るには出来たのだが、、、

【レリーフマップなし】

【レリーフマップあり】

、、、どうもLWの仕様のかなりイヤな所(キャッシュ絡みもあり?)を踏んでしまったらしく、SDKの普通の方法では上の画像が出来ないため、UV用のプラグインを別途作成して半ば無理矢理実現している.

そのインターフェイスたるやUVを指定してからテクスチャをZ平面1m x 1mで貼るとそれがUVにマッピングされるというかなり謎のシロモノ :-<
インハウスツールなら良いけど、これはちょっと公開するものとしてはアレだろーという気も.

またLW本体のバンプを参照すると場合によっては計算が上手く行かない(かなり特殊な計算をしているので)という事もあり、自前でベクトルテクスチャを使用している、これでLW8で動かない事確定(苦笑)

自己の影も試してみたが、比較的勾配の緩やかなテクスチャでは上手く行くものの急勾配のテクスチャでは誤差を拾いまくるので実装は見送り. まぁ実装できてもシャープな(レイトレースシャドウのような)影になってしまうので、余り未練は無いのだけど. 個人的にはCG特有のシャープな影というのが大嫌い(屋外を演出するキーライトのごく一部を除く)なので ;-)

というかねーコレ重いのよ、計算的にはHyperVoxelのサーフェス版みたいな計算(※1)やってるから(笑)
(そのくせ他のObjectを遮蔽しないし、ちょっと使いづらい気もしなくもなかったり:-<

※1) 分かり易く書くとレリーフマップってのはつまりは局所的HeightFieldで、等値面のダイレクト(ボリューム)レンダリングアルゴリズムと同じ考え方なんよ、というトコロ(余計分かり難いか(^^;; ゲーム用途なら若干誤差が出ても良いので2分法のような方法で精度を落としてある程度高速に求めても問題無いのだけど、プリレンダの3D用途だと重要な所が全く違って出来るだけ破綻無くムービーに耐えうる精度で計算しなきゃならんという事もあって結局HyperVoxelのボリューム計算と同じような手法を採用している.

2006/1/13追記)

>そのくせ他のObjectを遮蔽しないし、
と書いたけどいけるかも.

めり込む物体が透明体や透明度マップ使っているとNGだけどね ;-)
、、、しかし今度はレリーフマップの影の問題が、、、(影がオブジェクトに落ちない)、、、何処かで割り切りをつけねばならぬのだろうけど、どうにも汎用的に使えるモノとは言い難い気分 :-<

---------------

先日のカメラマッチで少々不満を感じたので自作の行列言語を改造中、やはり電卓 (という用途・ソフト) はいい、心が休まる(苦笑)

コンピュータを使っていると関数電卓レベルではどうにもならないけど市販の計算ソフト(Matlabとか)まで持ち出す程では無いという用途が結構あるのだけど、コレって余り無いのかな？シェーダとか書いている時はグラフソフトとにらめっこして関数を設計する事がしばしばなのだけど、これも余り大規模だと覚えるのが面倒で面倒で(頭が悪いだけか(苦笑)

帰ってきました、という事で遅ればせながら、あけましておめでとうございます.

帰省中はPCが無かったので、プログラムのネタを何か思いつく度に組めないのがこたえて、禁断症状状態でした、思いついた事を検証できないというのはタバコが切れた時と同じ位イライラするものだと実感、、、ってその状態はどうなんだという気もするorz

後は親孝行というのも難しいものだなぁ、などと、所詮子供が親にしてやれる事など限られているのかもなぁと思ったり.

---------------

という事で帰省の目的の一つだったエピポーラ幾何など、一通り関連する本を通読して理解した気分になる、まぁこれだけでも今回の帰省の価値は十分にあったと思う、実際帰って早速カメラマッチ (6点以上の画像と空間座標の組み合わせからカメラを校正する) など作ってみたが一応ちゃんと一致している模様 (というか帰宅して即行でプログラム書き始めた by 禁断症状orz

別にアプリケーション化しているワケではないのだけど(LWには既にF911さんの作られている優秀なプラグインがあるので) 実際の導出過程はこんなカンジ (ただ自分専用で使っている自作の計算・行列処理用言語でのソースなので見ても分からないかも (ってダメじゃんorz

まぁ一応一括演算型の言語でほぼJavaScriptなどと同様の構文、行列の乗算は .演算子で転置行列が '演算子、要素は0インデックスで行列と一次元配列としての扱いは可逆、といった程度、とか書いとくと読めなくも無いかもしれないような、やっぱダメなような(えー

# ホントはPCで数式がもう少し楽に書ければ、その過程を貼り付けるのだけど :-<

まぁ別に何をするでは無いのだけど、どっかでいきなりカメラマッチしたくなる事があるかも (あるのか?) しれないし、知っていて損は無いかなぁ、程度の話. 一応上に書いた校正済みのカメラが2個あれば画像座標から空間上の点をできるのでソフトウェアモーションキャプチャもできるし、凸形状に限定すればその点群からデローネ分割を使ってメッシュを作る事なんかも可能、ちゃんとしたメッシュの流れを追うなら2画像のエピポーラ線をガイドにメッシュを貼ってゆく方が妥当だろうけど.

何より趣味でやっている分野なのに自分にとってどうやるのか分からないアルゴリズムがある時点で非常に気持ち悪いワケで、それが例え1つでも解消されるのは良い事なのであります ;-)

---------------

その他の作業予定)

・unRealがLW8対応限定 (まぁ仕方ないですよねorz) になってしまうらしいので、Toonエッジプラグインに少なくとも自分の使うかもしれない機能をつける、と言っても透明度対応とサーフェスピアシング程度だけど.

・レリーフマップ
というか、コレ自分とこの試験画像がNewtekのForumの方に晒されてたんだけどorz
作れるのは作れると思っているのだけど幾つか問題があって、一つは突起自体の自己の影でこれは他のシェーダとの相性から外す事になるかもしれない、という事、LWと同じシェーディングなら全部自前でやってしまって良いのだけど、他のシェーダ(例えばOGO_HikariとかG2とか自前シェーディング系)と組み合わせた時に完全なものを作るのは不可能、また影の計算式が不明もしくはインテグレートできない為、対応するとしても現状ではシャープなレイトレースシャドウ(not エリアライト)にしか対応できない. また方式の問題上GI (特にスカイライト系のライティング) との相性が余り良くない(これはバンプも同じだが、立体的になる分より相性の悪さが顕著化する可能性はある) そして最後にLW8では動かないかもしれないというトコロ.(法線を決定するのにベクトルテクスチャを使用しているのだけど、LW8のSDKではこの機能がバグっている為) 多分だがこの辺については回避策は無い.

、、、今年も問題山積 :-<

---------------

その他)

3万円分ほどレゴブロック買った、満足.

複素数も大体イメージ掴めた、満足.

実家で両親が2人して正月早々FXライトセーバー振り回してスターウォーズごっこをやっていたorz

買ってきたレゴのフェラーリを父が勝手に組み立ててた、その後正月の挨拶に来た取引先の人に嬉しそうに見せてたorz orz orz
(更にその後取引先の人と仮面ライダーのマスクが欲しいとか言う話で盛り上がったらしいorz

---------------

その他2)

TANEさんのClothシミュレータ実験が上がってるのでダウンロード、、、Cygwin入れてないから動かないorz

元の頂点位置に仮想フックを想定して形状を保つって考え方は面白いなぁとか、、、しかし内圧+元の形に戻るモデルってやっぱり乳なんでしょうか?(ヲイ、、、いやでもTANEさんの事だからそれ以外には考えられないような(マテコラ

# LWのClothとかだとパラメータが固めでないと伸びっぱなしになってしまいますが(^^;;

---------------

その他3)

KOJIさん所で洒落にならない話が上がっている模様 (公式BBSのNo. 817の記事) プログラマ必読の内容.

環境はWinXP SP2 + Shell拡張を行うアプリがインストされた環境 + ToolTipという所らしい、解決案からすると多分エクスプローラのシェルオブジェクトとインプロセスで動くShellエクステンションのの問題かしらん、しかし記事に書かれている通り表示スレッドと呼び出しスレッドが別という話ならもっとヤバい事になっている可能性もあるのかも X-<

コモンダイアログのFileのOpen/Save, シェルのフォルダ選択って殆どのアプリに影響する話な気が、、、まぁ暗黙にCoInitialize()を使っているアプリも多いので顕在化しないケースも多いのかもしれないけど :-<

自分としての対応はWinXPのSP2なんぞ使う奴が悪いという事で放置(えー
(まぁでもそういう所まで含め環境を選択するのはユーザーの責任でしょ、という所. プラグイン(dll)でCoInitialize()を呼ぶ訳にも行かんしね :-P

# まぁでも仕事関連には一報入れといた方が良さそう.