そういえば Deferred でも複数マテリアル使う場合に G-Buffer にマテリアルの種類書き込むみたいなことしてる例があったな
kb10uy(@kb10uy@mstdn.maud.io)の投稿
そういえば 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
このアカウントは、notestockで公開設定になっていません。
では遅延させたいジョブをどこに保存しておくかという話になるが、アプリケーション側でインメモリで持たせるのはなんか微妙な気がするんだよなあ
Amazon SQS とかで動かすことを考えると delayed queue をどうするか問題が発生する気がするぞこれ……
Redis 前提で設計してたら ack/nack 後から入れることになって絶対面倒だったろうからこれでええねん vs 別に AMQP バックエンドで動かしたい人そんなおらんやろ
櫻ノろこ🌸の投稿
rocco65e@misskey.io
このアカウントは、notestockで公開設定になっていません。
RabbitMQ が本当にブローカーとしての役割しかないのでログ取る場所を別途用意しないといけなさそうなんだよな
このアカウントは、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?!)
パスワードみたいなのはともかく、復元可能な secret credential を保存しなきゃいけない場合って何で暗号化かけたりするのがいいんだろう
このアカウントは、notestockで公開設定になっていません。
よく知られたクラック済パスワードリストみたいなのを採用すれば多少納得してもらえるのではなかろうか
bcrypt のストレッチ回数って多くの場合 "10" (1024 回) だと思うけど、あれどこまで小さくしても現実的にセキュアなんだろうね
まあ近年の CPU は暗号化とかハッシュ化とかに特化した高速な命令を持っていたり、 SIMD による計算の高速化がしやすかったりとか、一部アルゴリズムのコストは爆下がりしているからね……
セキュアなパスワードハッシュは(SHA-1 とか MD5 に比べると)計算コストがバカにならなくて……みたいなことを言っている人がいた気がする。するだけでいないかもしれない
