この記事は CyberAgent Developers Advent Calendar 2024 14日目の記事です。

はじめに

こんにちは、ゲーム・エンターテイメント事業部 SGEコア技術本部（以下コアテク）の矢野です。

今年10月、Unity の久々のメジャーアップデートである Unity6 がリリースされました。
多くの機能や改善が含まれており、素晴らしいアップデートだと感じています。
しかし、更新内容が多い分、その全てを把握するのは容易ではありません。

とはいえ、Unity エンジニアが実際に把握すべきアップデートはそれほど多くないとも思います。
例えば、まだプレビュー版であったり、使用するには時期尚早だと思える機能については後で把握すれば良いでしょう。
また、グラフィック関連は多くの機能が追加されましたが、グラフィックエンジニア以外は概要や使い方だけを知る程度で十分なものも多いと思います。

そこで本記事では、幅広い Unity エンジニアが知っておくべき Unity6 の注目機能を効率的に把握できるように、モバイルアプリの Unity エンジニアの観点からまとめます。
あくまで私からの観点でまとめた記事であり、取り上げていない機能の中にも有用なものがたくさんありますので、その点ご留意ください。

Build Profiles – ビルド設定を複数保持・切り替え

さて、Unity におけるゲーム開発では、開発中は Build Settings の Development Build を有効にしておくことが多いです。
また、Player Settings を使って開発環境と本番環境でアプリアイコンを分けたり、Scripting Define Symbols を分けたりすることがあります。
これまでの Unity では、ビルド時にスクリプトを実行することでこのような処理を行っていました。

Unity6 からは Build Settings が Build Profiles に代わり、環境ごとに Build Settings や Player Settings を保持・切り替えできるようになりました。

Build Profiles の使い方は以下の通りです。

File > Build Profiles から Build Profiles ウィンドウを開く
左上の Add Build Profile ボタンを押下する
プラットフォームを選択するウィンドウが現れるので、設定を追加したいプラットフォームを選択
追加された Build Profile を変更する

さて、このように一見便利な Build Profiles ですが、一つ弱点があります。
実際のユースケースを考えると、「基本的にはベースの設定を継承しつつ、Development Build など一部の設定だけを変えたい」ということが想定されます。
しかしながら、現状の Build Profiles はベースの設定を初期値としてコピーするだけなので、コピー後にベース設定の値を変更してもそれは自作の Profile には反映されません。

これは必要な機能だと思うので、今後のアップデートに期待したいところです。
なお、詳細な情報はないので予想でしかありませんが、Unite 2024 の講演で触れられていた Sub Profiles というのがそれに当たる機能ではないかと思っています。
Graphics Settings も追加されるみたいですね。

Unite 2024 セッションスライド — 【日本語吹き替え】Unity エンジンのロードマップ｜Unite 2024 より

ところでコアテクでは、Build Magic という OSS を公開しています。
これはまさに Build Profiles と同じ課題を解決するためのツールです。

Build Magic のリポジトリ

Build Magic の方は、先ほど述べた「基本的にはベースの設定を使いつつ、Development Build など一部の設定だけを変えたい」というユースケースに対応できるよう設計されています。
また、Unity6 より前のバージョンでも使用できますので、よかったら触ってみてください。

Object.InstantiateAsync でオブジェクトを非同期生成

次に、正確には Unity2022LTS の途中から入っている機能なのですが、Object.InstantiateAsync についてまとめます。

以前のバージョンでは、Prefab などを動的に生成する際に、以下のように同期的に生成する必要がありました。

using UnityEngine;

public sealed class Example : MonoBehaviour
{
    [SerializeField] private GameObject prefab;

    private void Start()
    {
        for (var i = 0; i < 1000; i++)
            Instantiate(prefab);
    }
}

この方法には、メインフレームで同期的に処理を行うため、一度に多くのオブジェクトを生成する際にスパイク（カクつき）が発生しやすいという課題がありました。

そこで Unity6 では非同期的にオブジェクトを生成できる Object.InstantiateAsync が追加されました。これを使うと、内部的に Unity のジョブシステムが使用され、マルチスレッドでいい感じに処理を複数スレッド・複数フレームに分散してくれます。

using Cysharp.Threading.Tasks;
using UnityEngine;

public sealed class Example : MonoBehaviour
{
    [SerializeField] private GameObject prefab;

    private async void Start()
    {
        // タスクを10個に分けて生成
        var tasks = new UniTask[10];
        for (var i = 0; i < 10; i++)
        {
            // 1つのタスクにつき100個ずつ生成（合計1000個）
            var task = InstantiateAsync(prefab, 100).ToUniTask();
            tasks[i] = task;
        }

        await UniTask.WhenAll(tasks);
    }
}

重いオブジェクトを多数生成する時に特に有効な機能であると言えます。

Profiler を見ると、生成処理が各ワーカースレッドに分散されていることがよくわかります。

なお、この API でオブジェクトの生成処理自体の負荷は分散されますが、生成後に MonoBehaviour の Awake メソッドがメインスレッドで一気に呼ばれることに注意が必要です。
すなわち Awake メソッドに書いている処理が重いと、そのせいでスパイクしてしまいます。

これを防ぐには、AsyncInstantiateOperation.SetIntegrationTimeMSを使用します。
長くなるので本記事では詳細は割愛しますが、Awake 処理がボトルネックになっていそうな場合には調べてみてください。

Addressable の Play Asset Delivery 対応

Addressable アセットシステムが Play Asset Delivery（以下PAD）に正式対応しました！
のですが、そもそもそう言われてピンと来る人は多くないのではないかと思います。

PAD とは、開発者目線でざっくり言ってしまえば、「iOS が 4GB のアプリサイズまで許容されているのに対して、Android はアプリサイズの制限がかなり厳しいので、実質的に大きなサイズのアプリを作れるように Google が提供している仕組み」です。
これにより諸々含め 8GB までを Google Play で配信できるようになります。（12/16 ご指摘いただき値を修正しました）

このサイズの値についてはたまに制限が緩和されたりするので最新情報は以下のページなどを参照してください。

アプリのサイズを最適化して Google Play のアプリのサイズ上限内に収める – Play Console ヘルプ

また、PAD に関しては私のブログにもまとめていますので、必要に応じて参照してください。今はなき OBB (Opaque Binary Blob) という仕組みからまとめています。懐かしさを覚える方もいそうです。

【Unity】Android App BundleとPlay Asset Deliveryの概要をサクッと学ぶ – LIGHT11

さて、この Google が提供している PAD に対して Unity の Addressable アセットシステムの対応状況はというと、今までは以下のように追加実装が必要な状態でした（詳細の説明は割愛）。

ファイルサイズが1GB未満でinstall-timeだけでいいなら特に追加実装は不要。ファイルサイズが1GB以上になると前述のようにアセットパックが分割されて小さいほうがfast-follow配信モードになるので追加実装が必要。
Addressables × Play Asset Deliveryの調査メモより

このような状況に対して、Unity6 からは Addressables for Android というパッケージがリリースされました。これにより、Unity でも PAD を追加実装なしで制御できるようになりました。

Addressables for Android package

もう少しだけ具体的に書いておくと、以下のことができるようになりました。

Fast Follow や On Demand 配信タイプのサポート
アセットパックの数を正しく制御可能（アセットパックは上限数があるため）
Texture Compression Targeting のサポート

最後の Texture Compression Target については、Android の端末に応じて適した圧縮設定のテクスチャを配信することで、ダウンロードサイズを最適化する機能です。

Unity Behavior – Unity 謹製ビヘイビアツリー

ついに、Unity 謹製のビヘイビアツリーが登場しました。

そもそもビヘイビアツリーとは、ゲームにおけるAI（機械学習文脈のAIではないです）を作るためのツールです。
敵が「プレイヤーが近くにいたら攻撃」「HPが減ったら逃げる」など、意思決定をする条件と結果としての行動をノードベースのツールで組んでいきます。
下図のようなビジュアルスクリプティングツールなので、エンジニア以外でも AI のロジックを思い通りに実現できます。

このツールは元々は、最近 Unity が推している Unity Muse という AI（こっちは生成AI文脈でのAI。ややこしい）系のツール群の一部として開発されていました。
その中からビヘイビアツリーの機能だけが抜き出され、無料で使えるパッケージとして公開されました（Muse は有料です）。

Muse と連携することで生成AIを使った自然言語によるノード生成ができますが、本記事ではそれは一旦置いておきます。
Unity Behavior はツールとしてよくできているので、ビヘイビアツリーの導入を検討している方は選択肢の一つとして検証してみてください。

私のブログにも使い方をまとめていますので、必要に応じてこちらもご参照ください。

【Unity】Unity謹製ビヘイビアツリー「Unity Behavior」の使い方まとめ – LIGHT11

ビジュアルスクリプティングといえば、Unity にはその名も Visual Scripting という名前のツールが存在します。私の周りではあまり使われているところを見ませんが、よくできたツールだと思います。思い出したので書き添えておきます。

私のブログにも Visual Scripting の概要をまとめていますので以下にリンクを貼っておきますが、Visual Scripting の前身となるサードパーティアセット Bolt を Unity 社が買収した過渡期の記事となっていますのでその点ご注意ください。

【Unity】Boltとは？ビジュアルスクリプティングツールとしての立ち位置と基本的な使い方 – LIGHT11

Render Graph – 新しいレンダリングパイプライン構築システム

Render Graph は、メモリ・処理効率とメンテナンス性に優れた、レンダリングパイプラインを構築するためのシステムです。
SRP (Scriptable Render Pipeline) の上に載っている仕組みで、元々 HDRP (High Definition Render Pipeline) に導入されていましたが、Unity6 からは URP (Universal Render Pipeline) にも導入されました。

さて、一般的にレンダリングパイプラインでは、例えば Deferred Rendering における G-Buffer など、多数の中間テクスチャを作成します。

G-Buffers — 【Unity】URPでDeferred Renderingの概要を学んでサクッと使うより

テクスチャを使用する際には多くのメモリを消費するため、同じフォーマット・同じサイズのテクスチャをできる限り使い回すとメモリを節約できます。

しかし、テクスチャを使い回すには、使い回しを行う時点でそのテクスチャがすでに役目を終えていることを確認しなければなりません。
まだ後で参照されるはずだったテクスチャに書き込みを行ってしまったら、レンダリング結果が破綻してしまうからです。

そこで Render Graph では、各レンダーパスが使用するテクスチャ（など）の情報からレンダーパス同士を繋いだ依存関係グラフを構築し、テクスチャを可能な限り使い回すことでメモリを最適化します。
今まで手動で管理が必要だったテクスチャ（など）の管理を自動化してくれることで、レンダーパス作成時のメンテナンス性の観点からもメリットがあります。

その他にもレンダーパスのマージやカリングをして処理負荷を低減させる機能など色々なメリットがあるのですが、長くなるので割愛します。
興味がある方は、弊社グラフィックエンジニアが連載している以下の記事を参照してください。

Unity6からRenderGraphを使いこなそうー基本機能編 – CORETECH ENGINEER BLOG

なお、Render Graph は従来の仕組みとの互換性はないので、今まで作成していたレンダーパスは Render Graph 用に書き直す必要があります。
Unity6 以降も従来の仕組みで動かすこともできますが、いずれは Render Graph に一本化されるようなので、中長期的な観点では移行を進めた方が良さそうです。

Render Graph Viewer – Render Graph 分析ツール

前節の Render Graph による自動化は便利ですが、最適化が意図した通りに行われているかを確認するときや、バグが発生したときには、自動化の結果を確認する必要があります。
そのために用意されている、Render Graph 分析ツールが Render Graph Viewer です。

このツールを使うと、以下のようなことが分析できます。

各テクスチャに書き込みが行われたタイミング・読み込みが行われたタイミング
Native Render Pass（詳細は割愛）にマージされたパス
パスカリング機能により処理がスキップされたパス
そのレンダーパスを定義しているスクリプトへのリンク
その他レンダーパスやリソースの詳細

グラフィックエンジニアでなくても最適化などの際に便利なので、ツールの存在は頭に入れておくと良さそうです。
Window > Analysis > Render Graph Viewer から開けます。

Shader Graph ヒートマップでノードの重さを可視化

他にもグラフィック関連の分析ツールが追加されました。

Shader Graph にはヒートマップ機能が追加されました。
これを使用すると下図のように、シェーダグラフのノードごとの「処理の重さ」を可視化することができます。

シェーダグラフを組んでいるといつの間にか処理が重くなってしまったりします。
実際、エンジニアであってもどのノードがどれくらいの処理の重さなのかはよくわからないものです。
そんな時にこの機能を有効にしておくことで、重い処理に注意を払いながらグラフを構築することができます。

なお仕組みとしては、各ノードごとに特定環境における GPU のサイクル数を計測し、その値に応じてノードに色を振り分けているといったものになります。
したがって、カスタムノードやカスタムグラフについては色が振り分けられておらず、自分で色を設定する必要がある点に注意してください。

VFX Graph Profiling Information

前節の Shader Graph に加えて、VFX Graph の方にもプロファイリングツールが入りました。
下図のように右上のボタンから開くことで、CPUやGPUの情報などをみることができます。

Spatial-Temporal Post-processing – 新しいアップスケーラー

グラフィックの処理効率を上げる上でレンダリング解像度は重要です。
小さい解像度で描画したものを綺麗に拡大（アップスケール）することができれば、その分処理負荷は小さくて済みます。

これを行うのがアップスケーラーです。

Unity6 からは Spatial-Temporal Post-processing （STP）という名前のアップスケーラーが追加されました。
Unity が独自で開発を行ったアップスケーラーで、解像度をかなり小さくしても綺麗にアップスケールされます。

下図は100%、50%、25%、10%でレンダリングした結果を比較したものです。

このシーンではかなり綺麗な結果が得られていることがわかります。
シーンの構成により結果の綺麗さは変わりますので、ぜひ一度実際に試してみてください。

さてアップスケーリングにも当然処理負荷はかかるので、十分に処理負荷が削減できているかを確認する必要があります。
Window > Analysis > Rendering Debugger を開き、Diaplay Stats を見ると GPU の処理時間が見れるので、これで計測するのが良さそうです。

STP の使い方としては、Universal Render Pipeline Asset の Quality から、Upscaling Filter を STP に設定した上で、Render Scale を小さく設定します。

Rendering Debugger の Rendering > Map Overlays を STP にすると右上に画面解像度に対する描画解像度の比率を可視化したものを表示することができます。

STP はモバイルでも使えますが Shader Model 5.0 が要件となっています。

ちなみに HDRP では Dynamic Resolution という機能で GPU のワークロードにより動的に解像度が変更できるので、組み合わせると強力な効果を発揮しそうです。

STP については、年明け1月8日に行われる弊社主催のイベント CA.unity にて、弊社グラフィックエンジニアのチャンさんが登壇しますので、ぜひこちらもご覧ください。

CA.unity #9 – compass

また、上述の Rendering Debugger には他にも有用な機能が多数あるのと、ビルド後の実機でも使用することができるのでとても便利な機能となっています。
本筋から逸れるのでここでは説明しませんが、私のブログ記事にまとめていますので必要に応じて参照してください。

【Unity】【URP】あらゆる描画のデバッグをできるRendering Debuggerの概要&よく使う機能まとめ – LIGHT11

GPU Resident Drawer – 設定一つでGPU駆動レンダリング

この機能については説明が複雑にならざるを得ないので、先に誤解を恐れず重要なポイントだけざっくりまとめると、

GPUインスタンシングによりドローコールを減らしてCPU負荷を削減する
- 同じメッシュが多数描画されるような場面で特に有効
ジョブシステムを使ってレンダリングコマンドの発行も効率的に行われる
Forward+で、MeshRenderer にのみ適用可能
カスタムシェーダは対応が必要

です。

使い方は非常に簡単で、 Universal Render Pipeline Asset の Rendering > GPU Resident Drawer を Instanced Drawing に切り替えるだけです。

さて、それではもう少し詳しく説明します。
とはいえ私はグラフィックエンジニアではないので、間違いがあったらご指摘ください。

まず、SRP (Scriptable Render Pipeline) には SRP Batcher という仕組みがあります。
これは、シェーダキーワードが同じものを多数描画する際に GPU に対するセットパスコールをひとまとめにして描画を効率的に行う仕組みです。
SRP Batcher については必要に応じて以下を参照してください。

【Unity】SRP Batcherまとめ – Dynamic BachingやGPUインスタンシングとの違い～シェーダの書き方まで – LIGHT11

一方で、この SRP Batcher は GPU インスタンシングと併用できないため、ドローコールの削減という観点では効果がありませんでした。
GPU インスタンシングについても細かくは説明しませんが、必要に応じて以下を参照してください。

【Unity】大量のメッシュを軽く描画！GPUインスタンシングの基礎知識とシェーダの書き方まとめ – LIGHT11

さて、これらとは別に DOTS の流れで Batch Renderer Group という API が作られました。
これを使うとレンダリングコマンドをジョブシステムを使って並列で生成したり、GPU インスタンシングを使った描画処理を行うことにより、大量のメッシュを効率的に描画できます。
また内部的に GraphicsBuffer にデータを格納してGPU 側に描画用のデータを保持するので、GPUにデータを送信するオーバーヘッドを軽減させることができます（インスタンス情報が変わらない限り）。
この辺りは以下のマニュアルに記載があります。

DOTS Instancing shaders – Unity Manual

この Batch Renderer Group は SRP の仕組みに載っているので、SRP Batcher によるセットパスコールの削減を効かせつつ、GPU インスタンシングによるドローコールの削減を行えます。
しかしながらこれは DOTS の文脈で作られたので、DOTS の Entity には対応しているものの、GameObject では使用しづらいものでした。
これを GameObject でも簡単に使えるようにしたのが GPU Resident Drawer です。

まとめると、GPU Resident Drawer により、今まで通り SRP Batcher によるセットパスコールのバッチングを効かせつつ、内部的に Batch Renderer Group を使うことで、ジョブシステムを使ったレンダリングコマンドの発行や、インスタンシングによるドローコールの削減といった恩恵を受けられるということになります。

実際に URP のサンプルシーン「Garden」で ON/OFF を切り替えてみると Batches の値が顕著に変わることを確認することができます。

Frame Debugger 上では下図のように Hybrid Batch Group として表示されるので、この辺りは非グラフィックエンジニアでもざっくり把握しておいたほうが良さそうです。

なお、この機能には以下の制約があるので注意が必要です。

Forward+ Renderer である必要がある
Compute Shader が使える環境であること
MeshRenderer だけが対象
MaterialPropertyBlock を使用しているオブジェクトは対象外
リアルタイム GI に影響するオブジェクトは対象外
シェーダが対応している必要がある

この辺りに関しては以下の動画でわかりやすく説明されています。

URP 17へのアップグレードとRender Graphの活用方法 – YouTube

GPU オクルージョンカリング

GPU Resident Drawer を有効にすると GPU オクルージョンカリングを使用することができます。
これはその名の通り GPU でオクルージョンカリングを行う機能です。

オクルージョンカリングとは「あるオブジェクトに隠れてカメラから見えないオブジェクト」をそもそも描画処理の対象から外して効率化するための機能です。

CPU で行うオクルージョンカリングについては以前から Unity に実装されています。
こちらについては私のブログにまとめていますので、必要に応じて参照してください。

【Unity】オクルージョンカリングを使って遮蔽されたオブジェクトをカリングして処理負荷を小さくする – LIGHT11 より

これを CPU ではなく GPU で行うのが GPU オクルージョンカリングです。
Universal Render Pipeline Asset で GPU Resident Drawer を有効にした状態で GPU Occulusion Culling にチェックを入れると有効化できます。

Window > Analysis > Rendering Debugger を開き、GPU Resident Drawer > Occlusion Test Overlay にチェックを入れると、下図のように Game ビューに半透明の単色矩形が表示されます。
これは GPU オクルージョンカリングによりカリング処理が行われた領域を示しています。

また同様に、Occuluder Debug View にチェックを入れると、GPU オクルージョンカリングのために描画される中間バッファを可視化することができます。

このことからわかるように、GPU オクルージョンカリングは中間バッファを作成するためのプリパスを実行します。
オクルージョンカリングでフラグメントが破棄されることによる処理負荷の減少量よりもプリパスの処理のほうが重い場合は、有効にすると全体の処理負荷としては大きくなるのでご注意ください。

Adaptive Probe Volumes – 高品質ライトプローブ自動配置

Adaptive Probe Volumes（以下APV）は、Unity6 の機能の中でも注目している人が多い機能のように感じています。
そのため本記事では詳細な解説というよりも、そもそもライトプローブとは何なのか？というところを中心にまとめたいと思います。

Unity には、ゲーム中に移動を行わない Static な GameObject と、移動を行う Dynamic な GameObject が存在します。
Inspector の下図の部分にチェックが付けると Static としてマークされます。

Static なオブジェクトは動かないので、事前にその位置におけるライティング情報を「ベイク」しておくことができます。
ベイクは事前に時間をかけて光の影響を計算するので、下図のように間接光の影響を考慮したレンダリングができます。

一方、Dynamic なオブジェクトはそれ自体が動いてしまうので、事前にその位置におけるライティング情報をベイクできません。
そのため下図のような間接光の影響を受けないレンダリング結果となります。

2枚目の図の方が違和感が強いと思います。

ライトプローブはこのような違和感を軽減するための仕組みです。
ざっくり説明すると、「その位置における光の影響を表す情報」をシーン上にたくさんばら撒いておいて、Dynamic オブジェクトをレンダリングする際に近くのライトプローブ情報を参照し、それらしい色をつける、といったものです。
私のブログでも説明していますので、必要に応じて参照してください。

【Unity】Light ProbeでDynamicなオブジェクトにも間接光を影響させる – LIGHT11

さてこのように便利なライトプローブですが、以下の二つの課題がありました。

ライトプローブをシーン上にたくさん配置するのが大変
ライト色の影響の仕方がざっくりすぎる（オブジェクト全体にかかる）

これを解決する機能が Unity6 で登場した APV です。
APV は根本的な仕組みは上述のライトプローブと同様ですが、プローブの配置を自動で行ってくれるという特徴があります。
また、ライト色もより詳細（オブジェクト単位ではなくピクセル単位）に影響するようになりました。

ライトプローブの比較 — Unityの新しいライティング機能 Adaptive Probe Volumes – YouTube より

APV の概要については Unity Japan が出している以下の動画がわかりやすいので併せてご覧ください。

Unityの新しいライティング機能 Adaptive Probe Volumes – YouTube

従来のライトプローブの仕組みとの比較に加えて、ベイクしたライトマップとの比較もされていて面白い内容となっています。
ただし HDRP に Experimental として導入された時期の動画なので、操作方法は他の資料を参照することをおすすめします。

Awaitable – Unity公式 async/await 対応

これまで Unity では、PlayerLoop ベースの非同期メソッドが書けず、UniTask を使う必要がありました。

以下は UniTask を使った非同期メソッドの簡単な例です。

using Cysharp.Threading.Tasks;
using UnityEngine;

public sealed class Example : MonoBehaviour
{
    private async void Start()
    {
        await WaitFramesAndLogAsync(10, "Test");
    }

    // 指定されたフレーム数だけ待機してからmessageをログに出力する非同期メソッド
    private async UniTask WaitFramesAndLogAsync(int frameCount, string message)
    {
        await UniTask.DelayFrame(frameCount);
        Debug.Log(message + ": " + Time.frameCount);
    }
}

Unity6 からは、以下のように Awaitable を使用することで非同期メソッドを書けるようになりました。

using UnityEngine;

public sealed class Example : MonoBehaviour
{
    private async void Start()
    {
        await WaitFramesAndLogAsync(10, "Test");
    }

    // 指定されたフレーム数だけ待機してからmessageをログに出力する非同期メソッド
    private async Awaitable WaitFramesAndLogAsync(int frameCount, string message)
    {
        for (var i = 0; i < frameCount; i++)
            await Awaitable.NextFrameAsync();
        Debug.Log(message + ": " + Time.frameCount);
    }
}

めでたしめでたし。

といきたいところですが、Awaitable には例えば UniTask.WhenAll のようなメソッドが存在しておらず、使い勝手は UniTask に軍配が上がっているのが現状です。
そのためアプリケーション開発においては、UniTask を使うことを推奨します。

一方でライブラリ開発においては、独立したパッケージとして公開する際に UniTask のようなサードパーティライブラリへの依存を無くしたいという需要があります。
このようなケースでは Awaitable が有用です。

この辺りの見解は UniTask の作者の neuecc さんが示してくださっていますので、ぜひこちらもご参照ください。

Guide for UniTask and Awaitable in Unity 6

また、非同期メソッドに関連して、Unity6 からは MonoBehaviour に destroyCancellationToken プロパティが追加されました。
これを使うと、MonoBehaviour が破棄された時に非同期処理をキャンセルすることができます。

using System.Threading;
using UnityEngine;

public sealed class Example : MonoBehaviour
{
    private async void Start()
    {
        // CancellationTokenを渡すことで、MonoBehaviour が破棄されたら処理をキャンセルできる
        await WaitFramesAndLogAsync(10, "Test", destroyCancellationToken);
    }

    private async Awaitable WaitFramesAndLogAsync(int frameCount, string message, CancellationToken cancellationToken = default)
    {
        for (var i = 0; i < frameCount; i++)
            await Awaitable.NextFrameAsync(cancellationToken);
        Debug.Log(message + ": " + Time.frameCount);
    }
}

Personalプランでも起動時Unityロゴを削除可能に

Personal プランで今までアプリ起動時に出てた Unity ロゴを非表示にできるようになりました。

Project Settings > Player > Show Unity Logo から非表示にできるらしいです。わーい

参考にしたサイト・動画、および謝辞

最後まで読んでいただきありがとうございました。

末尾にはなりますが、本記事の執筆にあたって参考にした資料へのリンクと謝辞をまとめて終わります。
執筆者、講演者の皆様ありがとうございます。

まず、Unity6 のオーバービューに関しては CEDEC2024 における Unity 社による講演がわかりやすいです。

【CEDEC2024】リリース間近！Unity 6 のすべて – YouTube

また、7月1日に行われた U/DAYという Unity 社主催のイベントのアーカイブが最近公開されました。
このイベントは定員制で、アーカイブもしばらく限定公開だったのですが、現在は一般公開されています。
特に以下の講演は、Render Graph の概要をとてもわかりやすく説明してくれています。 GPU Resident Drawerの説明もわかりやすかったです。

URP 17へのアップグレードとRender Graphの活用方法 – YouTube

U/DAY といえば以下の UI Toolkit の講演もオススメです。
個人的にランタイムに導入するには時期尚早と思っているので本記事では取り上げませんでしたが、エディタ拡張はもうこっちでしょうという感覚です。

30分で分かる！Unity UI Toolkit 入門～ランタイム編～ – YouTube

さて Render Graph といえば、記事中でも紹介しましたが、弊社弊事業部（コアテク）のチャンさんがRender Graph についてのまとめ記事を執筆しています。
Render Graph について実際に使って調べた内容はまだ希少価値が高い内容だと思いますので、ぜひこちらもご覧ください（連載はもう少し続くとのことです）。

Unity6からRenderGraphを使いこなそうー基本機能編 – CORETECH ENGINEER BLOG

Unity6からRenderGraphを使いこなそう！応用実装編1「RenderPassの構築」 – CORETECH ENGINEER BLOG

Unity6からRenderGraphを使いこなそう！応用実装編2「データの受け渡し」 – CORETECH ENGINEER BLOG

またレンダリング関連で言えば、GDC における公演も日本語翻訳版が公開されています。これもオススメ。

Unity 6でのレンダリングのカスタマイズとパフォーマンス – YouTube

Unity Behavior についてはまだ情報が少ないので、手前味噌ですが私のブログ記事をリンクしておきます。
私の記事はざっとまとめたものが多いので、そのうち誰かが詳細をまとめてくれることを期待しつつ。

【Unity】Unity謹製ビヘイビアツリー「Unity Behavior」の使い方まとめ – LIGHT11

もちろん公式ドキュメントも一通り見ておいた方がいいです。

Behavior 1.0.6

Shader Graph ヒートマップはまともなドキュメントがないので、詳しく知りたい人は以下のスレッドを追いましょう。

2023.3 Heatmap Color Mode – Unity Engine – Unity Discussions

Object.InstantiateAsync は Unity 公式がショート動画を出しています。
いろんな機能をサクッと知れるショート動画、いいですね。