UE5の神的な新機能であるところの、「Nanite（ナナイト）」、いわゆる無限にポリゴンを表示できるというアレですが、それについての情報をメモ書きします。
6月5日に公式動画の“Inside Unreal Nanite編“が公開されました。
私は「エピックジャパンの人が日本語字幕付けてくれたら観ようかな」と思ってずっと待ってましたが、ついに日本語字幕が付いていたので早速視聴しました。
色々とためになる情報があったので、自分でも一応ブログにまとめておこうというのが今回の記事になります。
ちなみに、すでに公式ドキュメントで優れた情報が提供されていますので、私の記事よりまず先にそちらを確認されることをオススメします。
https://docs.unrealengine.com/5.0/ja/RenderingFeatures/Nanite/
Naniteの概要
概要について、まずは公式ドキュメントから引用させてもらいます。
Nanite は、Unreal Engine 5 の新しい仮想化ジオメトリ システムであり、新しい内部メッシュ フォーマットとレンダリング テクノロジーを使用して、ピクセル スケールの詳細と多数のオブジェクトをレンダリングします。あなたが知覚できるディテールだけをインテリジェントに処理し、それ以上は行いません。Nanite のデータ形式は高度に圧縮され、きめ細かいストリーミングと自動詳細度をサポートします。
なるほど…たしかに正確な説明なんでしょうけど、すいませんが何も知らん人がいきなりこれを読んでもちょっとよく分からないかも。
まあ要するに、Naniteはポリゴンを無限に描画できるようにする機能です。
Naniteの経緯
Naniteのメイン開発者であるBrianさんは、それまでずっとUE4のバーチャルテクスチャ機能に取り組んできました。
[UE] Virtual TextureとそのStreamingの仕組み、またよく頂く質問への回答
それまで３Dモデルのテクスチャというのは全ての解像度のミップマップを全部メモリに読み込んでましたので、表示する3Dモデルが多くなるにつれてメチャメチャメモリを消費していました。
しかし、バーチャルテクスチャのストリーミングによって、３Dモデルのテクスチャは”今この瞬間”必要なテクスチャの必要な部分だけをストリーミングしてメモリに読み込むので、つまりはどんだけ高解像度のテクスチャを大量に使っても、消費されるメモリはだいたい常に一定に収まるようになりました。
（メチャメチャ高解像度のテクスチャを作っても、普段は普通の解像度のミップマップしか読み込まれなくて、画面にモデルが大写しになるくらい近づいた時だけ読み込まれる）
つまり、ゲーム開発者はもうテクスチャのメモリ予算（バジェット）のやり繰りについて一切考えなくて良くなったという事です。
メモリを節約しなきゃ…とかいってテクスチャの解像度をケチったりしなくて良くなりました。
Brianさん達は、「このバーチャルテクスチャの考え方を３Dモデルのポリゴンにも応用できるんじゃね？」という大胆なアイデアを考え始めました。（というかBrianさんは10年以上このアイデアについてあれこれ考えていたそうです）
それで生まれたのがNaniteです。
つまり、Naniteとは一言で言えばバーチャルテクスチャストリーミングのポリゴン版と言えるでしょう。
言葉で言うのは簡単ですが、ポリゴンはテクスチャほど簡単に扱えるものではありません。死ぬほど困難な作業だったんじゃないかと想像できます。
とにかく、バーチャルテクスチャストリーミングによってテクスチャのメモリ予算について開発者は一切気にする必要が無くなったのと同様に、Naniteによってメッシュのメモリ予算についても気にする必要はなくなりました。
何が嬉しいのか
何が嬉しいって、無限にポリゴン出していいよとか言われたらそんなもんテンション爆上げだろうが！！
おっと、失礼しました。
ゲーム開発者ならご存知の通り、今までのゲーム開発では、描画できるポリゴン数には限界がありました。
つまり、描画するポリゴン数が多ければ多いほど負荷が上がるという事です。ポリゴン数に比例してパフォーマンスが下がります。まあ、最近はシェーダ負荷によっては必ずしもそうは言えないとか、モバイルだとポリゴン数よりフィルレートが問題だ、みたいな話もありますが、いずれにしろ、ポリゴン数は少ないに越した事はありませんでした。
ですので、限られたポリゴン予算をどう割り振るか、背景に何ポリ割り振るのか？自動車は何ポリでモデリングすればいい？そういう事をイチイチ悩むハメになりました。
こういう割り振りの設計は沢山のアーティストの思惑が絡み合って、みんな「俺のモデルにもっとポリゴン使わせろ！」とか主張し合って大喧嘩になったりして、大変労力がかかって面倒なものでした。
そして、少ないポリゴンのモデルでもリッチに見えるように、工夫するというか誤魔化すテクニックが色々とありました。
例えば、スカルプトなどで作ったハイポリモデルから、ちまちまとリトポ作業してローポリモデルを生成します。それで、ハイポリモデルから法線マップをベイクするといった作業です。
ついでに言えば、遠くのモデルは低ポリのモデルに差し替わるようにする工夫、LODというものもありましたから、それぞれのモデルについてLOD版のモデルも用意する手間がありました。
こういうのは、ぶっちゃけて言うと大して面白い作業ではないかもしれません。
リトポしたところで見映えが良くなるわけでは無いからです。できるだけ見映えが悪くならないように限界までポリゴン数を削るという、まあやらないで済むならそれに越した事は無い作業ではないでしょうか。
というわけで、今まではポリゴン描画数に限界があったので、ポリゴン予算割り振りの打ち合わせとか、リトポとか、まあぶっちゃけて言ってしまえばゲームのクオリティアップとは関係ない不毛な作業に大きな労力を取られるハメになってたわけです。
で、Naniteでポリゴン数の制限が取っ払われたら、どうなるのか？
アーティストはもうアレコレ悩む必要が無くなります。自分が作った最高品質のモデルが出し放題です！
リトポ？法線マップのベイク？もう不要ですよ。だってベイク前の超ハイポリモデルをそのまま使っていいんだもん。
CG映画で表示してたような鬼みたいにポリゴンが多い超ハイポリモデルでも、そのままUE5で表示してゲームに登場させる事が可能になるでしょう。
LOD的な技術もNaniteでは自動化されています。モデルが遠くに表示されるにつれてじわじわローポリに切り替わっていきますが、ゲームプレイヤーが知覚できない範囲で行われます。
LODみたいにパッとモデルが切り替わって、プレイヤーに違和感を覚えさせてしまうといった事は起きません。
Naniteによってアーティストの負担は軽くなります。
つまり、ゲームがより簡単に作れるようになるという事です。
性能
古代の谷デモ
ダウンロードサイズが100GBもあった事で話題のUE5の古代の谷デモですが、背景のモデルは一つ辺り100万～200万ポリゴンの超ハイポリMegascansモデルがそのまま使われてます。
さらに、古代の谷ステージ全体で100万個くらいのモデルが配置されてるそうなので、ステージ全体で1兆ポリゴンです。
それでもサクサク動作してしまいます。
これがNaniteの実力というわけです。
実装の詳細？
Naniteの実装の技術的な詳細についてはこの記事では取り上げません。
何故なら、私がよく分かってないからです。
Naniteは魔法みたいなテクノロジーですが、技術的にはやはりメチャクチャややこしい事を沢山やってるようです。
私はUE5でNaniteを使えさえすればよいので、詳細についてはそこまで興味ありません。
どういう使い方をすればいいのかさえ知れればそれでいいです。
↓Naniteの技術的な詳細に興味がある方は、Nanite作ったBrianさん達がSiggraph2021で発表した講演の資料がこちらにあるのでそっちを見てください。
http://advances.realtimerendering.com/s2021/
メッシュのクラスタリングとオクルージョンカリング
さて、Naniteは無限にポリゴンが描画できると言っても、クソ真面目に超超ハイポリゴンをそのまま全部描画してるわけではありません。
目一杯メッシュに近づけば、たしかに元のハイポリメッシュそのままで表示されますが、遠くになるにつれてメッシュはこっそり荒くなっていきます。
とは言え、それは人間に知覚できないレベルで起きます。Nanite以前は遠くのメッシュはLODに切り替わったりしてましたが、あれだと切り替わりの瞬間に明らかにパッとローポリに切り替わったな…という事がモロバレになったりしてましたが、Naniteではポリゴンが荒くなる変化には全く気付きません。
つまり、どんだけ高ポリゴンのモデルを画面に大量配置しても、結局画面内のポリゴン密度は変化しないという事になります。
ですから、画面上に何ポリゴン出そうが、結局描画する量は一定であり、負荷も一定になるという事です。
さらにNaniteではほぼ完全なオクルージョンカリングが行われます。
Nanite以前でもモデル単位のオクルージョンカリングは行われてましたが、モデル単位であり、モデルがほんの一部でも画面に映ってたら、当然ながらモデル全体が描画されていました。
しかし、Naniteでは無駄な描画をピクセルレベルで弾くようです。つまり、基本的に画面のピクセルごとに１回ずつしか描画されない事になります。
常に最小限の描画だけがおこなわれるので、これも描画負荷一定に繋がります。
とは言え、オクルージョンカリングは完全ではなく、条件が悪いと複数回描画（オーバードロー）されるピクセルも出てきます。
例えば、古代の谷サンプルも実は条件が悪いです。古代の谷はMegascansのモデルをキットバッシュ的に配置して作成されていますが、つまり見えない部分で沢山のメッシュの重なりが発生しており、あまりに近い距離でメッシュが重なってるとNaniteはオーバードローが発生してしまいます。
↓これは古代の谷のNaniteオーバードロー表示です。色が明るい部分ほどオーバードローが沢山発生しているという事です。
とは言え条件が悪くても負荷は最大で2倍程度に収まるようです。
パフォーマンス
以上の話で、Naniteではポリゴンをいくら大量に表示してもほぼパフォーマンスに影響しないことが分かりました。
とは言え、Naniteでは画面解像度がパフォーマンスに直撃します。解像度に比例して負荷が上がります。
解像度が～2496×1404（動的解像度）でテンポラルアンチエイリアスで4kにアップサンプリングしているという条件で、
可視性バッファ生成の部分に～2.5msの負荷がかかってます。これは完全にGPU駆動の処理なので、CPUの負荷はほぼゼロです。
次に、各マテリアル毎の描画部分に～2msの負荷がかかってます。これもほぼGPUのみの処理ですが、ドローコールを叩く部分だけ、CPUがデバイス応答待ちになります。
お気づきの方がいるかもしれませんが、マテリアル描画の部分はマテリアル数に比例して負荷が増えていきますので、画面内にメチャメチャ一杯マテリアル出しちゃうと結構重くなるかもしれません。
というわけで、合わせて～4.5msの負荷なので、60fpsのゲームのバジェットに収まります。
ちなみにUE5は今ではTemporal Super Resolutionという機能があり、低負荷で1080pを4kにアップサンプリングできます。見た目はほぼネイティブ4kと変わらなくなるらしいです。
「でも、そんな超ハイポリメッシュ使ってたら、ディスクサイズがいくらあっても足りないじゃないか！」
と思われるかもしれませんし、私もてっきりそう思ってましたが、意外な事に、そんな事はないんです。
これは公式ドキュメントのNaniteのページの”データサイズ”の項目で説明されています。
ドキュメントではMegascansの岩のモデルを例に取って説明されてます。
↓まずこれが、岩のハイポリメッシュです。ポリゴン数は154万ポリゴンあります。パッケージ化された後のディスクサイズは148.95MBです。
当たり前ですが、Nanite以前はこんな背景の岩なんかに150万ポリゴンも割くポリゴン予算はありませんでしたので、Megascansではローポリ版のモデルも用意されてました。
↓これがローポリ版のメッシュです。たったの2万ポリまで削られてます。パッケージ化された後のディスクサイズも1.34MBまで削減されてます。
ポリゴン数が1/75まで削減されたにもかかわらず、法線マップのおかげで見映えがあまり変わらない事に驚きますが、モデルの縁をよく見ると、モデルのデコボコした詳細が失われてる事に気付きます。さらに接近して眺めれば違いは顕著になるかもしれません。
まあ、とにかくNanite以前はこのローポリ版のモデルをゲームに使ってたわけです。
さて、ではNaniteメッシュは？というと、元のハイポリメッシュと同じ見た目、同じ154万ポリゴンを維持してるにもかかわらず、 パッケージ化された後のディスクサイズは19.64MBとかなり小さくなります。
なぜサイズが小さくなるのか？というと、Naniteメッシュは量子化（クオンタイズ）による非可逆圧縮が行われるからです。
画像に例えると、ハイポリ→ローポリの変化は画像の解像度を下げる操作に該当します。普通に画質が悪化しますよね。
それに対して、ハイポリ→Naniteメッシュの非可逆圧縮は、言わばpngをjpgに変換するようなものです。微妙に劣化しますが、見ててもほとんど気付きません。
さて、ここまでをまとめると、ハイポリメッシュ→148.95MBで、ローポリメッシュ→1.34MBで、Naniteメッシュ→19.64MBとなります。
「たしかにNaniteメッシュはハイポリからかなりサイズが減ってるけど、でもローポリメッシュと比べたら10倍以上のサイズじゃん！どこがNaniteでもディスクサイズ大丈夫だよ！」と思われるかもしれません。
ここで、一つのトリックが使われます。
今までメッシュの話だけしてましたが、モデルにはメッシュだけでなく、テクスチャも含まれてます。
この岩モデルの場合、8.2MBの4kアルベドテクスチャと21.85MBの4k法線テクスチャがあります。
ローポリメッシュの場合は法線テクスチャが無いとのっぺりしたローポリである事がバレバレになってしまうので、法線テクスチャは必須です。
しかし、ハイポリメッシュやNaniteメッシュは実は法線テクスチャが無くても十分に見映えが優れています。
さらに、UE5ではバーチャルシャドウマップによってメッチャ綺麗で細かいシャドウが表示されるようになりましたから、ハイポリメッシュのデコボコのセルフシャドウ陰影がすごい綺麗に出るようになったという事もあります。
↓バーチャルシャドウマップでセルフシャドウがメッチャ綺麗に出てる様子
というわけで、Naniteメッシュにはモデル固有の法線マップは不要です。とは言え、それだとさすがにほんのちょっぴりデコボコ感に欠けるような気がしますから、色んなアセットで使い回せるような汎用のタイリングされた詳細法線マップを足す事にしましょう。
↓そうするとこんな感じになります。
優れた見栄えですね！
ここまでの話をまとめると、
まずローポリメッシュは、アルベドと法線テクスチャが必須ですから、合計するとディスクサイズは31.04MBとなります。
Naniteメッシュは固有の法線テクスチャが不要だと分かりました（汎用の詳細法線テクスチャは他で使い回してる物なので計算に含めなくていいでしょう）から、メッシュとアルベドテクスチャを合わせると27.83MBとなります。
何という事でしょう！Naniteメッシュはローポリメッシュよりメチャメチャ見栄えが良くなったにもかかわらず、消費するディスクサイズを減少させる事に成功しました！
要するに、今までは法線マップのサイズがクソデカすぎたのが、表示ポリゴン予算の制限から解放されてハイポリ出し放題になれば、ローポリ＋法線マップ使うよりハイポリモデル出す方がディスクサイズも抑えられるという結論です。
これでもはやNaniteでハイポリメッシュを使うデメリットは一切無くなったので、気兼ねなくジャンジャンハイポリを使えますね。
ちなみに、ディスクサイズはともかく、メモリ予算的にはどうなの？という話があるかもしれません。
テクスチャに関しては元々バーチャルテクスチャーストリーミング技術によってメモリ予算はまったく気にしなくてよくなってましたし、Naniteによってメッシュも必要な時だけ必要なディティールでストリーミングされるようになったので、メモリ予算は気にしなくて良くなりました。
（ちなみにですが、そうは言ってもプロジェクトの中の３Dモデルはオリジナルの状態で保存されてるわけなので、プロジェクトファイルがメチャメチャに肥大化する事だけは避けられないでしょうね。つまりそんなクソデカプロジェクトをどうやってGitリポジトリ管理するかという問題は悩ましいかも）
そういえば、Naniteメッシュでは頂点カラーを使用する事は可能だそうです。
もしかするとアルベドテクスチャを使うより頂点カラーで色を設定した方がサイズが小さくなるかもしれませんね。
それについてはQuixelのGalenさんによれば、前にちょっとそれはテストした気がするけど、何らかの理由でやめたんだと思うけど、何でだったか忘れたけど、また今度調査してみたいとの事。
制限
真っ先に書いておくべき制限として、Naniteは現在、PS5とXbox シリーズ S|X、そしてPC（DirectX11またはDirectX12が動く環境）だけがサポートされてます。（DirectXが動くPCって事実上Windowsだけだよね？）
スマホやSwitchではNaniteは動作しません。将来的にサポートされるかどうかも分かりません。
Naniteは現在、剛体ジオメトリのみサポートしてます。
要するに、スタティックメッシュです。
アクターが移動したり、回転したり、スケールすることは可能です。
しかし、頂点アニメーションやスキンメッシュアニメーションなどは現在サポートされてません。
これはつまり、風に揺れる葉っぱとか木とかのフォリッジも未サポートという事です。（完全に動かないスタティックメッシュとしてなら置ける）
ちなみにスキンメッシュはダメですが、ロボットみたいな剛体メッシュでできたキャラクターならNanite対応できるそうで、実際に古代の谷のボスはそうやって作られてます。
テッセレーションやディスプレイスメントもNaniteは対応してません。（ハイポリ表示できるなら不要かも？）
ワールドポジションオフセットも非対応です。
また、Naniteが苦手なタイプのメッシュもあります。
小っちゃい物が一杯集まってるようなものは苦手との事。たとえば草や木の葉っぱなどです。
表示できないわけでは無いですが、他のメッシュと同様に無限に表示できるという訳には行かないかもという事です。
さらに、マテリアルについても現在不透明マテリアルしかサポートされてません。
半透明マテリアル、マスクマテリアルは未サポートです。
今後の見通し
Naniteメッシュのサイズ削減ツール
UE5の中でNaniteメッシュのサイズ調整ができるようにするツールが用意される予定みたいです。
Brianさんはゲームの開発中はディスクサイズがどうたら～とか考えずにゲームを面白くする作業に集中して欲しいという事です。
Naniteによってどんなハイポリモデルだろうが動作するようになりましたが、ゲームが完成してみると、例えばゲームサイズがブルーレイディスク容量に収まらなくて、結局Naniteメッシュのサイズを削減せざるを得ない事態は起きえます。
そういう時にイチイチDCCツールに戻ってメッシュの調整…とかやるのも大変なので、UE5のエディター内でポチッとするだけでメッシュサイズを減らせる、そんな風にしたいとの事。
将来スキンメッシュとかがサポートされるようになるのか？
Brianさんによると、少なくとも直近では予定は無くて、やるとしても結構先になるだろうとの事。
話のテンションからすると、割と難しそうです。
それより直近でやるのは、インスタンス数をもっと沢山表示できるようにする改善作業だそうです。
また、上記のメッシュ削減ツールなどのエディタツールの改善や、Naniteメッシュのさらなる圧縮などを直近で行うそうです。
また、マスクや半透明マテリアルは今後サポートされるのか？については、サポートされる予定だそうです。
しかし、技術的には結構難しいので慎重に作業してるとの事。
Megascans向けのコリジョン生成ツール？
Galenさん達は古代の谷の作業でMegascansメッシュに対していい感じにコリジョンを生成するためのツールを作成して使ってたそうです。
これはもしかするとその内提供されるかもしれないとの事です。
Inside Unrealの中で出た話題
Megascans買収の経緯？
Naniteの開発中、BrianさんはNaniteで表示するモデルがなかったのか、しゃーないのでメチャメチャにポリゴンを細分化したプリミティブ（キューブとか球とか）を表示してデモしてました。
しかし、プリミティブがいくら表示されてもポリゴン数が多かろうが少なかろうが全然違いが分からないですよね。
もっとちゃんとした、超ハイポリモデルが必要です。Brianさんは「MegascansのQuixelを買収しようぜ」と同僚と話をしました。
そうしてQuixelはEpicに買収されたわけです（多分）。
今にしてみると、もしEpicがQuixelを買収してなかったら、UE5とNaniteが発表されても、我々ユーザーとしては「そんな事言われてもそんなハイポリモデルなんて持ってないよ」と戸惑ってしまったかもしれません。
ですが、すでにUEユーザーはMegascans使い放題だったので、「すげえ！これを無限に表示しまくれるんだ！」とテンションが爆上がったわけですね。
つまり、Quixel買収はNaniteの布石だったわけで、Epicの買収戦略はすごい！という話です。
Naniteはソリッドなメッシュとか細いメッシュとかちゃんと表示できるの？
UE5のデモでは岩とか銅像とかばっかり表示してたけど、もしかしてソリッドなメッシュとか細いメッシュだと描画が崩れちゃうんじゃないの？という疑惑があったそうです。
Brianさんはこれに応えるためにソリッドなメッシュとか自転車のモデルを表示して見せました。
メカっぽいキャラのモデルも表示しました。
ちゃんと表示されてますね。
質問「何百万ポリものモデルが使えるのはいいけど、そんな超ハイポリのテクスチャをどうやって編集すればいいですか？」
答えとしては、Quixel MixerはMegascansの超ハイポリモデルを扱えるように設計された3Dペイントソフトなので、それを使ってくださいとの事。
タダですしね。
質問「ランドスケープはNaniteでサポートされるのか？」
サポートされる予定は今のところ無いみたいです。
ちなみにUE5のアーリーアクセスの現在、ランドスケープはLumenのライトバウンスにまだ対応してないそうです。（それは結構こまるな）
UE5の正式リリースまでにはサポートされるだろうとの事。
ちなみにBrianさんやGalenさん達は「ランドスケープの新バージョン作りてーなー」みたいな話し合いをした事があるそうです。でもそれはやるとしても結構先の話になるだろうとの事。
質問「マスクマテリアルが使えないから木を表示できないって話があるけど、木の葉っぱも全部ポリゴンにすればいんじゃね？」
これに付いては、Galenさんは「それは試したけどダメだった。草とかの細い部分の描画がメチャメチャ崩れちゃう！」と言って、Brianさんは「いや今のNaniteにはそんなバグは無いハズ！」って返してちょっと火花バチバチになってたので結局どうなのかよく分かりません。
質問「Naniteを使わない方がいいケースってあったりするの？例えばローポリモデルしか使って無いとか。ハイポリとローポリモデル両方ある時は、ハイポリだけNaniteでローポリは普通に描画した方がいいの？」
これについては、Brianさんによれば、Naniteが使えるモデルだったら全部Nanite使った方が吉。との事です。
例えローポリモデルだとしても、Naniteをオンにして損した試しは無いとの事。
とは言え、結局は一度はオンとオフを見比べてプロファイラで確認した方がいいでしょう。
また、Naniteと非Naniteを混在させた方がいいケースがあるのか？については、できるだけ全部Naniteに纏めた方が良いとの事。
質問「NaniteはVRとかで使えますか？」
Naniteでマルチビューレンダリングは可能なので、VRでもNaniteは使えるようになるハズとの事。
質問「Naniteは同じ種類のモデルを沢山表示はできても、沢山の種類を表示する場合は不利だったりしないんですか？」
Brianさんによれば、とにかくNaniteはそれ以前の描画方法に対して不利な点は何も無くて、アドバンテージしかないそうです。
可視性バッファの生成については画面上の全てのモデルを一発で描画してくれるので、CPU効率は圧倒的との事。
Naniteは理論上は100万種類のモデルを同時に表示しても描画パフォーマンスに影響はないとの事。ただ、100万種類のモデルはさすがにメモリが足りないだろうからそっちで問題が起きるだろうとの事。
（私の想像では、100万種類のモデルが全部共通のマテリアルなら大丈夫だろうけど、それぞれ別のマテリアルを持ってたら100万ドローコールが発生するので負荷はある程度増える気はします。）
質問「Naniteで表示されるメッシュの画面密度を変更できますか？」
変更できないそうです。
というのも、現時点で十分に人間の知覚の限界まで高密度に表示されるから、今のところ変更する必要なさそうだからです。
Naniteは99%完璧に動作しますが、極めてまれに、見て分かるレベルで表示崩れを起こすケースもあるっちゃあるかもしれない。
そういうのは極めてまれなので、あんまり細々とした編集機能は付けたくないとの事。
質問「プロシージャルメッシュはNaniteでサポートされますか？」
今のところサポート予定はないそうです。
というのも、Naniteメッシュのメッシュクラスタ生成処理は相当負荷と時間がかかる作業なので、ランタイムで実行する事は想定されてないそうです。
所感
Inside Unrealの動画でBrianさん達の話を聞いたおかげでNaniteが結局どういうものなのか、輪郭を掴むことができました。
Naniteが発表された時の衝撃は大きくて、あまりに凄すぎて、私がUnrealEngineを使い始める決定打になりました。
私がNaniteを気に入っている理由は、まず第一に、たった一つの技術で色んな問題をまとめて解決しているところです。
１．ポリゴン描画予算を気にしなくてよくなった。
２．メッシュのメモリ予算を気にしなくてよくなった。
３．手動でLODを生成しなくて良くなった。また、LOD切り替わり時の違和感なども起きなくなった。
４．根本的に描画負荷を減らした。ほぼ完全なオクルージョンカリングを実現した。そして、今までは基本的にインスタンス毎にドローコールが発生していた（インスタンシングが効いてれば纏められたけど）のを、マテリアル毎に１回ずつしかドローコールを呼ばなく済むようになった。（つまり理想的なバッチングが実現されている）
５．超ハイポリモデルでもむしろローポリの時よりディスクサイズを抑えられるようになった。（法線マップが要らなくなったので）
これらの問題がNaniteで一挙に解決されました。すごすぎますね。
正直言ってどの問題も、私には解決される日が来るなんて考えた事さえなかったものばかりです。
ゲーム表現に革命的な改善をもたらしたNaniteは、コードで書かれた芸術とさえ呼べるかもしれません。
まあ、実際にはNaniteは一つのシンプルな天才的アイデアというよりは、色んな技術と工夫を総動員したソリューションと言うべきもののようですが。
私はこのような洗練された夢のような技術に触れているとそれだけで嬉しくなってしまいますね。
Naniteのもう一つのいい所は、これだけの大革新をやっておきながら、既存のUnrealEngineのワークフローと全く衝突しないで、自然にエンジンに統合されて使える事です。
スタティックメッシュの設定でチェックをポチッと入れるだけでNaniteメッシュに変換されてNaniteで使えるようになります。マテリアルだって既存の物をそのまま使えます。
いや～、すごいですね。
しいて言えばスキンメッシュや半透明がサポートされてなくて、結構制限がまだあるっちゃありますが。
さて、Naniteを見た時は私は「すごすぎる未来の技術だ！」と感動しましたが、もしかするとNaniteの手法の考え方時代は昔からあったりするのかもしれません。私は技術トレンドを深く追ってるわけではないので分かりませんが。
Naniteが要求するスペック要件はかなり高めです。もしこのようなアイデアを思いついていたとしても、昔だとハードスペックの問題で無理って事でボツになってたかもしれません。
Brianさんは10年以上Naniteのアイデアについて考えていたとの事ですが、それが今回のUE5のタイミングで実装されたのは、ついに時が来たからでしょう。
時と言うのは、PS5やXBoxなどの次世代機の登場です。
今世代機が今までに比べて一番進歩したところと言えば、やはり超高速SSDが標準搭載されてストレージ速度が爆上がりした事が大きいと思います。
PS4のHDDはSATA2なので転送速度は300MB/s以下でしたが、PS5のSSDは5.5GB/sで20倍近くに達します。（ストレージ速度だけではなくストレージアーキテクチャもすごいらしい）
Naniteはメッシュをストリーミングで読み込むので、ストレージ高速化の恩恵を最大限に受けられます。
じゃあ逆に言えばPCでHDDにインストールされたUE5製のゲームはメッシュのストリーミングが間に合わないんじゃないの？という疑問が湧いてきます。
それについては、↓こちらのInside Unreal Welcome To Unreal Engine 5 Early Access編でちょっと話があります。（1:46:21あたりから）
「僕は古代の谷をHDDに入れて作業してるけど大丈夫だったよ」的な事を述べられています。
まあ気になる方は古代の谷をビルドしてHDDに置いて実行してみれば実際どうなのか確認できるでしょう。
Windowsではゲームからストレージへのアクセスを高速化するDirectStorageという技術も準備が進められています。
あと数年もすればPC（特にゲーミングPC）でもかなり高速SSDの普及が進んでるかもしれません。
Naniteは今はまだ次世代コンソールとPCしか対応してませんが、ゆくゆくはさらにスマホの性能も進化して、Naniteが普通にスマホでも動作するようになるかもしれません。
つまり、今からUE5を使ってゲーム開発を始めれば、完成する頃にはちょうど諸々が良くなってるのかもしれませんね。