LW8.2が出た模様、今回の改善は

• AAの種類追加
• UVのサブパッチ対応
• UVの非連続編集編集機能強化
• IKBooster改善

余り時間的に余裕が無いので落ち着いては触れていないものの、一応少し触ってみる.

個人的に気になっていたAAについて試した所では仕上がりの絵のシャープさ加減で言うと
ランチョス > ミッチェル >= クラシック > ボックス > ガウス
といったカンジ.

クラシック以外は明確に効果として出すにはAAをPLDに設定して適性サンプリングを切らないといけない模様(というか同じフィルタでもオプションによって違う絵になってしまう)再構成フィルタのソフトバージョンに関しては何か後処理っぽい位強くかかってしまうので、個人的には余り使わないかも.

感想としてはまぁ悪く無いんんだけど、ちょっとこの辺の組み合わせの複雑さ何とかならんかな、という所と、独自っぽくてフィルタカーネルのクセが分かり辛いカンジ(普通にbox,triangle,gauss,catmull,sincとかできなかったのだろうか...
まぁ一応その手のもので出せるタイプの絵は大体出せるので構わないのですが.

# しかし、シャドウマップの詳細オプションは今回も据え置きですか...orz

UVのサブパッチ対応は文句なし、というか素晴らしいです.

UV編集はポリゴンを選択すると勝手にUVだけ切り離される仕様になっている模様、従来通りの連続したものとして編集する場合は頂点選択を使うカンジで明確にモードを意識する必要はあるものの、総じて良いカンジ(というかここは標準であって然るべき機能ではあるけど:-P

ま、後はIKBosterの機能強化といった所(この辺はまだ試してない)

結局今回の一番の目玉はUVのサブパッチ対応だった気がする、ただこれだけでも非常に便利な機能なのでそろそろメインを7から8に移すかなぁという気になりました.

# 穿った見方をすると今回のAA関連及びVIPERの改善についてはFPrimeを意識したのではないかなぁという気がしなくも無かったり、何やらAAフィルタに関しては映像業界でもFPrimeのフィルタカーネルの方が好評だったとかいう話もあるようですし;-)

# ShaderTreeですが、現在土日しか時間取れてません(というか下手すりゃ土日も取れていない)ので今しばらくお待ちくださいm(_ _)m

ShaderTreeですが、一番懸念してたGUIの使い勝手とレスポンスについてそこそこ好評みたいなので、取り合えずGUIデザインについてはこの方向で、後はノードのパラメータの整備や想定ケースでのノードライブラリの拡充に重点を置いて開発したいと思います.

しかし結構意外だったのが何人かの方からレスポンスについてそれ程悪く無い評価を頂いた事、LWのSDKの限界もあって常に全画面再描画&その度にピクセル単位のアクセスになっている為パフォーマンスがかなり心配で、実際自分の環境では若干もたりが気になっていたのだけど、取り合えずは杞憂だった模様(ちなみに自分のマシンは数世代前のやたら遅いマシンで、3Dやるのにそんな遅いマシンでやるとは考えられないようなマシンです(笑)

という事で当座の作業はライブラリ構成の見直しとマニュアル作成を予定、多少忙しくはあるのだけど早めにリリースできるようにしたいと思いますm(_ _)m

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

コードの再利用の嘘の話、数学の証明に例えると非常に分かり易いかと思ってみる. プログラムを書くという作業は証明に非常に似ている、両方ともある目的を実現する為に要素を一つずつ積み上げて結果を構築する、当然その積み上げる仮定で一箇所でも問題があればそれに連なる全ての結果は意味を成さなくなってしまう.

ここで問題を解決する為にコードを再利用するという事は、数学の証明を延々書いた用紙の一部を値などを書き直して別の証明に適用するのに非常に良く似ている. 問題が完全に同じ過程で解けるものならば問題無いが、そうでなければ余計に手間がかかって、かつ機械的に数値だけを変えていったのでは致命的な問題を引き起こしかねない事は、少なくとも一度でも証明問題を解いた事がある人間には容易に想像がつくのではないだろうか、特にその証明が用紙にして数百枚に渉って書き綴られている場合など、その概念だけ引っ張ってきて書き直す方がはるかにマシだろう （まぁ日本の学校教育での証明問題は半分程度は脳内テンプレートマッチングではあるが、あくまで答えが用意されている練習問題レベルの話で、実用的な証明となるとそうは行かないので割愛;-)

無論証明でも定理や別の証明を引用する事はあるが、それはその結果が完全に独立しているからこそ成立する。これがプログラムではライブラリになる訳だが、この時留意するのはそれが独立しているという点にあり、別の証明の過程の一部に依存があってはいけない(その場合その別の証明の全てを組み込まねばならない、そしてその証明はその想定ケース以外は保証しない)

これは「車輪の再発明」の話とも繋がる、既存の証明を完全に独立したものとして引用できるならば、その部分の車輪の再発明は確かに不要だろう、しかしその既存の証明が現在の証明の内容の一部として分離不可能なレベルで含まれるならば、その既存の証明を理解する必要があるというのもまぁ至極当たり前の話だろう.

よってプログラムと数学の証明の類似性を仮定すると、ライブラリのように再利用を目的として作られたコードならいざ知らず、全ての種類のプログラムに対して「コードの再利用」を主張したり、また良くあるように分析なしで「車輪の再発明」などと軽々しく発言するのは実に無意味かつ無価値だと思うが如何(無論前提が崩れた場合にはその限りに非ず;-)

# 余談ではあるが「車輪の再発明」という言葉、昔は聞かなかったよなぁ、と思うことしきり. 耳にするようになったのはSEとプログラマが別の職業として分かれた頃からだったろうか？そうして考えるとこの言葉、元々はオタク的技術者の自己満足を否定する為に使われ始めたような気もしないでも無い. 実際独り善がりのエンジニア的な本末転倒の自己満足もまたビジネス的な観点からは非常に問題があると思うのだけど、最近はむしろ便利な逃げ口上として使われているような気がしないでもなかったり、問題を言語化・概念化して再取り込みする事は情報処理の観点として非常に重要な行為ではあるのだけれど、時に原点に立ち返りその意味を確認する事も必要だと思ったり:-P

# 余談その2
そういった意味ではTB_ShaderManなんぞまさにエンジニア的自己満足の産物以外の何者でも無いのだが(苦笑) 確かに自分の使うレベルで考えた時にスクリプトを超える自由度と柔軟さを持つインターフェイスを見出せなかった点もあるけど、プラグイン(アプリ)として見るとターゲット想定を見誤ってるとしか、というかもうバカとしか(爆)
、、、と言って落としておく;-)

ShaderTreeは難しいですか、やっぱりマニュアルは必須っぽいなぁ、うーん(^^;;;
ノードベースの表現力の限界とかで無理な部分もあるけど、出来るだけ簡単に理解できるものにしたい所、悩ましい.

なお簡単な使い方を書いておくと

・ノードの作成は左のツリーで選択して'add Component'ボタンもしくはダブルクリック

・基本的にはまずrootノードを作成し(これがShaderTreeプラグインの最終出力になる、無いと何も出力されない) そのチャンネルごとにテクスチャを繋いで行く、rootノードにパラメータの繋がっていない所は元のサーフェスの設定が使われる.

・ノードの接続は左から右方向で、出力のボックス(各ノードの右のボックス)の上でマウスの左ボタンをドラッグして別のノードの入力ボックス(各ノードの左のボックス)に繋げる事で可能、一旦繋いだ接続は繋がっている入力ボックスを再度ドラッグする事で切断や繋ぎ変えができます. ボックスの色はカラー、ベクトル、値及びany typeに対応していますが、あくまで目安で何でも接続可能.

・作成されたノードにパラメータがある場合は右クリックポップアップメニューの'Edit property'もしくはノードのダブルクリックで可能、またコネクトボックスがあるのに編集画面に表示されないパラメータは別のノードが接続されていない限りはレンダリング時にデフォルトの値(一般的な設定値が設定されている)が自動的に使用される.

・複数のノードを選択する場合はシフトを押しながら、もしくは3ボタンマウスの真ん中のボタン(将来的には変更可能性あり)またシフトキー及び真ん中ボタンクリックはトグルになっている為、選択されたノードを再度クリックする事で非選択の状態にする事も可能. また全てのノードの選択・非選択は右クリックメニューでも可能

・カット・コピー・ペースト・削除はそれぞれ右クリックもしくはキーボードの'x', 'c', 'v', [delete]キーで可能、クリップボードはLW内で共用されているので別のサーフェスのShaderTreeにもペースト可能.

・データの保存は左上のメニューで、ファイルとしてのSave&Load以外にLWのプリセットとしての保存も可能

・マクロは複数のノードをまとめる機能、macroノードを作成しダブルクリックでマクロ編集モードに、マクロ編集モードではマクロの結果はrootの代わりにmacro rootノードを作成し、そこに出力結果を繋げる. マクロに対し入力を与えたい場合はそのマクロを使用している編集画面のmacroノードの入力にノードを繋ぎ、マクロ編集モードではmacro paramノードの出力からその入力を取ってこれる. またmacro内に更にmacroを入れる事も可能、マクロ編集から一つ上のレベルに抜けるには右上の'Quit Macro'ボタンを押す.

・使い方の基本としてはテクスチャブレンドの場合最も重要なのはFunctionの下にある'mix'ノードで、これでアルファを指定して複数のテクスチャを混合可能

・カスタムシェーディングでテクスチャだけでなくLWのシェーディングまで変える場合はrootパラメータのrepl_parを100%に設定し、repl_colに実際のシェーディング結果を繋げる. repl_colに繋げるノードはCustomShader配下のものを色々足し合わせたり混ぜ合わせる事で可能、また元のサーフェスの情報はGlobal配下のspot/geomノードで取得可能なので、これをカスタムシェーダに上手く繋げばシェーディング結果だけを指定してテクスチャのインターフェイスはLWのものを使う事も可能.

・制限事項はプラグイン内のプレビューではShaderTree以前に適用されているシェーダの結果が取得できない(レンダリング時には反映される)事とVIPERでは一部法線情報が正確にならない部分もある(LWのサーフェスプレビューは問題なし)FPrimeではシェーダ自体使えない.

、、、やっぱ難しいかも(苦笑)

遅ればせながら明けましておめでとうございます、という事にて.

まず、雑記にも書いた年末を予定していたプラグインの改修についてですが、少々予定が延びていますm(_ _)m
というのも前の雑記を書いた少し後から少々作っている物があり、コアの部分についての妥当性をそれを使って検証してからの方が良いだろうという事で、一応2月から3月を目処にしたいと思っております.

なお作っている物はこんなカンジ↓

実はもう殆ど完成しているのだが、若干しっくりこない所があるので正式公開はもう少し先を予定.
遊んでみるだけなら一応ココにも置いときます、まだ正式版ではセーブデータなどが変わる可能性が非常に高い為、あくまで雰囲気だけですが;-)

ただ問題はノードライブラリだけで100種類程度あるので、マニュアル作りが面倒、それぞれ平均でパラメータが4個とすると400個程度の説明を書く必要があり、少々気が重い所。とは言えマニュアルが無いと多分使うのは難しいと思うので作る予定ではありますが、詳細な各ノードのマニュアルは初回リリース後という形になるかも.

まぁ今更シェーダツリーなんぞ作らなくてもsabreやVisualTextureのような優秀なプラグインがあるのも確かなのですが、どうにも自分の想定した使い方が出来るものが無く、ちょっと作ってみようというカンジの軽い気持ちで作っているモノなのでまぁその程度という事で(*1)後はまぁ自分の中でTB_2ndSrfとTB_ShaderManの間を埋めるものがあっても良いかな、というカンジもあったり;-)

しかし、この所やたら忙しくなっているので、なかなか時間が取れないのが頭の痛い所.

*1) 正確にはVisualTextureは想定する使い方に近い事はできるのもののライブラリのクセが強すぎ、後プレビューでシェーディングに誤魔化しが入っていてマテリアルのプレビューに使えない点が気に入らなかった、sabreは自分にとってある意味理想的なライブラリだったのだけど、カスタムシェーディングに特化していた為排他的にしか使えない部分がネックだった、という事でその中間程度のクセの少ないもので、後は型を余り意識しないで繋ぎ合わせられるものが欲しかったというトコロ.

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

本日の教訓

ソフトウェアは積み上げるものではありません、プログラムコードもまた然り。
管理コストはコード量に対し線形では無いし、製品という立場でメンテナンススケジュールなども考慮すると非常に頭の痛い話。以前Javaの余り良いと思えない所に巨大なクラスライブラリを挙げましたが、独自にモノリシックでアプリとライブラリがくっついてしまっているようなフレームワークを作ってしまうよりは遥かに良いのかもしれません、という事で少々考えを改めました:-<

というか、ソレってどういう思想なのか、とも非常に不思議に思ったり。「コードの再利用」とかの考えの元にという事なのだろうか？(個人的にはよく言う「コードの再利用」については非常に懐疑的で、むしろ重要なのは「思考の再利用」だと思っているが)あるいは自分の知らぬ所で別の開発の方法論があり、もしかしたらそちらの方法論の方が上手く行くのだろうか、などとも何とも不思議に思う所しきり.