ども。Pocolです。
今日は，
[McGuire 2012] Morgan McGuire, Padraic Hennessy, Michael Bukowski, Brian Osman, “A Reconstruction Filter for Plausible Motion Blur”, I3D 2012.
を読んでみます。
こんるるー。Pocoldです。
今日は，前回読んだ[Hulin 2011a]のサプリメンタルマテリアルである[Hulin 2011b]を読むことにします。
[Hullin 2011a] Matthias Hullin, Elmar Eisemann, Hans-Peter Seidel, Sungkil Lee, “Physically-Based Real-Time Lens Flare Redering”, SIGGPRAH 2011, No.108, pp.1-10.
[Hullin 2011b] Matthias Hullin, Elmar Eisemann, Hans-Peter Seidel, Sungkil Lee, “Supplemental Material – Physically Based Rea-Time Lens Flare Rendering”, SIGGRAPH 2011.
いつもながら誤字・誤訳があるかと思いますので，ご指摘頂ける場合は正しい翻訳例と共に指摘して頂けるとありがたいです。
わふー。Pocolです。
twitterみてたら，
Physically-Based Real-Time Lens Flare Renderingの特許が切れていると話題を見て，
https://patents.google.com/patent/US20140210844A1/enを見てみたら，確かに
Abandonedとなっていたので，ちょっと実装する気が湧いてきたので，まずは論文を読むことにしました。
[Hullin 2011] Matthias Hullin, Elmar Eisemann, Hans-Peter Seidel, Sungkil Lee, “Physically-Based Real-Time Lens Flare Redering”, SIGGPRAH 2011, No.108, pp.1-10.
いつもながら、誤字・誤訳があるかと思いますので，ご指摘頂ける場合は正しい翻訳例と共に指摘して頂けるとありがたいです。
こんばんわ。Pocolです。
もうすぐSIGGRAPHですね。SIGGRAPHのコースで「なねぃと」についての話があるそうで，そのコースを受ける前にある程度は調査しておこうと思いました。Sさん、問題あればご連絡を。
今回の調査では下記のようなことを知りたいなと思ったので，調査してみました。
なねぃとは仮想化マイクロポリゴンジオメトリシステムです。いわゆるVirtual Textureみたいなテクスチャストリーミングのメッシュ版という感じのやつです。細かいポリゴンを扱えるのが売りになっていて，ものすごくいい感じのディテールが表現できます。
なねぃとを実現するためのキーだと思っているものは次の通りです。
まずGPU駆動描画はその名の通り，GPU上で描画するかどうかを判定を行い，その結果で描画が駆動する手法のことを言ったりします。これはカプコンさんだったり，アサクリだったり，Trialsだったりと色々な会社さんがすでに取り組まれています。内容について知らない方がいたら下記の資料などを読むと良いと思います。
UE5はバウンディングのスケールに応じてソフトウェアラスタライズとハードウェアラスタライズの分岐がコンピュートシェーダ上で決定されます。
小さな三角形はコンピュートシェーダを用いたソフトウェアラスタライズが実行され，大きな三角形に対してハードウェアラスタライザが実行されます。
ソフトウェアラスタライザですが，小さな三角形に対しては平均で3倍高速化したと「Nanite | Inside Unreal」の動画でKarisが言っていました。恐るべき速度ですね。
あとは，この高速なソフトウェアラスタライズを支える技術として，Deferred Materialを使用しています。いわゆるVisibility Bufferというやつです。
これの何が良いかというと，深度とマテリアルインデックスをバッファに出力してしまい，マテリアル評価を遅延実行できるというメリットがあります。つまり，いちいちシェーダの切り替えをしなくて良いということです。これによりUE5は不透明物体の描画を1ドローで実現しています。
さらにNaniteを見ていてがんばっているなーと思うのがデータの圧縮です。1トライアングルにつき平均14.4Byteだそうです。一応自分でもソースコードを追ってみて，確かにそうだなということを確認しました。
まずは，レンダラーの流れをつかみ大雑把にどんなことをやっているのかを把握してみました。
レンダラーの実装は，Engine/Source/Runtime/Renderer/Private/DeferredShadingRenderer.cppにあります。これがディファードレンダリングの実装になっており，Render()メソッドに実装があるので，これを地味に読み解いていきました。なんとこの関数1600行ほどあります。
この関数をところどころを端折った疑似コードが下記のような感じになります。
ざっくりですが，処理をまとめておくと
…という感じです。
下記のシェーダが実行されるようです。
左側は実行される関数で，右側はその関数が実装されているファイルパスを表します。
PersistentCull()がおそらく一番巨大なシェーダコードになると思うのですが，クラスタ階層のトラバーサルとかカリング，あとはソフトウェアラスタライズかハードウェアラスタライズかどうかの切り分けなんかも行っています。
MicroPolyRasterize()がソフトウェアラスタライズを行っているのですが，R32G32のバッファに書き込みをします。Rチャンネルの25bit分がVisibleIndexで，残りの7bitがTriangleIDになっています。GチャンネルはDepthに割り当てられているようです。
下記のシェーダが実行されるようです。
名前通りの処理っぽいです。
下記のシェーダが実行されるようです。
ClassifyMaterials()の中では，VisibleなMaterialとMaterial Rangeを決定するようです。Material Rangeにはマテリアルのマスクビットが格納されています。
大雑把な理解として，描画対象となるマテリアルの矩形範囲を決めているようです。
FullScreenVS()では，決定したマテリアルの矩形範囲にあるタイルで，本当にそのマテリアルの描画必要かどうかを判定して，要らないところはNaNを頂点シェーダで設定して，タイルをカリングするという処理を行うようです。タイルカリングには5つのモードがあるようです。
ストリーミングの管理はFStreamingManagerというクラスで管理されているようです。
Engine/Source/Runtime/Engine/Public/Rendering/NaniteStreamingManager.hにクラスの宣言があります。
・クラスタページデータ
・クラスタページヘッダ
・クラスタ修正更新バッファ
・ストリーミングリクエストバッファ
・ストリーミングリクエストリードバックバッファ
・ペンディングページ
・リクエストハッシュテーブル
などを保持しているようですが，まだ理解しきれていないので，理解できるようになったら別の記事として書くことにします。
ページリクエストは，PersistentClusterCull()というシェーダが実行されてRequestPageRange()という関数内でリクエストが書き込まれるようです。
このシェーダで書き込んだページリクエストの取得はディファードレンダラー内のAsyncUpdate()内でバッファをmapすることでCPU側で取得されるようです。
リクエストハッシュテーブルにGPUから取得したものを登録して，被るものがあるかどうかをチェック。チェックにヒットしたらストリーミングするページとしてプッシュし，優先度でソートして，LRUを更新しています。
一方，検索にヒットしない場合は，優先度付きリクエストヒープにいったんプッシュするようです。その後、このヒープからポップしてストリーミングするページを選択しています。
ストリーミングするものは読み込みされている状態なので，送ればいいのですが，これから読み込みしないといけないペンディング状態のものについては，ペンディング状態のページを収集し，ランタイムリソースIDがコンピュートシェーダで書き込まれるので，これを利用してFbyteBulkDataを取得するようです。取得したデータをFIORequestTaskに登録し，ParallelFor文を用いて，ファイルの非同期読み込みが実行さるようです。
ストリーミングマネージャのEndAsyncUpdate()という関数で，読み込み完了待ちをしてからResourceUplodTo()関数を使ってGPUに転送しているみたいです。
FStaticMeshBuilder::Build()経由でBuildNaniteFromHiResourceModel()が呼び出されて，データが作成されるようです。
BuildDAG(), ReduceDAG(), FindDAGCut()などの内部の処理がまだ全然理解できていないので，鋭意調査中です。
ジオメトリデータはEncodeGeometryData()という関数でエンコードされるようです。
Positionデータは63bitに。
法線ベクトルはOctrahedronで表現し，XYで18bitに。
テクスチャ座標はXYで32bitに。
ここまで合計14byteになるので，確かにKarisが言っていた平均14.4Bという数字は納得できます。
ちなみに頂点カラーやUV数を増やす場合はさらにデータ容量が増えていく感じです。
今回は，えらくざっくりですが，どんな感じで動くのかについて調査しました。
レンダリングフローについては理解できたのですが，実際のストリーミングの詳しい処理内容や，階層LODの作成方法など，まだまだわからない箇所もあるので次回調査してみたいと思います。
わふー。Pocolです。
今日は，[Yan 2015] Ling-Qi Yan, Chi-Wei Tseng, Henrik Wann Jensen, Ravi Ramamoorithi, “Physically-Accurate Fur Reflectance: Modeling, Measurement and Rendering”, ACM Transaction on Graphics, Vol.34, Issue 6, November 2015.
を読んでみることにします。
いつもながら，誤字・誤訳があるかと思いますので，ご指摘頂ける場合は正しい翻訳例と共に指摘して頂けるとありがたいです。
こんばんわんわん。Pocolです。
今日は，[Chiang 2016]Matt Jen-Yuan Chiang, Benedikt Bitterli, Chuck Tappan, Brent Burley, “A Practical and Controllable Hair and Fur Model for Production Path Tracing”, Computer Graphics forum, Vol.35, Issue.2, pp.275-283, 2016.
を読んでみようと思います。
いつもながら、誤字・誤訳が多々あるかと思いますので，ご指摘頂ける場合は正しい翻訳例と共に指摘して頂けるとありがたいです。
わふー。Pocolです。
今日は，Weta Digitalによる
[d’Eon 2011] Eugene d’Eon, Guillaume Francois, Martin Hill, Joe Letteri, Jean-Marie Aubry, “An Energy-Conserving Hair Reflectance Model”, Eurographics Symposium on Rendering 2011, Vol.30, No.4, 2011.
を読んでみることにします。
いつもながら、誤字・誤訳があるかと思いますので，ご指摘頂ける場合は正しい翻訳例と共に指摘して頂けると幸いです。
こんるる～。Pocolです。
今日は[Turquin 2019] Emmanuel Tureuin, “Practical multiple scattering compensation for microfacet models”
を読んでみようと思います。
いつもながら、誤字・誤訳があるかと思いますので，ご指摘頂ける場合は正しい翻訳例と共に指摘して頂けるとありがたいです。
