引き続きJavaScript、コアの構文評価ルーチンは動くようになった、左辺値の評価や入れ子になったオブジェクトメンバの参照、クロージャ呼び出しにprototypeによるオブジェクト生成等々、とは言っても制御構造なんかは動いてないのだが、実は制御構文は定型化してしまえば簡単なので後回し. 取り敢えず内部構造のリファクタリングを先に行う.

しかしこうして改めて見るとJavaScriptって結構純粋指向な言語だなぁなどと思ったり、構文が似ているだけでC++やJavaとはクラスの実体の考え方が違いますよ. その反面prototypeによる継承というか、実際はちょっと違ってJavaScriptの場合オブジェクトの実体はそもそもコンテキスト(辞書のようなもの)で、通常オブジェクトが生成される時は関数呼び出しのコンテキストとthisに格納されるオブジェクト本体のコンテキストが格納され、prototypeが指定されている時はこのオブジェクトが新規では無くprototypeが指すオブジェクトがコピー(浅いコピー)されてアサインされ、これがnew構文から戻った時点で生成されたオブジェクトになるのだが、結構解説ページなど見てるとprototypeを継承と間違えてしまいそうで結構危ういなぁと思ったり.

当然prototypeを別変数に格納しておいて、後でオリジナルを書き換えると当然それ以降生成されるオブジェクトにも変更は反映されていたりするのですな(笑)

後はデリゲート(対象オブジェクトが指定されているクロージャのようなもの、JavaScriptの場合全てはオブジェクトから独立したクロージャで、それがオブジェクトメンバに格納されているだけ、なので構文レベルで別途サポートが必要)やプロパティ機能、あるいは遅延評価など追加してみるのも面白いかも、とか. 多分イテレータ処理は関数で書けそうな予感なので言語組み込みでは構文糖以外では不要な気もしていたり. 折角動的でインタプリタ内蔵なのでLispライクなマクロ機能を考えて見るのもアリかも等々(まぁLispと比較すると構文記述の一貫性が無いのでevalに対するテンプレート展開になってしまうかもしれないが、、、

ただ、、、JavaScriptのこの純粋さは逆に大規模なプログラムを書く時は邪魔になるかもなぁ、という気もする. 動的解決型言語はある意味好きなのだけど、メソッド結合等の実行時エラーなどで規模が大きくなるとデバッグが面倒な気がする、Objective-Cにも同じ事思った気がするけど(笑)

、、、まぁそれ以前にスクリプトでそんな大きな規模のプログラムを書こうとする事自体間違いな気もするけど :-P

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

上手くやればDOS(16bit)で動くJavaScriptが作れるかも、と思ったのだけど、Digital Mars C++でコンパイルしたらエンジン部分だけで即効コードセグメントサイズが64kbを越えてしまった、HP200LXでポケコンライクというのも考えたのだが少々無理だった模様、残念.

# しかし一応ラージモデルは指定してるし、exeも吐けてる、ただエラーメッセージが'OPTLINK : Error 19: Segment Size Exceeds 64k : MAIN_TEXT'という所、内部でjmpがアセンブラでどう展開されてるか見てみないとイカンかもなー、普通これでダメになるとも思えないのだが、、、

# (追記) DMCはそもそもアセンブラコードを吐いてくれない模様orz、、、しかし取り敢えず-NVオプションを付けたらコンパイル出来た、vtableのアクセスにfarデータを許可するオプションらしい. これでいーのかな？

# (2005/09/02追記) -NVオプションでは無く-NSオプション(各関数をそれぞれのコードセグメントに配置)だった模様、但しこれを付けてやると今度はスタックオーバーフローを起こす(sigh) 流れ的にそんなにスタックを使ってるとも思えない(固定サイズでバッファを取っている所は無い)のだけど、、、ただ16bitDOSの場合スタックは最大で64kb、場合によっては数10kbしか取れないのでその可能性もあるなぁ、うーむ:-<

帰省中にふと思い立ってJavaScriptのインタプリタなど書いている、という事で先日書いたLWプラグインの話はもう暫く見送りの予定. 現状はこっちの方が面白い(笑)

TB_ShaderManで取り敢えずある程度の理解度まで言語作成はやったつもりだが、どちらかというと特化型言語で注力したのはシェーディングという莫大な反復計算をどのように効率良く実現できるか、という部分であり汎用言語では無かった為、その部分の勉強不足を補う為にもJavaScriptなら現状の一般的なスクリプトの機能の大半を備えている為、勉強としてはある程度十分であろうという所.

方式は構文木を辿る形式 (実際Server上で動かしたりや反復計算やクリティカルなループを処理しないならこれで十分だろう) で現状パーサが完了し、エバリュエータの内部構造を如何に楽に表現するか、という事で内部データ構造を色々調整している所. GC方式はリファレンスカウンタとMark & Sweepを組み合わせたものでコンパクションはサポートしない. 出来るだけシンプルな構成にしたかったのだが、メンテの簡略化の為C++の内部構造にマッピングしている為、任意タイミングでのGCをサポートするには評価時の中間計算オブジェクトが問題になる. 速度をある程度確保する為、色々悩んだ結果2重のリファレンスカウンタで管理したり (例外発生時のオブジェクト回収が発生するせいで余計に構造が複雑になる) とGC周りはかなり複雑なソースになってしまっている、コアは500行程度だが、正直これが他人のコードなら自分は絶対メンテはしたくない(笑)

まぁもう暫く続ける予定、ライブラリはともかく言語要素としてはJavaScript 1.1程度の構文を処理できる程度までは作るつもり. 頭の中で理解したつもりになっていても実際作ってみると色々な事が見えてくるので実にに楽しい.

# 某氏(Cプログラマ)によく「C++って要るかぁ？」と言われてしまうのだが、今回正直作ってて同じモノをCでは絶対書きたくないと心底思う、例外やGCまで考慮したオブジェクトの寿命管理面倒過ぎて(※1)、、、ええ、もうヘタレと言われても全然構いませんよ、みたいな(笑)

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

※1) そういった所ではLScriptの文法は比較的内部管理の楽な所に落ち着いているような、システム定義オブジェクトのみ構造体構造を許可し、ユーザーに提供されるのはPrimitive型のみとか、Perlなんかもオブジェクトの寿命はリファレンスカウンタonlyらしい (これが配列に配列を入れられない理由だが) し、実際マクロ言語や数10行のスクリプトメインならメモリ管理はリファレンスカウンタonlyの方が遥かに楽だなぁと思ったり、、、Full GCやオブジェクトサポートの為のデータ構造もそれ程では無いにしてもリファレンスカウンタに比べると遥かに大きなオーバーヘッドがあるし(※2)

※2) 余談だがよく「オブジェクト指向はより直感的だ」という話があるのだが、正直コレ結構疑問、粒度の粗いライブラリを「使う」レベルのオブジェクト指向は確かにユーザーにとって容易なのだが、クラスを作るとなるとこれが逆転するように思う. 実際C++が普及し始めた当初これでプログラマは設計力や想定力によって「クラスを使う側」と「クラスを作る側」の2層に分かれ両者のスキルレベルには大きな溝が出来るなぁと思ったのだが、そんなカンジ(※3)、、、まぁC++の場合はそれ以前にメモリ剥き出しのアーキテクチャでクラスを設計せねばならんという大きな問題があるのだけど(笑)

※3) まぁ実際にはオブジェクト指向言語で無くても両者の間には大きな差があったのかもしれない、仕事でやってるとたまにグローバル変数とフラットなデータ構造 (というか変数の山) やMFCのハンドラ内にサンプルサイトから拾ってきたようなコードでフラットに手続きを羅列して1つの処理を行っていたりと、かなりクラクラする内容も多かったり.

業務連絡、仕事もある程度山場を抜けた(?)ので本日より盆休みで実家に帰ります、帰宅は気分と事情次第という事で. 今回は携帯は忘れない予定につき急な用件はそちらにお願いします.

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

戻ってからの話になるけど、TB_IPlaneにテクスチャAAの機能付けるかも？(まだちょい未定)

【現在調整中、普通にアンチクォリティLow(Adaptive off)のヤツ】

ただサンプリングスポットサイズだけ設定してテクスチャ自体はLWの機能を使うつもりなのだけど、LWのテクスチャエンジンと標準のスポットサイズ計算式が変(?)なので、それらをどうサポートする形にするのか、かなり問題.

文章考えるのも面倒なので、以下独り言風に

「LWのShaderに渡されるspotサイズってピクセルのスポットサイズをAAの最大ピクセルサンプル数でスケーリングした値になっているんだけど、この方式ってAdaptiveサンプリング使わないなら妥当だけど、Adaptiveサンプリング有りだとちょっと変じゃない？というかちゃんと高周波成分を持った部分全域でAdaptiveが処理されれば問題無いけど、テクスチャによってはピクセル欠ける事になるよ、というか実際欠けてるし」

「LWが計算しているスポットスケールは単にカメラからシェーディング位置までの距離の関数になっているみたいで、視線ベクトルと法線の角度による影響が考慮されてないみたい、確かにLWのやり方は若干テクスチャがシャープになるけど視線と法線が直角を成す近傍ではテクスチャ欠けるでしょ、コレ. 後広い平面をテクスチャを貼ってレンダリングした際に遠距離部分のエイリアスが酷いのもこれが原因だし、実際自前でそういう計算して置き換えたらちゃんと直ったし」

「とは言ってもLW本体のMIPマップエンジンが本当に単純な構成だから、これでちゃんと計算した値にすると今度はMIPのボケが顕著に出るね. 本当はここはちゃんとテクスチャの再構築フィルタを設定して欲しいんだが、少なくともRenderManではできるけど:-P」

「LW8になってテクスチャエンジンが若干変わったというけど、遠景でのエイリアスはそんなに変わった印象は受けなかったなぁ、まぁLW8はバグがちゃんと直るまで本格的に対応するつもりも無いのでどーでもいーけど、つーかさっさとバグ直せよ(--#」

「無限平面の上にポリゴンオブジェクトを重ねて同じテクスチャを使う事を考えるとLW標準の計算式を使う方が良いのだけど、これだと特に無限平面みたいなものではクォリティが悪くなるというか使い物にならない、自前の計算式の場合は結果が微妙にLWと異なるので合成に問題があるケースも想定される、後LWのMIPエンジンをそのまま使うのでボケが結構強い、何の対策もしてないごくそのままのMIPエンジンだから仕方ないけど. 結局は2つの方式を選択式にするのがベストなんだろうけど、ユーザーに分かり難いオプションになる気もするのが悩み所だよなぁ」

などなど、まーそんなカンジです.

何やら大量にメールが来ている、何かと思えば前の会社の友達と色々やりとりしている擬似MLで、どうもコミケだとかでお台場にある会社の周辺がえらい事になっているらしい、曰く色々な意味で憂鬱あるいはネタだという事で盛り上がっている模様.

しかし本音をいうと個人的にはアニメオタクと呼ばれる人たちが羨ましく思う、風呂に入らぬなどというのはそもそれ以前に人間として論外なのだが、どのようなベクトルであれ、煩悩を向ける対象があるのは、何かを生み出す原動力になり得る為. 最近痛感するのは所詮幾ら努力しても煩悩にはかなわぬという所、何かを生み出すエネルギーやそれを理解できる力を得られるなら魂でも売り渡す覚悟だが、所詮興味の持てぬものには持てぬ (神経回路がそのように想起されない) ワケで、特にグラフィックやモデリング、そういう煩悩があるというのは非常に力になるのでは、と思う.

また何かを作る以外でも、実は弟がアニメオタク(漫画オタクか? 何か色々種類があるのだと講釈された記憶があるのだが定かに非ず) をやっていて、その生活を見ていて思うのはどのような下らぬものであれ、膨大な消費に支えられ、それを楽しいと感じられる生活、また人生観というのは非常に楽しいのではないかと思う. 自分の場合その辺に殆ど興味が無く、ただ己に何ができるのか、という部分にしか関心が無い為、己の無力さと頭の悪さに絶望する羽目になる. そんな中、メディアを含む己を取り巻く環境を消費する事だけで自我空間を形成できるとしたら、それは素晴らしく楽しい人生ではないのか、とも思ったりする.

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

<割とどうでも良い事につき削除>

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

先日書いたLW9のシェーダーノード、画面写真が出ていた. 見た限り殆ど自分のと同じようなパラメータという所で少々残念、というのもTB_ShaderTreeについては自分が使う上で、各種Surface内部のパラメータが勝手に代わってはマズい、という事でああいったSDKそのままのルートノード構成になっているのだが、実際にはこれはユーザーにとってベストの解とは思えぬ為. この方式ではShaderTreeを使うユーザーがLWのサーフェスの各チャンネルが例えば値なのかベクトルなのか、あるいはカラーなのかなどをちゃんと理解せねばならない. 実際TB_ShaderTreeは大多数にとってはまだ難しいと思う.

実際には例えばユーザーがspecularにカラー出力のノードをアタッチする場合、それはspecularレベルにそのカラーの輝度を割り当てたいのでは無く、あくまでシェーディングのspecularで表される部分にその色を割り当てたいのだ. しかしこれをやってしまう場合LWのシェーディングアルゴリズムの制約から、プラグインが勝手に各チャンネルをカスタムシェーディング向けに変更してしまわねば実現できない、これは自分が他のシェーダーと組み合わせるのに都合が悪いのがあるのだが、標準機能であればその部分をある程度ノードはノードとして限定した上でLWのシェーディング部分を拡張できる余地があるので、もう少し頑張って欲しい気がするのだが、、、

無論ノード方式でどこまでできるのか、という臨界点は誤ってはいけないワケで. 以前TB_ShaderTreeでNonlinear Reflection(というらしい)エフェクトを実装してみた所、かなり複雑なノード構成になってしまったり、逆にプログラム言語で実装するとこの辺は簡単なワケで(笑) まぁその辺が限界だろうなぁ、とか色々あり、ある部分ではTB_ShaderTreeのデフォルトパラメータはそういった複雑な構成のノードになるのを如何に軽減するか、という試みでもあったのだが. 新しく出てくるいノードタイプのエディタならもっとその自分がノード方式の限界では、と考えている部分を如何に解消するアプローチを考案するか、という所に興味があったので(まだ断定はできないが) あまりにLWの内部パラメータそのままな実装に少々残念な気分になってしまったり(苦笑)

一部で話題のFPrime 2.0 & G2 1.7 3日間だけのセールという事で見に行ったんだけど、セール対象はG2のみという事なんで、取り敢えず見送り. G2の代わりは自作シェーダで十分なので、本命はライティングの調整用にFPrimeは興味があるのだけど、自分の作るシーンの場合現状Shaderが大量に入っているのが悩み(^^;;

ただそこでちょっと目に付いたのがHP上のSSSの謳い文句、記憶違いでなければ、以前試してもらった所ではG2のSSSは正確にはSSSでは無くSolid Translucentだった気がする.

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

まぁ、割とどうでも良い内容なので突っ込むのもどうかとも思うし、SSSという言葉自体一般用語化しているので厳密に定義するのも難しいのだが、LWのシェーダでSSSを謳うシェーダの場合主に実現の方式により2系統ある (と考えている)

多いのは先に書いたSolid Translucent系のアルゴリズムで、シェーディング位置から見た場合に光源の光がどれだけ透過したか、その透過距離でSSS項(とは言いたくないが)を決定するもので、G2, ChanLum, sabreの透過 (名前忘れた) ノードなどがこの方式になる、TB_ShaderTreeのTranslucentノードもこの方式を取っている.

この方式は光の透過が支配的な物体についてはそれをある程度十分に表現し得る為、蝋などの表現には良いのだが、拡散反射自体がSSSの影響を受けている人間の皮膚やゴム、大理石などを表現できるものでは無い、逆に元々このSSSブームの火付け役となったHenrik Wann Jensen氏の発表にあるソフトな拡散反射については殆ど表現できず (物体の厚みによる影響以外は殆ど定数項になる) その部分については通常のLambertian diffuseあるいは人間の皮膚を表現する場合にはOren-nayer's diffuseなどで誤魔化すのが主流の模様.

逆に言うとこの方式は本来のSSSというよりは、そのブームでサンプル画像によく挙げられた(SSSの本質では無いものの、素人にも分かり易い)光に手をかざした時にそれが透けて見える画像のエフェクトを実現するものと言える.

もう一つの方式は拡散反射自体をSSSとして表現するもの (Diffuse with multiscattering) で、これが実は本来のHenrik Wann Jensen氏のSSSに近いものなのだが、物体全域に渡ってサンプリングしたものを重み関数(件の論文では内部多重散乱を近似する為に双極子近似を用いている)を加味して積算し、その結果がシェーディング位置の拡散反射となるもので、これが実際のBSSRDFに近いものなのだが、これについては自分の知る限りLWのプラグインで実現しているのはOGO_Hikari位のものだと思う.

実際これらの方式を比較してみると以下のような画像になる(SSS項のみレンダリング)この画像では平行光源1灯だけだが、それでも透過減衰だけで陰影を誤魔化している前者に比べ、後者の方式はある程度ちゃんと物体形状により拡散反射項が作成さる、これが複雑な形状や複雑なライティングが絡むと更に差異は大きくなる(注：シェーダごとに設定パラメータが大きく異なる為、設定については必ずしも同じ物を表している訳では無い)

【元画像】(LW標準のdiffuse + ambient)

【Solid translucent】(TB_ShaderTree使用)

【Solid translucent(ブラー有り)】(TB_ShaderTree使用)

【Diffuse with multiscattering】(TB_ShaderMan + 独自SSSシェーダ(未公開)、背面透過を強めに設定)

リリース直後G2のSSSがイマイチfakeっぽい仕上がりになるという話があったのだが、実は上に書いた様な話で、SSSの透過のみの計算で拡散反射項(物体が柔らかく見える条件)については通常のシェーディングと同じような方式(LW標準方式よりは少し凝っている)で近似してしまっているからという所だと思いながら見ていたり(笑)

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

、、、まぁ、割とどうでも良い事だし、それをSSSと言ってもアカデミックには許されなくてもマーケティング的には構わないワケだし、実際後者の方式をLWで動く形で実装すると色々面倒なのである意味妥当とも言えるのだが、どうにも気になって仕方ない辺りこれだからオタクってやーねぇみたいなそんなカンジ＞自分(爆)

# なおLWのSSS系シェーダのSkaについてはどの系列のアルゴリズムか分からなかった、diffuseはそのままで光の浸透のみなのでSSS項の話は前者に近い気もするのだが、大抵のシェーダは見れば大体どういった方式&ある程度の使われている数式のタイプ等は分かるつもりだったんだけどまだまだ、という所ですな(苦笑)

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

暇みてはアーマードコアの新作三昧、正直別に面白いという訳ではないのだが(笑) つまりは例のごとくの出来でしか無いワケで、半ば惰性でやっているだけでなんかこのゲーム何時も見ていて思うのだけど、ミリタリーオタク的な何か妙なストイズムに対するナルシチズムみたいなモノ感じるんだよねぇ、所詮拘りなんて結果に現れなきゃ何の意味も無いワケで、そこら辺がなんとゆーかオタクっぽい自己満足みたいなそんな印象.

ま、これは自分に対する戒めでもアリ、技術屋 (あるいはプログラムオタク) として拘るべき所は拘っても良いけど、所詮結果の出ない拘りは自己満足でしか無く、価値など無いワケであります、ええ. まぁだからといってプライドを捨ててヘタレSEの仲間入りとかそういうのじゃなく、拘るとしてもその拘りが意味を成すのかどうか、その意図は何か、ちゃんと大局的に捉えるべし、とまーそんなトコロ :-P

Siggraphポーーーーゥ！！LightWave 9.0 Future Preview来ましたね〜

やっぱウチとしては注目すべきはココでしょうオッケーーーーィ

>Material Shader Node Graph

(笑) まぁでも真面目な話で言うと本来本体が持つのが最も妥当な機能なんでそうあるべきでしょう、という所にて. ただ'Using existing LightWave shaders'つーことはもっと粒度が粗いのかしらん? まぁ出てみないと分からん部分もあり、これが自分の期待通りのものであれば嬉しいし、そうでなければTB_ShaderTreeを作り続ける羽目になるでしょう(余りプラグインとか他の環境に依存するものを作り込むのも結構不毛な気がするんだよね、結局今の段階ではLWのレンダリング機能が自分の及第点に達してない為作る羽目になっているのだけど.)

他にもN-Gonサポートにエッジサポート、'Visibly similar to micro-poly displacement'などなどジオメトリに関しては自分の不満と思っていた個所が文面の通りならかなり改善されるという事で結構期待.今までLWのSubdivisionは独自方式だったけどCatmull/Clark曲面に変更らしいですね、これも他のソフトとの互換性を考えると嬉しい限り. ただ一寸気になるのはSubPixel Displacementがサブパッチと同じ個所に書かれていると言う所、最悪の仮定をするとサブパッチのテッセレーションがディスプレイ基準になったので、その副産物としてSubPixelDisplacementができるよ、という事かもしれず、、、

まぁReyesみたいに普通のObjectもバリバリテッセレーションされてフレーム間のジオメトリの分割が一定で無くなるとTB_EdgeとかTB_NormalMapが動かなくなるんだが(笑)

後は

>Improved wrapper for LWVParms, with easy evaluation, automatic loading, saving, copying and xpanel control setup

んー、上手く行けばLScriptでもちゃんとしたシェーダ書けるようになるかしらん? だとしたらそれはそれで、という所. LW8では大分速度改善されてるし(それでもまだかなり辛いのだけど)更に速くなってShader系で使うUtility functionがもう少し実装されて、vector<->配列の部分とかがもう少し良くなればあるいは、、、

というかそれ以前に現在はLScriptでilluminate呼ぶとLWが落ちるのですが orz
(最新版の8.3ではsa.illuminateは呼べなくなっているが、インタプリタ上のスコープエンジンで妙な誤魔化し方をしているのかグローバルシンボルのilluminate(本来は未定義の筈)を呼ぶと落ちる、またその他の適当な関数名はちゃんと未定義エラーになる、、、これがスコープエンジンで誤魔化しているならちゃんと動いてないし、パーサ部分でシンボル解決がおかしくてクラッシュしているなら事態はもっと深刻な話になる、というのも本来言語エンジンをそう作ってはいけない話が発生している可能性が高いので、、、まぁ単項マイナスの処理なんかもそうなんだけど(--;;)

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

まぁ発表自体は聞こえの良い所だけ集めた感もあるなぁという気も少々したり、ちょっとアレなので上で解決されると期待できる部分は置いておいて、自分が気にしているLWのレンダラの欠点なんぞ挙げてみる.

【影の表現力に乏しい】
エリアライトシャドウが無い事やシャドウマップオプションが非常に少ない点(少なくともシャドウマップについてはシーンの細かい調整をする為に他にバイアス設定とサンプル数設定が必要、欲を言うとDSMも欲しいけど)エリアライトシャドウは面・線ライトを使うのも手ではあるのだが、今度はdiffuseのシェーディングにも影響してしまい、コントロールが難しい、あるいは影を落とすライトはシーンのキーになるライトであるケースが多く、その際に再度照明設定を行う必要がある等々.

、、、どーしてもRaytraceのくっきりした影だとシーン内の階調が少なくなってのっぺりしたり、ライト当てすぎ(この場合物体の形状的なメリハリを付けるのが目的なので光の届かない部分の演出になる)て絵の主題とは関係無い高周波成分が増えて雑然としたりするんだよねぇ:-<

【モーションブラーと被写界深度がダメダメ】
規則的に複数の画像を重ね合わせる方式の為高周波のエイリアスが発生し易く、またクォリティを上げようとするとレンダリング枚数が増える&シーンによっては最高レベルでもサンプル数が足りなくなる.

モーションブラーなどは時系列も考えてプラグインの制御も考慮する大変なのは分かるのだけど、ここはやはりストカスティックサンプリングな方式でやって欲しい所、下手をするとPixerの特許を踏んでしまう可能性があるのだが、他のレンダラで対応しているものがあるのだから、やはり特許の逃げ手はあるのではないかと思ったり.

【GI関連がかなり弱い(その1)】
コースティクスは使用用途が限定されているのであれでも良いと思う(ボリュームフォトンは無いけど、かなり特殊な用途だしライティングジェル+VolumeLightでも誤魔化しが効くし、処理的にもやたら重いので個人的には要らないと思う) ラジオシティの方は本当にごく初歩的なMCRTを取り敢えず乗せましたというレベル、まぁそれでもある程度のケースでは問題無いのだが、MCRTと併用されるIrradianceCacheの実装がダメダメな為、画像を全て馬鹿正直なMCRTで計算する結果になるという辺りはどんなものか、という所.

つまりはGIの補間モードの事なのだが、余りLWでこの機能を使う話は聞かない(画像が斑になってしまうので)なのだけど、普通MCRT系のレンダラの場合この補間モードの方が標準だと思うのですが、、、

欲を言うなら低周波が強く出てしまうので1次反射には使い辛いので1次反射は従来通りMCRTで計算して2次以降はフォトンマップで計算するようにすると更にGIの反射回数を増やしてもそんなに重くならないのでは、とも思ったり.

【GI関連がかなり弱い(その2)】
一応LW自体はHDRI対応を謳っているのだが、上記の様に本当に馬鹿正直にサンプリングする方式な為、晴れた日の画像のように指向性の強い光を持ったHDRIを上手く反映できない、この為そういった画像を貼っても曇り空の画像と似た結果しか得られず、太陽が出ている部分など高周波の部分の再現性は非常に悪いし、逆にその部分がサンプリングのエラーの様に画像に出てしまって使い物にならないケースもある.

正直ImageWorldプラグインをサポートするとこの話も難しいのだが、そんなの要らないから、本体組み込みでちゃんとした「背景画像」としてHDRIの偏りによるインポータンスまで考慮したレンダリングをサポートして欲しい所

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

とまーこんなカンジ、どれも地味で改善を発表してもインパクトが無いのは分かるのだけど、結構地味に重要な機能だと思うのでマジで何とかして下さい、ここまで来るとプラグインでどうにかするには限界があります、みたいなorz

本当はこれだけ文句があれば「乗り換えれば」って話なのだけど、でも趣味で使うには結構お手軽な値段なんだよなぁ、と. MAXとか維持費はVerUpのコスト考えると本職で無いと辛いし、C4Dは最近の流れ見ているとメーカーがボッたくり企業と化していて(きっとメーカー側としては昔フォーカスしてたLWは追い抜いたから次はMAXと対抗する路線とか考えているんだろうなぁ、だからこのソフトはハイエンドなんですよ、みたいな雰囲気、体験版触る限りでは、確かに各機能のとっかかりは非常に良いのだけど、そこから細かい所詰めて行くと如何にもソフトの技術屋が机上で設計しました的でかなり役不足な印象が) 維持費にそこまでかかるなら細かい所がこなれてないソフトよりMAX単体の方が、、、みたいな気になるし、Mayaとかどーなんかなぁとも思ってみたり、XSIとか、、、うーん(悩)

# ま、好き勝手書いたのでツッコミあればどーぞ、みたいな所で.

# 何か読み返していると結構C4D攻撃しちゃってるなー、ユーザーの方ごめんなさい、という事でm(_ _)m
まぁ実際の所MAXONの最近のマーケティングとか、漏れ聞こえる所だけではあるものの、聞いているとソフト屋として「それはどうなんよ？」みたいな所が結構あったので、と言うトコロ. まぁ片や自分の使っているLWなんてC4DをGUIのアプリに例えるならコマンドラインのような泥臭いゴリ押しソフトなのですが(笑)

# 同時期発表のLW8.5については特に何も書いてないですが、、、8.x系列については機能追加は要らないのでお願いだからちゃんとバグだけ直して下さいという所orz

先日書いたTB_fakeSkinのSheenパラメータが光源の影を反映するバージョンをExperimental VersionとしてJunkに登録、実際Sheen effectについては場合によって不自然に光り過ぎるのがかなり自分でも気になっていたので、これを以って区切りとする.

これで (まぁ自分の腕が未熟なせいもあるのだけど) 3Dで結構表現しにくい逆光主体の構図で主題Objectがある場合の絵作りでも、それなりにサーフェス上にライティングの表情がつけられるかも、とも思う、というよりはScatteringに使用している関数はバックライト「も」サポートしているという具合なのだが、Sheen effectについては光の単散乱に近いエフェクトとしているのでエフェクトとして現れるのはバックライト〜サイドの光源についてのみというカンジ. 実際LW標準のシェーディングアルゴリズムではバックライトはシェーディングに影響しない為 (正確にはdiffuseは完全に影響しない、specularはある程度影響を受ける) ので普段は余り気にしない(?、一応配置するけど殆ど影響は現れない)背後からの光源が結構レンダリング結果に影響する形になる.

なお、先日書いたようにソリッドなオブジェクトでのみちゃんと動作する、概念的にエンドユーザ向けとしては分かり難い為、空気のサーフェスに関する話がある程度SSS系シェーダの定型手法として定着するまではこの機能は正式サポートするつもりは無い、ただ欠点としては認識している為不完全のまま放置するのも気持ち悪いという所にて.

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

仕事がクライアントのアクション待ち(少なくとも自分の中では、それでいーんだよね?(爆))になったので少々コンパイラなど調べて遊ぶ.

気が付いたら出ていたMinGW日本語対応版、ベースはgcc3.3.3で少し触った感ではかなり環境としてしっかりしているカンジ、gcc本体以外にリソースコンパイラもちゃんと日本語化されているのでWin32で通常アプリを作るのは問題無いと思ったり. gccは2.xの頃は最適化はVC6 > gccだったのだけど、3.x系列になってからは部分的に劣る個所もあるものの、ある程度についてはVC6 < gccとなっている印象. VC7以降については現状インストールしていないので分からない(VC7は場合によってはVC6より良いコードを吐く) ただまだまだIntelコンパイラにはかなわぬ模様.

後少々調べものをしていて見つけたのがTinyCCというコンパイラ、Cのみ(C++はサポートしない、仕様としてはC99準拠)のコンパイラ、非常に(今としては)コンパクトなコンパイラでgccの10倍以上のコンパイル速度でCのソースをスクリプト感覚で実行できるらしい. 最近のバージョンでWin32(MinGW)もサポートしたらしいのでちょっと日本語化してみた、後は少々特殊なバグ修正など、まぁquick hackなので少々dirtyな所もあるのだけど.

TinyC Compiler 0.9.23 for Win32 日本語(SJIS)化バージョン

LGPLに従い修正ソースも添付、まぁ大した修正はやってないのだけど(^^;;

コンパイラ自体の作りはかなりしっかりしている印象で、数千行程度の規模のものもちゃんとコンパイルできて動いているし、linux版ではカーネルのある程度コアの部分もコンパイルできるレベルらしいので、言語処理系としては安心して使えるレベルかと思う.(コンパイラ自体が信頼できないプログラミング言語って最低だし :-P

実際の所着想は面白いと思うし中間ファイルを生成しない、-runオプション使用時は実行形式すら吐かないので機能単位のテストには良いかもと思ったり、dllの使用も単にdefファイルがインポートライブラリと同じ扱いで非常にお手軽だったり、本体もコンパクトだし、ただ昔のマシンならより有用であったろうものの、最近のPCは随分速くなっている訳で、確かにgccは最適化オプション有りだとかなり重いのだけど機能レベルのソースならそんなに複雑にもならぬというと少々微妙な気もしたり.

一応コンパイラ自体がライブラリになっているのも面白いし、アプリに組み込む事でC-Nativeなコードの動的結合も実現できるのだが、C言語の危険性という事を考慮するとインタプリタ方式の方が妥当な気もしてみたり、、、まぁ(^^;;

後はX端末が大量にぶら下がった環境(自分の大学時代の言語関連の授業現場がそんな具合)での学生なんかの教育には、少しでもマシンへの負荷が少ないので有用かもしれない、とか. ソース自体コンパクトで見易かったり改造も容易なのでコンパイラやスタートアップまで手を入れながら扱えるような開発環境としては(プログラマの遊び用だが)良いのかも. 後はPEフォーマットとかネィティブのコンパイラを作りたい向けの資料的価値とか(これは大きいと思う)色々.

まぁなんだかんだ言ってオモチャとしては非常に触ってて楽しかったりで結構好き(笑) 何に使うのかと問われると答えに窮するのだけど(^^;;

なみにWin版はリソースのリンクに対応していないのがネック、後gccも含めUnix移植系のヘッダなどはやはりWin特化環境に比べると信頼性に欠ける気もしたり、まぁdllのインポート部分は定義だけなのだが、やっぱりUnixのようなオペレーションで使用するアプリのソースコードのコンパイルなどを日常的に行う向きかなぁ、トカ、最適化機能はコンパクトさ故に推して知るべしという所.

# 自分でビルドする場合は上のgccをインストールした上でここからMsys( MSYS-1.0.8.exeのみでOK)を落としてきてconfigure実行すれば簡単にmakeできます、逆にVC++とかではそのままでは通らない模様で移植には苦労しそうな予感.

# というかこのコンパイラの作者、QEMUの作者さんなのね.

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

上の文章書いてて疲れた、やっぱり文章を書くのは苦手. だったら書かねば良いのだが、まぁプライベートで雑談ネタにしてしまった為Upする約束をしてしまったのがこんなにダラダラ書いてた理由だったり(笑)