逆にデカいオブジェクトがほんのり遮蔽してるのはそれっぽさが減りがち(取ってくるピクセル数が限られるのでしょうがない)
どっちもまあ言われれば納得はできる感じしません?
(右がレイトレなので"本当"に近い)
https://docs.unrealengine.com/ja/RenderingAndGraphics/RayTracing/index.html
極端な話をすると話題のレイトレがあったとしても「ウソ」を貫き通せるなら「ウソ」を返したほうがコスパは良いのでほとんどのゲームではそうなっていると思います
ほぼ 3 年前の記事:
> 3D Graphics is a Lie
> For the last thirty years, almost all games have used the same general technique ...(中略)...
> Through approaches like z-buffering and occlusion culling, games have historically strived to minimize the number of spurious pixels rendered, ...
Announcing Microsoft DirectX Raytracing!
https://devblogs.microsoft.com/directx/announcing-microsoft-directx-raytracing/
NPR な表現に倒してしまうというのはひとつの手だと思う(これは多くの VRChat ワールドやアバターなどもそうであるように)
代償として空間計算量が数倍以上必要なのと、そもそも昔の GPU はそれを実現するための機能をサポートしていなかったので手法の提案から実用化まで 2~30 年空きがある
Forward と Deferred の違いですが、計算量の概念がわかるおたくには O(NM) と (N+M) ぐらい違うというのが比較的わかりやすいと思う
このアカウントは、notestockで公開設定になっていません。
ほぼあってます(補足としては、万人向けのデバイスとしてはおそらく「酔わない」のが至上命題で、これの下限は諸説ある。Quest2 だとたしか今は 72Hz)
ちなみにほぼ真ん前/画面中央しか見てないやんけという経験則に基づいて外側を荒くするやつはもう実用化されてます(Foveated Rendering だっけ)
被写界深度的な効果、片目だとわりとかんたんにできるけど両目だと奥か手前の景色が左右ズレを起こしてしまうし、レンズフレアにいたっては裸眼で観測できるのかすら謎
2010 年代以降のリアルタイムレンダリングはかなり Deferred Rendering と G-Buffer のアイデアによるところが大きく、VR では様々な理由により使いづらく Forward が好まれているのが現状ですね まあそろそろ G-Buffer の VR での効率化の手法とか出てきそうですが
だからまあいくらベイクしたとて AAA タイトルみたいな陰影表現を VR でやろうと思うとそれはそれは計算コストが膨れ上がってしまうでしょう……
実際 UE4 のリリースか何かで 通常の Deferred から Oculus カスタムの Forward にしたら最大で数割フレームレートが上がったという話がたしかあったがあれはもともと VR 最適化ある程度込みでつくられてたっぽいんだよな
このアカウントは、notestockで公開設定になっていません。
ハンコ作りマシン、切削工具とか中に置きたくない感あるし、もしかしてレーザーで焼いてるとか?
Anker の Anker PowerPort Atom III Slim (Four Ports)(PD 充電器 65W 4ポート USB-C)【PowerIQ3.0搭載 / PD対応/GaN(窒素ガリウム)採用】 iPhone iPad iPod 各種、 MacBook Air、その他USB-C機器対応 (ブラック) を Amazon でチェック!
https://amzn.to/3bOxbDe
45WのPDがあってAポートが付いてるのはこれが咲いたっぽい
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
トイレの蓋がいたずらされてて開かなくて、出しちゃった女の子|minoco|pixivFANBOX https://minoco123.fanbox.cc/posts/1815280
中華の日本語が怪しい電子部品大量パックつい買っちゃうんだよな(今日は↓のを買った)
【620個入】コネクタ/デュポンコネクタ セット 2.54mm オスピン メスピン KINCREA https://www.amazon.co.jp/gp/product/B07DF9BJKH?psc=1
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
Rustでcrate Aが内部的に依存している他のcrate Bの型Tを返してきてて、そのTを自分のプログラム中で明示的に扱いたいときってcrate BをCargo.tomlに追加するしかない?具体的にはscraper::element_ref::ElementRefの返してくるego_tree::NodeRefに対するpredicateを関数として書きたい
このアカウントは、notestockで公開設定になっていません。
Asciidoctor Rust Implementation
https://gist.github.com/jamesmunns/06f70b68bde8e1394b79e936a8599718
人々が我慢の限界を超える瞬間を見た
あと productivity が ORM > Query Builder なのはそうか?と思うんだけどこれは SQL わかる補正っぽいんだよな
React Server Componentsに感じたフロントエンドの消失 https://zenn.dev/koduki/articles/3f5215f2a79843
眼鏡外してるから「バンドは接続されました」の通知メッセージがパンツに見えた
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
時間見ろ時間、え、相対時間表示だからわからない?そっか…
同じ話か忘れちゃったけどワンクリックでフル画像表示できるしデバイスの都合にもよるのに CSS でサムネイル表示をクロップするのは同一性保持権侵害になりうるみたいなのはさすがに Twitter 他サービス側がかわいそうだと思っています(Mastodon はこの文脈かは知らないけど対応していますね)
日本の法だと単に URL を介した紹介でも十分に違法扱いできた気がする (たぶん探せば掲示板あたりで判例あると思う) ので、べつに「同内容の投稿」セマンティクスは必要なさそう
あと Twitter の歴史的経緯からして RT 自体の full_text に RT: @.... が付与されてコピーされるというのがあったのでまあ Twitter のお気持ちとしてはそうなのかもしれないな……
あれ児ポという観点でいくと Twitter の挙動としては本人が投稿したのと同じになるのでまあそういう解釈になりえるなあとは思った
たとえばほたが乳デケー甘雨を RT して僕がそれを見て「いい乳ですね」って返信したとしてほたがいい乳ですねって言われる蓋然性ゼロでしょ
Twitter 謎仕様変更、まあ色々あるけどなぜ RT にリプすると RT した人も対象になるようになったのかもかなり謎だと思いますね
↓についてはコンテンツとして偶々リプツリーのどれかになってしまうという解釈をしている
あ、あと Twitter の web UI って URL 引用したとき引用された側のリプライ欄に引用した側の投稿を繋げて表示することがあるので、実はそれが in_reply_to で繋がってると勘違いしてたりしない?
直前の投稿 (conversation の最新の投稿) への言及なら in_reply_to だけで済ますけど、 conversation 中の特定の投稿について言及したかったら in_reply_to と URL 両方使うなぁ
別に Twitter でも引用リプ会話が in_reply_to になってるとは限らないって言おうとしたけど表示上の話かしら
機能として用意されてるので当人を責める気にはなれないけど screen_name をクラスタに合わせてちょくちょく変える人できればやめてほしいなあと思ってる もしくは Twitter が user_id で直でユーザーに飛べるようにしろ
どうせ screen_name を変更したらその部分は無意味になるので、あまり考えないことにしている
ちなみに「リプライを自己BT/RT」する人と「通常(トゥ|ツイ)ートを後から CC などでメンション」する人は僕の観測だと半々ぐらいな気がしますね 僕は後者です
screen_name を置き換えるやつテクとしては知ってるけど API で無限に status_id から user を引けるわけじゃないというのを考えるとあんまり使いたくないんだよね……
そのトラックバック機能、公開範囲に制限が無く、相手に通知が取ばない形の返信でよくない?って思う https://mstdn.maud.io/@kb10uy/105572079271028908
ActivityPub でトラックバック通知が飛ばせたほうがいいんじゃないかという話は一理あるがそれを受け取って表示するかどうかも結局各サーバーの実装次第だしな……
メールアドレスを投稿できなくなっても善良なユーザが不便するだけで、人々は勝手に <at> とか全角@とかで迂回する、という例でも出せばいいか?
どちらかというと「今までは DRM なしで閲覧できていたデータがある日突然 DRM 必要になった、話が違う」が近いと思う
DLsite で DRM 対策が含まれている専用ビューワが提供されてるとして(実際されてるが)、 DRM かけるのをやめろという先は DLsite ではなくかけてるクリエイターじゃない?みたいな話のほうがこれは近いように思える
そう考えるとこの「M1 Mac で実行できないようにしている」主体は Apple というよりデベロッパ側で、M1 Mac ユーザーは Apple には勝てなくてもその制限をかけてるデベロッパには勝てるのかもしれない
多分 Apple としてはこのサイドロードを認めてしまうとデベロッパに対して「MacApp Store で非公開でも一定数動かすやつがいるから我慢しろ」みたいなポーズをとることになってしまって微妙な感じになってそう
このアカウントは、notestockで公開設定になっていません。
ipaファイル、iOSデバイスのバックアップユーティリティでも使わない限り本来エンドユーザに露出しないはずですけど、なんでそんなもんわざわざMacで実行しようとしましたか?と言いたくなる気持ちはあるね
このアカウントは、notestockで公開設定になっていません。
野良アプリ(App ではなくね)が完全に封じられたわけではないので 「macOS 向けに提供しないデベロッパが悪い」という方向性で片付けられそう?
iOS Appが使えること自体は宣伝してたが、サイドロードできるほどの裁量があるとかつて名言していましたかね?
不自由な方が Mac らしいというのはそれはそうで、私が疑問に思っているのはそこではなく「後から制限を追加することは許容されるのか」ですね
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。