kb10uy(@kb10uy@mstdn.maud.io)の投稿
GI オン固定だったからオフとの比較はできなかったけど SSGI といわれればそうっぽいし違うと言われてもそうっぽいなんとも言えないラインの挙動
ああいうのも本当は Secrets Manager とか HSM みたいなところに保存したほうがいいのかしら
しかし現実的に Web サービスの secret key 的なやつは .env などで渡しがちというのはあるなあ
$2y$... みたいなやつ Modular Crypt Format っていうんだ(名前は知らなかった)
このアカウントは、notestockで公開設定になっていません。
の投稿
suzunashi_0@misskey.io
このアカウントは、notestockで公開設定になっていません。
pepper/secretkey と混同して1/3 選ぶのはわかるが 4 は……
そういえばぴこぴっぴで漢字描画するやつは結局 no alloc で終わったんだったな
https://git.kb10uy.org/kb10uy/raspi-pico-kanji
このアカウントは、notestockで公開設定になっていません。
組み込み(というか OS が管理してくれない環境)だと bad_alloc などの逃げ場が無いな、そういえば
コンパイラがより賢く……とか言うけど、コンパイラが賢くなる前にリリース期日が来るわけで……
総合的に半透明が相対的にコスト高くなったから使われるようになった手法という感じがする、別に PS2 世代とかでもやればできたと思うので(GS がディザリングをサポートしていたかは知らないけど)
一応デメリットもあるにはあって擬似的なアルファ値があまりにも低すぎると描画されるピクセル数が少なくなりすぎて崩壊するというようなことがある
FFXV でカメラが寄ったとき描画がピクセル飛ばして穴開きっぽくなってるの、アルファの処理しなくていいからうまいなぁと思った記憶がある
ニンテンドーの比較的最近のゲームでも確かキャラに寄ったときの処理がディザリングだったやつがあった気がするんだけどなんだったかなあ
原神でキャラにカメラが寄ったときにディザリングされるやつも(こっちは AA かかってなかったと思うけど)不透明扱いで擬似的に半透明にしてるやつだと思う
ディザリングだけだとジャギが目立つので Temporal AA もいっしょにかけるとだいぶいい感じになってこれが UE にマテリアルノードとして実装されている Dither Temporal AA です
なのでまあ半透明オブジェクトばっかりの環境だと実はそんなに deferred はおいしくないという話があり、不透明扱いで半透明オブジェクトを描画する手法としてディザリングなどがある
deferred は Z buffer 的に隠れてる部分が一切描画されない前提で話が進むので半透明オブジェクトはその時点でお帰りいただくしかない
半透明は原理的に deferred で描画できないので forward になるとしてカットインも forward なんだ
このアカウントは、notestockで公開設定になっていません。
@unarist なるほど……(SSGI だとすると広めに取る以外に見えてる範囲のキャッシュとか見えない法線の推定をうまくやっているとかかもしれないし、大穴として本当に別途計算している可能性も出てきた)
原神が Reflection Probe を改造しているらしいのは置いといてもリアルタイムにリフレクション更新するのも別に安くはないからなあ…… skylight は空全体から受けた光として一律にちょっとだけ青い光を足すみたいなやつとかです
太陽の位置が固定とか屋内で照明の位置が固定の場合にはベイクしたライティングデータがメインになるんだけど屋外で太陽の位置が変化するとなるとどうしても skylight と低解像度の realtime reflection ぐらいしか頼れないところがありそう
screen-space 系の最大の欠点はピクセルとして描画されなければ元からないようなものになってしまうところで、SSR で反射が急に消えるのも SSGI で光が急に謎の状態になるのも本来反射すべきポリゴンがそもそも描画されてなくてなかったことになっているのに由来している(はず)
SSS は逆光で肌のキワで光がちょっと透けてたりするやつで、これもライトの情報が別途あれば screen-space でそこそこ良い感じに計算できるので最近はよく使われている
screen-space subsurface scattering の略称が SSSSS なの本当に良い(良いか？)
別に forward でも使えるテクニックはある(SSAO とかはそう)けど一部のオブジェクトしかバッファにない描画途中だと使えないテクニックもある(SSR/SSSSS はそうだったはず)
なぜ deferred rendering で SS ほげほげが使われやすいかというと単純に G-Buffer にスクリーン全体の各種情報が一旦集積されてからライティング・最終シェーディングが発生するのでお得なんですよね
ちょっとプレイしてるだけでもおそらく SSR と SSSSS は使われてそうと感じただし SSAO もまあ多分入ってるでしょうという感じがするので GI も SSGI なんじゃないかなあ、という
原神のレンダリング基本 deferred のはずなんでスクリーンスペース系のテクが相対的によく使われてそうという予想がある
うなしの協力により
・オフ→オンで日が出てるときの壁などの光の説得力がかなり上がる
・挙動的に SSGI っぽい気はする
ということがわかった
スクリーン スペース グローバル イルミネーション | Unreal Engine ドキュメント
https://docs.unrealengine.com/4.27/ja/BuildingWorlds/LightingAndShadows/ScreenSpaceGlobalIllumination/
グローバル イルミネーション | Unreal Engine ドキュメント
https://docs.unrealengine.com/4.27/ja/RenderingAndGraphics/GlobalIllumination/
GI が使えるプラットフォームの要求スペック的に SSGI ぐらいしか使えなくないか？と思ったもので
そういえば GI のほうもちょっと気になるんですが、カメラの角度によって同じ場所の GI の結果が変わる感じのやつだったりします？
一応これだと衣装の形で各パーティクルの可視性が決まるのでキャラによって見えやすさが違うのに説明はつくが……
常時発生の ParticleSystem で Emitter が股間に付いてる……もちょっと微妙だなあ
移動方向をベースにしててスリップストリームに相当する場所がたまたま股間なだけなのかもしれない(もしそうなら後ろ泳ぎできたら頭側にもやが発生しそう)
シンプルに「キャラの体基準の座標系で水平より上から見ていればそのまま、水平より下からの角度なら角度に応じてモヤを強く」くらいな感じがする
このアカウントは、notestockで公開設定になっていません。
単に水中用のエフェクトがそんなに完成してなくて水面付近と同じエフェクトが出てるだけという説も思い付いたが、その場合どの角度から見ても腰周りにエフェクトが出てないとおかしい気もする
うなしの動画も一時停止してよく見ると蛍のスカートの中が青っぽくぼかされてるフレームがなくはないんだよな
スカートでだけ発生する場合水面エフェクトの実装が depth buffer に依存してて向かってスカートの中が凹な depth なのでたまたま水面判定されちゃうみたいなのも考えられなくはなかったのだが……
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
見える角度でしか発生してないあたり技術的制約というわけでもなさそうだし本当にそういう対策なのか……？
このアカウントは、notestockで公開設定になっていません。
GitHub とかみたいに背景色変わってる(なんなら padding があってもよい)ぐらいの方が個人的には好み
今の Mastodon の <code> のスタイル、フォントだけが monospace になるのでちょっとわかりづらいなと思うときがある
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
