そういえば Deferred でも複数マテリアル使う場合に G-Buffer にマテリアルの種類書き込むみたいなことしてる例があったな
Posting kb10uy(@kb10uy@mstdn.maud.io)
もみあげの長い美少女の話ばかりしています
Avatar icon: [𝕏] CamemBellcheese
Header: [𝕏] generalcanon
各種フレコ:
beatmaniaIIDX(八段): 1751-5340
オンゲキ(15.8): 3067667719792
Arcaea(◆9): 433827474
そういえば Deferred でも複数マテリアル使う場合に G-Buffer にマテリアルの種類書き込むみたいなことしてる例があったな
Android だと UserPrefs とかだったかな まあどのみちろくな場所ではないので大した量のデータは保存できないと思ったほうがいいらしい
ただ計算上は Scene 全体でひとつになるっぽいので間に誰も入らないならそのままでもいいかも(部屋を動かすときにまとめて動かせてるので分けたほうが便利ではある)
密度以外でありえそうなのだとサンプリングポイントがメッシュの境目とか内側に入っちゃってるとかはあるかもしれない(同様に真っ暗なポイントとして記録されるので拾われると暗くなる)
部屋の外にはみ出てると部屋の外の明るさ(暗さ)拾ったりしちゃうので室内の分は完全に室内に留めたほうがよいとされています[誰によって?]
後ろ側に何か描画してあるところにだけ描くみたいな処理だったはず……(ちなみに違いは裏面になってる部分を先に描画するのが 2 パス、全部一気に描画するのが 1 パスで、閉じたメッシュは基本 2 パスじゃないとおかしくなりがち)
描画タイプ「標準」は表情のオーバーレイメッシュとかを想定してるらしいので服とかは 1 パスあるいは 2 パスの方がいいらしいわね
とりあえず JSON 的オブジェクトとして動的に構築してトップレベルが Array だったら T[] にしてそれ以外なら T として 1 要素の Vec を作る
そういえば string | object | (string | object)[] 問題についてはこれで解決しました
あーーーーこれ ActivityPub 関連だけ別レイヤーで crate 分けたほうがいいな……
その一 いつもと違う痛み方に気が付くこと
その二 ちゃんと気圧まで見ること
いいね？
ningen_mame@misskey.io
This account is not set to public on notestock.
sorted set が欲しくなるが、そうするとそれこそ Redis でええやんという話に
では遅延させたいジョブをどこに保存しておくかという話になるが、アプリケーション側でインメモリで持たせるのはなんか微妙な気がするんだよなあ
Amazon SQS とかで動かすことを考えると delayed queue をどうするか問題が発生する気がするぞこれ……
Redis 前提で設計してたら ack/nack 後から入れることになって絶対面倒だったろうからこれでええねん vs 別に AMQP バックエンドで動かしたい人そんなおらんやろ
deser に失敗した場合 nack を投げる手段がなかったので追加した
X formerly Twitter の連携ログイン経由で不正利用されうるからって言ってたね
しかしシステムストレージが 32GB とかだったころからするとだいぶ食うようになったなあ
櫻ノろこ🌸漫画練習中
rocco65e@misskey.io
This account is not set to public on notestock.
RabbitMQ が本当にブローカーとしての役割しかないのでログ取る場所を別途用意しないといけなさそうなんだよな
> Custom Algorithms
> Don't do this.
ここすき
This account is not set to public on notestock.
https://max.levch.in/post/724289457144070144/shamir-secret-sharing-its-3am-paul-the-head-of
> the manual pages were identical, except Solaris had a “special feature”: any passphrase entered that was longer than 8 characters long was automatically reduced to that length anyway. (Who needs long passwords, amiright?!)
それこそ OAuth token とか、あと AP 実装におけるローカルユーザーの秘密鍵とか
パスワードみたいなのはともかく、復元可能な secret credential を保存しなきゃいけない場合って何で暗号化かけたりするのがいいんだろう
This account is not set to public on notestock.
そういえば 1Password の Watchtower にもあった気がするな
HaveIBeenPwned の API でチェックするという手があるのか
よく知られたクラック済パスワードリストみたいなのを採用すれば多少納得してもらえるのではなかろうか
bcrypt のストレッチ回数って多くの場合 "10" (1024 回) だと思うけど、あれどこまで小さくしても現実的にセキュアなんだろうね
まあ近年の CPU は暗号化とかハッシュ化とかに特化した高速な命令を持っていたり、 SIMD による計算の高速化がしやすかったりとか、一部アルゴリズムのコストは爆下がりしているからね……
セキュアなパスワードハッシュは(SHA-1 とか MD5 に比べると)計算コストがバカにならなくて……みたいなことを言っている人がいた気がする。するだけでいないかもしれない
VRChat でずれるのは PostProcessingStack が SPS-I 対応してないかららしい
