自分で作ろうと思うツールに似た物はできるだけ触らないようにする.
とは noboyama氏が書いていた内容だが、自分の場合性格的に考慮材料については全ての情報を集めた上で行動するが信条になっている為、何とも悩ましいなぁ、とも思う.

およそTB_ShaderTreeをリリースしてから考えていた事ではあるのだが、そういった部分は考慮しなければならないと思う反面、プラグインのようなものは実装の制約上およそ解の選択肢はそんなに無いとも言える.

先日日記に貼ったエリアシャドウプラグインを余り積極的に公開しない&発展させない理由もここで、多分Shadow Designerとかぶる可能性があるのではないかなぁ、という所. 実物を持っている訳では無いが、以前雑誌の記事でポストエフェクト的な処理であるとの話は知っており、だとするならLWのプラグインという性格上取り得る実装の選択肢は非常に限定されている(杞憂かもしれないが(^^;

こういった話が何とも馬鹿らしいと思うのも事実、実際 (使ってくれているユーザーには申し訳無い気もするが) 自分のページのプログラムは肩の力を抜いたほんのお遊び程度の感覚で作っているもので、そんな程度で無くなる市場価値なら無くなってしまった方が良いというのが本音ではある:-P

とは言えフリーというのが恐ろしいものでもあるのは確かで、それを市場の製品が上回る為には圧倒的に優れているか、同じフリーで出すしか無いのかもしれないとも思う(見当違いの可能性もあるが). そしてプラグインのような限定された市場での単機能なものは非常にその辺り難しい事情があるのではとも. 実際自分がプログラムを作るのは既にあるとかは一切関係無い、ただ自分が使う道具である以上市販品を持ってくるよりは自分で作る方がはるかに自由度が効くというだけの話. そういった意味では欲しいと思って作れそうな機能は全て作ってしまうワケで、そして作った以上公開したいと思うのは例えば絵描きの人が自分の絵を公開したいと思うのと同じような感覚なワケで.

まぁこんな事を気にする事自体実に傲慢、もしくは自意識過剰とも言えるし、気にせず作るのが「遊び」という感覚では最も相応な気もするが、最近は海外で紹介される事もあり、若干ナーバスになっているのも事実、はてさて:-<

# ちなみにシェアウェアとかにしないのはLWのプラグインのようなニッチ市場でのマーケットに懐疑的である事とユーザーサポートやらがとにかく面倒というだけの話. 正直ペイしないだろうし、そんなものは真面目に仕事をする方がよっぽど気楽なワケで. 後は個人的にモノを作る人間は好きなので、その手助け程度になれば別段制限する事もあるまい、という思いもあったり色々.

# まぁ開発側からすると実際現行の殆どのシェアウェア(レジストしたらずっとユーザーサポート)みたいな売り方はよっぽどマーケットが広くないと成立しない話で、そういった意味ではLWやもしくは3Dそのもののようなニッチ市場でそれは無理があるだろう、というトコロ. 売り切りバグ修正のみとかVerUpやサポート有料ならまだ何とかなるだろうけど、それにした所で商売に乗せて無駄な機能を増やして散漫になっていくアプリも腐る程あったりするワケで、なかなか難しい所ではなかろうかと思ったり.

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

LW8でのバンプの問題については依然Newtekからは何の回答も無し、正直余りLWのプラグインにばかり構っているワケにもいかないので、4月の10日頃までに回答が無ければ注意書き付きでリリースしようかとも考えてます:-<

Newtekからの回答が来るまでプラグインの修正版リリースは中断、という事で暇なのでお遊び程度にLWの平行・ポイント・スポットライトでエリアシャドウを実現するプラグインを作ってみる.

最近大量のカスタムシェーダを使っているので、それとの相性を考えて後からPixelFilterで影だけ合成する方式を採用. Shaderで情報を集め、PixelFilterで実際の影の計算・合成を行っているのだが、その過程でエリアライトを大きくしなくても影を距離で減衰させると少ないサンプルでもそこそこ見栄えが良くなる模様. こんな具合

減衰なしの場合


減衰ありの場合


(おまけ)エリアライトのサイズを大きくした場合、減衰ありの場合に比べサンプル数をかなり多く取らないと粒状感が目立つ

まぁ階調が増えるので当たり前と言えば当たり前、結局の所絵作りの場合大きなサイズのエリアライトを使うメリットは画像内の主題とは関係無い部分にたいする高周波成分の除去とその上での視覚の不自然さの軽減にあるので、物理的に正しい現象とは言えないものの、そこそこ効果的かもしれん、とは思う. (一応大気の多重散乱も考えられるが、ここで使っている減衰項程極端な係数にはならない筈)

まぁそれだけと言えばそれだけの話なのだが.

、、、とここまでやって計算式を見直した所、シェーダプラグインで計算できる上にその方が精度が良い事に気付く、間抜け :-<

# まぁ実際にはPixelFilterでやるメリットもあるのだが、他のシェーダやラジオシティ等の反復系の計算コストに影響しない、とか.

(追記)
取り合えず実験的に作ったプラグイン気が向いたらちゃんと上の話でシェーダで実装したものを作るかもしれないし作らないかもしれない、ちなみに対象となるのは影なし設定されているライトのみ. 余りこの辺の話は一人歩きして欲しくない(最近海外からのメールも増えた)のでJunk以下の扱いとして一応雑記内扱い.

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

もうすぐMOMO展が始まる模様、他の人の作例を見るというのは3Dの見せ方に対する考えとか、あるいは機能的に気になる個所などの参考になるので、毎回結構楽しみにしています. 後は3Dソフト別の人口比率やマーケット的なものも見えるし.

そういった意味では3Dやっている方のソフトに関する日記なんかも非常に参考になって面白いです、、、見方間違っているかもしれませんが(苦笑)

「やさしい水素爆弾の作り方」タイトルにギョッとして見に行ったのだが、実際は高校時代(中学だったか？)にやる電気分解で水素を発生して爆発させる話だった. 何ともほほえましく化学実験を娯楽にしていた昔を思い出し懐かしい気分になる、とはいっても水素も塩素もはっきり言って余り良い思いでがあるワケでも無いし、ちゃんとドラフト内でやるべき実験だとは思うけど.

何となく久しぶりに化学の話を目にしたのだが、一応これでも昔は化学専攻だったので何とも懐かしい気分. ただ化学の場合もプログラムと同じように面白いのだけど個人では余り薬品も手に入らないし、自宅で実験する事もできないので、高校時代管理の甘い化学部で薬品を使い放題だった頃はともかく大学に入ってからは急速に興味を無くし、むしろ手軽に思考を検証できるプログラムに惹かれていったように思う.

上の記事を読んでイオン化傾向どうたったかな、と思ったのだが、もうそれすら忘れてしまったカンジでダメダメ. 炭酸ナトリウムの大ビンを持って走り回ったのも今は昔. まぁそんなものかもしれない.

# 水素爆弾というと普通はやはり「水爆」だと思うのだが、これは原子的に不安定な重水素や3重水素に高エネルギー(通常は原爆を爆発させたりする)を与えてやりヘリウムと中性子への核融合反応により転化した質量エネルギー(例の有名な式で現されるヤツ)を爆発のエネルギーとする兵器の事で、こちらとは別の話. というか最初そちらの話かと思ってしまった＞水素爆弾

先日書いたバンプの問題、DStormにメールしたのだけど「確認できない」と返って来てしまったので再現の確認を含めて同じシーンを100回x2(7.5&8.2.1)程レンダリングとプレビューを行う事に. んで一応こちらで出来る確認はやったので再度詳細を書いて送付、、、疲れた、しかしなんかこういう確認をやっていると自分がパラノイアになった気分になる(苦笑)

TB_ShaderTreeの改修はほぼ上がっているのだが、この問題の明確な回答があるまでリリースは先送り、ただDStormとやり取りしていて気付いたのだけどLW7.5のdパッチで既に問題が発生している可能性も捨てきれない. というのも該当バージョンから'Surf Mixer'プラグインが添付されており、これがバンプ正常に反映しない話を海外の掲示板で見かけたから、なのだが (ちなみに自分の所では8.2.1になっても同様に反映しない) 個人的には'Surf Mixer'プラグインをどう作るかは大体見えている(と思っている)ので、その辺根が同じ気もしなかったりなかったり.

現状色々な作業の兼ね合いから安定して動くLW7.5の環境を残したい為dパッチは入れてないのだけど、7.5d使っている人がいたらTB_2ndSurfのバンプが機能しているか教えてもらえると助かります、みたいな(^^;; あるいは別マシンにインストールしてテストするか、後少ししたらテストマシンが別用途に使えそうではあるし、、、

<2005/03/23追記>

DStormより回答がありました、LW7.xと8.xで同一シーケンスのSDKの結果が違っている事を確認、問題の可能性もありNewtekにサンプル等送付、問い合わせ中につき、何らかの回答があるまで暫くお待ちくださいとの事. もう暫く待つ事になりそう.

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

ちなみにTB_ShaderTreeの次バージョンではUVマップを取得してプロシージャルをUVに沿って貼る事や複数の頂点カラーを取得して色々混ぜ合わせたりできるようになってます. 後はAmbient Occlusionの結果がLWのラジオとほぼ同等の結果が取れるよう改善(というか半球分割の式を間違えていたので修正(^^;; とかDiffuse-Wrapped及びbacklight-wrappedノードを使用した時に出る嫌な影がほぼ解消されて、普通に使えるシェーダになってたり、色々.

、、、でもバンプの問題が決着しない限りLW7.5(not dパッチ、dパッチについては不明)までしか完全対応できないんだよねぇ、と考えるとちと難しい気分、将来的にでも何か展望が見えていれば違うのだけど:-<

後ちょっとTB_fakeSkinのSheenパラメータを実際の影を反映するようにアルゴリズムを変更してみたり、これでバックライトで縁が影の影響を無視して光り過ぎて不自然になる状況は回避できる模様、照明アルゴリズム変わるけど、これDefaultにしちゃって良いよね、みたいな(というかその辺を気にしないからこそフリーソフトなワケだが(笑). まぁこの辺もこの件が上がったらボチボチ次の改修辺りに乗せようかと思ってますが、まぁ予定は未定という所で;-)

<2005/03/23追記>

Sheenパラメータの変更、大丈夫かなーと思ってたら分布関数上の欠陥を発見、やはり正確に計算しようとするとソリッドなオブジェクトを想定してスキャンせねばならない模様、という事で暫く先送り:-<

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

今更ながらにF911氏のUV Chalkを使ってみるが非常に便利で素晴らしいの一言に尽きる. 今更なのは8.xでは動作するものの今まで自分の使っている7.5(not dパッチ、日本語版の最初のって7.5bだと思ってたけど7.5aなのかしらん？)ではクラッシュしていたので暫く使っていなかったのだが、ちゃんと直ってて、自分の現在のワークフローに組み込めそう.

本当はnoboyama氏のAutomatonなんかも試してみたいのだが、自分の場合スケルゴン+Vertex Paintよりもレイアウトで骨入れ、影響は押さえのボーンで調整という方に慣れているのでなかなか難しい(^^;;; どうにもスケルゴンに馴染めなかったり、Vertex Paintでウェイト調整するのに慣れなかったりするのだけど、これってやっぱり少数派なのかしらん？

しかし、これらを見るにつけ良くも悪くもLWの魅力ってフリープラグイン組み合わせた時にできる事にあるよなぁ、とか思ってしまったり. 本体だけだともっと別のソフトの方が魅力的に見えてしまうのが何とも言えず(笑)

LW8.2を色々いじる、といってもオペレーションでは無くSDKから見た部分の話. LW7.5で悩まされたVParam(テクスチャ+エンベロープのついたボタン周り)レンダリング周りのバグが結構修正されている模様、ざっと確認できた所では

• VParamのエンベロープが保存されないバグ
• VParam内テクスチャのエンベロープが保存されないバグ
• カラーエンベロープが同名のものがあるとコンフリクトするバグ
• テクスチャの参照情報がプラグインから読まれると本体のサーフェスから消えるバグ

が修正されている模様、つまりLW8(.2?)ではVParamを使う場合に単純にVParam本体とテクスチャリファレンスだけ保存すればちゃんと動くようになっている模様で、この辺はMarvin Landis氏のサンプルを意識しての事だろうか、などとも考えて見る.

一応これらのバグについては自前のライブラリでLW7でもちゃんと動作するものを作ってあるのだが、将来的にLW7.xを切り捨てる場合は無駄な部分になるので、今のうちに仕込みだけはしておいた方が良さそう、という事でTB_ShaderTreeの改修作業に追加、まぁ今月中には何とかする予定ではある.

なおTB_ShaderTree以外の改修を予定しているプラグインについても今回の改修でLW6.xはサポート対象外とする予定、LW7はまだ自分もメインで使っているし、LW8には乗り換えないユーザーも多いと思うのでまだサポート予定(多分LW9が出る位まではサポートするつもり). まぁコアの置き換えなので見た目が殆ど変わらないプラグインも多いのだけど、より安心して使えるものという事で完成度は上げるつもり(但し過去のセーブデータとの互換性が無くなるので暫くは旧バージョンも置いておく必要があると思うが;-)

またLWのレンダリングバグについてはVParam以外でもPreview/VIPERでbumpHeightが反映されない問題とpolygonID==NULLとなってジオメトリがスキャンできないバグが修正されている模様、但し相変わらずwNorm0は未定義だし、レンダリング中のシャドウフラグも0のまま:-<

LW8での見栄えを考えるとTB_ShaderTreeのGUIはもう少しソリッドなイメージの方が良かったかな、などとつまらぬ事を考えてしまったり;-)

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

<2005/3/18追記>

VParam絡みのバグが直っているかと思ったのだが致命的な問題を発見、というのもVParamでバンプテクスチャを実現した際にちゃんと機能しないという致命的なもの. 影響されるプラグインはTB_2ndSurf, TB_Dirt, TB_ShaderTree、特にVParamだけでは無く、TB_ShaderTreeではLWTextureIDでベクトルデータ型のテクスチャを扱っている為、問題はベクトル型のテクスチャ(LWVPDT_VECTOR, TRT_VECTOR) を扱う個所に問題があると思われる.

まだ8.2.1と8.2、8.01で試しただけだが、ちょっと余裕を見て(現在多忙)DStormに質問すると共に、これらのプラグインについてはバンプについてはLW8.x非対応という事になります、LW7.xでは正常に動いている事からほぼLWのバグだと思うけどX-<

# まだ8.xは信頼して使える程安定してない、という所だろうか. しかし8.xになってからのLWは頻繁にバージョンアップするのは良いのだけど、少々バグが多く7.xの時と比較しても安心して使えるものが出ていないような気がする、Newtekに何かあったのだろうか？:-<

<削除>

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

TB_ShaderTreeのバグ報告、テクスチャ周りの保存関係なのだが、コアに相当する部分の機能で事態はTB_ShaderTreeのみならず、ほぼ全てのプラグインに影響. 元々LWのSDKで公開されているこの部分には色々バグがあり、それを回避する為の工夫やらで実はプラグインのエンベロープとテクスチャが付いた入力を処理するのは色々難しいのだが、その回避策で今度はLW本体の機能とコンフリクトしていた模様. 試しに他の人が作ったプラグイン(割と有名なヤツ)で試しても同じ症状が出る事からほぼ間違い無し.

ただこれでは問題なので、一応内部で何が起きているかを推測しての回避策は完成、テストをサボっていた個所なのである程度厳密にテストした所ではほぼLW標準の機能と同レベルで動くと思うものの、問題は過去のセーブデータの互換性が無くなったという所. 特にShaderTreeのようなものは過去の資産が重要になるので余りやりたくなかったのだが、コア部品なので互換性維持の為の回避策も打ち出せず、という事で申し訳無い気もするのだけど、近日修正予定.

後はちょこちょこ修正して若干パフォーマンス上がってます、特に大量のノードを持ったツリーやカスタムシェーディングでシェーダを使う場合は結構違ってくる筈。

、、、というかそろそろShaderTree作るのも飽きてきたし(えー
自分の及第点レベルで安定したら一区切りとしたいぞ、と. 余り道具ばかり作ってても本末転倒だし;-)

ただ、本来このページは友人への近況報告と暇つぶし程度に作ったものの投棄所程度の感覚でやっている為、微妙にこういう事態になるとギャップを感じる(指摘があったのは海外だし)のも確か. テキスト系のサイトをやっていた友人がひょんな事から有名になって本とかに書いて、2チャンネルのオフとか行った時にサインを下さいと言われた時に「何かが違う」と感じてサイトを閉じたのはこんなカンジだったのだろうか、とも思ってみる.

まぁ別にサイト閉じるとかいう気は無く、肩の力を抜いて今まで通り「ご近所への夕食のおすそ分け」程度の感覚で続けて行くつもりではあるのだけど;-)
ポリシーは「無理はしない、努力もしない、やりたくない事は絶対しない」というカンジで(笑)

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

なお0.42以降で追加した機能で自前ストックのシェーダライブラリからSSS系エフェクトのSolid Translucentを 'translucent'ノードとして追加、少々扱いが面倒であるものの、マーケット用語的には「SSS機能搭載」というカンジ、まぁ厳密に言うとこれをSSSと言いたくない部分もあるのだけど、件の論文にある多重散乱によるソフトな拡散散乱項の陰影の計算についても一応ストックはあるのだけど、真面目にLWでやろうとするとジオメトリ作成に相当制約が入るので、普及版として分かり易い所ではこんな所かもしれないとも思う.

先日書いたilluminance文に相当するノードは結局見送り、これを使いこなせる人はTB_ShaderManも使いこなせるだろうから、どちらかというとエンドユーザー向けのTB_ShaderTreeにあえて分かり難い概念を入れる事もあるまい、という所. なお想定ユーザーとしてはTB_2ndSurfはエントリユーザー向け、TB_ShaderTreeはLWを使いこなせるプロ向けっぽいカンジで、TB_ShaderManはインハウスツールとかまで使ってて例えば自前でG2とか作れる人向け(ヲイヲイ)という具合で、、、というかそのレベルでファイナルにLWなんて使うのか？というツッコミが正解かも(苦笑)

なお某所でsabreのライトリストに相当する機能が欲しいという話もあったのだが、LWの場合カスタムシェーディングに関しては実装可能ではあるものの、チャンネルのみを修正し、様々なシェーダを組み合わせるアプローチを想定する場合一貫性を持った実装は不可能なので実装の予定は無し. まぁそれぞれのプログラムで特徴がある、という事でどれか一つのプログラムが全てを包括しなくてもそれぞれ自分の使い易いものを使うのが良いかと思ったり.

という事で今度こそ一段落したら次は年末からずれ込んでいたTB_ShaderManの改修作業を予定.

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

原付の保険の更新でバイク屋行って昔乗ってたマシンの話してたら「CRM-50? 何なら探そうか? 全国探せばまだ手に入ると思うよ」と言われてしまい、即効で ノートPC&新PC ＜ CRM-50に傾く、今やってる仕事のお金が入ったらまずPCよりもそちら優先;-)

やっぱり2ストは良い、あの暴力的な加速が何とも素敵、もう殆ど生産されなくなってしまっているが個人的には環境汚染税とか払っても2ストマシンの生産は続けて欲しい所、、、まぁ今度こそ事故って死ぬかも(以前CRM-50で事故って1年入院(苦笑)

でも今乗ってるsolo(オレンジ+ベージュ)もpopなカンジで気に入っているのが悩ましい、JazzやMAGNA50程アレなカンジでも無いし、まぁ素直に中免取れば良いのかもしれないが、、、(そのクラスだとKawasakiのEstrellaかYamahaのDragStarが気になる)

理由はDLページに書いた通り、気付いて打ちのめされる事しきり. あーだこーだ騒ぐ外野については何とも思わないのだけど、個人的にはプログラムに限らずモノを作るという行為については最大限の敬意を払いたいと思っているので、それをないがしろにしてしまった自分自身の行為にヘコむ事しきり.

余りネガティブに考えても仕方ないので事実は事実として受け止めて、改修作業頑張ろう＞自分

ようやくTB_ShaderTreeリリース完了、1ヶ月程度で切り上げるつもりが結局ドキュメントやら何やらで3ヶ月程度かかってしまった. まぁ肩の荷が一つ下りたと少々ダラダラしていたのだが、flayの方でMacro単体で保存できないという話があり、試して見たら、、、やっちゃったよ(笑)

実際はファイルメニューの save, load及び presetの読み込みは現在の編集画面、つまりマクロ編集中であれば保存・ロードされるのはその画面に表示されるマクロ以下のノードとするつもりだったのだが、コード整理の段階でエンバグしてプラグイン内の全てのシェーダツリーが対象になってしまっていた模様.

という事で現行リリースのものとは、仕様が異なり、混乱を招きかねない気もするが、初期の意図した通りの動作をする修正版を近日中にリリース予定.

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

しかし評判を見ているとやっぱり難しいかなぁ、と思うこともしきりで、もう少しサンプルとかを増やした方が良いのかもしれない、とも思う.

特に分かり難い点としてLWのシェーディングには2種類の方式(LW標準とSDKに公開されているreplacement_colorを使用する方法)がある事を理解する必要があるという点にもあるかもしれない(後者はプラグインのみに公開されている為、通常今までのLWでユーザーに見えるのは前者の部分のみ)

まぁある程度は時間が解決してくれる、もしくは使いこなして貰えず消えて行く(苦笑)
とは思うので、現行の仕様についてはそのままで、サンプル等は別途考えるものとしようかとは思っているが、、、

他に裸のraytrace系のノード (raytrace, raycast) の使い方が分からないという話もあったのだが、そこについては流石に勉強してくれ、としか言いようが無い(レイトレの実行には座標とベクトルが必要でしょ、とか;-)

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

後はCGTalkの議論なんかを見ているとSSSを実現しようとしている人がいて少々悩む、基準座標からのグラデーション+RayCastなどでそれっぽいエフェクトは実現できるのだが、それ以上の全てのライトについての複雑なエフェクト、つまりシェーディングロジックそのものをカスタマイズするという事になると現行のものでは不可能だろうという所.

一応解決する為にはRenderManSLでいう所のilluminance文に相当するノードを実装し、特殊なマクロノードとして光源に対する反復計算をそのノードに入れ込んでしまえば良い (実は開発中に試験実装しており、機能的に複雑なので公開版には乗せていないだけで既に完成はしている(笑)) のだが、例えばごく簡単なシェーディングアルゴリズムを実装するとしてもLambert DiffuseやPhong/Halfway Specular程度でノード数が10〜20程度になってしまい非常に煩雑で殆どのユーザーは使いこなせないのではないかという危惧があり (これでOrenNayerの計算などまで実現する事を考えるとホラーになってしまう)実装しても下手に機能を複雑かつ分かり難いものにしてしまわないか、というのが懸念事項.

後はエンジン部の評価方式がノードを直接辿る方式である為、ノードでそこまで複雑な計算を乗せてしまうと速度的にも余り望ましくない結果になる為 (せいぜいLScriptと同程度、但し現行ではLScriptはバグの為カスタムシェーダは作れないが) その辺までカスタマイズしたいのであればTB_ShaderManの方を推奨という気分. (ちなみにG2などは自前で交差判定ルーチンを持っているようなのでより柔軟性は高いが、アルゴリズム的にはTB_ShaderManでG2のソリッドトランスルーセントやOGO_Hikariの多重散乱まで含めた拡散反射計算は実装出来るよう作ってある、というか実際自前で作って使っているし(笑))

余り拡張してもVBで無理矢理API叩きまくるような醜悪な話 (得意気にTipsとかで書かれてるケースも多いが) にしかならない気もするし、あるいはHSPでDirectXとか、、、(まぁそのユーザーサイドの気持ちも分からなくもないのだけど) さて、どうしたものか、、、:-<

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

ふと考えてみると前日にKOJIさんの作っている彩と写真屋のクリップボード連携関連で似たような種類の話したなぁ、と思ってみたり. 「それはユーザーが判断する事」として取り合えずの出来る事の可能性を広げておくか、あるいはユーザーに分かり難くなり、ともするとコンセプトが散漫になる事を懸念してオミットするか、はてさて:-<

# 何はともあれ保存機能もついて、製品版もそろそろ秒読みですね、という事で楽しみな事しきり、色々な意味で(笑)