リリースはもう少し先になりますが、次のTB_ShaderManではようやく画像に対する任意UV座標でのアクセスが可能になります(今まではLWのテクスチャエンジンでパラメータにテクスチャを割り当てる方式しかサポートしていなかった)これでPaintMapや予め計算した値をテクスチャに格納してレンダリング時に再現するようなシェーダも実装可能に.

通常レベルのShaderについてはほぼSDKと同レベルで実現可能となる為、機能的には現状コアでは一区切りとなる予定、とは言え予定は未定でもあるけど;-)

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

LWプラグインで可変サイズの凝ったGUIを作る為に休日1日色々調べてみる.
というのもこれが出来るかどうかでインターフェイス設計の自由度が大きく変わる為なのだが.

通常LWのプラグインでGUIを作る場合、Win32等を使う事はできない仕様になっている(無理矢理使うのは一応不可能ではないが)のでSDKで用意されている独自のWindowシステムであるPanelサービスなるものを使う.

第一ステップとしてOpen時にGUIのサイズを可変にするフラグがLW7から追加になった為、これを設定してパネルを開く、、、通常のWindowsアプリのように端をドラッグしてもサイズが変わらない、どうやら単に関数で手動でパネルのサイズを変更できるだけ、という事らしい. 仕方なく右下に小さな領域を取って自前でリサイズ時のドラッグ処理を実行する、面倒.

次にGUIにコントロールを配置した場合を試す、、、一応サイズの変更は設定している筈だがリサイズしてもコントロールのサイズが変わらない、どうやら一旦作ってしまったコントロールのサイズは変更できないらしい。更にSDKのAPIがOpen時のコントロール配置を憶えていてそのサイズ以下にはWindowサイズを変更できない。ついでに言うと一旦作成したコントロールはパネルが破棄されるまで手動で破棄する事もできない模様.

これでは可変サイズのGUIの実現など無理(あるいはコントロールを一切使わないで、全てのコントロールを自作する)な話な気もするのだが、実際LWのSpreadSheetやMotionMixer、或いは市販のプラグインのVisualTextureなどでもLWのコントロールを使用したリサイズ可能なGUIを実現している.

という事でそれらの挙動を観察する、、、とリサイズ直後にやたら画面のちらつきが目立つのと、リサイズ直後の瞬間Windowが別位置に発生している模様、 まさかと思いつつ思いついた方法を試すと自前のGUIでも実現出来た、出来た事は出来たのだが、、、思いついた方法とは以下の通り

1. コントロールの作成をPanelのOpen後に作成する(一応SDKのドキュメントにはOpen前に全てのコントロールを作るよう書いてあるのだが、、、:-<)
2. リサイズ時は単に自前でリサイズ処理を行う.
3. リサイズが終了した時点でPanelを全て破棄し、再度そのサイズに合わせたPanelを作り直す.
4. 新しく作られたGUIに以前の状態を復帰する.

、、、マジですか？
まぁ、一応実現できるには実現できるし、他のプラグインなんかの挙動を観察していても恐らくこの方法で間違い無いとは思うのだが、はっきり言って力技過ぎてこの時代に正気の沙汰とは思えない、、、頼むから普通にWin32で組ませろといったカンジX-<

という事で一応のスケルトン(というかベースクラス)は完成させたものの使用するかどうかは未定、実現できるにはできるが余りに無理がありすぎて正直やるだけの価値があるかどうか疑問、標準のSpreadSheetを使っていると場合によっては不安定になったりするのも妙に納得、しかも当然画面はちらつきまくるX-<

GUIに画像を貼り付ける為のRasterAPIも余りまともとは思えない仕様(Win32のdibなどを作るのと同じ手順だがピクセルの内部構造にアクセスする手段を提供していない為、SetPixelと同様のAPIで1ドットずつ設定して行く)だし、この辺は何とかして欲しい所.

正直この辺のGUI APIを充実させるかどうかでサードパーティ製のプラグインがLWと連携する際の使い勝手にも大きく影響すると思うし、LWのような外部のプラグインに頼ったソフトでは結構生命線とも言える問題だと思うのだが、何とも何とも:-<

まぁサイズ可変自体LW7で追加になったという事でSpreadSheetとMotionMixerの為の間に合わせの拡張なのだろうが、余りにも間に合わせな仕様に呆れかえる事しきり.

無論バージョン互換とはいってもTB_ShaderManなどは複数のVMを搭載するワケにも行かないので限界はあるのですが、バージョンを入れ替えた際に最悪パラメータの設定直しになったとしても、その他読み込めなくなるなどの致命的なトラブルを回避し、また開発側のバージョンアップによる互換性の維持にかけるコストを可能な限り削減する事を意図しています.

スケジュール的には年内に再度全てのプラグインについて改修を行い、また現状のラインナップで使い捨てのレベルで開発したもののjunkに振り分けなどの整理も意図しています. ただユーザーへの見え方としては機能アップは殆ど無く、セーブデータの互換性だけが無くなる形になるので、いささかの顰蹙はあろうかと思いますが、どうかご了承願います.

と、いう事でTB_ShaderManの新バージョンのリリースはそれまで延期とします、とは言っても自分の性格からしてこういう話を公表する時はほぼ全て目処が立っているのですが(笑)

実際新しいコアライブラリのプロトタイプは既に実装済み、ただこういうものは作ってから数週間寝かせて見落としが無いかを熟考する時間が必要なので、という事で. 実際コード書いているよりもそうやって考えている時間の方が遥かに長いのですが(TB_ShaderManの時は実際の実装は2週間程度(笑))、、、まぁそんなものでしょう、という事で;-)

手を抜く為なら労力を惜しまない、というのもアレですが、得てして力技で考慮も無しに実装してしまうと後々まで悪影響を残すので、やはり作り込むような真似はしてはイカンと思ったり(苦笑)

# とはいえまずは用事がある為、数日留守にする予定です;-)

この土日は久しぶりに焼肉を食べに行ったり、例のツボを3Dで作ってみたりという事でプラグインには進展無し、まぁたまにはそんな日もあるだろう、という事でまぁ良し.

という事で例のツボ、友達がうろ覚えで描いたものを更にうろ覚えでアレンジしたので最早別物に、しかしこういうベクトルはやっぱり大好きで、いじっていて楽しい.

後はちょっと掲示板でPythonネタが上がっていたので色々調べてみたり、明日からはTB_ShaderManの改修作業再開予定.

TB_ShaderMan以外のプラグインの改修は終了、ただTB_ShaderManに関しては引っ掛かる所があり今暫くかかる予定、先日の乱数の件は画面固定の乱数系列で良い系列が得られたので、全てのrandom()呼び出しについて適用するように変更、まぁ実際の所Shaderを書く上でrandom()なんて関数はモンテカルロ以外で使ってはいけないモノ(通常はnoiseやcellnoiseを使う)なので良しとする. 実際にはShader勉強始めのコードで何回かパターンに乱数を使ったコードを見たので、そういう層を切り捨てる結果になる気もするが、本来そういう使い方をするモノでは無いのでまぁ良しとする事に.

後引っ掛かっているのが先日実装したTLS/ShaderData絡みの件なのだが、これについては削除を検討中、というのもプログラム言語という観点ではあっても良い機能なのだが、反面アプリケーション寄りのツールキットとして考えると余りに機能が複雑で、把握が難しく、また再帰呼び出しを意識した際に意識する領分が非常に広くなるという点にある(少なくとも自分にとってTB_ShaderManはプログラム環境では無く、アプリケーションという位置付けに近い) 現状のようなベタな形で実装するのでは無く、レイの再帰に伴うスタックのようなイメージで実装すべきであり、限定を付けた上で実装するもので、このような汎用的な形で実装するべきでは無い気がしている.

と、いう事でこの部分に関しては次期バージョンは機能削減になるかもしれない、まぁ実際の所これで実装できるのはブーリアンシェーダやレイの透過に合わせてエフェクトを加えるようなシェーダに限定されるので(あるいは本当に複雑な情報についてはそもそもより細かい情報収集機構が必要になるが、それはSDKの領分だと思う)

と、、、いったカンジ、まぁ実際には数日中には仕上げるつもり(余り時間的余裕も無いしね;-)
幾つかコアに近い仕様が変わるので、良い機会なのでオペコードの整理もしようか、とか思ったり(という事でまたシェーダの再コンパイルが必要になるかもしれませんm(__)m

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

最近暇をみては「プログラミングのための線形代数」なんて本を読んでます、内容はプログラムは全く無く数学の話だけなのですが、行列式や固有値、固有ベクトルについてそれの持っている意味や射影空間での具体的なイメージを含めて解説してくれているのは非常に有難く自分的には良著、学校ではこういうイメージでは教えてくれなかったなぁ、トカ. まぁ自らの不勉強が原因なのでアレですが、なかなか、まぁ勉強はできる時にやっておくのが良いという事を痛感中(苦笑)

要はアニメーション時にちらつき軽減なのだが、勿論影響されるのはほぼ全てのプラグイン(笑)
手法は取り合えずスクリーンピクセルを乱数系列の初期値にして各タスクで乱数ライブラリを独立させるというごく単純な話(それでダメならオブジェクト座標でのボロノイ図を初期値にしてしまう、トカ(笑)
、、、シーンサイズの適切な推定が難しいけど:-<

問題はそれをデフォルトでやってしまうかどうか、という事。頭の中で組み立てた仮説でそれ程テストしていないのが不安というのもあるのだが、それ以前に特性として乱数を固定する場合単なるランダムサンプルに比べ同サンプル数では粒状感が若干強く出る上に、現状初期値の算出の問題とも言えるが近傍ピクセルまで含めた系列という事では余り質も宜しくない(まぁ粗いサンプルで目立つ程度ではあるが) 更に当然アンチはかかりが悪くなるので、サンプルを増やす以外にスムーズにする方法は無いカンジ.

ただ選択式とするとTB_ShaderManの場合にrandom()の他に拡張関数としてrandom2()などと用意するのは美しくない、、、という事で考えをまとめるまでちょっとリリース時期が伸びるかもしれません:-<

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

後TB_ShaderManの今回の目玉(?)は独自拡張の"reference"座標系の追加、自分で言うのもアレではあるが、かなり便利だと思ったり、この機能はRenderManを使っている時にも欲しい所だけどDisplacementまで考慮するとちょっと実装は無理っぽい、という事で参照頂点&法線情報程度で我慢:-<

この時ばかりはSubPixel Displacementを持っていないLWに感謝な気分、まぁプログラムが書けないと何の役にも立たないのはいつもの通りなのだが(笑)

余談だけど、フリーのレンダラでよく思うのがLightFlow(開発終了)にしてもVirtuaLightにしても、あるいはPOV-Rayにしてもそうなのだけど、プロシージャルパターンやシェーダを持ったレンダラで参照ジオメトリ情報を持ってないのは如何なる事か、とか思ったりするのだけど、、、アニメーションに使えないじゃん、みたいな、、、全部UVマップでやれって事なのかな？X-<

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

というかいい加減区切りたい所ではあるのだけど、、、いつまでもこればっかやっているワケにもいかないし(笑)
なんかついでにLW->RenderManのエクスポータも久しぶりに手を入れているし、「彩」の新しいバージョンも出てるみたいだし(T_T)

という事でまたまた近日中に総入れ替えの予定、というかTB_ShaderMan以外はもう実は完成しているのだが、TB_ShaderManについては若干座標系などに仕様変更が入る予定で(本当はこの時点で変更するのは余り良くない事は認識しているのだが)それと合わせて調整中、まぁ他のプラグインは外見は殆ど変わっていないので特に問題は無いと思う.

TB_ShaderManの仕様変更この時点でという事やRenderManとの互換性で色々悩んだのだが、将来に禍根を残すよりは良い、という事で断行. と言うかそろそろプラグインばかりいじっていても他の事が出来ないし本末転倒なので、これで一旦区切りとしたい所ではある、、、他にもやりたい事あるし;-)

しかし、余り独自仕様を大量に入れてしまっても、完全に自分仕様になってしまって使いこなせる人が殆どいなくなってしまう、というのはちょっと難しい所ではある、実際自前でLWからRenderManへ変換するプログラムなども使っていて、恐らく使いこなしての表現力は他の公開されているLW用RIBエクスポータを上回るとは思うのだが、余りに独自仕様や実験機能が多い為公開はしていない、というかできない(笑)
、、、まぁRenderMan自体レンダラというよりはレンダラ環境作成の為のミドルウェアに近いシロモノなのでそんなものかもしれないけど(笑)

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

HDDの整理をしていて昔作った画像発見

、、、見せた友達には「馬鹿だね」と言われたけど、実際その通りだと思います(笑)

日付を見ると2年前という事で、時の流れというのは早いものですが、まぁその友達は元気にしているのかなぁ、とか思ってみたり. (それ以前に忙しいと数年程度は平気で友達をほったらかしにしてしまう性格は反省すべき所ではありますが、個人的には悪気は無いんだけどなぁ(苦笑)

思えば、コレ作っている時にTB_Edgeを作ろうと思い立ったのですが、何せ作っているものの馬鹿らしさに比べ面取りが面倒この上なく、何で自分はこんなに苦労してこんな物面取りしているの？という気分になったのがきっかけだったと記憶しています(笑)

# ちなみにこういう画像作ってますが個人的には２ちゃんねるとかのコミュニケーションスタンスは好きでは無いので、その手の話は振らないで下さいね;-)

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

KOJIさんから教えてもらったえらい話、「ゲームソフト大手各社、「3D技術特許の侵害」で訴えられる」だそうな、実際の特許の文面には目を通してないですが、記事に書かれている内容通りだとするとゲームはおろか殆どの3Dソフト、というか3Dそのものに影響しそうな話ではあります、誠に困ったモノで.

まぁ実際米国で成立してても日本国内で成立していない限りは日本で作る場合には影響ないワケではありますが:-<
しかし実現する為の方法論では無く、概念に特許を与えてしまうというのはある意味問題だと思いますがねぇ＞米国の特許がらみの権利主義

ようやくプラグインの改修も終り、と思ったのだが、一つ頭の痛い問題を発見する.
問題の詳細は省略するが、現状自作のプラグインの殆どのパラメータにはテクスチャを貼れるようにしているのだが、これについてボーンなどの変形を伴った際の変形時にオブジェクト座標で立方体状に貼り付けたテクスチャが機能しない、というもの.

問題自体の修正は簡単なのだが、この修正を行うとLW本体のバグによりSurface Bakerと併用できなくなる上にBaker実行時に不用意に適用しているとLW自体が落ちるX-<
自作のプラグインでBakerが必要になる可能性としてはTB_DirtとTB_2ndSrfなのだが(TB_Edge,TB_ShaderMan等は元々サポートしていない)TB_Dirtについては機能ダウンさせてテクスチャを一切サポートしない仕様とし、TB_2ndSrfを重ねる事で現状の機能を再現する事ができるが、TB_2ndSrfについてBakerが使えないのはかなり痛い所ではある(単純にマルチテクスチャをするだけで無く、素材作り等にも使っている為:-<

暫らく考える事にしたいと思いますが、、、さて、どうしたものか？:-<

なお先日書いたTB_ShaderManでのisshadowray()の速度低下については若干コアを作り変えましたが、現状のもので既に問題解決していますのでご心配なく(と、誰に言っているのだか(笑)

# しかし、友達に言われた通り、バグというのは解決したと思ってもまた出てくるものですな:=<
余りソフトのクオリティの問題として頻繁にバージョンアップするのは望ましくないとも思うのだが、まあフリーで配ってるものなので別段気にする事もないのかもしれませんが(使いたいヤツだけ使え、というカンジで、ね;-)

一応LWのSDKにも該当フラグの記述はあるのだがLWのバグにより機能していない(常に0が返る)のであくまでShaderManから呼ばれた影のトレース時に限定されるのだが、LWの共有メモリ機構を利用してTLSもどきを実装する事でマルチスレッドでも整合性を保てるように調整.

と、ここまでは良かったのだが、LW内の共有メモリの検索が重いらしく、速度的には15〜20%の低下が見られた、例えばシェーダ無しで45秒、Nativeの自前でシェーディングを計算するシェーダで60秒、以前のShaderManシェーダで75秒(シーン内の全てのサーフェスに適用)だったシーンについて90秒程度かかってしまっている.

Pluginはdllで実行されている為、LWのレンダリングスレッドがどのようなスレッドが走っているかについては正確に管理できない為、動的にスレッドをチェックするしか無く、内部的なキャッシュは機能しない(正確にはレンダリング開始・終了時に状態遷移を含むものを完全にクリーンナップするのが難しい)一応LWのプラグインにはレンダリング開始・終了通知コールバックが定義されているのだが、実はこれはそれ程アテにならない(笑、、、えないけどX-<
(ちなみに先日の半分LWのバグだというマルチスレッドの問題もこれが絡んでいる:-<

機能としては理想的にはシーン内の全てのシェーダに設定されている場合に最も良く機能するので、サーフェスごとのスイッチでON/OFFするような機能では無い.

、、、非常に悩ましい所で、マルチサンプルや透明体が絡むと速度効率は変わるものの、標準的なシングルトレースの場合にシェーダ無し(or Nativeの軽いシェーダ)の50%平均という速度は許容範囲だろうか？非常に重要な関数ではあるのだが、たかだか1関数、しかも限定付きの機能について速度20%減というのは如何なものなのだろうか？(無論機能的には表現の幅は大きく広がるのだが)実際エンドユーザーの立場として見るとどうなのか、というのはソフトを作る上で推し量るのが非常に難しい、特に長い間開発していると:-<
(それ以前にShaderManがエンドユーザー向けなのか、というツッコミは置いといて(笑)

内容については余りに恥ずかしくて書くのも辛いのだが、現状ShaderManはシングルスレッドで動かしてください、という事で、次バージョンでは対応します(平謝り)

いやもう本当に懺悔するような気分で...これからはLWは常にマルチスレッドでレンダリングするようにしようと思います(x_x)

という事でかなりの数のプラグインが影響される予定、一応の修正予定は TB_ShaderMan, TB_Edge, TB_fakeSkin, TB_2ndSrf, TB_IPlane, TB_Dirt, TB_NormalMapといったカンジ、まぁ殆どは機能追加も余り無い(GradientがあるものについてはGradientの種類のみ)なので、セーブデータもそのまま使える予定、ただTB_2ndSrfについては変更アリで、メニュー的には1つ項目が追加になるだけなものの、Gradientの追加機能と併用した際に標準機能では出来ないエフェクト系などとしても活用可能なように、後はノンフォトでGradientと'Light Incidence'を使う事で陰影を付ける手法などと同様のアプローチで簡単なシェーダのようなものも設定可能になる予定、ただ実際そういう使い方に気付いてくれる人がいるかどうかは不明だけど(^^;;

しかし改めてLWのGradientの着眼点は偉大だと実感.


(10/20追記)
表面上の変更は少ない、と書きましたが幾つか面白い事を思いついたのでTB_2ndSrfはもう少し機能が追加になるかもしれません、またそれに伴ってTB_EdgeとTB_Dirtにも手を加えるかも、という事で(^^;;

、、、現在Gradientの種類が30over、前のバージョンの3倍(笑)

まぁ余りPluginばかりいじっていても、本質はやっぱり3Dを作る所なワケで、区切りも重要なのだけど、やっぱPluginのソースとかいじってると色々拘りたい部分が出てきて本末転倒な気もしてみたり.

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

最新版のLW8.0.1にてLScript Shaderを動かしてみた所かなり速くなっている模様、ありゃりゃと思いつつ(ShaderMan無駄に作ったかと(笑)、複雑なシェーダについてはどうかと試した所、、、illuminate呼んだらLWごと落ちた(--#
(illuminate(RenderManの場合illuminance)はShaderを書く上での基本になる機能の事、ね.

ほっとしたようながっかりしたような少し複雑な気持ち(笑)

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

前の会社の友達(元上司)との会話、一生懸命真面目に就職して普通に人生を送りたいと考えている可愛い後輩に対し「会社なんて下らないから、やめとけやめとけ、諦めろ」などというのはどうかと思います.

、、、少なくとも40歳以前までなら許せますが、50過ぎたオッサン(しかも元部長)とかが言う台詞では無いかと、ええ(笑)

相変わらずつらつらとSSSシェーダをいじってみたり、ある程度ロジックが固まったら他の自分の良く使うアルゴリズムと合わせて1つのベースシェーダに合わせてしまうと良いかもしれない、などと思う.

現状の結果、照明は平行光源1灯

しかし、、、使い所によるのだが、SSSって嬉しいか？とか思ってしまう部分もアリ、ジオメトリ形状に依存するのでオブジェクト作る段階で意識しなければならないし、多重サンプリングかけるので重いし:-<

まぁ現状のShaderManでもできるものをベースシェーダとして一つのプラグインに落とし込む理由はせいぜいシェーディングノイズ除去(2Dのポスト処理、モンテカルロなどの高周波ノイズを除去する)を実装できるから、という程度の話でしかないのだが、後は何となく「それっぽくて」嬉しいから、という程度。まぁOGO_Hikariなどもあるので余り一般公開するつもりも無いので適当に考える事にしようと思ったり(笑)

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

しかし、、、やはりシェーダ書きは難しいのかもしれない、と思ったり。プログラム的にはそんなに難しくないのだけど、ある程度のセオリーとか、よく使う関数の形状なんかは頭に入れておかねばならない、という事ではそうなのかもorz

後はRenderManなんかは情報が少ないのもあるかも、日本語で現在入手可能な資料はわずかに「Advanced RenderMan」のみで、海外でも後は「RenderMan Companion 邦題：実践CGへの誘い(絶版)」位なので確かに、辛いのかもしれない、とも思ったり。

、、、それでも自分が覚えた時よりは楽にはなっているんだけど、当時は日本語の本は無くて「実践CGへの誘い」を図書館で借りて全部コピーしたり、「Advanced RenderMan」を洋書で注文したり。

イントロダクションにはならないですが、取り合えずリファレンスについてはPixarのページでSpecificationが公開されているので、それを参照するのが妥当かと、、、後は、どうやって勉強すれば良いのだろう？うーん:-<

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

LW8.0(正確には7.5d)で搭載されたグラディエントの'Surface Thickness'を自前プラグインにも実装してみる(実はプラグインのグラディエントモードは全部自前で制御する必要がある)が、激しく使えないカンジ、取り合えず標準機能が両面サーフェス基本というのはどうかという気がする、トレースは視線方向だしシングルトレースしか行わないので透過した時のオブジェクトの形状がはっきりと出てしまう為、余り使い物にならない気がしたり、、、半透明機能にも思うのだけど、なんでこんな機能が標準になっているのかはちょっと疑問.

ちなみにLW7.5dは色々問題があるようなので見送りの予定、8.0.1も入っているのだけど、未だにメインは7.5b使ってます、IKBoosterもイマイチなカンジでバグも一部残っているみたいだし、インターフェイスのカスタマイズも面倒なので、現状安心して使える方が優先;-)

先日のNormalMapに絡んで関連するサイトを探してて見つけたフリープラグインを置いているサイト、ここにあるTextureGuide2がなかなか良いカンジ、選択ポリゴンにフィットさせて展開した後のUVをちゃんと編集できる(標準のTextureGuideは編集できない、、、何で？:-<)のでバキバキ貼って一枚のUVにまとめられるのが素敵、後はRelaxUVは適応部が平面展開できる事が前提だけど、なかなか便利かも,

しかしもう少しマップを作るのが楽にならないかなぁ＞展開図にペイントしてテストレンダの繰り返し

Netの掲示板にてLWのNormalMapプラグインのシェーダがボーンと併用した時に反転してしまうという話があり、面白そうだったのでShaderだけ実装、暫く触った所ではうまく動いている模様、オリジナルが修正されるまでの暫定対応のつもりだが、取り合えずJunkに入れておいたので、欲しい人は適当に持っていって下さい的に.

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

しかし同じ掲示板でGI談義とかやっている内容を見ると、シェーディングロジック周りの話って3Dユーザーでも余り一般的では無いのかな、とかシェーダを書けというのは自分が思っているよりも意外と難しい話なのかな、とか思ったり、、、慣れればGradientとかいじるのの延長程度の話なんだけど、、、うーむ:-<

でも正直スクリプトにしてもシェーダーにしても(モノにもよるけど)内部設計的なプログラム内の空間認識能力は余り必要無いので、そういった意味ではとっつきが悪いだけでプログラムとはまた別の話だと思ったり、という考え方は職業病的な考え方なのかな？

ShaderManにてTB_fakeSkinで使っているアルゴリズムを実装してみた、、、行数100行程度で速度的にはNativeには負けるもののそれ程著しい速度低下は無い模様.

なんかもうNativeで書く必要無いかも、と思ってみたり.
まぁ実際はプログラマの立場から見るよりもスクリプトというのはとっつき難いらしいので、エンドユーザー向けという事でわかり易い専用のプラグインの方が良いのだろうけど、、、手間が余りに違いすぎて、ねぇ(ちなみにNative版はコアが1200行、周辺まで入れると2100行程度:-<

という事で上に書いたものコッソリ置いておきます、、、次バージョンではサンプルに入れるかもしれないけど.

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

LW自分用Tips
影だけ落とすライトは２つ光源をつけてそれぞれ同じ色でプラスマイナス逆の明るさにし、マイナスの光源を影なし、プラスの光源を影ありにすると作成できる、影の色は光源色の補色となる.

最近気付いたけど、個人的にはシャドウマップが好きなので非常に便利、後エリアライトとかも影だけ上手く調節できるカンジでかなりいーかんじ、、、って当たり前の話かもしれないけど(^^;;

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

昨日書いたの件について
>誰かさんはGCが受け付けないらしいけど(笑)

ＫＯＪＩさんから突っ込みが入ってましたので補足
>マジメに答えると、別にGCが受け付けないってんじゃなくて、もしか
>メモリ管理の事をパフォーマンスも含めて100%無視できるレベルのGC
>があるなら喜んで使いますよ。でも現状はＣでやるよりも大量の理論
>を知り、Ｃでやるよりも難解な方法でGCの動作(即ちメモリ管理)を考
>えなければいけないわけで、だったらGC要らんでしょ、っていうのが
>俺の考え。

という事だそうです、いや実際ファミレスでよく話している内容なんで実は分かってたんですが(^^;

大体は僕も同感で、実際サーバ系のJavaのチューニングの話などでGCの方式まで意識したパフォーマンスチューニングの記事があったりするけど、本来GCなんて実装系依存の話で、それを意識してチューニングしなければいけないシステムなんて本末転倒も良い所だと思うし、現在ではGCも方式の工夫などにより速度的に大きく改善しているのだが、それでもインタラクティブな操作をするにはその程度のラグであっても問題になるのも確か(ゲームや対話的なアプリなど)

真面目に言うとC/C++でもある程度以上複雑な規模のデータ構造を扱う場合はバックにメモリを管理してあるタイミングで解放したりリファレンスカウンタやより複雑な使用チェックなどでGCもどきの事を実行するルーチンorクラスなんかは書くのが当たり前なので、ある程度自分の手法に合わせて定型化しておけばメモリの問題で苦労する事は余り無いと思う.ただそれを自前で書くかシステムライブラリとして組み込まれているか、程度の違いでしか無い、言うなればオブジェクト指向言語(OOP)でなくともアセンブラであってもプログラマによってはオブジェクト指向で昔から設計している(OOD)という話と似ているとも思う.

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

ただ全てにおいてそれを望むのでなく、それ程高度に制御する必要が無い分野においては、実際メモリリークがバグの主要な原因の一つに挙げられている現在の状況では技術レベルの底上げとしてGCは有効であるとも思ったり.

そういった意味ではMFCと比較するとJavaプログラマの人に怒られてしまいそうだが、Win32に対するAPIとMFCの関係に近いとも言える気がする。重要な点はその是非では無く、それらを選択的に制御できる事(例えばGCであれば部分的にGCの適用外とする、あるいは選択的にGC対象とする、GCは明示的に走らせる、もしくは走るタイミングを明示的に指定する、またはGCを禁止するタイミングを指定する等)の選択肢があれば良い気もするのだが、該当言語にその辺の細かい制御が存在しない点をある程度自分たちは問題と感じるのだろうな、と思ったり.

まぁ実際そうやって複雑にしてまでGCを実行するアプローチもどうか、という議論はあるし、だとするならよりエンドユーザー(というかプログラマ)フレンドリーに全てをGC対象とする、というアプローチもアリだとは思う(ただ実際現状でGC言語を使うメリットはエンドユーザーのためというよりはむしろプログラマの都合でしかない、そしてメンテナンスコストという点でもJavaのような生もの言語を使いメンテの発注をユーザーに要求するのは売り手側の都合からくる選択でしか無い、流行のユーザー受けを狙ったキーワードをちりばめた現行システムの焼き直しで金をせびるような体質ができてしまっている事も確かではある)

# ただ念の為書いておくと上記のようなユーザーをなかば騙すような方式を批判するつもりは正直自分には余り無い、というのも今日のような肥大化したコンピュータ業界の雇用を維持する為にはそうでもしなければやっていけない現状があり（コンピュータ業界以外の人向けに詳しく説明すると、システムの設計は本来10年程度の経験は最低限必要になるかなり職人的側面を持つ業種なのだが、実際のコンピュータ業界では大学出てから初めてコンピュータを触ったレベルの子供の遊び程度の人間を技術者として売り込み、口先でごまかしてその実は外注などに丸投げするケースがかなり多く、酷い(それ程酷くなくても)会社だとそういうレベルの"技術者"が7〜8割以上を占めている場合もある)
またシステムを委託するという点については単にそのモノを発注する以外にもしもの為の責任の転嫁先といった保険を買うといった政治的側面も存在すると思うからではある。ただ反面それを繰り返してきた結果が現状のIT投資に対する不信感を生み出した側面もある、とは思うので悩ましい所ではあるのだが.

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

一方で実際の所プラットフォームは変わってもソフトをどのように設計するか、という点についての最も根幹となる部分は実はここ数10年で全く変わっていないと個人的には思っていて、ただやはりそれをある程度プログラマの職人的な「勘」に依存してた部分があり、明確に伝達出来てこなかった背景がある為、それらの底上げの為に明確に概念化する必要があるのだろう、と思ったり＞昨今のオブジェクト指向やデザインパターンのSE向けの書籍が乱立している事情

その意味では確かに不要な人間には不要な代物なのだが、万人にそれを求めるのは難しいという現在のコンピュータ業界の不幸な技術者事情もあったりするのだろう、とも思います;-)


# 余談だけど本末転倒といえばエンプラ系のWeb系シンクライアントで低コスト化の流れから、やはり使い辛いという事でServletやJSP,JSFにFlash,WebからNativeの機能にアクセスする為にCOM使って、接続にSSL立ててクライアント認証して、更にXMLでデータ管理、などと様々な分野を組み合わせて苦労するという流れ(それらの専門技術者を確保せねばならないし、それぞれのエンジニア同士の情報伝達コストも馬鹿にならない)を見ていると、結局そうなるなら最初から専用のクラサバでやっちゃえば良いんじゃない、という現状はもっと不幸かもしれませんが、、、まぁ実際ミドルウェアを使うのは将来の拡張性とメンテの分離、未来的な拡張に対する接続性の確保という点も重要なポイントなので、一概に言える話では無いでしょうけど、ね;-)

# 上の話について、確かに作りこみは悪ではあるのだけど、反面「車輪の再発明」「資源の再利用」に代表されるキーワード化してその本来の意味を失った「便利な言葉」による無秩序な再利用と要件分析を放棄したバックボーンの構築もまた悪だと思うのですな、実際前の会社ではそれで泥沼になるプロジェクトも沢山見てきたし;-)

# しかし読み返すと偉そうな事書いてますね、言葉負けしないよう頑張らなきゃね＞自分(といって落としておく(笑)

何か、、、TANEさんとやっている事がかぶっている気がする＞JavaにD言語
まぁJavaは僕の方がTANEさんの日記を見て久しぶりにやってみようか、という事で真似して始めたのだけど(^^;;

ちなみにTANEさんの書かれている「Javaはうれしくない」ですが、個人的にはGC言語でもインスタンスのDeepCopyなどは意識する必要があり、参照なのかコピーなのかといったメモリの使用状況は意識する必要があると思うので、実際メモリ管理は少し楽になる程度、という気もしていたり(C/C++でも大量にメモリを確保する場合はマネージャとか書くし、確かにGCである程度楽にはなるけど、それ程深刻にメモリ管理に悩んだ事もないし(笑)

どちらかというとJavaで嬉しいのはシリアライズやリフレクション, RMI, ClassLoaderとかその辺りではないかと思ったり、後はJNIとかもある程度制限があるものの自作アプリ(Native)にJavaでプラグインを作る機能なんかを持たせられるので面白い気がする(100% PureJava?そんなの知らない;-)

D言語なんかはその辺中途半端で、全部自前で実装する必要がある点は本当にGC付きのC++のようなカンジ、ただこのアプローチで致命的なのは本来GCはシステムが持つべきもので例えばAPIやモジュール境界をまたいで管理する領域なんかはGCの対象外にする必要がある事、少なくともD言語のランタイムは共通にしてモジュール境界でクラスを受け渡せるような方式にして欲しい所.

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

JavaにしてもD言語にしても決して感触的には悪く無いのだけど、まだ仕様が流動的だったりするので、余り自分にとっての背中を預けられる言語では無いという印象なのも確か(Javaは最新の1.5でかなり基本の文法に手が入ったし、D言語は言わずもがな)。それを仕事でメインに使っているのならアリなのだろうけど、現状では僕の「自分が欲しいもの」を作る為の分野と一致しないので余り勉強にも身が入らない.

Javaは現状でまだ言語仕様に手が入る点と肥大化し過ぎたライブラリがネック、ランタイムのバージョンの問題もありクライアント系は環境が限定できない点で非常に難しいような、正直そろそろ枯れて欲しい所だけど、ただ言語としてfixさせてしまうとJavaのようなクラスライブラリ込みの言語として出来る事が停止してしまう訳で難しいのかも、後VMの起動に時間がかかったり、GUIが致命的に重かったり(最近は昔よりはマシになってるけど)そもそもGUIパーツを座標指定できない部分なんかは確かにクロスプラットフォームを考えると理解できるのだけど(この辺は.NET Frameworkの方がマシ、ただ現状まだプレビューで実用にはWinFXを待つ必要があるとは思うけど)正直もう少し何とかならないかと思ったり(自前で全部描画という手もあるが...:-<

D言語はまだまだ発展途上で初期レベルの言語の根幹に関わる仕様もfixされていないので、本格的に使うには信頼に足るレベルでは無い。ただこの言語、もう7年も作っているらしいのでオープンソースの駄目な所(広げた風呂敷の口を閉じて一旦正規リリースとしての機能を限定し、明確に仕様を打ち出すのが難しく(モノとしての信頼性に関わるのだが)、深く機能を掘り下げるよりも広く機能が横に広がる傾向にあり、製作者達の興味の無い所は据え置きにされる為、結果禄に完成しない) が出ている気がする.

D言語の分野についてはニーズはある(というかJava1.0betaが出た当初一部プログラマが期待した分野がまさにそこ、ただ現状ではクライアントJavaは既に死んでいる)と思うので、着眼点は悪く無いのだが、言語仕様が若干雑然としている点なども含め難しい所、IBMとかBorlandが買い取って開発するとかになればまた違ってくるとは思うのだけど、ここ数年(数十年のオーダーではまだ未知数だが)でモノになる言語とは思えない気もしたり.

# ちなみにD言語のページで紹介されているC++との速度比較ではDigitalMars C++(DMC)が使われているけど、DMCはかなり最適化が弱かったような、、、Win上の環境だとVC++(最適化つき)が一般的なコンパイラで最も早く、bccはそれより1.5〜2.0倍程度遅い、VC++の最適化無しは最適化ありの3倍程度遅く、gccは2.x系列の時はbccと同程度、3.xになってからはVC++に追いつきそうな所まで来ているカンジ、VC++でもVS.NET付属のものはVS6の1.2〜1.5倍程度出しIntelC++に並ぶケースもあるのだけど、IntelC++に比べると若干最適化が効くかどうかが不安定、肝心のDMCは確かVC++の最適化無しより遅かった記憶があるのだけど、、、ただいずれにしてもここで最適化しても巨大なアプリになるとメッセージループのコスト等で相殺されて余り意味が無くなるケースも多かったり;-)

# 色々文句っぽい事書いているけど、実はべつに上記言語が嫌いというワケでも無く(誰かさんはGCが受け付けないらしいけど(笑)自分はメインでC/C++を使っているけど、それんついてもやっぱり似たような事は色々思うワケで、ただ自分のメインとなる分野を考えた時に上記言語にそれ程メリットを感じないというトコロかも;-)

# D言語の7年開発続けている、で思い出したけど、何処かにやっぱり7年開発続けているソフトがあったような、、、(笑)

何か色々引っ掻き回された気分でかなりげんなり、結果云々よりも弄ばれた感があり気分的に余り宜しくない:-<
その間色々停止していたので、若干タイミングを逃してしまった事が頭痛の種ではあるが、反面これで過去については全てけりがついたと考えるとまぁ、これもまた悪くも無いか、といった所。

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

ようやくShaderManの正式リリースにこぎつける、結局Shaderの領分を外れる為最後まで迷っていたライトパラメータの拡張についてはリリースしてみて様子を見る事に、ギフトウェア化は面倒なのでやめ;-)

多分パーティクルなどと連携するような特殊なもの以外の汎用的なシェーダについてはこれで打ち止めの予定。シェーダプログラムを書く必要はあるものの、これで自分の理想とする質感についてはほぼカバーできるのが理由。

今後はモーション系やモデリング系にも手を出すか、あるいは他の分野の開発にメインを置く予定、一応(と書いてたらネタが一つ思いついた、樹木用の葉の１枚１枚を(連結をスキャンした上で)微妙に色を変えるシェーダとかどうだろう(笑)

しかし、結局ノードベースのシェーダーエディタとシェーディング言語の2パターン作ったのだが、実際使ってみるとノードベースの場合シェーディングロジックなどまで含むある程度以上の規模のシェーダを作るのは無理があると実感、ある程度抽象化されたものを手早く組み立てるには良いのだがそれ以上となると過去の日記で書いた50行程度のシェーダでも無理がある為、ベストの形はノードエディタ+各ノードはプログラマブル、といった所かもしれない、と思ったり。

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

おまけ

メタリックなティーポット

起毛生地のティーポット(形状に左右されるシェーダの為イマイチ:-<

どちらも物理的モデル云々と言うわけでは無く、それらしく見えれば良いというアプローチ、結局こういうのは思いつき次第で難しく考えるよりも表面設定の一環位に考えるのもまた楽し;-)


(10/1追記)
ティーポットでの起毛シェーダの結果がイマイチだったので再チャレンジ、こういうものの方がわかり易いかもしれない.

モデリングとかは適当なでっち上げなんでその辺は突っ込み無しの方向で、、、男物って右だっけ？それとも左？
(普段ボタンついた服なんて殆ど着ないので良く分からない(苦笑)

ShaderManを正式リリースに向け鋭意調整中、もうそろそろfixと思ったのだが、1点不満があったのでLWのSDKの制限から若干トリッキーになったもののrayhittest()関数を実装、機能はレイを飛ばし交点のジオメトリ情報(座標・法線)を取得するというもの.

で、新しく出来るようになった事は以下の通り.

マルチサンプルによるSSS(Sub-Surface-Scattering)シェーダ

ちなみにシェーダのコード量は100行程度(笑) これ以外にもOGO_Hikariのボリュームシェーダのようなものも作成可能.

なおSSSやボリュームシェーダではサンプリング点を見積るのにジオメトリ情報を取得する必要があるのだが、最初交点情報が正確に取れない場合があり暫し悩む事に.

結局原因はLWの制約上あるIDを持つポリゴン上の点からrayCast,rayShadeなどのレイトレース関数を実行する場合レイが衝突したポリゴンが同一IDの場合は衝突を検出しない事が原因の模様

OGO氏のOGO_Hikariなどと同様、別途裏向きポリゴンをマージしない状態(マージするとLWが同じポリゴンと見てしまう模様)で作成する事で何とか解決としたカンジ.

、、、まぁこちらもSSSのロジックを自前で記述できる必要があるのだけど;-)
シェーディング言語にも関わらず、制約として近年の流行であるSSSが記述できないのはどうか、という点が気になっていたのである意味ほっと一息:-D

後一つ出来ない事はG2やunRealのペイントマップが実現できない事(テクスチャ機能未サポートの為)があるのだけど、ノンフォトは個人的には殆ど使わないので気にしない事にする.
(実際テクスチャ機能が無い点の殆どの部分は現状のパラメータにテクスチャを貼る方式で代用可能.

後少し、そろそろゴールが見えてきた気がする.

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

ホビーユースなので市販のプラグインはできるだけ使わないようにするポリシーだったのだけど、何となくLWプラグインのIFW2 Texturesを買ってしまいました、パラメータの設定が結構分かり難いものもある為(特に自前シェーディング系)プリセットをいじってカスタマイズする方が効率は良いのだが、プロシージャルがシェーダ200種以上とテクスチャ100種以上で用意されているというのはなかなかお得なカンジ.

まぁ自分の作っているものを否定するような気もするのだけど、Shaderを書くのはやはり手間がかかるので、それ程重要でない部分や細かいシェーディングロジックを調整する必要が無い部分についてはこういうのも良いだろう、と思ったりで結構良いカンジ(^^;;

先日書いたShaderManの正式版ですが、微妙にリリース遅れ中。プログラム自体は完成して実際に自分で使っているのだけど、サンプルとかにもっと有用なシェーダを増やした方が良いのかで悩んでます。

本当はもっと自分が普段使っているシェーダなどをサンプルとして同梱したいのだけど、公開されているシェーダを修正・流用して使っているものも多い為、そのまま添付して良いものかどうか悩ましい所(povmanとかは添付しているみたいだけど(^^;;

一応Renderman Shaderについては以下のページなどに大量のサンプルがあるので興味がある方はそちらを参照すると吉かも.

http://www.renderman.org/
http://www.highend3d.com/renderman/
http://accad.osu.edu/~smay/DigitalLighting/

まぁ結構そのままでは通らないものもあるので、その辺は修正が必要になるのだけど、ただ殆どのサーフェスシェーダのロジックは移植可能な筈.

後は、ギフトウェアについても、冷静に考えてみるとそれどころかプライベートのメールさえ返事を書くのが面倒な性分なのでどうしたものか、とか;-)

まぁぼちぼち考えるとはしましょう、と。

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

おまけ
お約束(?)のCD-ROMシェーダ、一応光源の方向で光り方も変化します、、、まぁこんな事もできますよ的に;-)

おまけ2
Dispersion(収差)シェーダ、まぁ今更透明体レンダリングして喜ぶのもアレですが、一応;-)

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

最近は何やらエンプラづいてJavaやらサーバ系の何とやらの勉強中、とは言っても自分の好きな分野と全くかぶらないので半ば適当ではあるけど、最近の動向は押さえておく意図と以前の会社での開発でそれ系が得意な人に任せていた部分を自分でもある程度押さえておこう、というカンジでまったり進行中.

何か、、、人生ってもっと単純になりませんかねぇ、と思う今日この頃。
とだけ言っても何の話か良く分からないと思うけど、まぁ何人かの友達には話してるし、後は当事者(笑)なんで、まぁ適当に愚痴モード.

確かにこんな身分になった人間に声をかけてくれるのは有難い事ではあるのかもしれないけど、こんなヤツ甘やかすと後でロクな事にならないよ的なカンジではある.

もっと世の中なんてナメたものと割り切って、特権的な話も受け入れても良いのかもしれないけど、何かそういったものを利用するのに自分の中でやましさや、甘やかされて育つ子供のような不安があるのも確か.

、、、なんでもっと単純に事が運ばないのだろう、と。
個人的にはもう単なる平凡なサラリーマンで良いから、楽にして的な思いもあるのだけど、僕はごく平凡なプログラマで、それ程大したものじゃないよ、と言いたい気持ちも何処かにあるのだけど、うーん.

と、該当何名かに向けて取り合えず愚痴です(笑)

# 気付くと雑記がやたら長くなってますね、でも取り合えず今年は丸々1ページで行って、来年は何か対処しましょう、という事で(^^;

酔っぱらって帰宅、彩の新版が出たのでちょっと落書き、はっきり言って趣味悪いです＞自分
いつかこういうクリーチャーをLWで量産したいな、と。

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

ここ数日考えていたのですが、ShaderManも安定してきたのでそろそろbetaを取り外しても良いかと思ったり。で、最新版からはかつてのqemLOSS3のようなギフトウェアの形式を取ろうかと思ってみたり。正直面倒が嫌いな事や、いまいち匿名メールやハンドルだけのメールといった最近ネットを使い始めた方々のコミュニケーションに慣れない為何ともといった所ではあるのですが、モノがモノだけに欲しいと言う人も少ないだろう、という事で検討中。やっぱり動向を知りたいという気持ちもありますし;-)

ちなみに最新版では細かい修正以外にLW上で貼った任意テクスチャ座標についてバンプまで含めたパターン計算に十分な情報をサポートした事と、複数のシェーダをレイヤーで重ねられるようにしたのが最大のウリではあります。
、、、とは言えどちらもシェーダを書かなければならないのですが(笑)

ちなみにシェーダの速度自体はサーフェスの複雑さにも依存しますが、総じて自前でフルシェーディングを行うNativeのシェーダと同程度〜最低でも50%位は出ている模様。 VM自体(スタックベースの仮想アセンブラマシン)の速度はPerlの1.5x3倍, VB6の1.0x3倍程度(x3はベクトル演算の為)とNativeコードに比べるとそれ程早い訳ではないものの、レンダリングの他の計算と合わせた時には十分な計算速度が出ているようで一安心、、、実は自分でも作る前はパフォーマンスが出せるかと結構不安だったりしていたのですけど(笑)

noboyama氏よりWTLなるものを紹介されたのでここ数日遊んでいました。
モノはMS製のGUIライブラリで、現在はCPLに基づいたMSのオープンソースソフト扱い、ATLをベースにした設計でMFCに変わる新しいGUIライブラリを作ったという代物。

但し発表当時余り話題にのぼる事も無く、リファレンスなども殆ど存在しない事から自己解決できるマニア向けでユーザーも少なく、現在はMSのサポートも縮小傾向にある点はちょっと微妙かも(^^;;

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

WTL7.1
http://www.microsoft.com/downloads/details.aspx?FamilyID=1be1eb52-aa96-4685-99a5-4256737781c5&DisplayLang=en

リファレンス(WTL3.1の頃のものだが現在でも99%は同じとの事)
http://www.pallium.com/wtl31quickref.php

クラス階層図
http://www.codeproject.com/wtl/wtldocs2/hierarchy.asp

入門用参考ページ
http://www.codeproject.com/wtl/
http://home.att.ne.jp/banana/akatsuki/doc/atlwtl/index.html
http://homepage1.nifty.com/Roy_/Software/WTL/WTL.htm

印象としてはMFCをシンプルにしたようなライブラリ、抽象化されるのはGUI及びGDI周りのみでDoc-Viewやシリアライズなどは持たず、基底となるObjectクラスも無い。

クラスインターフェイスはMFCに順ずる(APIとほぼ1対1)ものの、MFCに比べ過度にラッピングされていない為、APIとの親和性が比較的高く、メッセージマップなどは全て統一されたインターフェイスで作成でき、メッセージマップのチェーンにより基底クラスの処理を呼び出す為、MFCのようにクラスウィザードのの手助け無しでサクサク書いて行ける。

という事で悪く無い印象です、というかMFCよりは「はるかに」好みではあります;-)

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

ただ気になる点もあり、確かにカスタムコントロールを作る上での利便性はMFCより良いのですが、反面MFCとは共存できない模様で、またbccなどでもコンパイルできない(殆どはconst宣言の問題なので修正すれば通りそうではあるけど(^^;;

一方APIでカスタムコントロールを作る場合、MFCであろうとWTLだろうと問題無く組み込む事が出来、必要であれば各ライブラリでラッパークラス(MFCの場合はCWnd、WTLの場合はCWindowImpl<>にて)を作成する事である程度の利便性が図れる。

実際上のWTLの勉強中にも幾つか馴染まない個所があって、自前のAPIベースのライブラリを組み込んでみたのだが、やはりAPIの再利用性には及ばない気がしたのは事実(^^;;;

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

特に自分にとって重要な点は「同じようなコードを何回も書きたくない」という事で(だって面倒なんだもん(^^;;
仕事であればフレームワークはどのような物になるか分からないのだが、その様々なケースでの可搬性を考えると、やはりAPIが現状もっともベストの選択かとも思ったり。

かつてオブジェクト指向による再利用が話題となったが、フレームワークによる制約を受ける為。それらを越えてロバストなものを作ろうとするとフラットなAPIが最も可搬性があるのでは？という結論に行き着いたのは何とも言い難い気分ではある(^^;;

ただ自分がコードを書く際に最も重要視する個所が正にその部分で、使う関数・ライブラリのドメイン(ANSIとかPOSIXとかWin32とか)をプログラムの再利用想定に合わせて絞り込む事が重要だと思っています(例えば今回のShaderManの場合VMのソースのうちレンダラ依存の500行程度を修正すれば他のソフトのプラグインなんかにも適用できる、とか(エンディアンフリーでは無いですが(^^;;

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

無論APIで全てを作る場合、全ての作業メンバが設計になれていない事には容易に空中分解を起こす為、その底上げとしてMFCなどがある、と個人的には考えていて、そこでMFCの代わりにWTLを使うのは複雑化した場合のトラブルを避ける上では、選択としては良い選択だと思う。

ただそれはフレームワークの選択肢であって、バックボーンはやはりAPIで固めて行く方針で行こうと結論付けましたが、選択肢の幅が増えたという点はnoboyama氏に非常に感謝であります(^^)/

# でも実はプログラムを書く上で一番悩むのは変数・関数名をどうつけるか、だったりしますが(いやマジに(^^;;

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

KOJIさんの「彩」(僕が普段愛用してるペイントソフト)の話、今年の夏である程度の目処をつけると言っていたので、そろそろタイムリミットだよ〜と思って見に行くと、トップページには9月上旬との告知が、、、何だか先手を打たれてしまった気分でちょっとしょんぼり。

でも色々飯食いに行くついでに見せてもらっている所ではかなり完成しているので心配はしてないけど、今回の筆ツールと水性マーカーは非常に素敵な出来なので早く発表しようよ〜とか外野気分的には思ってしまう辺り何とも(苦笑)

個人的にはマーケティング的にメジャーになるかどうかはともかく、他に存在するペイントソフト系の中では間違いなく最高レベルの書き味だと思うので今から楽しみですよ。

毛色を変えてネットでよくある診断ページの紹介など、というか話題のネタにたまにやるのだけど、その中で比較的当たるものをピックアップ(笑)

という事で「タイプ別性格判断」やってみました。
結果はENTJ型でした、、、何気にすごく当たってるんですが(^^;
しかし改めて見直すと嫌なヤツですな、まぁ否定はしないんですがね(苦笑)

後以前やってよく当たるなぁと思ったのは「ソンディ・テスト」これの結果は

>性衝動　--タイプ
>社会への人間愛と、献身的傾向が一致した文化愛好型。性欲が昇華されて人間愛となっているが、
>献身的欲求があまりにも強くなると、攻撃性が抑圧を破ってあらわれ、おとなしく見えても激し
>い行動に走ることもある。
>
>発作衝動　++タイプ
>自分が善人であり、良心的である事を知ってもらいたい良心顕示型。自分が正しく、まじめである
>ことを訴える。極端な場合はヒステリー的感情爆発。しかし一般にはセンチメンタルな泣き虫でう
>るさい感じ。
>
>自我衝動　+0タイプ
>すべてのものを所有したい自己中心型。自分の存在から所有へと欲求が拡大する。極端な場合は自
>閉症となる。合理的で冷たく、人間関係ではあまり他人に好まれない。
>
>接触衝動　0+タイプ
>アルコール、喫煙、おしゃべりなどの快楽追求型。特に口を使う快楽に弱い。極端な場合はアルコール、
>麻薬中毒になる。しかし一般成人にもよくみられる反応である。

何故暑苦しいおっさんやおばさんの顔を選んで結果が出るのか不思議ですが自分に限らず周囲の結果も結構当たってました。

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

しかし、思い返すとこういう診断系のページを紹介する時に、当たっているから面白いと取るのか、その結果のバカバカしさが面白いと取るのかで既にその人の性格が現れますね;-)

ちなみに単に自分の結果を出すだけでは面白く無いので、実際に世の中の人間がどの程度の比率配分で区分されるのかも調べてみました。とは言え簡単にgoogleでの検索数(「〜型」で検索)の合計をチェックしただけなので、他の用語とかぶる場合や、インターネット上でHPを作るようなタイプの人間に分布の偏りが見られる可能性も高いですが(笑)

ここ2週間ほど作っていたものがようやく形になりました、と言う事でモノは本日公開のもの。
以前LWのシェーディング機能が弱いという話を書いたが、結局の所自分の理想とする自由度を考えた場合にこの形に、自分がここ数年欲しいと思っていたものを作る事が出来たので非常に満足ではある。

とは言え、有効に使えばBRDFについてはほぼあらゆる表現が可能であり、自分にとっては非常に有用なソフトではあるのは確かで、LWのプラグインシェーダを書くことを考えるとその1/10程度、LScriptと比較しても半分程度の労力(+安定性&速度(笑))で同じものが作れるのだが、プログラム言語という事もあり実際使いこなせるLWユーザーは余りいないだろう(せいぜい全体の数%程度か?)、という事ではジョークソフト的意図もある。
ある種only seriousというトコロで、こういうある種無駄とも言える努力は非常に楽しい;-)

ちなみにShaderManと言うと現在ではRenderManのシェーダツリーの方が有名だが、LWにも以前ShaderManという名前のプラグインがあり「あのRendermanのシェーダが使える、Rendermanの質感が出せる!!」という謳い文句で比較的広く販売されていた。

LW購入当初非常に興味を持ったのだが、よくよく調べると単にRendermanの入門書に掲載されている単純なサンプルをプラグインで実装しただけというプログラマならある種眉をひそめるような代物であった。

実際LWの標準的なシェーディングアルゴリズムとRendermanのサンプルで使用されているロジックはほぼ同様のものである為、差別化は殆ど無いと言える。

という事で今回のShaderManという名前は、自分がその名前を聞いた時に初めて想像したプラグインのイメージを実現したものでもある、、、とは言えやはりニッチである事は間違いないのだが、まぁ趣味だし自分はメインで使うのでそれでよし、と思ったり(苦笑)

大体一段落したので、次は以前作ったデータ処理向けインタプリタの開発を再開予定。実験データなど大量のデータを処理する為のもので大学時代に欲しかったものなのだが、最近ではめっきり数値処理を扱う事は無く、どちらかと言うと数式処理の方が使用頻度が高いのだが、実際に作れるだけの技術を身に付けた時にはそこまでの計算機能は不要になっている(表計算でも何とかなる)というのは何とも言い難いものがあるが;-)

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

普段愛用しているペイントソフト「彩」のコアテストバージョンが発表に、まだコアルーチンのテストという事で、以前のバージョンの機能は全て実装されておらず、ちょっと落書きして遊ぶ程度ですが、ＫＯＪＩさんによると今回"こそは"本気という事で(笑)

非常に期待大です、というかペンツール凄い気持ちいいよ、早く完成させろみたいな(ヲイ

友人に「言語処理系の一つも作れないでプログラマを名乗るとは笑止、ヘタレにつき人にあらず」などと言われてしまったので(一部誇張アリ)コンパイラ・インタプリタの作成を勉強中、ついでに手書きで構文解析器をメンテするのは嫌なのでyaccとlexの使い方についても勉強(既にヘタレかも(苦笑)

んで何となくではあるものの見えてきた気分、まだまだ勉強が必要なのだけど、規模にもよるけど、数ヶ月あればインタプリタ・コンパイラも何となく作れそうな「気分だけ」してみたり。

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

以下、未だ勉強中であるものの、コンパイラの勉強をしようとして挫折した別の友人への書置きとして自分の詰まった所などメモ。

・基本的な構文解析がどうやるのか分からない
再帰下降式の簡単な数式インタプリタ書いてみる。「C言語による最新アルゴリズム辞典」に短いサンプルがある。

・再帰による文法の評価順序
上向きと下向きの2つの方式がある。手書きで書きやすいのは下向き(下降式)構文解析、yaccを使う場合は上向き(上昇式)構文解析となり、それぞれトップレベルから、要素からの順に解析ルーチンが呼ばれる。

・関数・繰り返し処理など
その時点での簡単な式の評価なら構文解析時に可能だが、ループなどを含む場合は構文解析時に構文木を作る必要がある。トップレベルに戻ってきたら構文木が出来ているので、その構文木を評価する事でインタプリットできる。構文木の構造体は言語設計に寄るが、言語要素の全てを表現する構造となる。

・構文解析中に確保した作業メモリの解放
自分のアプローチとしては専用マネージャで確保し基本的にトップレベルに戻ってきた時に作業メモリを解放。構文木の各構造は別途構文木マネージャにより必要に応じて開放。

・評価
得られた構文木をトップレベルから再帰的に辿る事で評価可能。変数や関数は裏でルックアップテーブルを持つ。
メモリ上に分断化された構文木を辿るのは効率が良くないので、速度が必要な場合やコンパイラを作る場合には構文木を辿ってテンプレートに従ってVMやアセンブラのコードを吐き出す。

・日本語の取り扱い
解析時に日本語をS-JISからEUCに暫定的に変換するとASCIIコードとかぶらない為、処理が楽になる。後は何処かのタイミングで元に戻す。

・lex&yaccを使ったルーチンを部品として自作プログラムに組み込む
入力のカスタマイズ(lexのYY_INPUTマクロ)、エラー復帰(yaccのerrorトークン及びyyclearin規則)、また複数のパーサを組み込む場合にはlex&yaccの生成コードのプリフィクスを指定。構文解析ルーチンではグローバル変数などを使用している為、パラで呼ばれる事を想定して排他処理をかける。

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

ちなみに、まだコードの最適化については分かっていない:-<
しかし、現在yacc&lexの本って出てないのかも、自分は昔買ったのを持っているのだけど、amazonで調べたら全部在庫なしになっていた...最近はO'Reillyなんかも出る本の方向性変わっている気がするし、やっぱ時代に取り残されてますか？(涙)

とは言えまだまだ勉強しなきゃね;-)

まずは現状報告、例の所は残念ながら落ちました。会社には期待してなかったものの勤務条件が良かっただけにちょっと残念。まぁでも引きずっても仕方ないので、その件の敗因分析と修正項目のリストアップ及び修正案作成だけやって、現在更に職探し中です(苦笑)

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

ちょっと肩の力を抜いてObjective-Cの勉強などしてました。

Object指向言語としては基本的にはC++と同様、特徴は主に

・オブジェクトメソッドの呼び出しが全て動的に決定される
これにより統一して扱われるインスタンスに対しメソッド実装の動的問い合わせを行ってからの呼び出しも可能だが、反面コンパイル時にオブジェクトメソッドの実装の有無が決定できない為、クラスで実装されていないメソッドを呼び出すと実行時にエラーとなる。

・オブジェクトは全て基底としてObjectクラス(ランタイムによりさまざま)を持つ、ライブラリや文法については標準は規定されていない為、細かい部分は実装系に依存する。(異なる2種のObjective-C処理系でライブラリや細かい文法が異なるケースも多い)

・インスタンスは基本的に参照として統一的にid型として扱われる、コピーはdeepCopyなどで明示的に行う。また継承は単一継承で行われる。処理系にもよるが生成したインスタンスは明示的に削除する、但しライブラリで選択的に(Mac)あるいは言語として(POC)リファレンスカウンタなどのgcを持つものもある。

Windows上で使えるObjective-C処理系としては以下の2つを発見

MinGW(gcc)
gccベースのObjective-C、昔NeXTから寄贈されたコードがベースになっているらしい。
実行形式も置いてあるのでそのまま使える。

Portable Object Compiler(POC)
Objective-C->Cプリプロセッサ、色々と実験的な機能を取り入れている。メッセージをオブジェクト化したり、ブロッククロージャ(但しコンパイラ言語なので限界あり)をサポートしたり、言語レベルでガベージコレクション(リファレンスカウンタorBoehm GC)をサポートしている。VC++用のコンパイル済み実行形式も置いてあるが周辺ライブラリは最低限のものしか付属してないのでコンパイル要。なおEUCは通るがS-Jisを含むソースはコンパイルエラーとなる。

また基本的な文法についてはAppleのDevelopperページなんかが役に立つ(一部MacOS用の開発環境に特化した方言もあるものの、概ね他のObjective-Cでも使える)

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

感想としては、言語自体はシンプルなのでC++程イメージを掴むのは難しくない。後はクラスライブラリをどれだけ把握するか、というObject指向言語の典型的な学習曲線に従うと思われる。

ただメソッド名等のプログラムミスは実行時にそのパスを通らないと検出できない事、またその回避策も無い為、コンパイラ型の言語に向いているかは少々疑問で、何らかの形で開発環境などがサポートしないと効率が悪いと感じた。

動的とは言え、シンボルなどはコンパイラ型言語の制約を受ける為、あくまでメソッド名(セレクタ)などの要素に限られる点で自由度はそれ程大きくは無い。

ただ(これもコンパイラ型言語の制約は受けるが)POCのブロッククロージャの文法で

id block={
    char *msg="Hello world!!";
    puts(msg);
};
[block value];

などと書けるのは非常に羨ましい、内部的にはコンパイラが無名の関数を別途生成するだけなので、C/C++でも同じ書き方ができたら良いのにと思ったり、Object指向とは余り関係無いけど(^^;;

感想としてはまぁ特にObject指向言語として目新しい所がある訳でも無いし、実際Objective-Cをメインで使う事も無い(と思う)のだけど、基本的な機構はC/C++などでも実現できる訳で、こういった言語とその裏にあるどう作るかという概念について学ぶのも設計の参考になると思ったり。

# 余談だけど、最近また増えはじめたObject指向設計の本を読むと(ものにもよるけど)また昔のブームの時と同様にOODとOOPの混同がある、と思うのは自分だけだろうか:-<
(ただ昔のブームがプログラマ向けだったのに対し、今のブームはもう少し裾野が広がっている印象を受けるけど、やっぱり明示的に「オブジェクト指向で設計」などと言うとどうにも胡散臭い印象を受けるのは自分だけだろうか(笑)

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

後は少し興味対象を広げよう、と言う事で色々本を読んでます。ただ人間の各個体の揺らぎの範疇で説明がつく内容についてはどうにも興味を持てないので、生物の進化や機構だったり宇宙の成立だったり大統一理論系だったり、とまぁ(苦笑)ただこういうのは知識を仕入れても個人で実験出来る訳でないのが何とも辛い所。

後子供向けの図鑑が何冊か欲しくなっているので(昆虫、海の生き物、太陽系、宇宙、古代の生き物は欲しい所) この前確認した所大体一冊2000円程度と技術書に比べると安いので、現在良いものを探し中。ただ色々本屋で見ると子供向けとは言いつつ大人でも楽しめる内容なので中々お勧め。

なお調べ物の最中に子供の頃見て正体不明だった宇宙生物じみた生き物の正体を知る事に、トラウマになっているので余り語りたく無いのですが、どうやらコウガイビルと言うらしい。余りにおぞましいのだが、進化上は面白い位置にあり、摂食行動なんかは実に特徴的で改めて見ると感心してみたり(細かくは述べませんが、興味のある人は「コウガイビル」で検索してみると色々出てきます(^^;;

面接行ってきました、まぁ受かるか落ちるかは上手くニーズが一致するか、なので何とも。
ただ一つ気付いた点として面接で色々自分がやってきた事を説明するのだが、自分場合やってきた事を正直に説明すると「何か実にウソ臭い」少なくとも自分だったらそんなアピールをする人間は信頼しない気がしてみたり(笑)

比較基準の問題だけなのだが、こういう時は何とも...ummm:-<
どうにも面接とかで自分を売り込むのは苦手だと実感。

確かに言わんとする事やニーズも理解できる、数百万行のコードをでっち上げるのは確かに1人では不可能で、世の中にはたしかにどのような状態であれ、それら一式を力任せで用意する仕事も必要だとは思うのだが、やはり自分としては、一通り揃っているものの何ら光るものの無いものよりは、小さいが磨かれたものを作る方が自分は好きだ。

先方は割り切りだと言っていたが、確かにその通りだろう、しかしそれで何かを作っているなどというプライドを持ちたいとは決して思わない(自分がみじめになるだけ、だから;-)

ある種の見切りをつけ前の会社を辞め、その後再就職にあたりある程度の割り切りはつけようとは考えたものの、いざ現実にその決断に直面するとなかなか悩ましい。自分はそこまで現状の(企業で構成されている部分の)コンピュータ業界で働くという事に割り切りをつけられるだろうか、と自問自答。

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

個人的にはその人間のしがらみの全てを取っ払って「あなたは何者で、何をする人間なのか？」と問うた時に答えられない人間は好きではない(自分に対しても他人に対しても)のだが、何となくではあるものの、この辺のSEやコンサルタントという仕事に対する嫌悪感は全てはここから始まっているのかもしれない、とは思う。

6/21追記) 余談だが冷静に考えると200〜300万行という数値はある意味大したものだが、同時に大したものでは無い事に気付く。確かにモノリシックにそれだけの規模があるなら大変だが、モジュール化と階層化、スケルトン部分以外の共通した土台を元にした実際の実装が複数存在する事などを考えるとまぁ妥当な話だろう。しかし、行数というのは確かに大規模では妥当な算定方法なのかもしれないが、やはりそれを強調するのはどうにも胡散臭さが漂うなぁ...言っているのがlinuxのディストリビューションと周辺パッケージ含めて何百万行って言っているようなものだから(苦笑)

現状ではLW+Rendermanという余りにニッチな自分のニーズを埋める為のプログラムなので。なお実際ユーザー会などに出てる人に聞いた所によるとRendermanのまともなユーザーは日本でも数百人位しかいないんじゃないか、との事。とするとわざわざミドルエンドで市販ではまともなエクスポータも無い状態(自分は自作のものを使用している)のLWで使っているのはせいぜい日本で10人程度でしょうかね;-)

実際LWレベルの表面設定機能があれば外部ソフトに頼る必要は余り無い訳なので、実際にはShadeやCarraraとかに組み込む方が有用かもしれない。実際SDKを見る限りでは十分可能だと思うのだけど、如何せん自分が本体を持っていないので何とも:-<

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

そういえばＫＯＪＩさんと話していて「今度こそ」夏ぐらいまでには「彩」の新版をとの話が出ました。暫く忙しくてここ2年程中断していたらしいのですが、現状一段落したので仕事もカットして鋭意製作中との事、と言うか完成間近まできていたのに全面作り直しなんてやっていたから(笑)

個人的には体験版の仕様(512x512まで、独自形式のみ保存可)では使う前に放り出していた人もいるのではないかと思うのですが、、、(実際自分も最初に触ったバージョンがそうならまず使わないでしょう)

個人的には非常に良いソフトで、タブレットを使った場合の手書きとのギャップの解消(特に細い線)については、おそらく世界最高水準レベルだと思いますし、最近に至るまで色々なソフトを見ていますが、手書きの再現性とレスポンスについてこれに勝るソフトは見た事が無いので、正直今から楽しみではあります(但しタブレットを持ってないと全く意味ないですが;-)

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

「日記の更新が無いぞ」と友達に心配されてしまったのですが、先のDeepShadeが一段落して、社会復帰(笑)までにやりたい事の大体7〜8割は終わったので現状腑抜けてます。

実家の方で色々ごたごたしてたり、就職活動を始めたりといった具合で、一応ニューラルネットだったり、古代の生物に関する本を読んだり、神経心理学に関する本を読んだり、癌に関する本を読んだりとはあるのですが、ここに書くまでの話でも無かったので(笑)

しかし、最終的にはこの半年近くの間で「自分に足りない」と感じていた内容のかなりの部分を埋める事ができたので非常に有意義な時間だったと思います、、、これから、どう転ぶにせよ、ね;-)

・対象プログラムのGDIリソース使用状況・種別がリアルタイムでモニタできるリソースモニタ兼リークチェッカ
・システム全体についてアプリケーション単位でリアルタイムでネットワークを監視してネットワークの使用があればそのアクセス状況について記録するツール

それぞれデバッグ・パフォーマンス分析用とスパイウェア等監視用、まともに作るとシステム寄りのかなり突っ込んだ話になり、フリーソフトなど色々調べてみるも満足行くものは見当たらず:-<
vectorなんかにはそれ系のはあるのだが、GUIとかに凝っているものの中身は標準コンポーネント呼び出しているようなものばかりだし...

自分で作るとなると作れなくは無いけど単調作業になるので面白みが無いし、システム寄りのノウハウは全部出すから、だれか作ってくれないかなぁと思ったり.

ソフトは巷に溢れているのだが、必要なものは見つからない、そして意外と現状のコンピュータに何かをさせるという環境は未だ不自由なまま、微妙に何かがずれている気がする.

本日何気なく疑問をもった事柄

疑問1)

ジョーズを見ていてサメが赤い血を流すシーンがあったのだが、赤い色素はヘモグロビンの影響であり、ヘモグロビンの機能は酸素を伝達する事になる。それに対し昆虫などの場合は血液は赤色では無い訳で、魚類と昆虫は進化上血液の機能が備わる前に分化した生物、という事になりそうな気がしてみる。

んで、どの辺りで分化したのか、が気になってみたり。結構昔学校で見た進化の図なんかでは魚類はからは書いているのだが、それ以前については書かれていない。多分昆虫はエビとかの仲間に近いのでは、と思ってみたり。多分脊椎が形成されたのが確かカンブリア紀の魚類とも甲殻類ともつかない生物が最初だったと記憶しているので、その頃分化したと考えるのが妥当なのだろうか？

疑問2)

昆虫の幼虫と成虫を見ていて思うのだが、幾つかの昆虫は幼虫の時期が殆どで成虫になってからの期間は水やせいぜい樹液などをエサとするだけで、繁殖の為だけに行動し、繁殖期が過ぎたら簡単に死んでしまうようなメカニズムを持っている、この場合幼虫to成虫というよりも活動個体to繁殖個体に近いのではないかと思う。では何故このように変態により個体の機能を明確に区別する必要があるのだろうか？

また昆虫でも幼生と生体が殆ど同じ機能を持っているものも存在する(ゴキブリとかカマキリとか)。つまりこれらの種と先に書いた種では遺伝子的な生存戦略が異なる訳で、それぞれどのような特徴があるのか、と思ってみたり。また昆虫以外にもウニやエビなどは 幼生の状態と生体の状態で別の生物と言える程違う訳で、これらの無脊椎から分化した生物の生存戦略とはどのようなものなのか、と思ってみたり。

また、昆虫やエビなどについて生命の起源は海中である事から、海の生物の方が速い筈なのだが、どの辺りで分化したのか、と疑問に思ったり。

まぁ、自分に知識が無いのでこれらの疑問に対して答えは持っていないのがちょっと悔しい。もっと本当はプログラム以外にも興味を持たないといけないとは思うのだが、時間も足りないというのは言い訳でしか無いが、複数の興味対象を持つとその比率配分で疲れてしまう、でもやっぱりいつか勉強しておきたいな、と思う本日。

4/14補足)
考えて見ればカモノハシなんかも面白いと思ったり、哺乳類で唯一卵生の生物だが、他の哺乳類が胎生である事を考えると哺乳類は元来卵生から胎生に進化したと言える、という事は哺乳類の生存条件(地上)において戦略上卵生よりも胎生の方が生存可能性が高い事を示す。それに対し鳥類では未だに卵生を維持しているが、これは鳥類のような生存環境では逆に卵生の方が胎生より有利、あるいは何らかの生存上の理由により卵生という戦略手段をとらざるを得ない状況にあるのだろうか？

総括すると、どのような理由があろうと警察としては現状のWinnyネットワークの根絶・あるいは回復不能なまでのダメージを与える必要があったのだろう。

今回の作者の件については非常にグレーゾーンでの解釈が多く、一部では余りに強引な法解釈であるとの指摘もある。で、情報を集めていた所、警察関係者の発言として、こういった強引な理由で逮捕に踏み切る場合にはある程度固めれば別の容疑で逮捕できる可能性があるか、あるいは何処かからの圧力がかかった可能性が高いとの事。無論ネット上の情報などその真偽の程は定かでは無いのでこの発言自体に信憑性があるかは非常に疑わしい所ではあるし、また一部では著作権団体の圧力だというような声もあるが、警察の従来までの著作権に対する対応と比較しても異例であり事態はそれ程単純なものでは無いと思われる。

ただ今回の件の本来の意図は単なる著作権云々の問題では無いように思われる。
先に書いた京都府警の機密文書流出の件だが、Winnyの分散所有型のモデルは言うなれば文書の永続性に対する一つの解と言える。

そして該当文書については単なる一署員の不祥事といった問題では無く、実際に民間人の名簿という形で個人を特定可能な情報が含まれており、Winnyの持つ分散型の特性上、そのような情報が「警視庁の職員の違法活動が原因で」Winnyネットワークが存続する限り恒久的に不特定多数に対して流出している可能性がある事になる。

とするならその事実はその組織の存続にとって非常に忌々しき問題となる。
例えばあなたがその組織のメンバーあった場合、その事実につてどう対処するだろうか？
考えてみると実に興味深い背景が想像できないだろうか？

# この件については客観的分析のみで、物事の善悪については触れない事にする、立場が違えば善悪の規範も異なる、悲しいかな世の中はそれ程単純ではないからだ。

「Winny開発者、逮捕」

正直Winnyに関連する文化自体にはネガティブなのだが、分散システムの実験性という点では、一つの試みとして非常に面白いものでもあり、ある意味分散型のシステムでここまで一般に定着した環境としては実に興味深い.

しかし、これはそういう問題では無く「プログラムの自由」に関わる問題で、技術に罪を問うかという問題でもある.

そういった意味で安直に見せしめを作ろうとする京都府警の態度には怒りと失望を禁じえない.
(実際にファイル共有して逮捕された連中には全く同情しないですけどね、自業自得;-)

余談だが先日Winnyネットワークを通じて警視庁や防衛庁の機密文書が漏れたという件について、確かあのウィルスは感染マシンがWinnyを使って実際にファイル交換を行っていないと動作しない訳で、実に失笑を禁じえないのだが、今回の件は警察内の身内の不祥事を誤魔化す意図や、現場の中央に対する点数稼ぎ(交通安全週間なんかでよくありますね、ノルマとか;-)もあるのかもしれない、とすら思う;-P

正直今回の件を受けて思うのは、現在のイラク人のアメリカに対する感情や、アメリカインディオの征服民に対する思いはこのような感情だったのかもしれないと思う.

プログラムの自由を信奉する者として、また末席ながら技術に携わる者として今回の京都府警の行動を非難する.

# ただ、今回この文を書くにあたってWinnyについて調べてみたのだが、暗号部分にRC4を使ってしまうのは余りにお粗末だと思う。また公開鍵系を使うにしても乱数系列などは時刻をシードにするなどもってのほかで、乱数の離散的特性などを含め慎重に選ばなければならない(自分、一応以前仕事でセキュリティ・暗号関連やってました(^^;;;

かつては、ウィルスに感染するようなユーザーはそのユーザーが自己のPCを管理出来ていないのが悪く、プログラムは自由だったと思うのだが.

自分も正直今でこそウィルスなどは作ろうとも思わないが、子供時代にはそのメカニズムに興味を持って、雑誌に掲載されたブートセクタ感染型のウィルスを改造して色々いじる事で、PCのブートシーケンスを理解した経緯もあり、それが世の中の趨勢と共に逮捕されるような状況になった現在というのは考えると何とも切ないものがある.

今でもPCに対する感覚というのはその時代から自分の中で止まったままで、かつて友人とプログラマとは何か、という話をした時も、またかつて実際そうであったように、自分はエンドユーザーでありプログラムはコンピュータを操作する為のオペレーションでしかなく、自分に出来る事である以上、誰でもやろうと思えば出来る事だと思っているという話をした.

そういった意味では今回の件は非常にショックだった、薄々、前の会社の人間の対応などでも気になっていたのだが、時代が変わり、そしてコンピュータを使う人間の種類も変わったのかもしれない、と思わせる出来事だった.

...とは言え自分は相変わらず「気に食わなかったら自分で組め、誰でも出来る事なんだから、組めないなら発言権など無い」と言いつづける(自分に対しても他人に対しても同様に)とも思うけど;-P

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

先日書いたテクスチャのアンチについては見えてきた模様.
せいぜいLWと同レベル程度(お世辞にもLWのテクスチャフィルタリングは綺麗では無い)のものではあるが、これで遠景に貼ってもある程度許せるものになりそうではある.

苦労したのは余りに初歩的なせいかMIPマップの構造(Σ(1/4)^nの極限値が4/3となる)は説明があっても、それをどう補間するか、については資料が見つからなかった為、結局自分で補間式を試行錯誤で作る事になった事だが、そのお陰で色々勉強になったので良し、今更ながらにRendermanなどのテクスチャやサンプルに対するフィルタ関数がサンプリング理論における窓関数の役割をしている点に気付いたりと少し間抜けな話もあったりして(^^;;

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

以前ここの日記に書いていたツールについて本日暫定アルファ版として試験公開。
ソフトの性質上前のバージョンとの互換性維持が非常に難しい為、現段階で公開するかどうか迷ったのですが、友人にも約束していたし、幾つかメールも頂いたので、という事で一応.

アルファ版と言っても機能的にはほぼ予定した最低限の機能は全て実装しているので、一応は問題無く使える筈.

ベータでは無くアルファとした理由はソフトの設計上これで良いのかという根本的な、所謂アプリケーションの完成形がまだ自分の中で確立出来ていない為です.
後は実際に使ってみないと判断できない、という事で場合によってはコア部分を書き直す可能性もある為(場合によってはこれをバージョン1という事もあるようですが;-)

という事で不具合及び自分自身が使う上での致命的な問題以外に関しては現状暫く凍結して1ユーザーとして判断するつもりなので、取り合えずの区切り.

なお現状把握している完成形までの問題点及びそれに対する実装のStateとしては

・テクスチャ機能が弱い(バイリニアのみ、面積フィルタリングはしていない)
→MIPマップの実装を試しているがまだ実用レベルで実装出来ていない.

・アニメーション機能が弱い
→スプラインエディタなどでサポートしたいが、インターフェイスの実装案及びアニメーションパラメータの連結についてがまだ見えていない.

・パターンが少ない(CheckerとかWoodとかお決まりのアレ)
→基本はイメージテクスチャ + ノイズで何とでもなるので完成形が見えるまで後回し.

・ドキュメントが無い
→面倒なのでアルファ版以降.

またあくまで自分が使い易いように、という事でLWの標準パラメータと一致させているのだが、(LWの場合各チャンネルを変更するシェーダと自前でシェーディングを行うシェーダでは他のプラグインと併用した場合の併用の自由度が大きく異なる)
同時にLWのヘタレな仕様に制限される(例えばハイライトや自己発光に色設定できない、アンビエントに関する調整が出来ない、反射・屈折の減衰やティントについて細かい設定が出来ない等々)ため、他のソフトに組み込む事も考えると本当にこれで良いのかについても見えていない為、まだ変える可能性を残しつつも、このソフトの開発ばかりやっている訳にもいかない(飽きる)ので今回の試験公開という事にしてみた。

しかしこういうタイプのアプリケーションってプラグインなんかの小さなツールとはまた別の難しさがあるなぁ、と妙に実感。
...とはいえまだまだ自分はそんな偉そうな事を言えるだけの力量も無いのでアレな訳ですが(^^;;

まだ深く突っ込んでませんが、IK Boosterが予想以上にいーかんじですね、2軸動かしてもFlipping起こさないし、跳ねないし。バタフライの手の動きがちゃんと表現できます。ただまだ色々な機能との組み合わせでは使ってないので問題がある可能性もありますが。ただボーンを動かしていて通常の編集モードとIK Boosterのモードのどちらなのか分かり難いのが難点かも。.

EdgeToolsとRounderは小技的だけど便利ですね、Rounderの方は割り方を気を遣わないと5角以上のポリゴンが出てしまうので注意が必要ですが、仕上げなら問題無い訳で。

ドープシートは便利、ただこれも自作のスクリプトでキーフレームの移動とかやってたので余り目立ちませんが。SpreadSheetの再描画関連の挙動は相変わらず、あれ...ウザいんだけど:-<

GIのIrradianceCacheの精度は相変わらずダメダメで、今度も最終的にはモンテカルロか外部レンダラを使うしかなさそうなカンジ、せめてIrradianceGradient位使って欲しい...:-<

ダイナミクスはまだ触ってないので不明。人にもよるけど日常的に使う機能ではないから、まぁ(笑)

Layoutのマルチアンドゥは今更な感はあるけど、すごく便利。ただプログラマ的に見ればアンドゥは(特に後付けでの)実装が難しい機能なので、ご苦労様という所。

SDKのドキュメントはまだ出てないみたいなので、内部的にどう変わっているかは不明。
まぁ外見見る限りそれ程変わってない気もするけど(^^;;

しかし、世間的には盛り上がってませんね＞今回のUpdate
ま、暫く遊んでみようと思ってます。

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

CMでやっているけど「CASSHERN」(映画)が何気に気になってます。
元はアニメだか特撮だからしいですが、はっきり言って知りません(笑)

ただCMでやっている映像が面白いなぁ、と。もろゴシックでベタベタな気もしますが、やっぱゴシックって好きですね、余りマジにやられると見ていて気恥ずかしいですが;-)

ただ、CMの映像では面白そうでも、作っている所が日本の会社という事で、実際見てみたらハズしそうな気もするし、やっぱレンタル待ちの方が良いのかしらん？

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

プログラムの方は一段落、作成したテクスチャのLWでのレンダリングもできるようになりましたが、インターフェイスなどで部分的に気に食わない所があるので、未だGUI部分をいじってます。ロジック的なものはある程度決定論で済むので楽なのですが、オペレーションの設計部分は多分に非決定論的で難しいですね。

んで最近思うことがやねうらお氏著の「Windows プロフェッショナルゲーム プログラミング」が面白いなぁ、と。

前半の内容がアプリ内のデータ管理部をどう作るかというマクロ的な話で、デザパタ本とかより具体的な話寄りなのが素敵です、別段ゲームで無くとも非常に役に立ちますね。２の方はどちらかというと演算の効率化とかマイクロスレッドの話で局所的であったり、特化した話な気がするのでまだ購入してませんが(^^;;
...でもスタック切り替えで実行コンテキストを切り替えるのって昔のOS上ならともかく、今のOSでネィティブレベルでクライアントが実装するのって正しいのかな？;

ただこういう本(に限らずデザインパターン的な本)の読み方って、まずこれを読んで設計では無く、まず自分で作っていってある程度形になったタイミングで見落としが無いか、とかもっと良い設計方法は無いかとかの参考にするのが妥当な気がします。

...そういった意味ではデザインパターンは便利だし必要だとは思うんだけど、昨今のデザパタ談義はどうかなぁ、と思うんですが、そう思うのは私だけでしょうか？(UMLなんかも同じ、ね)

実際書籍とかでもよく書かれてますが、まずパターンありきで考えるのは間違いという事ですが、書籍なんかの場合パターンだけがクローズアップされて、読者に実際にそういった構造を必要とするものを作った経験が無ければむしろ毒にしかならないのでは、と思ったり。

<愚痴につき削除、要は他人に頼られたりアテにされたりするのって嫌いなんです、って事;-)>

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

話は変わるがデザインパターンの解説でよくクラスの相関で表現されるが、あれって余り良くないのではと思ったり。あれが表現しているのはプログラム内のデータ構造のフローで、そういった意味ではまずクラスありき的な名詞的アプローチというよりも、動詞的なアプローチなのだから、説明し易くはあるが、オブジェクトで解説するのって逆に分かり難いと思ってみたり。

そう思うのは実はまあ、時代に取り残されているのかもしれませんが;-)

ぶっちゃけ個人的には現在主流のクラス-インスタンスが分離されたオブジェクト指向云々よりも、C++のシンボルをそのまま透過的に使えるインラインLispの構文を備えた処理系が欲しい、と。事前予測無しに何でも突っ込める柔軟なゴミ入れが欲しいだけなんですが。コンテナとかそういうレベルでは無く、言語の記述要素(手続き型言語で言う所の宣言)レベルで実行時に評価、動的に構造の結合を変えるようなプログラム、という意味ね;-)

最近Carrara3の体験版で遊んでいます。

ポリゴンベースのパーソナルユースとしては中々いーかんじに一通りの機能が揃っていて、LWの感覚で詰めようとすると底が見えてしまうものの、これはLWとRendermanを比較しても同じようなものなのでまぁ、でも何か触ってて楽しい:-D
(描画関係が怪しかったり、プログラマから見てどっか壊してない？って挙動をする事があるのはご愛嬌;-)

LWを購入した当時にこれがあれば、取り合えず入門用として買っていたかもしれません(メタセコとの併用が前提ですが)といったカンジで、何か肩の力を抜いて遊べるオモチャとしてちょっと欲しくなってます.

...問題は既にLWを持っているので買っても殆ど意味無い事ですが、うーん;-)

# 余談だけど、最近思うのは3Dソフトで絵を作る場合の照明って照らすよりもどう影を落とすかという方が重要な気がしてみたり。極端な話純粋な環境光とAmbient Occlusion(スカイライトのようなもの)だけ、あるいはプラス照明条件(影無し+ライティングジェル)でキーライトならぬシャドウライトを配置して行く方が便利なんじゃないかと思ったり、などと思うのは自分だけだろうか?

試験実装なので別段速度などは気にせず線形検索にて実装、数時間で完成するもののAirでは動作するのだが、3Delightで動作しない為半日悩む事に。

結局の所、gridsizeオプション(一度にシェーディングされるマイクロポリゴン数)の問題と判明、IrradianceCacheを使用する場合にキャッシュを探して一致するものが無ければGIを計算、結果をキャッシュにストアするのだが、ここでの計算が並列化されていた為、正常にキャッシュの計算が出来ていなかった、間抜け。

この計算はDSO内では無く、Shader側で複数の文をまたいで計算されている為、仕方ないのでgridsizeオプションを1にする事で無事解決。

ちなみにこのIrradiance Cache、LWではラジオシティの補間モードになる訳だが、LWを使っている人ならおなじみの通り、各サンプルがシミのようになってしまって最終レンダには使いづらい。かといって許容誤差を大きく取ると細かい陰影が飛んでしまうというやっかいなもの。

んで今回のDSOをいじっていて思ったのだが、許容誤差をプレパス(キャッシュ構築時)と補間時に別の値を使用する事である程度の改善がみられないか、という事。一応各キャッシュ上の点についてweightがかかるので単純にプレパスを荒くしたのとは違う結果になる筈。

という事でやってみた。ちなみにGIアルゴリズムはごく単純なMCRTで、サンプリングは72ray/spot、拡散反射は2次まで計算。

【キャッシュ構築時の状態(プレパス)】

【キャッシュ構築時のパラメータで補間】

【キャッシュ構築時よりも許容誤差制限及びサンプル半径を広く取ったもの】

【おまけ: キャッシュ構築・補間時共に上と同じ広いサンプリング精度で計算した場合】

これを見る限り、cornellboxのようなシーンでは上手く行く模様。より複雑なオブジェクトに適用した時にどうなるか、はまだ未知ではあるが。

ちなみにレンダリングに2パスを用いるのでLWにはフィードバックは効かなそうではあるが(笑)
...強引にShaderでプレパスを計算してPixelFilterで補間とすればいけるかもしれないが(^^;;

まぁ自分が余り使わないので正直GIには余り興味が無いのだが(上手く使わないとリアルにはなっても絵として面白く無いし)ボロノイ的なものは他にも色々使い手はあるので勉強としてぼちぼち遊んで見るのも悪くないかもしれない。

# ちなみに最終的なGI+直接照明の合成はCinema4D形式にて。以前デモ版で試しただけだがCinema4DとLWでは同じシーンでもGI使用時に結果の輝度分布がかなり違ったものになるが、これはLWがGI使用時に環境光の影響を無視するのに対しCinema4DではGIの結果にデフォルトの環境光を加算しているのが原因と思われる(両方のロジックを自前のGI実装にて一致検証)まぁ近似なのでどっちでも良いのだけど、主観としてはCinema4Dで使われている方式の方が色合いとしては綺麗に出るなぁ、と思ったり;-)

というコトでDarkTreeのサンプルにあるようなテクスチャを作って見る。

...結構えらいことになっている;-)
個人的にツリー形式の編集画面というのは気持ちが良いのだけど、複雑になると把握が困難になるのでLWのようなレイヤー形式のインターフェイスもある意味もっともなのかもと思ったり。

ちなみに作っているソフトは上に書いたDarkTreeのようなプロシージャルジェネレータで複数のソフトで使う事を想定している為、シェーディングロジックまでは実装していないのだが、ここで感じるのはGradient(入力パラメータをグラデーション化する)とIncident(視点と法線の成す角度を出力する)の偉大さで、正確なシェーディングロジックの実装には及ばないものの、テクスチャだけで無くある程度の材質の違いまで表現できるのは手抜きとしては非常に便利:-D

ちなみにシェーディングロジックまで行くとツリー形式で編集するよりもプラグイン・シェーダを書いてしまう方が多分効率が良い.

しかし最近のソフトはきっちりしたテクスチャインターフェイスを持っているので、こういったソフトを必要とするのは複数のソフトを使っているユーザーだけだろう;-)

殆どの機能が動くようになったので、暫くは自分で使いながら随時オペレータノードを実装して行くつもり.

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

lspで実装する場合オーバーラップ処理が絡む為、単純なバイパスでは上手く行かない。 そこでローカルにサーバサービスを立ち上げ、Winsock呼び出しのシーケンスをその リダイレクトサービスの呼び出しと一致させる事で問題の解消を図る。

まずクライアント側はSocketを作成しサーバに接続する訳だが、この時の接続先の アドレスによってVPN対象アドレスであった場合には外部に接続する代わりにローカル で動作するサービスに接続を行う。

サービスでは接続に応じてhttpsなどのFirewallを越えられるプロトコルでラップ してターゲットサーバに送信を行う。 またサービスからのwinsockアクセスはlsp内でプログラムの判別を行う事で無限ループ になるのを防ぐ。

なおラップされるパケットにはオリジナルの接続先ポートが含まれる。

ターゲットサーバ側はacceptなどで待ち受けをする訳だが、それとは別にここでのVPNソフト の管轄となるhttpsなどのサーバをサービスとして立ち上げておく。 httpsサーバは外部からリクエストがあった場合にそのパケットを解凍し、ローカルの オリジナルのサーバにリダイレクトする事で双方向での通信を可能とする。

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

...何とかなりそうな気がすると思ったり、まぁハマりそうではあるが(笑)

2004/3/29補足)
書き忘れだが、LSPの場合TCP/IPなどのプロトコル単位に設定が必要な為、socketについては問題無いがIPX/SPXなど(ファイル・プリンタ共有等)を使用する場合については別途対応が必要となる。そういった意味では仮想LANカードを用意する方が妥当かもしれない.

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

それはさておき、最近はこんなものを作っている。



RendermanとLWで表面設定を共有する為のツール。 去年の10月頃に作りかけで放置したものだが、この引きこもりの間に1回形にしたい と思い開発再開。

とはいえスケルトンはほぼ完成していて、実際に色々なノードを実装しながら内部構造やエバリュエータ部に調整をかけるのがメインになる。そういった意味では新規のコード追加よりも 如何に現在のコードを削り磨くか、が問題で非常に難しい所。

教訓としては既存のコードを破棄し、作り直す事を恐れてはいけないという事だろう。 会社などでは余り有り得ない話ではあるが、これをやるかやらないかでプログラムの 質は大きく違うものとなる。そしてプログラムを書く事を重く考えてはいけない、 せいぜい日常に文章を書く事の延長程度に考える事が重要。

まぁ言うのは簡単、実行するのは難しいのだが;-)

もう子供の時からなのだが、体力が無いので無理が利かず、寝る時間になると問答無用で寝る。無論徹夜なんてできない。正常な判断はおろか、身体機能まで低下し、平衡感覚は無くなるは意識は飛ぶわ、といった所。無理やり起きて前倒しさせようとしても寝る時間帯を過ぎるとせいぜい1時間程度で目が覚めてしまう。

勿論昼寝も出来ず、睡眠薬も効かず、アルコールに弱い癖に日本酒1リットル近く飲んでようやく2時間程度眠れる。それでも体質上の寝る時間になるとやっぱり寝るというどうしようも無いもの。

実際前の会社でも1ヶ月の半分は大体そういう状態
(時間帯が合わずに朦朧とする、忙しい時は時間規則無視(笑)
だったのだが、さて、どーすっべかな、といった所(悩)

...ちなみに現在は昼12時寝、夜12時起き、友達からの電話の応対も出来ません、あー(涙)

# しかし、1日の平均睡眠時間が6時間の人と10時間の人を比較すると、1日の活動時間を12時間程度と仮定すると、成人してからの30年で10年の差が出る計算になりますね、ある意味凄い数字だと思ったり(^^;;

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

それはさておき相変わらずWin32の勉強中。

大体セオリーは確立できてきた模様。設計の基本はMVCもどき+ブロードキャスト通知で何とかいけそうなカンジ。MVCのモデル側でコントロールパラメータを提供する方式の方がスマートなのだが、クラスライブラリが前提になるのでこれはNG。

後はモーダルダイアログなんかは初期化・終了処理をもう少しいじり様があるな、とは思うがこれは簡単なので後回し。カスタムコントロール系はもう少し効率よく作れるようになりたい所。
今の自分では大体この程度(3Dアプリなんかでよく使われるプルダウンのフレーム)でも設計含め2日程度かかるので、これを1日までは効率化したい所。

まぁでも後はひたすら矩形処理に慣れる事な気がしないでもなかったり(笑)
こういうパーツは効率化も重要だけど、丁寧に作る事も重要なので、暇をみては色々なパーツを作っておくのも手かもしれない、先日のスクロールフレームなんかもちらつきを減らして、何とか普通のアプリレベルまでは持って行けたカンジ。

結局の所、次の自分にとっての壁は矩形処理と自前描画の部分を如何に定型化するかといった所.。課題として以前BCBで作ったグラディエントエディタやノードエディタでも移植してみるかとか思ったり。

でも自前描画だとどのライブラリでもそんなに手間は変わらないので、結局windowプログラムは矩形に始まり矩形に終わるといったカンジか(笑)

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

余談ではあるが、APIを勉強して行くとやっぱりMFCの駄目さ加減が目に付く。MFCとも突き合わせているのだが基本的なコーディングの手間は変わらないし、変にラップされて設計がおろそかになるし。

Wizardが生成するデフォルトが、Doc-Viewのフレームワークというのも色々問題があると思ったり、薄いラッパーの癖に変な所だけ過度にラップされていて妙に融通が効かない、かといってCWnd派生の汎用Windowをトップレベルで使おうとするとライブラリがアサートしてみたり(CWndをトップレベルにするのは想定外という事か？)はっきり言って要らん(笑)
...まぁCArchive相当などは自前で作っておかなくてはとは思うけど(^^;;

でも色々調べ物をしていると2ちゃんねるなんかもヒットするのだが、
(ちなみにあそこのコミュニケーションスタイルは嫌いです、人を罵倒する時はやっぱり面と向かって言うのが一番と思っているので(笑)
そこを読むと結構MFC擁護派もいて、上手い人はこれでもちゃんと使いこなせるのかな、とも思って見たり。

ま、余り自分ではMFCはそこまで突き詰めたいとは思いませんが;-)

<3/1 愚痴っぽいのも嫌なので削除しました;-) >
飲みは楽しかったです、ハイ(笑)

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

昨日書いたGet/SetParentについては基本的にWS_CHILD指定されているWindow専用のAPIと考えるのが妥当な模様。 一応ChildWindowについては上手く行くが、そこからOverlappedなどのWindowを作成したりすると変な事になるみたいで中々複雑。

何とか2月中に一段落させたいのだけれど...＞Win32の再勉強

ただ、内容を見れば分かるように、そこそこ使いではあると思うけど、作っている側は全く面白くない、アルゴリズムのかけらも無く、ただ面倒で、苦労する所は数少ない情報からLWのプラグインインターフェイスと格闘する、というもの。

これまた本末転倒な気がするし、この程度はソフトの標準であって良い機能だと思うのだけど...

雑記をトップから分離した事でもう少し下らない内容を書こうと思うも上手く行かない。
受ける印象とは違ってくだけた文章の方が難しいと実感。

本当はInjector(任意のプロセスに外部から侵入する為のライブラリ、APIHookなどで使う)を公開したかったのだけど、勤め先の上司から後数ヶ月待ってくれと言われて暫くネタが無い、誤魔化しにAESのコードでも載せてみようかなどとも考える。

しかしプラグインを増やすとページのレイアウトが見難くなる事に気付きブルーになる。

ついでにPhotoShopのプラグインアーキテクチャの勉強、色々とレガシーを引きずっているのか、どうにも面倒な構成になっている気がする、何でフレームバッファを処理するだけでこんなに面倒なのか。ＫＯＪＩさんが写真屋のプラグインをサポートしたい、と言っていたのを思い出したけど、これをフルでサポートするホストを作るのは相当大変だろう、と妙に実感。

Eetu Martola氏の汚しプラグインGritがダウンロード出来なくなっていたので仕方なく同じものを作ってみる、それだけでは面白く無いので自分好みに適当にカスタマイズ、bakerに対応させ、前から欲しいと思っていたバンプマップをつけてみる(最新のバージョンでは付いているのかな？)試しにレンダリングしてみるとやはりバンプの有無でかなり見え方が違ってかなりいーかんじ。

テクスチャも貼りたいと思ったのだが、LWのPlugin用テクスチャインターフェイス(LWTxtrEdFuncs)がどうにも上手く動いてくれず(パネルのsubscribe,unsubscribe時たまに落ちる:-<)断念、正直LWのバグではないかと思ってみたり。

LWもユーザー向けの部分は比較的しっかりしているのだけど、開発者向けの部分は結構いい加減で6.0の頃からあるLWSAF_SHADOWフラグが未だに実装されてなかったり、meshinfoのUV取得関数の一部が動いてなかったりと結構きついので、もう少しこの辺をまともにして貰いたい所。

Eetu氏の作品とかぶるのでプラグイン自体は今の所公開の予定なし、まぁ自分&友人向けといった所;-)

しかし結局プラグイン作りに追われて作ろうと思ったものは完成せず、本末転倒、嘲笑うべし。

11/10追記：
Gritもちゃんとbakeできる模様、bakerオプションでcontinuous surfaceオプションを外せば問題無いように見える。どうもcontinuous surfaceオプションを指定していると法線計算をはしょって一部法線が反転してしまうのが原因のようだが、マニュアルには書いてないし、間抜け＞自分

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

LWといえば最近はパッチモデリングにはまり中、といっても今の今までCtrl+Fの存在を知らなかったのが問題なのだが、メカ系統はサブパッチよりも作り易くて、今まで不満だった個所が解決されて満足。

優れていると思う所はセグメントに何個でもコントロールポイントを置くことが出来てその複数のコントロールポイントを加味して最終的に双三次曲面の0〜1区間としてポリゴンが生成される所、余りコントロールポイントが多いと分割数を上げないとちゃんと反映されないのは少し不便ではあるが、Shadeなんかもコントロールポイントを追加する度にセグメントを追加するのでなく、この方法なら皺も発生しないと思うのだけど...

更にレンダラも自作なのだから、サブピクセルまでバイナリ適応分割すれば、セグメントの繋ぎ目も問題なく処理できると思うのだが、何とも何とも。
...今のShadeの状況では望むべくも無いのかもしれないけど、やっぱり惜しいなぁ、と思う。

今までLWのプラグインだけを置いていたページの体裁を整えて正式ランチに向け準備。

正直プログラムを書くのは全然苦痛では無いのだけど、ページを作ったりと自分の興味が無い分野に関してはとことん不精なので、ここからトップページが出来上がるまでにどれだけかかるか、は不明。

正直こういった雑記というのも非常にエディプス的では無いか、と自問自答しながらも、友人・知人向けの近況報告としては良いのかもしれない。などと考え、また将来的に書き溜めておけば一つの更新のネタ(禄でもないコンテンツだけど)になるかも、と考えて見る。

どうでも良いが、更にこの文章を読み返し猫文学を連想する。