コード改編(20100501
#defineで置き換えになっていた語を戻したり
全体の見栄えを調整したり
公式以外の更新内容を整理したり
基本的に自己満足の為の内容
解って書いてる人にはどうでもいい事かもだけど
自分みたいに、google先生を頼りに初めてHLSLやってみる、とかいう人には
読みやすくなった分とかで助けになればとか思う
といいつつstateblockとかしてるけど

toonshader2拡散のすすめ
オナホ同梱版の発売もあって新規さんが増えた昨今、拡散を目的の一つとしていた再配布規約が全く役に立っていなかった件について
誰かのブログから、どこかの掲示板から、カス子への入り口はそれぞれだろうけど
その入り口部分で必然的に手に入るようにならないか、手に入るようにできないか、と思ったのよ、規約決めようって言った時は
だって、「このMOD表示されません、なんでですか」なんて質問が、いつまでも、次から次へと来るとか、馬鹿らしいじゃない
先の騒動の前は、居酒屋とギルドにしかファイルがなかった訳で（商用に含まれていたって噂もあるけど、私は知らない。何の連絡も貰ってないからね）
他所様からカス子入った人には、戸惑った人も多かったんじゃないかと思います
実際、そのように伺える質問が居酒屋にも幾らか来てますしね

AlphaScroll
XYSCROLLに暫定適用されていたものを新規にtechnique化
命名はkonoaさん
KAZAN2と統合するのがすごく手間取った
式の内容は理解できるんだけど
rgbとaを別々にスクロールさせて炎っぽく作ろうって言うそのアイデアだけは理解出来そうにない
正直すごい発想とか想像力だと思う

ParaHUD(20120401)
普通のアイテムとして使いやすいように、ボーンの影響を取り除いてみた
ポーズエディタに限定されずに使えるようになったから、少しは勝手もあがったはず
テストアイテムもいくらか判りやすくした
ParaHUD_frame.psdはテストアイテムのテクスチャを置き換えるときに、ウインドウサイズ毎の表示範囲を大体示したもの

ParaHUD
本当は、背景の~B.tsoに使いたかった
それでスクロールtbnと組み合わせれば、表現がすんごい変わると
ヒカリノハラの蛍の表現を増強したり、デフォ竹林背景とか夜の森背景とかに霧をかけたりとかetcetc
でもできないんだよね、~B.tsoとスクロールtbnの併用
テストアイテムはその名残
使えるようにならないかなー・・・今更すぎるか

lightdirfoecedとlightdir
shader中のlightdirforcedには、tdcg上（正確にはポーズエディタ上かな）でのライトの方向が入るわけだけど
材質ファイルの使われてない項目にlightdirってあるのは、当初固定光源で、材質ファイルで光源も扱おうとしてた、とか
んー・・・これ単体だとちょっとアリエナイな
でもambientと一緒に扱って、ライトを自在に操れた可能性はあった、と思えばー・・・眉唾だな

カス子でハーフランバートシェーダーを、っていう話があったんだ
そう、ハーフランバート
ランバートシェーダーっていうのが大元にあるんだけど、これは陰影を-1~+1で管理してた訳
オブジェクトの色*明るさ（-1〜+1）だったから、半分が真っ黒になっちゃう物だった、みたい
その陰影を和らげようと出てきたのがハーフランバート
陰影を0~+1で管理するシェーディングで、中身はいたって簡単
ランバートシェーディングの結果(-1~+1)に*0.5f+0.5fを付け足しただけの物
こうすると、描画が
オブジェクトの色*明るさ（0~+1）になるから、一番暗くても黒になるだけで、陰影がやわらかくなる
結局、カス子は陰影はテクスチャで管理できるものだから、これはいらないねって事で終わったんだけど
よくよく見直してみたら、カス子のシェーディングは元からハーフランバートだった、っていう話
じゃあ、カス子上では明るさ(0~+1)はどこで使われているのか
ずばり、シェーディングテクスチャのUV指定に使われてた
簡単に式にすると
ランバート
オブジェクトの色　*　明るさ(-1~+1)
ハーフランバート
オブジェクトの色　*　明るさ(((-1〜+1)*0.5)+0.5)
TDCG
オブジェクトの色　*　シェーディングテクスチャの任意の座標の色（X={明るさ(((-1〜+1)*0.5)+0.5)})
まぁ、カス子上だと*0.5+0.5が少し違ったりしたけど（AllAmbは基本*0.5+0.5だけど）
解りにくい？cMainPSとかcMainPS3とか見たら解りやすいよ！

＃新tech_eyedotn系について
本スレ136の59の通り、20100120は突然変異というか、他のとは違う部分があったわけですけど、
それがこういう形で見直されるとは思わなかった（’’

りーどみーにも書いてある通り、あの時フォンシェーディングみたいなのを移植した中に、カメラベクトルに対して垂直な面ほど透明度が低くなるっていう仕掛けが混ざってた訳ですけど
まさかαチャンネルでテクスチャが作られていたガーターに対してそういう効果が出るとは
発見した時は、なんでこんな仕掛けとか思ってたんですけどね

なので、このtechniqueの効果は、側面の色が濃くなるのではなくて、側面の透明度が低くなる≒黒いタイツは黒く、白いタイツは白くなります
単純に物体の側面を暗くして立体感を出すなら、ドロッセルみたいにBHLでやるのが確実ですから、ある意味網タイツ専用とも言えるtechniqueですかね

３行で纏めると

側面の色が濃い網タイツ
濃くする＝_eyedotn系＝technique書き換えだけでＯＫ
暗くする＝_BHL系＝texture変更とかきっと手間がかかる

shadetexの適用の歪み方？を調整するfloat_ambient
50にすると、ほぼテクスチャ通りの陰影がつくわけだけど（新テク20090220.jpg参照）
もしかして、ソフトウェア側でこの数字を弄れるようにして、
擬似的に光源の強さというか広さというかを調整していたんじゃないだろうか、とか
でなければ、こういう直感的に解り難い設定というか仕様は作らないんじゃないだろうか、とか

材質ファイルのcgfxファイル指定と、tso一個一個に埋め込まれてるcgfxファイル
もしかしたら、アイテムごとにcgfxファイルを持たせるつもりだったのかも知れない？
アイテムそれぞれが、自分に必要なtechniqueを用意できていたら、toonshader2は生まれてこなかったんだろうな（’’

新techを使うときに、そのtechniqueが必要とする値をcgfxファイルに記入していなかった場合、描画順で最後にその値を持つアイテムの値が使われるっぽい？
例えば、_HLC系テクニックを使ったオブジェクトをカテゴリ２で作ったとして、そのcgfxファイルでfloat4 HighLightColorを指定しなかった、とした場合
そのオブジェクトのハイライトは白[1,1,1,1]（即ちデフォルト値）になる
その状態で、カテゴリ３に_HLC系テクニックを使った、かつfloat4 HighLightColorを指定しているアイテムを装備すると、
カテゴリ２に装備した_HLC系テクニックのオブジェクトのハイライトは、カテゴリ３のオブジェクトのそれと同じ数値になる
・・・といった状態に度々遭遇しました、新テクのテスト中に
記述の内容については、少し気をつけて、書き損じのないようにしたほうがいいと思います
新テクで独自の項目が追加されているものについては、特に

恐らくkemokemoさんが追加しようとしていた新規technique
（toonshaderには入っている、リードミーには未記入つまり実装しつつも未発表）
にINVTEXっていうのがあるんだけど、もしかしたらtex2alphaと似たような事をしようとしていた？

頭文字のＮは開発者の趣味かも＞TDCG内のアイテムのナンバーとかからして？

NAT_~	= アルファチャンネル全描画
NZ_~	= ステンシル？を使おうとした？
NZAT_~	= アルファチャンネル全描画+ステンシルを使おうとした？
ZMAT_~	= ZFuncを使おうとした？ピクセル深度？
NCZAT_~	= cullmode=none 面を両面描画する？cullingOff？

wikiで、「※NAT系はテクスチャの透過部分が人物や他のオブジェクトに重なると、それを消してしまう場合があるので注意 
」とあるのは、単純に描画順のせい
NATでないtechniqueの多くは、不透明度で言って大凡20~25%くらいより低い部分は、面の描画を止めてしまう（greaterequal）
NAT系は、テクスチャの不透明度に関わらず面の描画をしているので（always）、透明な部分でも不透明度0%の透過オブジェクトを使っていると思えば良い
透過オブジェクトと描画順の関係については目薬でも見てください

2/28及び3/1のアレは、意外にこの描画しなくなる事を利用してる（意識してる、してないに関わらず）MODが多かったことで
方法を見直さざるをえないな、と

発案してくれたpiasu氏と、今回の件に巻き込むことになったuserの方は、なんだか面倒な事になった挙句結局新規techniqueで茶を濁す形になって面白みがなくて申し訳ない、と思っています

NZ系のStencillEnableは、デフォルトでfalseに設定されていた
おそらく項目だけ作って途上で使用をヤメたんじゃないかとも思うんだけど

NAT＝Nア(A)るふぁチ(T)ャンネル？
Zはステンシルバッファで、MがZFunc、Cはcullingってところなんだろうか

tsoの命名的にはありえない話じゃないはず

6/8
ColorRateが背景tbnの補正（実験結果
ピクセルシェーダで出力する数値はColRateで統一してあるあたり、モノ処理だけでなく環境光もココで一括処理みたい？
つまり、元々emissiveというか環境光に左右されない、発光する感じのモノは考えられてなかった（もしくは忘れられてた？）
/////////////////////////
だいたいデフォルト状態のtoonshader
///////////////////////////////////////
#if MONO

float4 toMono( float4 i )
{
	float n = ( i.r * 0.299 + i.g * 0.587 + i.b * 0.114 );
	float4	texcol = tex2D( MonoPal, float2( n, 0.5 ) );
	return float4( texcol.rgb, i.a );
}

float4 ColRate( float4 ic )
{
	return toMono( ic * ColorRate );
}

#else

float4 ColRate( float4 ic );
{
	return (ic * ColorRate );
}

#endif
////////////////////////////////////////

6/12
パース変換用行列
今までの描画距離MODだと、biasでw値に補正を入れていたけど、
vertexshader>pixelshaderの時に
position.xyz / position.w をするのに
w値に補正を入れてたらxyも歪んじゃうから、
じゃあZ値だけ圧縮してより遠くの頂点までZf以内の範囲に収めてしまえば
見かけ上遠くまで描画されるんじゃない？

と言う事に数時間かけて気付いた結果が今回のbiasなんだけど
はたして自分のした事が本当に合ってるのかどうか…

6/13
という話をしたら、
「Ｗ値を弄ることで視錐台カリングが外れるのが原因じゃ」というお言葉
ぐぐるも有用な情報を得られず、涙目

とりあえずbiasを弄りながら検証
x>大きく弄ると画面が歪むものの、描画距離に変化は見られない
y>同上
z>大きく弄るとメッシュがチラつく、きっとＺ値の差が切り捨てられる範囲内になって、同じ奥行きの頂点にされてる？	0.0001単位で変化させると、描画距離が徐々に伸びてゆくのが見て取れた
w>同上、ただし大きい数字だと視野が広がる感じ、AVPのエイリアン視界とか、Marathonのオーブとかそんな感じ。広角？魚眼？っていうのか

大凡予想通りの結果
6/12の仮定もあながち間違いではなさそうだけど、視錐台カリングが良くわからない
単純にＯＮ／ＯＦＦだけなら徐々に描画距離が伸びるように見えることもないんじゃないかと思うんだけど
まぁ内部の数字も見れてないんだしもう仕方ない

最終的にZ値を0.9985するbiasに差し替えて終了
