【Unityの集い in大阪】Unity最新情報

Unity 最新情報 Tatsuhiko Yamamura @ Unity

お品書き • Addressable • UIElement • Visual effect graph • DOTS

Addressable

アセットワークフローの更新

アセットの配置の 外部配置・内部配置を 出来るだけシンプルにする

ローカルリソース warier.prefab（ファイル名) Warrior（アドレス) archer.prefab（ファイル名) archer（アドレス) Addressables.LoadAssetAsync<GameObject>(“Warrior"); 指定のアドレスで アセットをロード Warrior（ロード済）

追加でダウンロードしたコンテンツ（リモート） warier.prefab（ファイル名) Warrior（アドレス) アプリに最初から含まれるリソース（ローカル） archer.prefab（ファイル名) archer（アドレス) Addressables.LoadAssetAsync<GameObject>(“Warrior"); リモートとローカルの 区別なくアセットをロード Warrior（ロード済）

GUIベースでの登録 追加でダウンロードしたコンテンツ warier.prefab（ファイル名) スロットだけ用意 Warrior（アドレス) [Serializable] AssetReferenceGameObject Warrior;

追加でダウンロードしたコンテンツ warier.prefab（ファイル名) warier（アドレス) ドラッグ＆ドロップ

追加でダウンロードしたコンテンツ warier.prefab（ファイル名) Warrior（アドレス) [Serializable] AssetReferenceGameObject Warrior; warier.LoadAssetAsync() ドラッグ＆ドロップで アセットを登録して 遅延ロードもできる Warrior（ロード済）

DEMO

コンテンツの更新 ローカルのアセット アセット バンドル1 Webから取得するアセット カタ ログ アセット バンドル2 archer [アセットバンドル1] warier [アセットバンドル2] コンテンツカタログ コンテンツカタログは アドレスが指すアセットが 何処にあるかを知っている

ローカルのアセット アセット バンドル1 Webから取得するアセット カタ ログ アセット バンドル2 archer [アセットバンドル1] warier [アセットバンドル2] コンテンツカタログ コンテンツカタログのお陰で ロードするアセットが 何処にあるかを 気にしなくても良い Addressables.LoadAssetAsync<GameObject>(“warier");

ローカルのアセット アセット バンドル1 Webから取得するアセット カタ ログ アセット バンドル2 archer [アセットバンドル1] warier [アセットバンドル2] コンテンツカタログ キャッシュと比較して ダウンロードする データ量を取得 Addressables.GetDownloadSizeAsync("default") Addressables.DownloadDependenciesAsync("default")

ローカルのアセット Webから取得するアセット NEW アセット バンドル1 カタ ログ アセット バンドル2 アセット バンドル3 NEW カタ ログ 新しいコンテンツを追加 カタログを更新

ローカルのアセット Webから取得するアセット NEW アセット バンドル1 カタ ログ アセット バンドル2 アセット バンドル3 archer [アセットバンドル1] warier [アセットバンドル2] rider [アセットバンドル3] コンテンツカタログ 新しいコンテンツカタログで アセットの情報を取得 NEW カタ ログ

ローカルのアセット Webから取得するアセット NEW アセット バンドル1 カタ ログ アセット バンドル2 アセット バンドル3 NEW カタ ログ archer [アセットバンドル1] warier [アセットバンドル2] rider [アセットバンドル3] コンテンツカタログ 追加/更新したアセットも スムーズに取得できる Addressables.LoadAssetAsync<GameObject>(“rider”);

DEMO

ビルド時間を短縮 ビルド時間

アセットの 収集 アセットの 変換 アセットの シリアライズ コンパイル IL2CPPで 変換 パッキング

アセットの 収集 アセットの 変換 アセットの シリアライズ コンパイル アセットの更新のみの場合、 コンテンツの更新のみを行う IL2CPPで 変換 パッキング

アセットの 収集 アセットの 変換 アセットの シリアライズ コンパイル IL2CPPで 変換 パッキング スクリプトの更新のみの場合、 スクリプトのビルドのみ行う

アセットの 収集 アセットの 変換 アセットの シリアライズ コンパイル IL2CPPで 変換 パッキング Androidのパッチビルドの場合は パッキングもスキップ

おもしろポイント • 毎回コンテンツの更新に長時間またなくても良い • コンテンツを足したり配置を動かしたりがやりやすい • ビルド時のパッキングルール周りが拡張しやすい

UIElements

エディターUI拡張の更新

UIの拡張の何が良いの？ • 入力を制限してミスを減らして 楽ができる • 操作を自動化して 楽ができる • 複合的な操作を単純化して 楽ができる

UIElement = DOMベースのUI Root Element Label <Title> Button [Row] Image Label [ボタンn]

UIElement = DOMベースのUI Root Element Label <Title> Button [Row] Image Label [ボタンn]

UIElement = DOMベースのUI Root Element Label <Title> Image Button [Row] Label [ボタンn]

UIElement = DOMベースのUI Root Element Label <Title> Button [Row] Image Label [ボタンn]

DEMO

少し整理すると…
var title = new Label{ text = "タイトル" };
var button = new Button();
var image = new Image();
var buttonText = new Label{text = "ボタン01"};

UI要素の定義

レイアウトの設定
rootVisualElement.Add(title);
rootVisualElement.Add(button);
button.Add(image);
button.Add(buttonText);

スタイルの調整

title.style.fontSize = 20;
button.style.flexDirection = FlexDirection.Row;
image.style.width = image.style.height = 80;
image.image = AssetDatabase.LoadAssetAtPath<Texture>("Assets/01.png");
buttonText.style.fontSize = 15;
button.clickable.clicked += ()=>{ Debug.Log("message"); };

イベントの登録

外部ファイルを使う レイアウトやスタイルをUXML（XML似）や USS（CSS似)で記述して使う 外部ファイルを使用するので、変更時にコンパイルが必要ない （XMLはウィンドウの再起動が必要）

MyLayout.uxml

XML文法の外部ファイルで
.rowModule{
flex-direction: row; レイアウトを設計
}
MyStyle.uss

Image{
<UXML xmlns="UnityEngine.Experimental.UIElements">
min-width:
80;
<Label text="タイトル"
name="title"/>
min-height:80;
<Button class="rowModule"
name="mybutton">
}
<Image name="foo"/>
<Label text="ボタン1"/>
Image#foo{
</Button>
background-image:url("/Assets/01.png");
</UXML>
特定のUIのスタイルを
}

CSSっぽい記述で調整

Label#title{
font-size: 20;
}

名前が”mybutton”のボタンを 押したときの挙動を定義

おもしろポイント • 直感的に作りやすい（※IMGUIと比較して） • XMLやCSSになれてると使いやすいかも？ • 大量にUIを描画したときに軽い

Visual Effect Graph

様々な表現に使える • パーティクル表現 • 点像 • インタラクティブな表現

様々な表現に使える

様々な表現に使える

様々な表現に使える

様々な表現に使える

特徴 • 次世代パーティクルジェネレーター • 非常に大量のパーティクルを生成できる • パーティクル以外にも、「表現」なら色々と使える • 複雑なシミュレーションをGPUで高速に実行 （Compute Shaderを自動生成） • 複雑な表現を実現可能 • コーディング無し（スタックとノードのハイブリットツール）

オブジェクトの生成以外はほぼGPUで動作 パーティクル生成 座標計算 描画 VFX Editor GPU GPU GPU Particle System （2018.1以降） CPU CPU GPU Particle System （２０１８．１未満） CPU CPU CPU

ParticleSystem 動きの計算 CPU 適正パーティクル数 1000 particles シミュレーション 接触の表現 接触判定 Visual Effect Graph GPU 10,000,000 particles シンプル 複雑 物理演算ベース 擬似的な表現 あり なし

動きはノードベースで構築 ノードを元にComputeShaderを生成

処理のスタック（積み上げ）は Spawn、Initialize、Update、Output この４つのカタマリが基本

パーティクル数はいくつか 指定された頻度で実行 初期値をどうするか 一度だけ実行 どのように変化するか ほぼ毎フレーム実行 どのようにレンダリングするか 毎フレーム実行

DEMO

注意点 • LWRPかHDRP限定 • Compute Shader（GPUを利用した演算）が 使用できないAndroid端末はソコソコ存在する （既存のレンダリングパイプラインでも動くが、メンテされない）

おもしろポイント • 大量にパーティクルを出せるのは気持ちがいい • 発想次第で、本当に色々できる

DOTS

スクリプト周りの更新

C# Job System CPUコアを 優 に U 活用する CP Burst 高度に最適化した 優 に U P C マシンコードを出力 ECS メモリアクセスの 優 に U P C 最適化 い し い し い し

Monobehaviourで実装

メインスレッド：2.15ms

Job System対応 ジョブの発行 処理の内容

ジョブの発行：0.6ms （メインスレッド） ジョブ発行:合計1.59ms（ワーカースレッド）

C# Job System CPUコアを 優 に U 活用する CP Burst 高度に最適化した 優 に U P C マシンコードを出力 ECS メモリアクセスの 優 に U P C 最適化 2018.1から 利用可能 2019.1から 利用可能 in preview い し い し い し

ECS データレイアウト を意識して、 効率的な プログラムを実現

ECSは何が良いの？ に U P C い し 優

ECSがやりたいこと • 同じ処理を繰り返す • 連続したデータを操作する

今までのアプローチ GameObject Transform Component int2 Position 参照 MoveComponent Transform trs int2 Speed void Update() { trs.Position += Speed; }

GroundCheck System MovingSystem GravitySystem

希望する組み合わせを持つオブジェクトを集める

Position

int2 Value
Speed

int2 Value
Position

int2 Value
Speed

int2 Value

Position

int2 Value
Speed

int2 Value

MoveSystem

Query<Position, Speed> q

void OnUpdate()
{
ForEach(Position p, Speed s)
{
p.Value += s.Value;
}
}

集めたデータを一斉に処理

Componentが参照を揃えるのではなく、
必要なComponentが揃っているオブジェクトを処理する

条件が揃うオブジェクトを操作 利用 更新

DEMO

おもしろポイント • 新しい設計で試行錯誤が楽しい • 量が多いとパフォーマンスが良い • 慣れてくると確かに楽 （触りだすのは機能がもう少し揃ってからでも良いかも）

Visual Scripting 来るもうすぐ 具体的には2019.2から触れる

おしまい