Unity グラフィック メモ1
メモしたのを書きなぐります
・2D Pixel Perfect
ドットバイドット表現が簡単に表現できる
さまざまな解像度でピクセル アートをくっきりと鮮明に保ち、動きを安定させる。
これは、Unity が解像度の変更に合わせてビューポートをスケーリングするために必要なすべての計算を行う単一のコンポーネントであるため、手動で行う必要はない。
参照サイト、参照サイト
・2D Tilemap Extras
Tilemapを使用する際に役立つ
参照サイト、参照サイト、参照サイト
・2D PSD Importer
Photoshopで作成したスプライトをレイヤー分けされた状態でUnityに引き込める
参照サイト、参照サイト
・SpriteShape
Spriteの形を簡単に変形でき、それに沿ったコライダーの配置なども可能
参照サイト、参照サイト
・Auto Graphics APIを調整してVulkanを使用する
参照サイト、参照サイト
・Color Gamutで色域を決定する
参照サイト、参照サイト
・ネイティブカメラの画像を取得
参照サイト
・Realtime Reflection Probesで、リアルタイムのリフレクションプローブを一括で有効・無効にする
参照サイト
・Anisotropic Texturesで、異方性フィルタリングを無効にするのか、テクスチャ毎に設定するのか、常に有効にするのか設定
参照サイト
・URPでソフトパーティクルを使用
ただ、深度テクスチャが必要で負荷がかかる
参照サイト、参照サイト
・Lod Biasで、LODが切り替わるカメラ距離を調整
参照サイト
・実機でカスタムシェーダを表示させるとピンク色になる
参照サイト、参照サイト
・FBX Exporter
Unity上から、メッシュやマテリアルをFBX形式にエクスポートし、Bleder内などで使用できるにする
参照サイト
・AR Foundation
AR開発する際に必要なもの
・ARKit Face Tracking
自分の顔を認識して、画面にモデル表示させたり、表情によってモデルの表情も変える
参照サイト
・ARのゲームを作成する際に必要なファイルフォーマットUSD
参照サイト
・Live Capture
バーチャルプロダクションをUnityエディタ上で行える
・プリレンダリングのムービーなどを流すときは、VideoPlayerを使用する。
昔はMovie Textures、Handheld.PlayFullScreenMovieなどで対応していたが、色々問題があるので、現在はVideoPlayerが主流。
参照サイト、参照サイト
・テクスチャのCompressionの圧縮を使用すると、画像のデータが圧縮され、オリジナルの画像の精度が若干失われる。圧縮すると、一部のピクセルの色が変わり、場合によっては色全体に変化が生じるため、この点に注意することが重要。
なお、色数が少なく、スプライトが小さいほど、圧縮によって生じる視覚的な変化が大きくなる。
参照サイト
・テクスチャのMax Sizeは、縦か横、片方の辺の長さだけがMaxSizeを超えている場合は、長辺がMaxSizeと同じになるように縮小される。
なのでMaxSizeを減らした方が容量削減になるが、大きく表示したい画像のMaxSizeを下げるとぼやける（小さい画像を拡大表示することになる為）ので上手いこと調節する必要がある。
また、プラットフォームやそのバージョンによってMaxSizeが正しく適用できない。
ただ、iPhone 4S ～とAndroid 4.0 ～なら、4096x4096に対応している。
参照サイト参照サイト(https://teratail.com/questions/164185)、参照サイト、参照サイト
・Sprite Renderer、Tilemap Renderer、Sprite Shape Renderer のソート順
また、個別にSorting LayerやOrder in Layerを設定しなくても親にSorting Groupをアタッチすることで、まとめることができる。
参照サイト
、参照サイト、参照サイト、参照サイト、参照サイト
・9スライス
9 スライスは、同一の画像を、複数のアセット を用意することなく様々なサイズで再利用できるようにする 2D 手法。画像を 9 分割することで、スプライトのサイズを変更した際に、各部をそれぞれ異なる形で拡大・縮小あるいはタイリング（格子状に並べる）でき、スプライトの比率が維持されるようになる。これは、例えば 2D 環境における壁や床などの、パターンやテクスチャーを作成する際に便利。
参照サイト、参照サイト
・Sprite EditorのSecondary Texturesを使用して、スプライトの任意の箇所を光らせたり、シェーディングを行う。
参照サイト、参考動画の31:30～
・マスク処理
①Image(uGUI)
Maskコンポーネント、RectMask2Dコンポーネント、UnmaskForUGUIライブラリ(一部だけ押せるボタンなども可能)などを使用
②Sprite
SpriteMaskコンポーネントや、 Sorting Groupで使用
参照サイト、参照サイト、参照サイト、参照サイト
・2つのスプライトアトラスがあり、どちらのスプライトアトラスにも同じスプライトがあった場合、スプライトを表示させる時はランダムにスプライトアトラスのスプライトを表示させてしまう。
なので、これを防ぐためには、以下の手順に従う。
１．両方のスプライトアトラスの ‘Include in Build’ を無効にする。
２．SpriteAtlas.GetSpriteを使用する。
using UnityEngine;
using UnityEngine.U2D;
public class SpriteAtlasTest : MonoBehaviour
{
public SpriteAtlas atlas;
public SpriteRenderer m_SpriteRenderer;
void Start()
{
Sprite m_sprite = atlas.GetSprite("oldwoman_85");
m_SpriteRenderer.sprite = m_sprite;
}
}
・LightAnchorで、ライトの位置・回転を手軽に調整する
参照サイト
・Stable Fit Shadow ProjectionとClose Fit Shadow Projection
カメラの距離に応じて、影の品質を変わるもの。
URPは、Stable Fit Shadow Projectionのみ対応
参照サイト、参照サイト
・ShaderGraphのTriplanarノードでスケールした際にテクスチャが伸びないようにする
参照サイト
・ビルトイン、URP、HDRPの仕様差異
参照サイト、参照サイト
・レンダリング パイプライン アセットをスクリプトから切り替える方法
参照サイト
・Indirect Multiplierで間接光の強さを変える
①Indirect Multiplierが0.3
②Indirect Multiplierが1
③Indirect Multiplierが3
参照サイト
・Culling Maskで、あるオブジェクトのシェーデイングと落ち影の有無を決める。
あるオブジェクトのLayerをPlayerとする。
見た感じ間接光は変わらない。
①Culling Maskで、Playerを選択
シェーデイングと落ち影がある
②Culling Maskで、Playerを選択しない
シェーデイングと落ち影がない
参照サイト
・URPのRender Modeで、ImportantやNot Importantで変更加えても見た目が変わらない（ビルトインは変わった）
①Important
②Not Important
参照サイト
・Baked Shadow Angle、Baked Shadow Radiusでソフトシャドウのばかし具合を調整する機能であるが、ModeがBakedで、staticオブジェクトでないと調整できなかった。
参照サイト
・αチャンネルで、クッキーの明るさを制御する
参照サイト
・SpotLightのInner/Outer Spot Angelで、半影を調整する
①Inner/Outer Spot Angelが、40.1/40.1
②Inner/Outer Spot Angelが、25.4/40.1
参照サイト、参照サイト、参照サイト
・AreaLightで他の種類のライトと比べてシェーディングが柔らかく繊細にする
ただ、負荷が高いのとURPではBakeしかできない。
参照サイト、参照サイト、参照サイト
・ライトの光と間接光を与えるオブジェクトの色を正しくしないと間接光や直接光は反映されない
参考動画、参照動画の17:00
・色環上で補色関係にあるものどうしを混ぜると白くなる
参照動画の20:20
・各ライトの減衰特性
参照動画の21:10
・光の種類は、ライト、エミシッブオブジェクト、環境光（SkyBox）
参考動画
・Sun Sourceでライト指定し、指定したライトの回転に合わせて太陽の位置や、Skyboxの空の様子を変える。
①Sun Source指定なし
Sun Sourceを指定しないと、シーン内で最も明るい指向性ライトを太陽と見なす。
②Sun Source指定あり
Sun Sourceを指定すると、指定したライトの回転に合わせて太陽の位置や、Skyboxの空の様子を変える。
③Procedural Skyboxではない
Procedural Skyboxでないと、指定したライトの回転に合わせて太陽の位置や、Skyboxの空の様子を変わらない。
参照サイト
・Realtime Shadow Colorで、影の色を変える
なお、これを行えるのは検証したところ、下記表の赤枠で囲った箇所のみ
参照サイト、参照サイト
・Environment Lighting（環境光)のSourceの、Skybox、Gradient、Colorを検証
①Skybox
Gradient より正確なライティングが得られるっぽい
②Gradient
上、下、横から別々の色を適用しブレンドさせる
③Color
全体に均一な色は反映
参照サイト
・同じライトやエミシッブでも、Intensity Multiplierで環境光を調整して明るさに変化を加えることができる
参考動画、参照サイト
・まっくらにしたいけどそうならない場合は、SkyBoxなどの環境光があるため
なのでSkyBoxMaterialを設定しないことや、Intensity Multiplierを0にすることでまっくらにできる。
参考動画
・Environment ReflectionsのSourceの、Skybox、Customを検証
①Skybox
Skybox Materialに設定されている環境光をリフレクションさせる。
②Custom
CubemapとRenderTextureのCubeを使用することで、環境光をリフレクションさせる。
参照サイト
・Environment ReflectionsのIntensity Multiplierの検証
環境光のリフレクションの度合いを調整できる。
①Intensity Multiplierが1
②Intensity Multiplierが0.2
参照サイト
・Environment ReflectionsのBouncesの検証
リフレクションされているオブジェクトが複数あった場合、リフレクションされているオブジェクトが黒く描画されることがある。Bouncesを調整することで回避できる。
①Bouncesが1
②Bouncesが5
なお、リフレクションされていないオブジェクトの場合そもそも黒くならない
リフレクションされていないオブジェクトとは、URPのLitシェーダでいうと、MetalicMapやSmoothnessの値が0に近いときや、Environment Reflectionsにチェックが入っていないオブジェクトのことである
下記が、Environment Reflectionsにチェックが入っていない状態の、Bouncesが1のときである
確かに、黒くなっていない
参照サイト、参考サイト
・部屋の中などは、環境光だけでなくリフレクションプローブも使用してライティングを表現したほうが良い見た目になる
参考動画
・FogのLinear、Exponential、Exponential Squaredの検証
Modeを変更することでフォグのかかり方を変えることができる。
なおこのFogは、この機能は各ピクセルに対して機械的にカラー値をブレンドする物で、実際の霧（あるいは大気散乱）の現象を模しているわけではない点に注意。
また、この機能では背景色とフォグ色とのブレンドは行われない。
①Linear
なお、StartとEndでフォグがかかる位置を調整でき、この両者の差が小さいほどフォグがかかり始める距離が近くなる。
②Exponential
Densityを変更することで、フォグがかかる位置を調整できる。
③Exponential Squared
Densityを変更することで、フォグがかかる位置を調整できる。
参考サイト、参考サイト、参考サイト
・Halo効果は、URPには適用できないのでLens Flare(SRP)コンポーネントとLens Flare(SRP)アセットを代わりに使用する。
なお、Lens Flare(SRP)アセットを自分で一から作成するのもいいが結構難しい。
URPのサンプルのそれがあるのでそれを使用するのもおすすめ。
なお、Halo Texture、Halo Strength、Flare Fade Speed、Flare Strengthをいじってみたが特に変化がなかった。
参照サイト、参照サイト、参照サイト、参照サイト
・影の品質調整
①Directional Lights
MaxDistanceの範囲が広ければ全体の品質は悪くなり、狭ければ品質が良い
カスケードを使用するとカメラからの距離に応じて品質を変更できる。
②SpotLight
Inner/Outer Spot Angelで調整
③PointLight
ライトとオブジェクト間の距離で決まる
参考動画
・Baked、Baked GI、RealTime、Mixedなどの分かりやすい図
参照サイト
・GIの対象にするかの判断事項
ライトのベイク/事前計算は比較的遅いプロセスなので、凹面やセルフシャドウなど、明確なライティングの変化を伴う大規模で複雑なアセットのみを “Contribute GI” としてマーク付けすべきです。均一なライティングを受ける小さい凸状のメッシュは “Contribute GI” として扱うべきではありません。したがって、よりシンプルなライトの近似を格納する ライトプローブ から間接光を受ける必要があります。大きい動的オブジェクトは、より局部化された間接光を受けるために LPPV を使用することができます。シーン内で “Contribute GI” とマーク付けするオブジェクト数を制限することは、適切なライト品質を維持しながらベイク時間を最短にするためにとても重要
参照サイト
・RealTimeGIとBakedGIをそれぞれ使用することはあまり推奨しない。
これらの機能を同時に有効にすると、同じデータセットを使用しないため、ベイク時間やランタイム時のメモリ使用量が大幅に増加します。ベイクした間接光とEnlighten Realtime Global Illuminationで提供される間接光は、ベイクに使用するライトマッパーに関係なく、視覚的に違いがあることが予想されます。
これは、Enlighten Realtime Global IlluminationがUnityのベイクバックエンドと大きく異なる解像度で動作し、間接照明をシミュレートするために異なるテクニックに依存しているためです。
したがって、ほとんどのプロジェクトでは、2つのグローバル・イルミネーション・システムのうち1つを選択する方が安全な戦略であると言えます。両方のシステムを使用することは、ほとんど推奨されません。
ある照明方法を別の照明方法よりも選択したい場合は、プロジェクトの性質と目的のハードウェアのパフォーマンス機能によって異なります。たとえば、ビデオ メモリと処理能力がより限られているモバイルでは、Baked GI ライティング アプローチの方がパフォーマンスが高い可能性があります。専用のグラフィックス ハードウェアを備えた「スタンドアロン コンピュータ」、または最近のゲーム コンソールでは、Precomputed Realtime GI を使用したり、両方のシステムを同時に使用したりすることさえ可能です。
どのアプローチを採用するかの決定は、特定のプロジェクトの性質と目的のターゲット プラットフォームに基づいて評価する必要があります。さまざまなハードウェアを対象とする場合、多くの場合、必要なアプローチを決定する最もパフォーマンスの低いものであることに注意してください。
・ビルトインパイプラインからURP、HDRPへの移行はコンバートする機能があるので比較的簡単であるが、独自シェーダーの場合手動で書き直す必要がある。
ただ、ビルトインパイプラインからHDRPの場合、見た目が変わる可能性がある。
また、HDRP⇔URPは、相互互換がないためライティング、マテリアル、シェーダーを手動で再処理する必要がある。
参照サイト
・RealTimeの特徴
ライトが増えて影響範囲がかぶると負荷が上がることが多い
間接光の表現はできないが、質感的には最も正しいことが多い（RealTimeGIで間接光の表現は可能であるが、2024 LTSあたりで廃止予定）
ランタイム計算を実行すると、特に複雑なシーンやローエンドのハードウェアで負担が高くなる場合がある。
参考動画、参考サイト、参考サイト
・Bakedの特徴
CPU負荷が低い
ライトを増やしても負荷が上がらない
Lightmap Resolutionで影の品質を上げようとすると、メモリ負荷が高くなる（ベイク時間も長くなる）
スペキュラがなくなる
ノーマルマップの効果を感じにくい（実際に試したのを後述)
ライトプローブ間が多すぎると切り替えの処理も多くなるので負荷が高くなる
複雑な計算は事前に実行されるため、ベイクしたライトはランタイムのシェーディングコストを削減し、影のレンダリングコストを削減される。
ライトのプロパティを変更しても変わらない。
参考動画、参照サイト
・Mixedの特徴
Baked Indirect→DistanceShadowmask →Shadowmask →Subtractive
左にいくにつれて、品質は下がるはパフォーマンスが良い（ただ公式ドキュメント、フォーラムだとShadowmaskが一番負荷が高いと記載されている）
ShadowMask(DistanceShadowmask)は、1オブジェクトにつ4つのライトまでしか適用されない。
4つ以上だと、ランダムにあるライトがBakedしたようになる（後述で試してみた）
ランタイムに混合ライトのプロパティを変更できる。これにより、リアルタイムのライティングは更新されるが、ベイクしたライティングは更新されない。
混合ライトのパフォーマンスコストは、ライティングモードによってかなり異なる。
ただし、混合ライトは常に、リアルタイムライトとベイクしたライトを組み合わせるため、混合ライトは常に、完全にベイクされたライティングよりもランタイムの計算が多く、完全にリアルタイムなライティングよりもメモリ使用量が多くなる。
参考動画、参照サイト、参照サイト
・ランタイムに Light プロパティを変更する場合は注意が必要。
以下公式ドキュメント抜粋
ランタイムに Light プロパティを変更する場合は注意が必要です。リアルタイムの直接ライティングとベイクした間接ライティングの非現実的な組み合わせを起こさない小さな変更のみを加えてください。例えば、赤い混合ライトをライトマップにベイクしてからランタイムにその色を緑に変更すると、直接ライティングは緑になりますが、ライトマップにベイクされた間接ライティングは赤のままです。ランタイムに混合ライトを移動する場合も同様です。直接ライティングはライトの新しい位置に従いますが、間接ライティングはライトがベイクされた位置に残ります。
・クッキーで、ライトの光をマスクしたり、コーティクスを作る
クッキーを使用することで、ランタイムのパフォーマンスへの影響を最小限に抑えながら複雑なライティングシナリオを再現したりするために使用できる。
また、以前はRealTimeとMixedしか対応していなかったが、現在ではBakedも対応されている。
Enable baked cookies supportにチェックしてベイクすれば使用可能。
参照サイト、参照サイト、参照サイト、参照サイト、参照サイト
・RealTime、Baked、Mixedのノーマルマップの質感
BakedとSubtractive以外はノーマルマップの質感が適用されていることが分かる。
①Baked
②RealTime
③Mixed
1)Baked Indirect
2)Shadowmask
3)Subtractive
・ShadowMask(DistanceShadowmask)は、1オブジェクトにつ4つのライトまでしか適用されない。
4つ以上だと、ランダムにあるライトがBakedしたようになる
①Shaded
②Baked LightMap
③ShadowMask
・Baked、RealTime、Mixedの直接光と間接光の検証
（影の挙動もModeやシャドウレシーブやシャドウキャスターの設定によって変わるので別途まとめる。）
下記表を検証してみた
①Baked
1)静的オブジェクト(static)
静的オブジェクトなので、動かすと直接光(緑)と間接光(青)が動きに合わせて反映されていないのが分かる
2)動的オブジェクト(非static)
ライトプローブは間接光を適用させるので、直接光(緑)の影響を受けていないことが分かる。もちろん間接光(青)は反映されている。
②RealTime
1)静的オブジェクト(static)
静的オブジェクトなので、動かすと間接光(青)が動きに合わせて反映されていないのが分かる。
ただ、直接光(緑)は動きに合わせて反映されていることが分かる。
また、スペキュラがあることが分かる。
2)動的オブジェクト(非static)
動きに合わせて、直接光(緑)と間接光(青)が反映されていることが分かる。
また、スペキュラがあることが分かる。
③Mixed
1)静的オブジェクト(static)
a)Baked Indirect
静的オブジェクトなので、動かすと間接光(青)が動きに合わせて反映されていないのが分かる。
ただ、直接光(緑)は動きに合わせて反映されていることが分かる。
また、スペキュラがあることが分かる。
b)DistanceShadowmask
静的オブジェクトなので、動かすと間接光(青)が動きに合わせて反映されていないのが分かる。
ただ、直接光(緑)は動きに合わせて反映されていることが分かる。
また、スペキュラがあることが分かる。
c)Shadowmask
静的オブジェクトなので、動かすと間接光(青)が動きに合わせて反映されていないのが分かる。
ただ、直接光(緑)は動きに合わせて反映されていることが分かる。
また、スペキュラがあることが分かる。
d)Subtractive
静的オブジェクトなので、動かすと間接光(青)が動きに合わせて反映されていないのが分かる。
また、直接光(緑)は動きに合わせて反映されていないことが分かる。
また、スペキュラがないことが分かる。
2)動的オブジェクト(非static)
a)Baked Indirect
動きに合わせて、直接光(緑)と間接光(青)が反映されていることが分かる。
また、スペキュラがあることが分かる。
b)DistanceShadowmask
動きに合わせて、直接光(緑)と間接光(青)が反映されていることが分かる。
また、スペキュラがあることが分かる。
c)Shadowmask
動きに合わせて、直接光(緑)と間接光(青)が反映されていることが分かる。
また、スペキュラがあることが分かる。
d)Subtractive
動きに合わせて、直接光(緑)と間接光(青)が反映されていることが分かる。
また、スペキュラがあることが分かる。
・エミシッブマテリアルの直接光と間接光の検証
①RealTime
1)静的オブジェクト(static)
直接光(白)と間接光(赤)が反映されていることが分かる。
ただ、静的オブジェクトなので動かすと反映されていないのが分かる。
また、影やスペキュラがないことが分かる。
2)動的オブジェクト(非static)
動かしても直接光(白)と間接光(赤)が反映されていることが分かる。
また、影やスペキュラがないことが分かる。
②Baked
1)静的オブジェクト(static)
直接光(白)と間接光(赤)が反映されていることが分かる。
ただ、静的オブジェクトなので動かすと反映されていないのが分かる。
また、スペキュラがないことが分かる。
また、影があることが分かる。
2)動的オブジェクト(非static)
直接光(白)は反映されていないが、動いていても間接光(赤)は反映されているのが分かる
また、影やスペキュラがないことが分かる。
③None
1)静的・動的オブジェクト(static、非static)
直接光(白)と間接光(赤)が反映されてないことが分かる。
ただ、Emissiveオブジェクトは発光している。
参照サイト、参照サイト
・ビルトイン、URPでエリアライトはBakeのみであるがエミシッブマテリアルを使用すればリアルタイムのエリアライトを疑似的に表現できる
参照サイト
・Baked、RealTime、Mixedの影の検証【その１】
下記表を検証してみた
今回は「シャドウレシーブが静的オブジェクト(static)」を検証
①Baked
1)静的オブジェクト(static)
シャドウ距離内・外で影があることが分かる。
ただ、動かすと影が動いていないことが分かる。
2)動的オブジェクト(非static)
シャドウ距離内・外で影がないことが分かる。
②RealTime
1)静的オブジェクト(static)
シャドウ距離内で影があることが分かる。
シャドウ距離外で影がないことが分かる。
動かすと影が動いてることが分かる。
2)動的オブジェクト(非static)
シャドウ距離内で影があることが分かる。
シャドウ距離外で影がないことが分かる。
動かすと影が動いてることが分かる。
③Mixed
1)静的オブジェクト(static)
a)Baked Indirect
シャドウ距離内で影があることが分かる。
シャドウ距離外で影がないことが分かる。
動かすと影が動いてることが分かる。
b)DistanceShadowmask
シャドウ距離内・外で影があることが分かる。
ただ、シャドウ距離外だと影が動いていないことが分かる。
c)Shadowmask
シャドウ距離内・外で影があることが分かる。
ただ、影が動いていないことが分かる。
d)Subtractive
シャドウ距離内・外で影があることが分かる。
ただ、影が動いていないことが分かる。
2)動的オブジェクト(非static)
a)Baked Indirect
シャドウ距離内で影があることが分かる。
シャドウ距離外で影がないことが分かる。
動かすと影が動いてることが分かる。
b)DistanceShadowmask
シャドウ距離内で影があることが分かる。
シャドウ距離外で影がないことが分かる。
動かすと影が動いてることが分かる。
c)Shadowmask
シャドウ距離内で影があることが分かる。
シャドウ距離外で影がないことが分かる。
動かすと影が動いてることが分かる。
d)Subtractive
シャドウ距離内で影があることが分かる。
シャドウ距離外で影がないことが分かる。
動かすと影が動いてることが分かる。
上は、Directional Lightでやったが、次はDirectional Light以外でやってみた
影が描画されていないことが分かる。
・Baked、RealTime、Mixedの影の検証【その２】
下記表を検証してみた
今回は「シャドウレシーブが動的オブジェクト(非static)」を検証
①Baked
1)静的オブジェクト(static)
シャドウレシーバをシャドウキャストの影の中に入ると影がうっすら描画されることが分かる。（ライトプローブの範囲だけ）
また、動かすと影が動いていないことが分かる。
今回のケースは特別で、
・シャドウをキャストするよりも小さいオブジェクトをレシーブ用に用意する
・ライトプローブをより細かい粒度で（特にシャドウキャスターの下部分に）配置する
上記を意識しないと、影が描画されない
それが下記のパターンである。
2)動的オブジェクト(非static)
シャドウ距離内・外で影がないことが分かる。
②RealTime
1)静的オブジェクト(static)
シャドウ距離内で影があることが分かる。
シャドウ距離外で影がないことが分かる。
動かすと影が動いてることが分かる。
2)動的オブジェクト(非static)
シャドウ距離内で影があることが分かる。
シャドウ距離外で影がないことが分かる。
動かすと影が動いてることが分かる。
③Mixed
1)静的オブジェクト(static)
a)Baked Indirect
シャドウ距離内で影があることが分かる。
シャドウ距離外で影がないことが分かる。
動かすと影が動いてることが分かる。
b)DistanceShadowmask
シャドウ距離内で影があり、動いていることが分かる。
シャドウ距離外でも影があるが、動いていないことが分かる。（ライトプローブの範囲だけ）
c)Shadowmask
シャドウ距離内・外でも影があるが、動いていないことが分かる。（ライトプローブの範囲だけ）
上の影だとうっすらなので、はっきりと影を描画させたい場合は、非staicシャドウキャスターを用意してShadowOnlyにすることで実現できる。
ただ、同じ位置に置いてしまうと変な見た目になるので少しずらす必要がある。
また、ハイポリにするとその分メモリの容量なども増えるのでローポリにするのが良い。
また、ドローコールも増えるので注意
参考動画の40:30
d)Subtractive
シャドウ距離内・外でも影があるが、動いていないことが分かる。（ライトプローブの範囲だけ）
上の影だとうっすらなので、はっきりと影を描画させたい場合は、非staicシャドウキャスターを用意してShadowOnlyにすることで実現できる。
ただ、同じ位置に置いてしまうと変な見た目になるので少しずらす必要がある。
また、ハイポリにするとその分メモリの容量なども増えるのでローポリにするのが良い。
また、ドローコールも増えるので注意
参考動画の40:30
2)動的オブジェクト(非static)
a)Baked Indirect
シャドウ距離内で影があることが分かる。
シャドウ距離外で影がないことが分かる。
動かすと影が動いてることが分かる。
b)DistanceShadowmask
シャドウ距離内で影があることが分かる。
シャドウ距離外で影がないことが分かる。
動かすと影が動いてることが分かる。
c)Shadowmask
シャドウ距離内で影があることが分かる。
シャドウ距離外で影がないことが分かる。
動かすと影が動いてることが分かる。
d)Subtractive
シャドウ距離内で影があることが分かる。
シャドウ距離外で影がないことが分かる。
動かすと影が動いてることが分かる。
・環境光をリアルタイムに反映させる
①Realtime Environment Lightingオン
環境光がリアルタイムで反映されているのが分かる。
②Realtime Environment Lightingオフ(Bake)
環境光がリアルタイムで反映されてないのが分かる。
参照サイト
・Ambient Occlusionの検証
これはライトマップにアンビエントオクルージョンをベイクするかどうか決める設定。
ベイクしたほうはアンビエントオクルージョンが適用されているのが分かる。
またライトマップサイズは同じで、ベイク時間はそこまで差がないのが分かる。
①ベイクしない
②ベイクする
参照サイト
・Ambient OcclusionのMax Distanceを検証
これは、AOを適用するためのレイの長さを設定する。
10のほうが、黒くなっているのが分かる。
またライトマップサイズは同じで、ベイク時間はそこまで差がないのが分かる。
①Max Distanceが1
②Max Distanceが10
参照サイト
・Ambient OcclusionのIndirect Contributionを検証
これはAOで遮蔽された空間における間接光の減衰指数を設定する。
この値が大きいとより黒くなる。
またライトマップサイズとベイク時間は同じであることが分かる。
①Indirect Contributionが1
②Indirect Contributionが10
参照サイト
・Ambient OcclusionのDirect Contributionを検証
AOで遮蔽された空間における直接光の減衰指数を設定する。
またライトマップサイズは同じで、ベイク時間はそこまで差がないのが分かる。
①Direct Contributionが0
②Direct Contributionが10
参照サイト
・Albedo Boostの検証
これはサーフェイス間で光が反射する際に乗算する係数を設定する。1.0 が物理的に正しい値になる。
値を大きくすると白くなる。
また、ライトマップサイズやベイク時間は変わらない。
①Albedo Boostが1
②Albedo Boostが10
参照サイト
・Indirect Intensityの検証
これはライトマップに保存されている間接光の輝度を 0 から 5 の値で設定する。
この値が大きいと白くなる。
また、ライトマップサイズやベイク時間は変わらない。
①Indirect Intensityが1
②Indirect Intensityが5
参照サイト
・直接光の拡散反射、直接光の鏡面反射、間接光の拡散反射、間接光の鏡面反射、環境光の拡散反射、環境光の鏡面反射を意識したライティング戦略
参照サイト
・Cast ShadowsのTwo Sidedにして、隙間のあるオブジェクトの影を正しく描画させる
参照サイト
・DistanceShadowMaskのリアルタイムシャドウとそうでない境目調整は、MaxDistanceで行う
参照サイト
・透視エイリアシング(パースペクティブエイリアシング)とは
シャドウマップを使用した影だと、ハードシャドウやシャドウマップが低解像度の場合、近くに影にジャギが入ったりする
これ解消するためには、カスケードシャドウを使用する
ただ、カスケードシャドウはディレクショナルライトでのみ機能する。
また、カスケードシャドウは、レンダリング中により多くのメモリと帯域幅を使用する。
なお、透視エイリアシングが起きるのは、下記表のシャドウマップの部分である。（当然、ライトマップやシャドウマスクでも設定次第でジャギは発生する）
参照サイト
・シャドウアクネを回避するためには、FBiasを調整すれば解決できる。
ただ、調整次第で影が離れたりして不自然な影(ピーターパニング)になったりするので注意。
参照サイト
・ビルトインの透明オブジェクトを描画するシェーダーや、ビルトインのUnlitシェーダは影がキャストされない
参照サイト
・Enlighten Baked Global Illumination は2022.2以降でUIから消えている。
①2022.3.15f
②①2022.2
参照サイト
・Enlighten RealTime Global Illumination は非推奨（ビルトインではサポートしている）
またリアルタイムGIの詳細は参照サイト参考
またLOD (Level of Detail) 機能を使用するモデルでリアルタイムグローバルイルミネーション を使用する際も参照サイト参考
参照サイト、参照サイト
・Light Probe Visualizationでライトプローブのデバッグを行う
参照サイト
・Light Explorerで、Scene内のLight、Reflection Probes、Light Probes、Emissivesの設定を変更したり、検索したりする。
なお拡張などもできる。
参照サイト、参照サイト
・UV Overlap の対処法
UV Overlap とはライトマップに展開したポリゴンのUVどうしが近すぎて対応するピクセルがかさなっている状態のことである。
これが何が問題であるかというと、明るい部分なのに影が見えるとか、暗い面なのに明るい面の情報が適用されて見た目的に不自然になる。
なのでこのUV Overlap を解消すると見た目の不自然さを解消できる。
具体的の解消方法は以下である。
①Lightmap Resolution や Lightmap Size の値を大きくする
②インポート設定の Pack Margin の値を大きくする
③Mesh Renderer の Scale In Lightmap の値を大きくする
④ライトマップ用UVを自分で作成する
参照サイト、参照サイト
・Generate Lightmap UVsについて
これをオンにすると、UnityがライトマップUVを自動生成、オフだとBlenderなどで独自作成したライトマップUVを適用させる。
なぜこの設定があるかというと、ライトマップにUV Overlap があると明るい部分なのに影が見えるとか、暗い面なのに明るい面の情報が適用されて見た目的に不自然になるのを解消するためである。
オンでライトマップUVを自動生成し、Pack Marginなどを調整してUV Overlapを解消できるが、それでもUV Overlap解消できない場合がある。
そういう場合に、オフにして独自作成したライトマップを適用させる。
なお、独自ライトマップを作成するさいの注意点を公式ドキュメントから抜粋
任意のコンテンツ作成ソフトウェアで独自のライトマップ UV を作成できます。ライトマップ UV をメッシュの 2 番目の UV チャンネルに配置する必要があります。
ライトマップ用に適切に設定された UV セットは、以下のルールに従う必要があります。
・[0,1] x [0,1] UV 空間内にある必要があります。
・個々のチャート間に十分なマージンが必要です。詳細は、UV オーバーラップ を参照してください。
・重複する面がないようにしてください。
・UV の角度と元のジオメトリの角度の差を小さくしてください。
・一部の領域のライトマップ解像度を高くしたい場合を除いて、UV の三角形の相対的なスケールと元のジオメトリの三角形の相対的なスケールの差を小さくしてください
Generate Lightmap UVsオン、オフで違いを検証してみた
確かにオンで調整した場合、チャートが変化しているのが分かる。
①Generate Lightmap UVsオフ
②Generate Lightmap UVsオン
・Generate Lightmap UVsのPack Marginについて
ライトマップにUV Overlap やライトのにじみを回避するためにこれを使用する。
メッシュレンダラーに使用するテクセル数は、Lightmap Resolution とLightmap Object Scaleの組み合わせで決まる。
UV チャートをあまり近づけて配置すると、最終的なライトマップで 隣り合うチャートのテクセルのにじみ が発生することがある。また、チャートを互いに離して配置すると、メモリが無駄になる。
なので、適切にPack Marginを設定する必要がある。
参照サイト
・Generate Lightmap UVsのAngle Error について
Angle Error が高いと、メッシュがより多くの三角形を持つ場合、角度の歪みにより形状を著しく歪ませる。
また下記画像の右側面は Area Error の値が高く、そのため、三角形が歪み、解像度が低くなり、ライトにアーティファクトが発生している。
参照サイト
・UVの重複について
ライトマップのUVが重なっていることをUV Overlapというがこの状態だと、下記画像のアーティファクトが発生してしまう。
適切なチャートの配置と間隔の決定は、いくつかのパラメーター (ライトマップ解像度、メッシュ UV、インポーター設定など) に依存するため、難しい場合がある。
解決策を公式ドキュメントから抜粋
・でライトマップの UV を提供する場合は、モデリングパッケージを使用してマージンを追加することができます。
・Unity がモデルのライトマップ UV を自動生成する場合、パックマージンを増やすように Unity に指示することができます。これを行う最も簡単な方法は、Margin Method を Calculate に設定し、適切な Min Lightmap Resolution と Min Object Scale を設定することです。Margin Method を Manual に設定したい場合は、Pack Margin の値を直接調整できます。これらの設定の詳細については、ライトマッピング UV の生成 のドキュメントを参照してください。
・ライトマップ全体の解像度を上げます。これにより、チャート間のピクセル数が増加し、にじみの可能性が減ります。欠点は、ライトマップが大きくなりすぎる場合があるということです。これは Lightmapper Settings の Lighting タブで行うことができます。
・1 つのゲームオブジェクトの解像度を上げます。これにより、重複する UV を持つゲームオブジェクトのライトマップ解像度のみを増加させることができます。一方、ライトマップのサイズを増やす可能性は低くなります。ゲームオブジェクトのライトマップ解像度は Mesh Renderer の Lightmap Settings で変更できます。
また
UVの重複を確認する方法は以下である
①Unity のコンソールで警告メッセージが表示される
以下メッセージ
There are 7 objects in the Scene with overlapping UV's. Please see the details list below or use the 'UV Overlap' visualisation mode in the Scene View or Lightmaps in Lighting Settings for more information.
②Scene (シーン) ビューで UV Overlap 描画モードを使用
③Baked Lightmaps Preview を使用
参照サイト、参照サイト
・メタパスの"LightMode"="Meta"で間接光をライトマップに反映させる
参照サイト
・ModelのNormals, Tangents, Smoothing Anglesについて
参照サイト
・MeshRenderのOptimize Realtime UVs、Max Distance、Max Angle、Ignore Normals、Min Chart Sizeについて
Realtime Global Illuminationオンの時に表示される。
リアルタイムGIは非推奨予定なのでこれらは割愛。一応詳しい内容は参照サイトを参考。
参照サイト、参照サイト
・MeshRenderのStitch Seamsについて
Stitch Seamsを使用すると、プログレッシブライトライトマッパーによって生成されたベイクしたライトマップで描画されたゲームオブジェクトの不要な尖ったエッジを滑らかにする機能。
ただ、オンにすると追加でベイク時間がかかる。
①Stitch Seamsオフ
②titch Seamsオン
上のようなアーティファクト発生する場合、Stitch Seams以外でも対処方法がある。
DCC ツールでメッシュを結合する、API によるメッシュの結合、フィルタリングとノイズ除去を無効にする、 ライトマップのパディングを増やす、 ライト プローブの使用、メッシュまたはテクスチャを使用して継ぎ目を隠すなどがある。
参照サイト、参照サイト
・減衰の計算方法を変える
参照サイト
・ライトプローブの技術的な情報
公式ドキュメントから抜粋
ライトプローブ内のライティング情報は、球面調和基底関数として符号化されます。 L2 球面調和関数とも呼ばれる 3次多項式を使用します。 これらは、各カラーチャンネルに 9 つずつ、全部で 27 の浮動小数点値を使用して格納されます。
・ライトプローブの間接光は、動的オブジェクトから最も近いプローブが 4つのライトプローブの四面体をもとに計算される。
参照サイト
・特定の状況下では、ライトプローブに輪状のアーティファクト が出る。
これは、ライトプローブの周囲のライトに大きな違いがある場合によく発生する。例えば、ライトプローブの片側に明るいライトがあり、反対側にライトがない場合などで発生する。
これを避けるために、いくつかの方法がある。以下公式ドキュメント抜粋
・Light Probe Group コンポーネントで、Remove Ringing を有効にします。Unity は意図しないライトスポットを自動的に取り除きます。ただし、これにより一般的にライトプローブの精度が低下し、ライトのコントラストが低下するため、外観の結果を確認する必要があります。
・プレイヤーがライトスポットが見える位置に到達できないような位置に、ゲーム内障害物を配置します。
・ライトプローブに直接光をベイクしないでください。直接光は、鋭い切れ目 (影のエッジなど) を持つ傾向があり、ライトプローブには適しません。間接光のみをベイクするには、混合ライティング を使用します。
・ライトプローブの配置の仕方
ライトプローブを必要以上に配置しすぎるとメモリ容量が大きくなってしまう。
なので、複雑なライトやコントラストの強いライトの領域にはライトプローブをより密なパターンで配置し、ライトがあまり変化しない領域では、ライトプローブの間隔を広げて配置すべき。
上の例では、ライトプローブは、コントラストとカラーの変化が大きいビルの近くやビル間ではより密に置かれ、道路沿いはライティングがあまり変化しないので広い間隔で置かれている。
ライトプローブを配置する最も簡単な方法は、それらを規則的な 3D グリッドパターンに配置することです。この設定はシンプルで効果的ですが、必要以上に多くのメモリを消費する可能性があり、余分なライトプローブが多く配置されることがある。例えば、上のシーンでは、道路に沿って多数のプローブが配置されていれば、リソースの無駄になる。道路の距離によってライトがあまり変化しないので、多くのライトプローブは近隣のライトプローブとほとんど同じライトのデータを格納します。このような状況では、より数の少ないライトプローブで、間隔をあけてこのライティングデータを補間する方がはるかに効率的。
参照サイト
・ライトプローブの配置のアンチパターン
①アンチパターン
車に明るいライティングが照らされていて、周囲暗いのに不自然である。
ライトプローブのライティングを受けるオブジェクトは、近くのライトプローブの光の情報を受ける。今回の配置の仕方だと暗い箇所にライトプローブがないため、明るいライトプローブの情報をもとにライティングしてしまったためである。
Bakeモードだとなおこの問題が顕著に見えてしまう。
なぜなら直接光も間接光もライトプローブをもとにライティングされるため。
RealTimeとMixedだと、直接光はリアルタイムで、間接光はライトプローブであるためそこまでこの問題が見受けられないかもしれない
②改善したパターン
ライトプローブを追加すると暗い箇所で車が暗くなっており見た目が不自然でない。
参照サイト、参照サイト
・動的 GI のためのライトプローブの配置の仕方
公式ドキュメントを抜粋
比較的変化のない 静的ライト の広い領域には、たった 2–3 のプローブを配置するだけで良い場合があります。なぜなら、そのライトは広い範囲にわたり変化しないからです。ただし、この領域内で 動くライト を使用し動くオブジェクトに対して反射光を投げようとようとする場合、この領域内でより密なライトプローブのネットワークが必要になります。そうすることにより、十分高いレベルの正確さでライトの範囲とスタイルを合わせることができます。
どのくらいの密度でライトプローブを配置するかは、ライトのサイズと範囲、移動する速度、反射光を受ける移動オブジェクトの大きさによって異なります。
・2Dのゲームでもライトプローブは、ライトプローブは 3D のボリュームを持つ必要がある。
3D のボリュームでないと、正しいライティングが計算できない
参照サイト
・MeshRenderのBlend ProbesのLight Probesについて
①Off
Offの場合、ライトプローブからは反映されず環境光が反映される
②Blend Probes
ライトプローブが適用されていることが分かる
③Use Proxy Volume
後述する（LPPVで使用する）
④Custom Provided
よくわからない
参照サイト、参照サイト、参照サイト、参照サイト
・LPPVについて
ライトプローブ利用時に大きいメッシュ使用したりすると間接光が正しくないことが起きる
LPPVを使用するとこれを防げる
使い方は、MeshRenderのBlend ProbesをUse Proxy Volumeにすればよい
なおパーティクルシステムでもできる
※URPでは対応していない
①LPPVなし
全体的に紫色になっていることが分かる。
②LPPVあり
画面奥は赤の間接光、手前は青の間接光で、正しい見た目であることがわかる。
参照サイト
・MeshRenderのAnchor Overrideについて
ライトプローブ、または リフレクションプローブ のシステムを使用する時に、補間する位置を決めるために使用する Transform を設定する。
デフォルトでは、これはメッシュのバウンディングボックスの中心点から計算される。ただし、違うゲームオブジェクトを Anchor Override フィールドに割り当てることにより、その点をオーバーライドすることができる。
使用用途は公式ドキュメント抜粋
ゲームオブジェクトが、2 つのメッシュがバウンディングボックスの位置にによって個々にライティングされ、ライティングがメッシュの継ぎ目で途切れているような隣接するメッシュを含むときに、Anchor Override が役立つ場合があります。両方のメッシュレンダラーの補間点として同じ Transform (例えば、親、または、子オブジェクトの) を使用するか、または、ライトプローブプロキシボリュームを使用することによって、これを避けることができます。
①デフォルト
②デフォルトでない
・ライトプローブとシーンのロード
①LoadSceneMode.Single
シーンが切り替わってもライトプローブが反映されていることが分かる。
②LoadSceneMode.Additive
こちらのサイトだとライトプローブが反映されていることが分かるが、自分でやってみたところ反映されなかった
参照サイト
・リフレクションプローブの実装方法
参照サイト
・リフレクションプローブのType
①Baked
ベイクしたプローブは、リアルタイムプローブよりも処理オーバーヘッドがはるかに低くなるが、ランタイムで反射が変化しない
ただ、反射させたいオブジェクトにReflection Probe Static をチェックしないとベイク対象外となる
②RealTime
Bekedと違いランタイムで反射が反映されるが、ランタイムでキューブマップを更新するため負荷がかかる。
③Custom
カスタムプローブを使用すると、3DCCツールなどで作成したキューブマップを適用できる
ただ、ランタイムで反射が変化しない
参照サイト
・リフレクションプローブのオーバーラップとImportance
リフレクションプローブ同士がかぶると、反射させたいオブジェクトとリフレクションプローブが交差している部分が大きい方が優先される。
ただ、Importanceで優先度を変えられる。
参照サイト
・リフレクションプローブのBox Projection
Box Projectionを使用すると、室内でリフレクションプローブを適用させたい場合に正しい反射を表現できる。
参照サイト
・シーンビュー描画モード
１．Shaded
実際のゲームで表示されるモード
２．Wireframe
ワイヤーフレームでメッシュを描画するモード
３．Shaded Wireframe
①と②を合わせた描画モード
４．Systems、Clustering、Lit Clustering、UV Charts(Global Illumination)
RealTimeGIのときに使用可能であるが、RealTimeGIは2024以降サポートが終了するため今回は割愛
５．Contributors/Receivers
動的オブジェクトか、静的オブジェクトでLightmapsを使用するのか、静的オブジェクトでLight Probesを使用するのかを描画するモード
①動的オブジェクト
②静的オブジェクトでLightmapsを使用
③静的オブジェクトでLight Probesを使用
６．Albedo、Emissive、Indirect、Directionality（Realtime Global Illumination）
RealTimeGIのときに使用可能であるが、RealTimeGIは2024以降サポートが終了するため今回は割愛
７．Baked Lightmap
ベイクしたライトマップを描画するモード。ベイクしていないと市松模様で描画されない。
また、LightMapResolutionによって市松の細かさが変わる。
①LightMapResolutionが4
①LightMapResolutionが20
８．Directionality
ローカルの法線方向を描画するモード
９．Shadowmask
Shadowmaskを描画するモード。Shadowmaskでない場合は表示されない。
検証した感じライトによって色分けされ、同にサーフェイスに複数ライトが当たっている場合混合色になる。
一つのライトだと単色になる。
１０．Albedo
アルベトだけを描画するモード
①通常
②Albedo
１１．Emissive
エミッシブを描画するモード
①通常
②Emissive
１２．UV Charts
チャートを描画するモード
１３．Texel Validity
よくわからない
１４．UV Overlap
UV Overlap とはライトマップに展開したポリゴンのUVどうしが近すぎて対応するピクセルがかさなっている状態のことである。
これが何が問題であるかというと、明るい部分なのに影が見えるとか、暗い面なのに明るい面の情報が適用されて見た目的に不自然になる。
なのでこのUV Overlap を解消すると見た目の不自然さを解消できる。
１５．Light Overlap
ベイクしたライトを赤色ライトで表示するモード。
ShadowMaskで使用する
参照サイト、参照サイト
・リアルタイムライトの影、鏡面反射光のハイライトが消える原因
Per Object Limitの設定値誤り
ただPer Object Limitの数を増やすと処理が重くなるらしい。
①Per Object Limitが3
②Per Object Limitが2
③Per Object Limitが0
また、RednerModeを変更することで適用させたいライトを指定できる。Importantだと計算コストはピクセルライティング、Not Importantだと計算コストは低いが頂点ライティング、Autoだとライトの強度とカメラからの相対距離をチェックしてImportantかNot Importantを判定する。Per Object Limitが1で、一つのライトだけImportantに設定してみた
多数のライトを使用したい場合は、DeferredRederingを検討してみてもいいかもしれない。
参照サイト、参照サイト
・ShadowMask時で、一部のオブジェクトは照らされておらず暗く見える。
ShadowMaskは、ライトを4つしか置けないので5つ以上置くと一部のライトはBakeしたものになる。
修正方法としては、影響を受けるライトを移動して、重ならないようにする。それ以外の場合は、 Light コンポーネントのRangeまたはSpot Angleパラメータを調整する
参照サイト
・意図しない環境光
予想される結果 (左) とスタンドアロン プレーヤー ビルドの実際の結果 (右) の比較
修正方法などは参照サイトを参照
参照サイト
・ライトマップによるぼやけた見た目
単位解像度あたり 8 テクセルでベイクされた Cornell Box シーン (左)。単位解像度あたり 32 テクセルでベイクされた同じシーン (右)。
左のようにぼやけないようにするためには、Lightmap Resolution、Scale In Lightmapを調整する。
また、影が下記のようにぼやけている場合は、均一なライトマップ UV スケールを維持することを意識する。
具体的に意識するポイントを参照サイトから抜粋してみた
・カスタム ライトマップ UV を作成するときは、UV シェルを 1 つの軸だけでスケーリングしないでください。UV シェルをスケーリングする必要がある場合は、すべての軸にわたって均一に行ってください。
・UV シェルをスケーリングするときは、アトラス全体をスケーリングします。必要でない限り、単一シェルのスケーリングは避けてください。
・エディター内のゲームオブジェクトにも同じロジックが適用されます。それらを均一にスケーリングするようにしてください。1 つの軸でオブジェクトをスケーリングすると、ライトマップ UV もストレッチされます。
・ライトマップの影のジャギ
左のようなジャギは、ライトマップの解像度が低すぎる場合に現れるアーティファクト。
これらを修正する方法は以下である
①Anti-aliasing Samplesを調整する
この値を大きくすればジャギがより見えなくなるが、ベイク時間が増える。
②Baked Shadow Angleの値を調整する
③Gaussianフィルターを適用
参照サイト
・下記のようなノイズを修正する方法はいくつかある
①Direct Samples、Indirect Samples、Environment Samplesの値を大きくする
Direct Samplesを上げるパターン
・エリア ライトで照らされたオブジェクトは、ノイズの多いソフト シャドウを生成します。
・Baked Shadow Angle の値を変更してライトをベイク処理すると、ノイズの多い結果が生成されます。
Indirect Samplesを上げるパターン
・間接照明のエリアはうるさいです。
・エミッシブ マテリアルを使用するオブジェクトは、多くのノイズを生成します。
Environment Samplesを上げるパターン
・焼き付けられた環境/HDRI はノイズの多い結果を生成します。
・これを確認するには、シーン内のすべてのライトを無効にする必要があることに注意してください。
②Denoiser、Filterを使用する
Filterの特徴は以下のとおり
・Gaussian:ライトマップにバイラテラル フィルタ (ブラー) を適用します。これにより、視覚的な忠実度を犠牲にして、ノイズが滑らかになる可能性があります。半径パラメータを増やして、フィルタリング強度を高めます。値が大きいと、アーティファクトのリークが発生する可能性があります。
・A-Trous :エッジ定義を維持しながらノイズを除去しようとするエッジ認識フィルター。サンプル数が多い場合や、ノイズ除去と併用するとうまく機能します。ノイズの多い HDR ライトマップではうまく機能しません。
Denoiserの特徴は以下のとおり
・Open Image Denoise (OIDN):Intel の機械学習デノイザー。ベンダーに依存しません。Windows、macOS、および Linux プラットフォームで動作します。
・Optix:Nvidia の機械学習デノイザー。Nvidia GPU でのみ動作します。Windows のみをサポートします。
・RadeonPro:AMD の機械学習デノイザー。ベンダーに依存しません。Windows と Linux で動作します。
・下記のようなアーティファクトを削除する方法
①Direct Samples、Indirect Samples、Environment Samplesを上げる
②Multiple Importance Samplingオンにする
③Denoiser、Filterを使用する
④エミッションマテリアルのGIをNoneにする
⑥ベイクしたライトを静的オブジェクトから遠ざける
参照サイト
・無効なテクセルのアーティファクト
下記のような赤い箇所が多いと、無効なテクセルがライトマップのむらのあるアーティファクトの原因になることがある。（描画モードでTexel Validity)
ライトマップのフィルタリングとノイズ除去は、無効なテクセルを隣接するテクセルに広げることで、この問題を悪化させる可能性がある。そのため、これから述べる修正方法で改善していく必要がある。
①メッシュの頂点の法線を外側にする(3DCCツールで行う)
②開いた面を避ける(3DCCツールで行う)
・開いている面をすべてキャップします。
・重なり合うすべての頂点を連結します。
・線と点のジオメトリは避けてください。
・ユース ケースで必要な場合を除き、フローティング ジオメトリは避けてください。
③シェーダーのRender FaceをBothにする(URPの場合)
ただ、両面グローバルイルミネーションを適用させるとアーティファクトが発生する可能性がある。
④ Lightmap Parameters のBackface Tolerance を調整する。MeshRenderのLightmap Parametersに個別設定。
ただ、いくつか気を付ける必要がある。
・値を大きくすると、ライトマッパーが背面を検出したときにテクセルを無効としてマークする可能性が高くなります。
・この値を下げると、無効化されたテクセルの数が減ります。
値が低いと、オクルージョンやバウンス ライティングが失われ、シーンの外観が変わる可能性があることに注意してください。
④メッシュをワールド座標の原点に近づけるか、Lightmap Parameters のPush offを調整
参照サイト
・下記のようなアーティファクトを削除する方法
Denoiserを使用しても以下の場合、アーティファクトを除去できない場合がある。それが以下である。
・特にノイズの多いシーンで、特にスペックル ノイズ (ホタル) が多い場合。
・膨張による薄いジオメトリとエッジの交差。
・HDR ライトマップを必要とする高輝度光源を使用する場合。
・シーンのノイズを除去するのに十分なトレーニング データがない場合。
①サンプル数を増やす
ほとんどの場合、Indirect Samplesがノイズ除去パフォーマンスの低下の最大の原因となる。
ほとんどのデノイザーは、256 サンプル以上で適切に機能する。
参照サイト
・Filterを使用しても下記画像の左のようにアーティファクトが生じる
修正方法は以下である
①Direct Samples、Indirect Samples、Environment Samplesのサンプル数を上げる
②Denoiserを使用する
③FilterのRadiusを調整する
参照サイト
・下記画像のように一部のジオメトリが光っている
修正方法は以下である
①Lightmap Resolutionを調整する
②解像度を上げることができない場合は、DCC ツールでライトマップ UV を変更する必要がある。明るい領域と暗い領域の間の継ぎ目でライトマップ UV チャートを分割する
③オブジェクトの配置を調整する
多くの場合、光漏れは積極的なフィルタリングの副産物ではなく、最適ではないオブジェクト配置の副産物である可能性があります。オブジェクトが交差したり、シーン ジオメトリからはみ出していないことを確認してください。屋内シーンでは、可能であれば片側の壁メッシュの使用を避けてください。代わりに押し出しメッシュを選択してください。
・下記画像のようなマッハバンドのようなアーティファクト
修正方法は以下である
①Lightmap Encodingを調整する
②HDR CubeMap Encodingを調整する（CubeMapはSkyboxやリフレクションプローブで使用する）
③Lightmap Compressionを調整する
④テクスチャのインポート設定でライトマップのFormatを調整する
参照サイト
・ライトプローブ使用時の輪状のアーティファクト
修正する方法は以下である
①Light Probe GroupのRemove Ringingを有効
これを有効にすると、ライトプローブにある程度のぼやけをもたらすことに注意することが重要。これにより、プローブで照らされたオブジェクトのコントラストがいくらか失われる。シーン内のライト プローブにリンギング アーティファクトが見られない場合は無効にする。
②LightのIntensityを下げる
③Mixedにする
参照サイト
・エミシッブマテリアルがたくさんある場合のライトプローブのアーティファクト
修正する方法は以下である
①Light Probe Sample Multiplierを増やす
参照サイト
・アンロードされたシーンのライトプローブ、追加ロードのライトプローブが含まれていることによるアーティファクト
修正する方法は以下である
①LightProbes.Tetrahedralizeを使用すつ
②マップのレベルデザインの調整
参照サイト
・LightmapperのMultiple Importance Samplingについて
ハイ コントラスト HDRI を使用する場合のノイズを低減します。低コントラストの環境照明を使用する場合は、このチェックボックスを無効にします。
・フォワード(Forward)レンダリングについて
１．ライトが多いと負荷が増える
２．MSAAが使用可能
３．半透明の処理可能
４．様々なハードウェアに対応
参照サイト
・ビルトインのフォワードレンダリングパスのBase Pass(FORWARDBASE)とAdditional Passes(FORWARDADD)について
参照サイト
・ビルトインのフォワードレンダリングパスのRender Modeにおける、ピクセルライト、頂点ライト、球面調和関数 (SH)ライトの決まり方
参照サイト
・ビルトインのフォワードレンダリングパスのCameraEvent と LightEvent の実行順序である
１．BeforeDepthTexture
２．Unity が不透明なジオメトリの深度をレンダリングします。
３．AfterDepthTexture
４．BeforeDepthNormalsTexture
５．Unity が不透明なジオメトリの深度法線をレンダリングします。
６．AfterDepthNormalsTexture
影をレンダリングします。
７．BeforeShadowMap
８．BeforeShadowMapPass
９．Unity が、現在のパスのすべてのシャドウキャスターをレンダリングします。
１０．AfterShadowMapPass
１１．Unity が、各パスに対して最後の 3 ステップを繰り返します。
１２．AfterShadowMap
１３．BeforeScreenSpaceMask
１４．Unity は、シャドウマップをスクリーンスペースバッファに集め、フィルタリングを行います
１５．AfterScreenSpaceMask
１６．BeforeForwardOpaque
１７．Unity が不透明なジオメトリをレンダリングします。
１８．AfterForwardOpaque
１９．BeforeSkybox
２０．Unity がスカイボックスをレンダリングします。
２１．AfterSkybox
２２．Unity がハローをレンダリングします。 BeforeImageEffectsOpaque
２３．Unity が不透明なものだけを対象にポストプロセスエフェクトを適用します。
２４．AfterImageEffectsOpaque
２５．BeforeForwardAlpha
２６．Unity が透明なジオメトリをレンダリングし、UI キャンバスを Screen Space - Camera のモードでレンダリングします。
２７．AfterForwardAlpha
２８．BeforeHaloAndLensFlares
２９．Unity がレンズフレアをレンダリングします。
３０．AfterHaloAndLensFlares
３１．BeforeImageEffects
３２．Unity がポストプロセスエフェクトの効果を適用します。
３３．AfterImageEffects
３４．AfterEverything
３５．Unity が、UI キャンバスを Screen Space - Camera 以外のモードで レンダリングします。
一応確認してみたが確かに上記の順で実行されていることがわかる。
参照サイト
・ディファード(Deferred)レンダリングについて
１．パフォーマンスはピクセル数に比例し、ライトが多くてもフォワードレンダリングと比べて負荷がかからない
２．特定のハードウェアには対応していない
Multiple Render Targets (MRT)、Shader Model 3.0 (またはそれ以降)、深度レンダーテクスチャへのサポートを伴うグラフィックカードが必要。2006年以降に作られた GeForce 8xxx、Radeon X2400、Intel G45 などをはじめとする、ほとんどの PC グラフィックスカードはディファードシェーディングをサポートする。
モバイルは、OpenGL ES 3.0 を実行するすべてのデバイスでサポートされる。
３．半透明のオブジェクトを処理できない
４．アンチエイリアスのための実際のサポートがない
５．正投影法はサポートしていない
６．ビルトインパイプラインのSingle Pass Stereo Instancingをサポートしていない
参照サイト、参照サイト
・ビルトインのディファードレンダリングパスのCameraEvent と LightEvent の実行順序である
１．BeforeGBuffer
２．Unity が不透明なジオメトリをレンダリングします。
３．AfterGBuffer
４．Unity が深度を解決します。
５．BeforeReflections
６．Unity がデフォルトのリフレクションと、リフレクションプローブのリフレクションをレンダリングします。
７．AfterReflections
８．Unity が G バッファのエミッシブチャンネルにリフレクションをコピーします。
９．BeforeLighting
影をレンダリングします。
１０．BeforeShadowMap
１１．BeforeShadowMapPass
１２．Unity が、現在のパスのすべてのシャドウキャスターをレンダリングします。
１３．AfterShadowMapPass
１４．Unity が、各パスに対して最後の 3 ステップを繰り返します。
１５．AfterShadowMap
１６．BeforeScreenSpaceMask
１７．Unity は、シャドウマップをスクリーンスペースバッファに集め、フィルタリングを行います
１８．AfterScreenSpaceMask
１９．AfterLighting
２０．BeforeFinalPass
２１．Unity が最終パスを処理します。
２２．AfterFinalPass
２３．BeforeForwardOpaque (ディファードを使用してレンダリングできない不透明なジオメトリがある場合にのみ呼び出されます)
２４．Unity がディファードレンダリングで処理できない不透明なジオメトリをレンダリングします。
２５．AfterForwardOpaque (ディファードを使用してレンダリングできない不透明なジオメトリがある場合にのみ呼び出されます)
２６．BeforeSkybox
２７．Unity がスカイボックスをレンダリングします。
２８．AfterSkybox
２９．Unity がハローをレンダリングします。 BeforeImageEffectsOpaque
３０．Unity が不透明なものだけを対象にポストプロセスエフェクトを適用します。
３１．AfterImageEffectsOpaque
３２．BeforeForwardAlpha
３３．Unity が透明なジオメトリをレンダリングし、UI キャンバスを Screen Space - Camera のモードでレンダリングします。
３４．AfterForwardAlpha
３５．BeforeHaloAndLensFlares
３６．Unity がレンズフレアをレンダリングします。
３７．AfterHaloAndLensFlares
３８．BeforeImageEffects
３９．Unity がポストプロセスエフェクトの効果を適用します。
４０．AfterImageEffects
４１．AfterEverything
４２．Unity が、UI キャンバスを Screen Space - Camera 以外のモードで レンダリングします。
一応確認してみたが確かに上記の順で実行されていることがわかる。
参照サイト
・ビルトインのフォワードレンダリングとディファードレンダリングとLegacy Vertex Lit についての比較表
参照サイト
・ビルトインのハードウェア要件
参照サイト
・色空間のリニアカラーとガンマカラーについて
１．リニアカラーはシェーダーに供給される色が、光の強度が増加するにつれて線形に明るくなる
代替の「ガンマ」色空間では、値が上がるにつれて明るさがすぐに白くなり始め、画質に悪影響を及ぼす。
２．リニアカラーはガンマカラーより、カラー計算の精度が高いので、最終的な画面出力の全体的なリアルさが向上する
３．リニアカラーはガンマカラーより幅広いプラットフォームに対応していない
参照サイト
・HDRについて
１．一部のモバイルプラットフォームではHDRは対応していない
２．MSAAを使用する場合、フォワードレンダリングは対応していない
３．ガンマカラーよりリニアカラーと組み合わせるほうが最適である
参照サイト、参照サイト
・ビルトインのコマンドバッファについて
CommandBuffer を利用するとレンダリングパイプラインを拡張して色々な表現が可能となる。
例えば、現在画面に映っているレンダーテクスチャをブラーをShaderでブラーかけて、その結果を別のシェーダーに渡して、任意のタイミングで実行できたりできる。
参照サイト
・Plnar MappingとTriplanar Mappingについて
Plnar MappingとTriplanar MappingはUVに依存せずテクスチャを貼り付けるもの
Plnar Mappingはワールド空間のy軸方向で、Triplanar Mappingはワールド空間のxyz軸方向に貼り付ける
メリットとしては、違うオブジェクト同士を重ねたときなどにテクスチャの境界で起こる不自然さを回避できる。
参照サイト、参照動画
・SRP、カスタムレンダリングパイプラインについて
参照サイト、参照サイト
・複数のカメラを切り替える
ソースコードは参照サイトを参照
参照サイト
・物理カメラ(Physical Camera)
Physical Camera (物理カメラ) は、Unity カメラで現実世界のカメラ形式のシミュレーションを行う。詳しい内容は参照サイトを参照
参照サイト
・カメラからの距離で求める視錐台のサイズ
参照サイト
・カメラからレイを飛ばしてヒットチェックしたオブジェクトの情報を取得
using UnityEngine;
//カメラにアタッチ
public class Example : MonoBehaviour
{
public Camera camera;
void Start()
{
RaycastHit hit;
// スクリーンスペースからレイを飛ばす
Ray ray = camera.ScreenPointToRay(Input.mousePosition);
// コライダーあるオブジェクトにヒットしたらtrue
if (Physics.Raycast(ray, out hit))
{
// ヒットしたオブジェクトのTrasformを取得
Transform objectHit = hit.transform;
Debug.Log("ヒットしたオブジェクトの名前は"+objectHit.name);
Debug.Log("ヒットしたオブジェクトの座標は" + objectHit.position);
}
}
}
・レイに沿ったカメラの移動
using UnityEngine;
//カメラにアタッチ
public class Example : MonoBehaviour
{
public bool zooming;
public float zoomSpeed;
public Camera camera;
void Update()
{
if (zooming)
{
Ray ray = camera.ScreenPointToRay(Input.mousePosition);
float zoomDistance = zoomSpeed * Input.GetAxis("Vertical") * Time.deltaTime;
camera.transform.Translate(ray.direction * zoomDistance, Space.World);
}
}
}
・オクルージョンカリングの、静的遮蔽物 (Static Occluder)と静的被遮蔽物 (Static Occludee)になるための条件
静的遮蔽物 (Static Occluder)は、Terrain RendererのとMesh Rendererコンポーネントがあること、不透明であること、ランタイムに移動しないことである
静的被遮蔽物 (Static Occludee)は、Renderer コンポーネントがあること、ランタイムに移動しないことである。
参照サイト
・オクルージョンカリングの LoadSceneMode.Singleでベイクする方法
LoadSceneMode.Singleでオクルージョンカリングをベイクする方法は、各シーンごとにベイクする。
その際、ベイクされたデータは、Assets/[ベイクしたシーン名]/OcclusionCullingData.asset に格納される。
また、LoadSceneMode.Singleでロードすると、読み込む前のシーンのベイクしたオクルージョンカリングのデータはアンロードされる。
参照サイト
・オクルージョンカリングのLoadSceneMode.Additiveでベイクする方法
オクルージョンカリングのLoadSceneMode.Additiveでベイクする方法は、マルチシーンでベイクする。
その際、ベイクされたデータは、Assets/[アクティブのシーン名]/OcclusionCullingData.asset に格納される。
また、LoadSceneMode.Additiveでロードしていくと、追加したシーンごとにベイクしたオクルージョンカリングのデータがロードされる。
参照サイト
・Occlusion Portalコンポーネントで、ドアのように遮蔽物になったりならなかったりする際にオクルージョンカリングを適用させる
参照サイト、参照サイト
・DLSSについて
なお、HDRPのみ対応している
参照サイト
・マルチディスプレイについて
参照サイト
・サポートされているモデルのファイル形式
Unityでは以下のファイル形式に対応している。
推奨はfbx
.fbx
.dae (Collada)
.dxf
.obj
参照サイト
・3DCGツールからオブジェクトをインポートした際のサポートしているもの
Mayaを例にあげる
１．サポートしているもの
・位置、回転、スケールのあるすべてのノード。ピボットポイントと名前もインポートします。
・頂点カラー、法線、最大 2 つの UV セット
・テクスチャとディフューズ色を持つマテリアル。各メッシュに複数のマテリアル。
・アニメーション
・ジョイント
・ブレンドシェイプ
・ライトとカメラ
・可視性
・カスタムプロパティアニメーション
２．制限
Unity は Autodesk® Maya® の Rotate Axis (事前回転) をサポートしていません。
ジョイントの制限には以下が含まれます。
・ジョイントの方向 (ジョイントのみの事後回転)
・セグメントスケール補正 (ジョイントのみのオプション)
Unity は Autodesk® Maya® で指定した Rotate Order (回転順序) をインポートしサポートします。ただし、一度インポートすると、Unity 内でその順序を再度変更することはできません。
Unity と異なる回転順序のモデルをインポートする場合は、Inspector の Rotation プロパティの横に 回転順序が表示されます。
３．ヒントとトラブルシューティング
・シーンを簡易に保つようにしましょう。エクスポートする時は、Unity で必要なオブジェクトだけをエクスポートします。
・Unity はポリゴンしかサポートしないため、エクスポートする前にパッチや NURBS サーフェスをポリゴンに変換します。詳細は、Autodesk® Maya® ドキュメント を参照してください。
・モデルが正しくエクスポートされなかった場合、Autodesk® Maya® のノード履歴が原因である可能性があります。Autodesk® Maya® で、Edit > Delete by Type > Non-Deformer History を選択し、モデルを再エクスポートします。
・Autodesk® Maya® FBX Exporter は、アニメーションを Unity に正しくインポートするために、Set Driven Key などのサポートされていない複雑なアニメーション制約をベイクします。Autodesk® Maya® で Set Driven Key を使用している場合は、アニメーションが正しくベイクされるように、ドライバーにキーを設定してください。詳細は、Autodesk® Maya® のドキュメントの「キーフレームアニメーション」を参照してください。
・Autodesk®Maya® 可視性の値は各シェイプに存在します。ただし、アニメーションにすることはできず、FBX ファイルにエクスポートされません。可視の値はシェイプ上ではなく、常にノード上に設定します。
・モデルをエクスポートする際について
参照サイト
・モデルをインポートする際について
参照サイト
Discussion