本日の大恥、油脂と一般的な炭化水素を混同していた、、、(一応化学系出身orz

先日のイオン化傾向を忘れていた件もそうだけど、ここまで来るとちょっと化学の再勉強しなきゃマズいかもしれない(涙)

# 勉強はどんなものであれ、できる時にしておいた方が良いと気づくのは大抵社会人になってからなのかもしれない、当時学校に行っている時はそうは思わなかったんだけど(苦笑)

昨日書いたLWの屈折率の問題、実際の所色々試した結果、設定上

物体A(屈折率Ea) → 物体B(屈折率Eb) → 物体C(屈折率Ec) → 物体D

と設定されている場合、実際にLWが計算している屈折率は

物体A(屈折率Ea'=Ea/1.0) → 物体B(屈折率Eb':=Eb/Ea) → 物体C(屈折率Ec':=Ec/Eb) → 物体D

となっているようでソリッドを仮定している模様(ちょい中途半端だが)、屈折ベクトルの計算は通常通り.

、、、まぁ分かるけど、これ全てのサーフェスにプラグインが適用されてればLWと同様の結果が再現できるけど、そうでなければ同一の実装できないよなぁ、といったカンジでもう少しPluginの事も考えて欲しいなぁというトコロ(ShaderAccessに以前の屈折率が入っていれば良いだけなのに:-<

多分上手く再現しているプラグインでも
プラグイン適用の透明体 → プラグイン適用されてない透明体 → 物体
とかでトレースすると上手く行かなくなる筈 X-<

ちなみにまだ屈折→反射→屈折とかは試してないのでこの場合どう計算しているのかはまだ不明.

# 昨日露骨に変と書いたのはちょっと言い過ぎかもしれませんね、訂正.

※追記)
屈折→反射→屈折の場合は
屈折(屈折率Ea'=Ea/1.0) → 反射 → 屈折(Eb'=Eb/Ea)

としてレイに現在の屈折率が入っている模様、、、やっぱ独自プラグインで対応するなら周辺ライブラリとしてTLSでpush/popして行かねばならぬ模様. でも対応しても他の人の作ったフルタイプのプラグインも併用するとやっぱダメダメになるなぁX-<

かといって複数シェーダ適用した呼び出しを考えるとstaticなバッファにデータは格納したくないし、、、

LW8.3の日本語パッチが出たので早速試してみるが、、、例のバンプテクスチャの問題直ってない:-<
恐らく同じ問題が原因になっているであろう標準機能の'Surf Mixer'のバンプ機能も以前どおり正常に動いておらず、以前の8.2.1の時の挙動から該当部分については修正ナシという事かもしれない.

という事でもう暫く8.xは正式サポート外、という事で. まぁホビーユーズで静止画メインなので自分的には余り7.5でも困らないのだが、まぁこのまま放置って事なら機能的に紛らわしいので、あてつけがましく (というか実際半分はその通りだが:-P) 関連して問題となるプラグインにバージョンチェック入れて7.x以前までしかサポートしないようにするのもアリかもとも思ったり、実際問題として余り自分matter以外の問題で懸念事項として気を割かれるのもストレスになるだけだし :-< ＞DLページの注意書きとか

# ついでに書くと、再構成フィルタのランチョスを使用した際にAdaptive Samplingの有無で最終的な画像イメージが大きく変わってしまう問題も修正されてない模様、、、多分sinc系のフィルタだと思うから、Adaptive時の再レンダリングのピクセル幅と再構成に必要な幅をミスってるんじゃないか、とか思うんだけどなぁ、、、という事で表題の通りダメだこりゃ、といったカンジ.

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

DHMさんのページで書かれているLWの屈折率の話、少々調べてみたのだが、というか露骨に変(笑)＞LWの屈折率の扱い
一応基本的な計算は通常の屈折ベクトルの計算なのだが、これが場合によって例えば

屈折率1.5の物体A → 屈折率1.5の物体B → 屈折率1.5の物体C → 物体D

として屈折した場合にAの表面でBとCの屈折率が1.0(無視)で扱われていたり、別のテストでは

屈折率1.5の物体A → 屈折率1.0の物体B → 屈折率1.0の物体C → 物体D

とした場合に正確な計算ではAの表面には1回だけ屈折した結果が入る筈がAで屈折した後、通常屈折しない筈のBもしくはCで良く分からない値で屈折した結果が入っている模様(実際にはB,Cは半分だけAと重なるようにして検証している)、、、というかこれは流石に独自方式とか以前の問題だと思うのだが(大汗)

と言っても1次レイもしくは奇数レイだけ特殊に扱われるワケでも無いようで、別のテストで上の画像のカメラの前に別の透明(屈折率1.0, 1.5の両方でテスト)した場合にはその向こうのObjは上と同じ結果でレンダリングされている :-<

、、、うちのプラグインも一応影響されるのだけど、どうしたものかな、自分のプラグインの場合それ程クリティカルじゃないから対応しないってのもアリかもしれん(微妙に問題がありそうなのはTB_ShadowCompだが、これも逃げ道あるし(笑)

# というかLWって結構こういうのってあるんだよね、specularの式がSDKに記載されているBlinnのHalfwayと微妙に違う結果になったり、テクスチャレイヤの合成モード(乗算とか)の演算が露骨に変でRGBの計算式を意識した時に予測通りの結果にならなくて問題になったり(特にテクスチャでパラメータのパーセンテージを切り分けている所とか、実はこれが2ndSurfプラグイン作った理由の一つでもあるけど:-<
、、、とは言えその方式でメリットがあるような方法を使っているワケでも無く、何かこういうのって露骨な顧客囲い込みっぽくてイヤだなぁ

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

ってゆーかやってらんねー、もー知らんってのが本音ですよ(苦笑)

GW中に風邪をうつされて先週一週間死亡、現在ようやく熱は下がるものの喉の腫れが酷くカラオケでひたすら歌ってもここまでは酷くならないような状態で、ここ数年風邪らしい風邪もひいていなかっただけに色々ダメージが大きい、馬鹿は風邪をひかないという話を謳歌していたのだが、この風邪は馬鹿でもひくらしく、熱があった時はPCに向かうと交感神経が刺激されて余計に熱が上がるという悪循環に.

現在在宅仕事(というか自営業)なので健康管理には事の他気を遣う、企業勤務であれば風邪でゲホゲホ言いながらも会社にさえ行っていればそれなりに体裁が繕えるのであるが、そうも行かぬのが辛いトコロ. そういう状態で治そうとして安静にしているとほぼ確実に引き篭もり状態になってしまって気がふさぐ事しきりで実に精神衛生上よろしくない:-<

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

Junkを更新、TB_ShadowCompでレイトレース反射・屈折及び半透明の影をサポートしました、という事で. ShaderとPixelFilterにオプションがあるので少々分かり辛いかもしれないのだが、Shaderのオプションはサーフェス上の反射・屈折に影を描画するかどうか、PixelFilter側はサーフェスの透明度による半透明の影を表現するかどうかというオプションになります.

また以前はShaderはサーフェス上のどの順番で適用しても良かったのだけど、上記オプションを使う場合に反射・屈折や透明度の設定はShaderが適用された時点の値を参照する為、チャンネルシェーダの後、フルシェーダの前に適用するのが最も良い結果になるかと思います、という事で.

しかしたまに外国の人からプラグインに絡んでメールを貰うのだが、向こうのデザイン系のプロダクションとか、ハリウッドでSFX関連やっている人もいるようで、こうして考えると実は海外ではLWってまだまだ使われているのかな、とか. 日本で言われている程状況的に酷くないのかなとも思ってしまう. 日本のLWのがダメだという事情はある意味国民性として大きな流れに流され易い国民性も影響しているのかなぁトカ.

まぁ実際の所詳しい事情までは分からないし、LWといっても実際ダメだと言われている所は紛れもない事実なので、そういった部分をインハウスツールバリバリで解決できるようなプロダクションの状況もまた特殊なのかもしれないのだが.

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

少々TB_NormalMapについて問い合わせがあったので、方式について補足しておくとTB_NormalMapでサポートしているマップ入力はObjectSpaceのノーマルマップで、プラグイン内部ではこれをTangentSpaceに変換して扱っています、またTangentSpaceで出力されたノーマルマップはサポートしていません、というトコロ.

内部で少々複雑な計算をしている為、レンダリングには時間がかかるものの、それ程増加傾向が無いので複雑なシーンではある程度吸収されるだろうという見込みにて.

TangentSpaceに対応して欲しいという要望もあるのだが、一応一般的なTangentSpaceの直交基底ベクトルの求め方については調べたもののLW上のデータだけでは対応できない為、内部でジオメトリをスキャンし少々面倒な計算をした上でキャッシュ化するエンジンを別途起こさねばならず、また直交基底がマッピング座標系に依存する事から現行のLWのテクスチャエディタでは無く、マップ座標系が１つだけとなるようなインターフェイスを別途起こさない限りは対応不可能と判断した為現状対応予定無し、まぁ現行のものでもTangentSpaceのものと同じ事は出来るので、というトコロにて;-)

# 後は実際自分が満足にノーマルマップを作れる環境を持っていないのも一つの理由、ZBrushとか持っていたらやる気も出るのだが、如何せん何やらアクティベーションやらあるらしく、正直そういうのうっとおしいので買う気ナシ、余りLWのプラグインとか買う気になれないのもその部分で、ただでさえLWのドングルがうっとおしいのにそれ以上にメーカーやらライセンス管理やら意識しなければならない縛りがあるのが嫌いというトコロ、特にプラグインはドングル交換とかでも影響されるし、気にする所はできるだけ少ない方が良い、どうにも心配性なのでinstall and forgetでないソフトは正直できるだけ使いたくないのが本音:-P

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

先日書いたCOMのActiveScriptエンジンのメモリリークの話、紹介したページのサンプルが間違っているようで、IActiveScriptのClose()を呼び忘れている模様、これをコールすればちゃんと動作するように. 後部分的にリファレンスカウンタの扱いが変だったり、サンプルをそのまま信じてしまうのも問題かと反省、というかそれ位気づけよ＞自分

という事で少々間抜けな話(自分が、ね;-)

# 上記内容仕事関連で調べたのだが、少なくとも暫くは使わなくなりそうな具合、というか迷走中につき何とも何とも. どのような形でも個人的には構わないのだが、若干の苦言を呈するなら意図はそれが物事の起点から終点まで一環していて初めて意図足り得るワケで、その辺だけは見失ってくれるなよ、と(これは友人に対してだけで無く、1ヶ月後の己に対しても.

ここ数日何故かJScript + WSHなど勉強中、というのも仕事で使うかもしれない、というトコロなのだが.
という事でまずは自作アプリにスクリプトエンジンを組み込む所からスタート(笑)

参考資料
http://www.microsoft.com/mind/0297/activescripting.asp

まぁ大体はこの資料のサンプルにある通り、CreateObjectについてもCLSIDFromProgIDからCoCreateInstanceでIUnknown取得してIDispatchをQIしてやれば実装できている模様、取り敢えずExcelで試した所ちゃんと動いている.

自作クラスについても普通にCOMでIDispatchを実装してそれを返すようにしてやれば動作する、インターフェイス問い合わせはリソースに格納したタイプライブラリを返してやればお手軽なカンジ.

ただ問題点はサンプルで使われている名前付きのトップレベルオブジェクト(shell == CHostShell)のリファレンスカウンタがスクリプトに渡された場合に正常に操作されていない模様でスクリプトが終了して全てのリファレンスを外してもリファレンスカウンタが0にならない(スクリプトがshellを参照しない場合は解放される)、タイプライブラリを使った方法が悪いのか、とも思ったのだが、同一の方法でもメソッドから自作のクラスを返す場合はちゃんと処理されている. 結局解決出来ず、ScriptSite(スクリプトインタプリタのデータ構造)を解放する際に強制解放してしまう事に:-<

取り合えずJScript, VBScript, ActivePerlでの動作は確認、ただPerlの配列構造が不明で、VARIANTのSafeArrayを介しても配列を渡す事ができなかったり、JScriptがSafeArrayをサポートしてない為、配列を介したアクセスはinもしくはoutの一方通行に限定される形(なおJScriptからSafeArrayを作る場合はScripting.Dictionaryを使って無理矢理作る)、この辺はやはり単一引数渡しで我慢するか、JScript/VBScriptのみのサポートに限定するしかないのだろうか？

しかしCOMは久しぶりに触ったけど、ストレスが溜まる(笑) 面倒なデータ構造が大量にあり、そのかしこに全てはあの言語の為にという腐った設計が見て取れるから(※1)で、その辺はさっさと.NETに以降して欲しい所、ただこちらはこちらで不安はあるが、、、(というかVB.NETって普及しているのだろうか?

まぁ所詮は汎用言語としてのスクリプト言語、上記のインターフェイスを使った所で構文規則までは拡張できない為、せいぜいライブラリ程度の拡張になる、そういった意味では特化型スクリプト程の効率の向上は図れない為、ターゲット的にはエンドユーザー向けのものに近いと言える. ライブラリはActiveXなどで実装すれば別にWSHやブラウザでも使えるので、そうすると意味があるのはプログラムモデルを規定したり(イベント発生時にスクリプトにプログラム側からコールバックする場合) 複数のスクリプトインスタンスを扱い必要に応じてそれらを呼び出す場合といった所かもしれない、まぁレジストリに登録しなくて良いのは大きいが;-)

と、ここまでやって大体目処は立ったし、正直飽きたので一区切りとする、まぁ後は色々、例えばスプライト等を持ったWindowを実装してJavaScriptでマルチメディアサポートしたインタラクティブなゲームが作れるような環境(HSPのようなもの)&それをパッケージ化して配布できるようなものを作るとか、3DViewerのようなものに組み込んでイベントに対しオーサリングできるようにするとか、色々夢は膨らむものの、如何せん自分がそういう所に興味が余り無い事や、汎用言語で構文までコントロールできないとなると3Dのような特化分野での効率化には限界があるので、そういった意味ではこのインターフェイスでマクロを実装する場合にはもっと汎用的なアプリの極めてマクロ的な挙動に対しスクリプト化するアプローチが正解な気がする;-)

※1) 余談だがmalloc/freeがシステムコールでは無くライブラリコールとして実装されているのはWin32の致命的な欠陥だと思うX-<
DOS時代から引きずっているライブラリの遺産な気もするのだが、ヒープの扱い自体はプロセスローカルとしてそれを使うようにすればオーバーヘッドも通常のライブラリコールと違わないワケで、何でモジュール混在環境の単一プロセスでClassを受け渡す程度でこんな面倒な事をしなければならないのかと. 後は大人数プロジェクトの場合の切り分けの問題とかも含めて、、、(※2)

※2) msvcrtを使うというのも一つの手ではあるのだが、この辺は一人で組んでいるものならそもそも気にしない所で、逆に企業で大人数となると、以前勤めてた企業(一応メンバーはVC++プログラマという事になっている)なんかの場合、その話をするとmsvcrtを使うってどういう事？とかいう回答が返ってきてしまうのでダメダメだったりした、はっきり言ってOSのプロセスモデルの詳細が頭の中に入ってないC/C++プログラマは死んで良いと思うのだが(※3):-P

※3) 毒吐きついでに書いておくと企業でC++プログラマというと高度な事をやっているように見られる部分もあるのだが、以前勤めてた企業のクライアント系C++プログラマの場合MFCでダイアログベースのアプリしか作れないようなプログラマが殆どだったりするワケで、そういった意味では実はこのレベルのプログラムはバッチファイルの少々高度なもの程度のものを作っている程度でしかない、そういった中でVBプログラマを馬鹿にするような会話が出る度にバカバカしく思う事しきりだったのだが、というか所詮言語なんて道具だしプログラマなら複数の言語使えて当たり前じゃーんみたいな(語尾上げ(※4)

※4) でも友人によるとそれでは足りないようで言語処理系の一つも自分で作れぬようではプログラマとは言わない(美味しんぼ風に)と言う輩もいたりするワケですが(まぁそれはそれで真理かもしれないが(笑)

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

ちょっとGW明けまで出かけてきます.