TOP › マイページTOP ›
入稿ドキュメントMAP › テクニカルガイド ›
シェーダーの半透明描画に関する注意事項

シェーダーの半透明描画に関する注意事項

出展物の外周を半透明のガラスにするデザインを多く見かけます。
しかしながら、半透明越しにメッシュを覗き見るデザインは描画不正を起こしやすく、リスクの高いデザインです。
このページではlilToonの設定を一例として描画不正の発生メカニズムを解説し、半透明の描画に関する注意喚起を行います。

この事象はUnityEditor上での動作確認や入稿シーンでの VRChat動作確認 では検出されず、実際に出展物がVketのワールドに反映された後に発生することがあります。
厳密に同じ事象ではありませんが、過去に発生した問題では「下見ワールドを最初に確認した時は問題なかったが、その後に他出展者の入稿が行われると描画不正が発生した」といった事例もあります。

そのため、Unity上での確認や下見ワールドでの確認を行っても、発生を防ぐことは難しいです。
適切に設定できていれば防げる事象ですが、下見ワールドで発生していない状況でも設定が適切とは限らないことが、この事象の難しさです。
Unityの描画処理がどのように行われ、なぜ問題が発生するかを理解し、発生リスクを低減する工夫が必要です。

半透明が描画不正となるメカニズム

重要なのは「衣装のRenderQueue」と「ガラスのRenderQueueとZWrite」の設定です。
RenderQueueは描画順を決める値です。
Unityは2500以下を「不透明」、2501以上を「半透明」として扱い、不透明はカメラに近いものから、半透明は遠いものから描画します。

ガラス側マテリアル(lilToon)の基本設定

衣装側マテリアル(lilToon)の基本設定

RenderQueueが同一の場合、カメラ(視点)とメッシュ原点の距離によって描画順が決定されます。
出展物の周囲を一周すると、ガラスのほうがカメラに近くなる視点と、衣装のほうがカメラに近くなる視点があります。
つまりRenderQueueが同一の場合は、描画順が突然入れ替わるケースがあるということです。

ZWriteは「後から描画するピクセルが描画済みの箇所よりも遠い場合は、そのピクセル描画をスキップする」という効果があります。
そのためZWriteがオンの場合には「衣装よりもガラスが先に描画されたとき、ガラスより遠くにある衣装のピクセルは描画がスキップされる」という動作を行います。
これが発生したものが冒頭のスクリーンショットでした。

lilToonの半透明は、アバター向けプロジェクトではデフォルトRenderQueueが2460ですが、ワールド向けプロジェクトではデフォルトRenderQueueが3000です。
アバター向けプロジェクトで作ったマテリアルを入稿用プロジェクトにインポートしたのか、入稿用プロジェクト内で新たに作成したマテリアルなのかでも値が異なります。
どの値が設定されているかは、実際にマテリアルのインスペクタを確認する必要があります。

解決方法(半透明)

解決案1: 出展物の衣装のRenderQueueが3000になっている場合は2460に変更する

入稿用プロジェクト内でRenderQueueが変更されてしまった場合は、元の値に直すことで事象が解消することがあります。
ただし、この案で対処できるのは出展物に設置したメッシュに限られるため、来場者のアバターに対しては解決案2以降のような対処法をご検討ください。

解決案2: ガラス側のZWriteをオフにする

ZWriteオフであれば、もしガラスのほうが先に描画されたとしても衣装の描画がスキップされることはなくなります。
この場合はガラスを貫通して衣装が見えてしまいますが、描画がスキップされて衣装が非表示になるよりは軽微な影響で済むという考えです。

解決案3: ガラス側のシェーダーをStandardに変更する

Standardシェーダーは、Rendering Mode を Transparent にするとZWriteがオフで動作します。
これにより解決案2と同じ仕組みで描画不正が解消します。

解決案4: そもそもガラスのような半透明メッシュで囲むデザインを見直す

これが最も推奨される案です。SetPassCallsも減ります。
小さな窓であれば、ガラスのメッシュが無くても、出展物全体へのデザイン上の影響は小さいと考えられます。
要素を減らす「引き算のデザイン」もご検討ください。

屈折・屈折ぼかしが描画不正となるメカニズム

前述の例はlilToonの描画モード「半透明」でのメカニズムです。
描画モード「屈折」「屈折ぼかし」は、少し異なるメカニズムで描画不正が発生します。
以下の例はVketちゃんのモデルと「すりガラス」を重ねた状態のイメージです。

屈折・屈折ぼかしは、シェーダー動作時点の画面をキャプチャし(GrabPass)、キャプチャ画像を加工して描画する仕組みです。

上の画像は「すりガラス(3000)」と「衣装(3001)」の組み合わせです。「衣装(2950)」「すりガラス(3000)」に設定しなおすことで、解消したように見えます。

しかし、追加で赤いキューブを描画すると、事象が再発しました。「衣装(2950)」と「すりガラス(3000)」は変更していません。

追加で描画した赤いキューブは、lilToonの「屈折」で、RenderQueueを2900にしたものです。
画面キャプチャは「シェーダー動作時点の画面」に対して行われる点を踏まえると、全体としては次の順番で描画が行われたことが分かります。

1. アバター素体の描画 (2000付近)
2. 屈折用の画面キャプチャ取得 (2900)
3. 赤キューブの描画 (2900)
4. 衣装の描画 (2950)
5. すりガラスの描画 (3000)

赤いキューブはテストのために意図的に配置したものですが、Vketのワールドにおいては「他出展者の入稿物」「ワールド設置物」「来場者のアバター」など多数のメッシュが同時に描画され、意図していないメッシュが同時に描画される場合があります。
そうした場合は、すりガラスのRenderQueueをどのように調整しても改善されません。

また、屈折・屈折ぼかしを通して別の屈折・屈折ぼかしを見ることは、シェーダーの仕組み上できません。
ここまでの画像はVketちゃんのモデルで検証した例ですが、来場者のアバターが相手でも同じことが起こります。

こういった「出展物単体ではなく、配置されるワールドや来場者のアバターまで想定しないと問題を発見できない」点が、描画不正の難しいところです。

解決方法(屈折・屈折ぼかし)

解決案1: 消えると困る部分(下着など)には屈折・屈折ぼかしシェーダーを使用しない

通常の半透明に留めておけば、RenderQueueを2460に設定することで、屈折・屈折ぼかしシェーダーによってメッシュが消されるのを防ぎやすくなります。

解決案2: すりガラス側のシェーダーを見直す

シェーダー動作時点で画面キャプチャするため、すりガラス側にlilToon以外のシェーダーを用いる案が考えられます。
ただし他のシェーダーに単純に変えても別の描画不正を招きやすいことから、解決案としては積極的には推奨できません。

解決案3: そもそもガラスのような半透明メッシュで囲むデザインを見直す

これが最も推奨される案です。SetPassCallsも減ります。
屈折・屈折ぼかしではなく半透明に変更するだけでも大幅に改善されますが、「メッシュを通して他のメッシュを確認する」というデザインに改善の余地があります。

さいごに

このページでは、描画不正のなかでも特に影響の大きい「出展物や来場者の衣装が消えてしまう問題」に絞って解説しました。
半透明のRenderQueueを単純に2460にしてしまうと、スカイボックスよりも先に描画されるため、その描画と干渉してしまうなど、問題は他にも存在します。

「半透明は問題を起こしやすいので、可能な限り使用しない」 という方針もご検討いただくと、トラブルを避けやすくなります。

付録: lilToonのデフォルトRenderQueue

関連リンク

公式ガイドラインの確認

入稿前に、必ず出展ガイドラインと入稿ルールを確認してください。入稿の手順は入稿ガイドをご覧ください。

• Vket 2026 Winter出展ガイドライン
• Vket 2026 Winter入稿ルール
• Vket 2026 Winter入稿ガイド
• 描画負荷(SetPassCalls/Batches)削減ノウハウ
• テクニカルガイド / 入稿Tips 一覧

↑ ページ上部に戻る