検索式は、検索クエリ言語に追加して、複数のプロバイダーを相互参照する複雑なクエリを表現することができます。例えば、コンパイルしないシェーダーを使用するシーン内のすべてのオブジェクトを検索することができます。
検索式を連結して、検索アイテムの変換や集合 (群) による操作を行うことができます。
Search ウィンドウに検索式を入力すると、結果を返します。
検索式はルート式で始まります。ルート式は内部式を含むことができます。
t:shader
のような簡易なクエリは式です。これは、プロジェクト内のシェーダーに対応するすべての検索アイテムを返します。
検索式言語を使用して 複数のクエリ を 1 つの式に組み合わせ、より柔軟な検索を作成することができます。
検索式は以下をサポートします。
- クエリ: t:shader
- ネスト状の式によるクエリ: t:prefab ref={t:texture}
- function: count{t:shader}
- リテラル: 3
または "this is a string literal"
- プロパティセレクター: @path または @mesh
(@
で始まる識別子はすべて、検索アイテムから値を抽出するセレクターであると見なされます。セレクターは、オブジェクトのプロパティを検索したり、結果を動的に計算するために使用されます。)
すべての検索式は、検索アイテム(IEnumerable<SearchItem>
) の集合を返します。一般的なガイドラインとして、検索式言語は中かっこ {}
を使用して一群のアイテムを示します。3
のようなリテラル式でさえ、内部的には集合 {3}
として評価されます。
検索式を連結して、より複雑なクエリを作成することができます。
t:prefab ref={t:texture}
t:texture
の部分は、プロジェクト内のすべてのテクスチャを検索します。t:prefab ref=
の部分は t:texture で返された各テクスチャに対してクエリを実行し、どのプレハブがこのテクスチャを参照するかを確認します。t:prefab ref={t:texture size>4000}
: テクスチャサイズが 4000 バイトより大きいプロジェクト内のプレハブをすべて見つけます。
これは、以下と同等です。
t:texture size>4000
を実行すると、プロジェクト内のすべての 4K テクスチャのリストを返します (例えば、armor.png
、treasure.png
)。
t:prefab ref=<one of the 4K textures>
を実行します (例えば、 t:prefab ref=armor.png の後に t:prefab ref=treasure.png)。
すべての検索結果を集計し、1 つの検索アイテムリストとして返します。
t:[shader, material, texture]
: タイプが shader
、material
、texture
のいずれかであるすべてのオブジェクトを見つけます。通常のクエリを使用すると、以下のように表現されます。
t:shader or t:material or t:texture
Unity には検索式関数のライブラリがあり、検索アイテムの群 (集合) を操作して変換できます。これらの関数はそれぞれ複数の引数を取り、アイテムの集合を返します。Unity の検索式では、波かっこ {} を使用して関数の呼び出しを表します。
関数の完全な一覧は こちら を参照してください。
例: 関数 count は、パラメーターとして渡された各群のアイテムを数え、数値を返します。
count{t:shader}
: プロジェクト内のシェーダーの数を含む集合を返します。例えば {34}
count{t:shader, t:texture}
: プロジェクトのシェーダーとテクスチャの数を含む集合を返します。例: {34, 2048}
.関数は連結され、LISP プログラミング言語で使われる s 式 に似ています。
ノート: ルート式は 1 つしか存在できません。
連結された関数の評価の例 (動作順)
print{"path=@path", first{10, sort{t:texture, @size}}}
: プロジェクト内の最大テクスチャ 10 個のパスを プリント します。
t:texture
: プロジェクト内のすべてのテクスチャを検索し、サイズプロパティを選択します。sort{ t:texture, @size}
: これらすべてのテクスチャを、そのsize プロパティに従ってソートします。first{10
: ソートされた最初の 10 個のテクスチャを選択します。print{ "path=@path"
: Unity Search が結果の各アイテム path=@path
の path プロパティを抽出する文字列形式に従って、このリストをコンソールに表示します。関数は複数のシグネチャ (メソッド名と各形式パラメーターの型と種類 (値、参照、出力)、C# と同様) を持ち、optional (関数に渡す必要のないパラメーター) と variadic (可変数の引数を取ることができるパラメーター) をサポートすることが可能です。
リテラルとは、、検索したい実際の単語や数、または、取得したい実際の数値で、クエリ文字列とは異なります。例えば、t:texture は、タイプ名に texture を含むアセット(例えば Texture2D) を検索しますが、引用符を付けてリテラルにすると、“t:texture” は、t:texture という名前のアセットを検索します。
式 | 説明 |
---|---|
数字 | 文字としての数字 (1、2、3 など )。 |
集合 | 角かっこ ([ ] ) |
文字列 | 一重引用符または二重引用符 ('' または "" ) |
数値リテラルは、関数のパラメーターとして使用することができます (first
など)。
first{10, t:shader}
-> {'t:shader' クエリが返す最初の10 個のシェーダー}
角かっこ []
を使って値の群 (集合) を表現します。集合はあらゆる種類の式を含むことができますが、検索式パーサーは集合の要素を検索クエリではなくリテラルであると見なします。
例
[t:shader, hello, 3]
-> ["t:shader", "hello", 3]
波かこ ({}
) を使用すると、パーサーはこれを 3 つのクエリとして扱います。
{t:shader, hello, 3}
-> {<クエリ t:shader を実行>, <クエリ hello を実行>, <クエリ 3 を実行>}
文字列リテラルは、いくつかの関数のパラメーターとして使用することができます (format
など)。文字列リテラルは、一重引用符または二重引用符で指定できます。
“hello” または ‘hello’
指定された書式をパラメーターとする Format 関数
format{t:texture, '@path (@size)'}
セレクターは、@
というプレフィックスで示される識別子です。セレクターを使用して、アイテムのプロパティにアクセスし、計算、フィルタリング、またはフォーマットを行います。セレクターは、UnityEngine.Object の シリアル化 されたプロパティにマップしたり、動的なデータにアクセスするためにカスタム関数にマップすることが可能です。
検索アイテムがサポートする基本セレクターは以下の通りです。
id
: 検索プロバイダーによるこのアイテムのユニークな ID。value
: アイテムの内部での値。デフォルトは ID だが、関数で、アイテムの値をオーバーライドすることができます。label
: Search ウィンドウに表示されるアイテムラベル。desc
または description
: アイテムの説明 (Search window ウィンドウの 2 行目)Unity では、検索アイテムの汎用セレクターも定義されています。
@name
: UnityEngine.Object.name@size
: アセットに対するディスク上のファイルサイズ@path
: アセットパス@extension
: アセットファイルの拡張子@provider
: このアイテムを取得した検索プロバイダー検索アイテムの特定のプロパティにアクセスして操作を行うには、セレクターを使用します。
count{t={distinct{select{a:assets, @type}}}}
a:assets, @type
は、オブジェクト名 assets
をすべて見つけ、それらのオブジェクトの type
プロパティを選択します。distinct
は、存在するすべてのタイプのリストを返します。t={list of types}
は、各タイプの各アセットの複数のリストを返します。count
は、プロジェクト内の各タイプのアセット数を数えます。avg{@size,t:shader}
t:shader, @size
はすべてのシェーダーを見つけ、次にサイズプロパティを選択します。avg
はプロジェクト内のすべてのシェーダーの平均サイズを計算します。print{@value, count{t:texture, t:material}}
@#
セレクターは、シリアライズされたプロパティとマテリアルプロパティを検出します。
sort{t:texture, @#height}
はすべてのテクスチャを、シリアライズされた height プロパティの順に並べ替えます。Search ウィンドウに表示しやすいように、検索式に名前を付けることができます。
例えば、 Search ウィンドウに sort{count{t:audio, t:texture}, @value,desc}
という式を入力すると、どの Count がどのタイプに対応するのか、紛らわしくなります。
sort{count{t:audio as Audio, t:texture as Texture}, desc}
というエイリアスを使うと、より分かりやすい結果が得られます。
エイリアス名を動的に生成するには、alias
関数を使用します。以下はその例です。
alias{[1, 2, 3], 'Title value'}
を選択すると、それらのラベルでアイテムを取得します。
{Title 1, Title 2, Title 3}
expand 演算子 ...
を使用すると、アイテムの集合を 1 つではなく、複数の集合にグループ化することができます。
...{expandable expression}
-> {sub expr 1} {sub expr 2} {sub expr N}
例
小さなプロジェクトに 3 つのプレハブ、4 つのテクスチャ、5 つのシェーダーがあります。以下の式は、すべての合計を求めます。
count{t:[prefab, texture, shader]}
-> {12}
検索式 t:[prefab, texture, shader]
の結果は、プレハブ、テクスチャ、シェーダーというタイプの12 アイテムが一緒になったリストです。これは t:prefab or t:texture or t:shader
とも表現できます。
各タイプのアセットの数を別々に数えるには、expand 演算子を使用します。
count{...t:[prefab, texture, shader]}
-> count{t:prefab, t:texture, t:shader}
-> {3, 4, 5}
groupBy
関数を expand 演算子と一緒に使うと、共通のキーでグループ化されたアイテムの集合を返すことができます。
例
プロジェクトには 3 タイプのアセット (プレハブ、テクスチャー、シェーダー) があります。検索アイテムのタイプを返すセレクター @type
の場合、式は次のように拡張されます。
count{t:prefab or t:texture or t:shader}
groupBy
関数を使用すると、アイテムをタイプ別にグループ化し、タイプごとに各アイテムの数を数えることができます。
count{...groupBy{t:prefab or t:texture or t:shader, @type}}
これらの例は、プロジェクト内の複雑なリクエストに対して検索式を使用する方法を示しています。
シーン内のプレハブ使用量を数え、使用量の多い順に並べ替えます。
sort{select{p: t:prefab *.prefab, @path, count{t:scene ref:@path} as count}, @count, desc}
すべてのアセットタイプごとに並べ替えて数えます。
sort{count{...groupby{a:assets, @type}}, @value, desc}
最も多くの頂点を持つメッシュを探します (プロジェクトで @vertices セレクターが利用可能であるという前提)。
first{sort{t:mesh, @vertices, desc}}
すべてのメッシュを頂点数で並べ替えます。
sort{select{h: t:mesh, @path, @vertices}, @vertices, desc}
全メッシュの頂点数を数えます。
sum{select{h:t:mesh, @vertices}}
メッシュを参照するすべてのアセットを検索します。
ref=select{p:t:mesh, @path}
プレハブシーンの参照回数をリストアップします。
select{p: *.prefab, @path, count{p: a:sceneIndex ref="@path"} as count}
検索式の評価は、C# の 反復処理 パターンと、yield キーワードの使用に基づいています。これにより、評価は完全に非同期な操作として公開され、可能な限りブロックされないことが保証されます。これにより、検索アイテムの初期の集合が完全に計算される前に、各検索式が計算を開始することができます。
デフォルトでは、エディターをブロックしないように、すべての検索式の評価はワーカースレッドで行われます。スレッドセーフでない Unity API に依存する必要がある操作 (一部のセレクターアクセサーなど) については、ユーティリティ API を使用してそれらの操作をメインスレッドのキューに入れ、yielding 検索アイテムのパターンを維持します。
検索式言語はカスタマイズが可能なように設計されています。フレームワークのすべての部分をカスタマイズするための API は、将来のリリースで利用可能になる予定です。