08/31 15:24 (@gorry5) @Saider51 レンダーステートの管理が面倒になるのは確かにありますね

08/31 15:28 (@Saider51) @gorry5 そこらへんもまあ、費用対効果で考えて決められれば良いんでしょうね?。みんな頑張れだ :D~ (peko)

08/31 15:28 (@gorry5) @Saider51 素材段階でOPTPiX Pro/imestaの「透明境界の色もれ予防」みたいな加工を施せば乗算なしでもほぼ問題は解決するのだけど、デザイナーや素材変換工程に負担かけるという欠点

08/31 15:31 (@Saider51) @gorry5 でもまぁ、そこら辺も含めて実機で目で確認して貰ってクオリティーチェックして貰う　かなぁ。実際のワークフローに落とし込む時には、ある意味今まで行ってきた古めかしい行為も混乱させない為に使い続けるって言うのもあるかもだし? (pene)

08/31 16:28 (@gorry5) @Saider51 ああ、今なんとなく「騙されているような気がする」理由がわかった

08/31 16:28 (@gorry5) @Saider51 Src1のRGB/A=1.0/1.0, Src2のRGB/A=0.0/0.0とすると、前者は0.25、後者は0.5になる

08/31 16:29 (@gorry5) @Saider51 ビットマップの補間アルゴリズムは通常前者なんですが、コンポジットは後者。たまたま昔のレンダラの計算式が「非乗算αが前者、乗算αが後者」になっていたためこうなったと

08/31 16:49 (@Saider51) @gorry5 なるほど！確かにこっちが混乱していたのはコンポジット？の演算をよく知らなかったから見たいですね。ここら辺は勉強不足なところもあるのでなんか色々知れてさんくすでする ( ゜?、゜) (komo)

08/31 17:12 (@gorry5) 「RGBA画像の拡大アルゴリズム」って、「結果をRGBAで欲しい場合」は正解はない…明るい不透明と透明の境界を補間するとき、「明るい不透明」「明るい半透明」「暗い不透明」のどれが適切かは状況で違うし、最も安直な「暗い半透明」は色滲みになる

08/31 17:17 (@DARL_Japan) @gorry5 「乗算済みアルファ」はどうですか？ URL:blogs.msdn.com (sida)