Unity シェーダー開発

シェーダーサポート概要

Rider は Unity シェーダー関連ファイルを認識し、次の専用エディターサポートを提供します：

• Unity ShaderLab .shader ファイル

• ShaderLab ファイルに埋め込まれた CG/HLSL シェーダーコード

• シェーダーのインクルードファイル（Unity 固有の .cginc ファイルや .hlsl 、 .hlslinc などの HLSL インクルードファイルを含む）

• Unity コンピュートシェーダー（ .compute ）ファイル

ShaderLab ファイルでは、Rider が 構文と エラーのハイライト、 コード補完、 カラーアシスト、 ブレースマッチング、 コメントやコメント解除アクション、 コードを折りたたむ、 パンくずリスト、 ファイル構造、 一般的なシェーダー構文向けライブテンプレート、「Search Everywhere 」連携、 シェーダーシンボルのナビゲーションを提供します。 ShaderLab ファイル内やスタンドアロンのインクルードファイル内の HLSL コードは Unity 固有のコンテキストで解析されるため、Rider はシェーダーキーワードやプラットフォームシンボル、インクルードルートを理解できます。

シェーダーファイルの作成と編集

新規 | Unity シェーダー を使用すると、Rider の Unity ファイルテンプレートからシェーダーファイルを作成できます。 Rider には一般的なシェーダータイプ向けテンプレートが用意されています：

• アンリットシェーダー

• 標準サーフェスシェーダー

• イメージ効果シェーダー

シェーダー作成後、ShaderLab の宣言やプロパティ、パス、埋め込み CG/HLSL コードを Rider で編集できます。 コードインサイトは ShaderLab の構造や埋め込みシェーダープログラム全体で機能するため、IDE 内で補完、ナビゲーション、ハイライト、フォーマットを活用できます。

シェーダーバリアントとキーワードの操作

シェーダーファイルを扱う場合、多くの場合、 #if プリプロセッサーディレクティブを使用してさまざまな シェーダーバリアント(英語)を生成する必要があります。 これらのブランチは、モバイルやデスクトップなど異なるプラットフォーム、Vulkan や DirectX など異なるグラフィックス API、または シェーダーキーワードで実行時に有効化される異なるユーザー機能向けの条件付き動作導入に使えます。

Rider は入力中にシェーダーソースコードを解析します。 セマンティックモデルを作成し、それを利用して構文ハイライト、 Ctrl＋クリック ナビゲーション、使用箇所の検索、スマートリネームやその他のリファクタリングなどの豊富な機能を提供できます。 ただし、すべてのプリプロセッサディレクティブ内容のセマンティックモデルを同時に Rider でビルドするのは現実的ではありません。非アクティブなブランチには既存フィールドや関数と競合する別宣言、壊れたコード、または予期しない構文（例：クローズブレース＋新規関数宣言）が含まれることがあります。 そのため、Rider は編集中、現在定義されているシンボルにもとづいてプリプロセッサブランチのみを解析します。 その結果、「非アクティブ」状態となり、グレー表示され、構文ハイライトやインスペクションが適用されないプリプロセッサブランチが発生します。

Rider では、どのシェーダーキーワードを有効にするか、またどの Unity シェーダープリプロセッサーシンボルを定義するかを選択できます。

エディター右上の バリアント ウィジェットでシェーダー解析コンテキストを設定できます。 このウィジェットから次の操作ができます：

• DirectX 11、Vulkan、Metal、OpenGL Core、OpenGL ES、または DirectX 11 feature level 9.x などのグラフィックス API を選択できます。

• デスクトップとモバイルのプラットフォームシンボルを切り替えます。

• #pragma shader_feature および #pragma multi_compile ディレクティブで宣言されているシェーダーキーワードの有効化または無効化ができます。

• 現在のコンテキストまたはすべてのコンテキストで有効化されたキーワードをリセットします。

例えば、 DirectX 11 を選択すると、Rider が SHADER_API_D3D11 シンボルを定義済みとみなし、 #if SHADER_API_D3D11 内はアクティブコードとして解析され、構文ハイライトやインスペクションが適用されます。 バルカン へ切り替えると、 SHADER_API_D3D11 はアクティブではなくなり、該当プリプロセッサブランチも非アクティブと見なされますが、 #if SHADER_API_VULKAN 内はアクティブとなります。

同様に、Rider はデスクトップとモバイルを切り替えて、 SHADER_API_DESKTOP または SHADER_API_MOBILE のシンボルをアクティブ化できます。

すべての既知の SHADER_ シンボルはコード補完ポップアップに表示されます：

キーワードのハイライト表示

Rider はシェーダーキーワードをハイライトし、現在のバリアントがコード解析にどう影響するかを示します：

• 有効なキーワード は明示的に選択したためアクティブです。

• 暗黙的に有効化されたキーワード は、Unity のセマンティクスでキーワード設定にデフォルトキーワードが必要なためアクティブになります。

• 無効化されたキーワード は現在のバリアントではアクティブではありません。

• 抑止されたキーワード は選択されていますが、同じキーワード設定内の他のキーワードが優先されているため非アクティブです。

以下の #pragma ディレクティブは、 BLUE、 RED、 GREEN シェーダーキーワードを宣言します。 これらのキーワードは、 Shader.EnableKeyword API などを使って実行時に有効化できます（詳細は シェーダーキーワードのドキュメント参照）。

#pragma shader_feature _ BLUE RED GREEN

これらのキーワードはプリプロセッサー定義シンボルでもあり、Rider はシェーダーバリアントウィジェットからこれらを有効化し、その後、該当するプリプロセッサブランチを処理します。 キーワードが有効になると、太字と下線でハイライトされます。

#pragma 内のキーワードもハイライトされます。 さらに、 #pragma 内やシンボルが使用されている場所ならどこでも、 Alt+Enter のコンテキストメニューからキーワードの有効化または無効化も行えます。

注意点: Unity では複数のキーワードを有効化できますが、pragma ディレクティブ内の最初のキーワードのみがアクティブとして扱われます。 その他のキーワードはすべて抑制され、アクティブにはなりません。 Rider では抑制されたキーワードに取り消し線が表示され、シンボルは定義されません。 Rider では、コード内で複数の競合するキーワードを有効化したり、同じキーワードを複数のプラグマで定義したりできるため、プラグマ内の他のキーワードは自動で無効化されません。 抑制されたキーワードに対して Alt+Enter メニューを使用すると、そのキーワードが抑制される原因となっているキーワードを無効にできます。

ブランチが非アクティブな場合、Rider は Code Vision のヒントで他のシェーダーバリアントではアクティブになる可能性を示します。 ヒントをクリックするとシェーダーキーワード構成ポップアップが開きます：

共有 HLSL インクルードのコンテキスト切り替え

.hlsl シェーダーファイルでは、プリプロセッサーシンボルと #if ステートメントを使用して、メソッドやデータ構造の定義、利用可能性、実装を変更することで、コンパイル時に動作を変更できます。 これらのファイルを解析する場合、Rider はデフォルトで、デフォルト定義シンボルの自動コンテキストを使用します。 これにより、 .hlsl ファイルのセクションが 構文ハイライトなしで非アクティブとしてマークされる可能性があります (コード補完、 インスペクションなど)。

.hlsl ファイルが複数の .shader ファイルから、または .shader ファイル内の複数の CGPROGRAM ブロックからインクルードされている場合、Rider はインクルードポイントで定義されたコンテキストで .hlsl ファイルを解析できます。 エディター右上の コンテキスト ウィジェットでコンテキストを切り替えられます。

例: FOO シンボルが定義されているかどうかで異なるメソッドを定義する example.hlsl ファイルがあるとします。 自動コンテキストでは、Rider はデフォルトで FOO が未定義であるとみなし、この #if ステートメントの最初のブランチを非アクティブとしてマークします。 bar 関数はこのコンテキストで定義されており、 foo 関数を使用しようとすると、未解決のシンボルエラーが発生します。

また、複数のシェーダープログラムを定義し、各 CGPROGRAM ブロックから example.hlsl を複数回インクルードする Foo.shader ファイルがあると仮定します。 各シェーダープログラムには独自のコンテキストがあります。 最初のものは 14 行目から始まり、 FOO というシンボルを定義してから example.hlsl をインクルードします。一方、2 番目のプログラムは 22 行目から始まり、 BAR を定義し、その後 HLSL ファイルをインクルードします。

example.hlsl を編集する際、コンテキストピッカーをクリックしてポップアップからシェーダープログラムの場所を選択することで、コンテキストを切り替えることができます。 Rider は自動コンテキストを表示しますが、 example.hlsl を含む場所も一覧表示します。 Foo.shader:14 を選択すると、Rider は Foo.shader の 14 行目にある CGPROGRAM シェーダーのコンテキストを使用して example.hlsl ファイルを解析します。 つまり、 FOO シンボルが定義され、上記の #if ステートメントの最初のブランチがアクティブになり、 foo 関数が定義されます。

シェーダーおよびパスの命名サポート

Rider は ShaderLab ファイル内で宣言されたシェーダーおよびパスの命名に対してコードインサイトを提供します。 Shader ブロックで宣言されたシェーダー名は フォールバック コマンドで解決され、パス名は UsePass コマンドで解決されます。 Rider ではこれらの参照に対して補完、 Ctrl+B ナビゲーション、 Alt+F7、 Shift+F6 などが利用できます。 パス名をリネームすると、Rider は UsePass 参照が指定の大文字フォーマットになることを保証します。

シェーダー名は C# コード内でも解決されます。 C# スクリプトで Shader.Find を使うと、Rider でシェーダー名の補完・ナビゲーション・使用箇所検索・リネームが可能です。

HLSL 機能

Rider は ShaderLab 内の HLSL コードや単体の HLSL インクルードファイルにも追加機能を提供します：

• Rider は #pragma surface および #pragma vertex ディレクティブ内のメソッド名を解決し、参照先メソッドが宣言されていない場合はエラーをハイライトします。

• #pragma ディレクティブのパラメーターに対してコード補完が利用可能です。

• パッケージ 仮想フォルダーは #include ステートメントでサポートされており、プロジェクトパッケージやパッケージキャッシングからファイルの補完やナビゲーションができます。

• UNITY_VERSION という定義済みマクロが解析時に認識されます。 マクロにマウスオーバーすると、プロジェクトで使用している Unity バージョンに基づく現在の値が確認できます。

シェーダーコードのナビゲート、検索、リファクタリング

Rider はシェーダーファイルおよびシェーダー関連 HLSL コードのセマンティックモデルを構築します。 アクティブな解析コンテキストに応じて、次の内容が有効化されます：

• シェーダー参照から宣言へのナビゲーション Ctrl+B

• 対応するシェーダーシンボルの使用箇所検索 Alt+F7

• シェーダー及び HLSL シンボルのリネームリファクタリング Shift+F6

• ShaderLab コマンドのクイックドキュメント Ctrl+Q

• Search Everywhere でのシェーダーシンボルやファイルの検索結果

• ShaderLab 構造のパンくずリストでナビゲーション

#if、 #ifdef、 shader_feature、 multi_compile のブランチに依存するシェーダーコードの場合、まず有効なバリアントを確認してください。 ナビゲーションと解析は現在選択されている シェーダーコンテキストに従います。

Frame Viewer でシェーダーをデバッグ

フレームビューアーツール で RenderDoc の .rdc スナップショットを IDE で直接開けます。 これによりレンダリングの動作確認やグラフィックスの不具合デバッグ時に別のツールへ切り替える必要がなくなります。

Frame Viewer で次のことができます：

• .rdc のレンダリングスナップショットを開いて確認する。

• 描画コールを階層ツリーでナビゲートする。

• シェーダーソースの使用状況で描画コールをフィルターできます。

• 頂点データ、入力、出力、テクスチャを検証する。

• テクスチャプレビューを展開する。

• 選択した頂点やピクセルのシェーダーデバッグを開始する。

• ブレークポイントの設定やマッピング済みシェーダーソースのステップ実行ができる。

Rider は、可能な場合、デバッグセッションを元の ShaderLab ソースにマッピングします。これには、 .shader ファイルや .cginc インクルードファイル内のソース範囲も含まれます。 元のソースマッピングが利用できない場合は、Rider で生成するか逆アセンブル済みのシェーダーコードにフォールバックできます。

トラブルシューティング