2021/03/21 に Unity ShaderGraphの本をリリースしました。
今回は、この本の魅力を紹介したいと思います。
zenn.dev
ノードについての解説や、ノードで作れる表現の作例を紹介しています。
🍎 Sineノード｜Unity ShaderGraph CookBook vol.1【ShaderGraph 入門】
書籍では、30種以上の作例を紹介しています。
ShaderGraph単体で完結するような表現に焦点を絞っています。
作例を知りたい方は以下のページをご覧ください。
🍍 レシピ一覧｜Unity ShaderGraph CookBook vol.1【ShaderGraph 入門】
本書の作例の一部は、GitHubにて公開しています。 github.com
Unity2020.3.0f1
Universal RP 10.3.2
Unityのポイントライトの影でグリッドを出してみました。
今回はこの3Dモデルの作り方を紹介します。
グリッドを球面へ投影したようなモデルを作ります。
このモデルと点光源が地面に映し出す影はグリッドの形になります。
線分PAの長さをD, 線分PBの長さをd、球の半径をRとおいたとき、以下のようになります。
dが分かれば、投影点Bの座標が分かります。
三角形 HPA と 三角形BPHは相似なので、以下が成り立ちます。
投影点Bの座標は以下のようになります。
投影点Bの座標が求まったので、次にこれをHoudiniで実装します。
Gridノードを使ってグリッドを作成します。
PolyExtrudeノードを使ってグリッドに穴をあけます。
投影点の座標を計算して、グリッド点を球へ投影します。
vector origin = { 0, 1, 0 }; // 点Pの座標
vector p = (@P - origin); // 点Pから平面へ向かうベクトル
vector dir = normalize(p); // 正規化
float R = 0.5; // 球の半径
float D = length(p); // 点Pから平面上の点までの距離
float d = 4 * R * R / D; // 点Pから投影点までの距離
@P = origin + d * dir; // 投影点の座標で置き換える
投影したモデルは、ROP FBX Outputノードなどで3Dモデル化します。
モデルをUnityへ取り込み、点光源を置くと、影がグリッドになります。
XOR演算を利用して、市松模様を作る方法を紹介します。
今回はワールド座標のX,Z成分から市松模様を作ります。
Unity2020.2.0f1
Universal RP 10.2.2
二つのシマシマに関してXORを適用すると、市松模様が作れます
xor(a,b)は以下のような値を取ります。
| a | b | xor(a,b) |
|---|---|---|
| 0 | 0 | 0 |
| 0 | 1 | 1 |
| 1 | 0 | 1 |
| 1 | 1 | 0 |
以下のようなシェーダーグラフを組みます。
これを板ポリゴンに貼り付けると、以下のようになります。
色のX成分、Z成分はそれぞれ以下のようになっています。
ShaderGraphにはXOR演算は用意されておらず、自分で作る必要があります。 今回はXORの実装方法を3つ紹介します。
1つ目の方法はAbsを利用したXORの実装です。
abs(a-b)
X成分(横シマ)からZ成分(縦シマ)を減算すると、以下のようになります。
減算結果にAbs(絶対値)を取ると、0,1が交互に並びます。
シェーダーグラフで実装すると以下のようになります。
以下の計算式でXORを作ることができます。
x * (1 - z) + (1 - x) * z
3つ目の方法は、Moduloを使ったXORの実装です
fmod(a+b, 2.0)
X成分とZ成分を足し合わせると、以下のようになります。
2で割った余りを計算すると0と1が交互に並びます。
シェーダーグラフで実装すると、以下のようになります。
Unityのシャドウマッピングについて、調べてみたものをまとめてみようと思います。
Unity2020.2.0f1
Universal RP 10.2.2
シーンに緑色のDirectional Lightを置くと、以下のようになります。
光が当たった領域は緑色になりますが、影の領域には色を与えません ( = 真っ黒になります)
Unityでは、「ある領域が影になっているかどうか」の判定にシャドウマップを利用します。
点光源を例に見てみます。
点光源から、シーンのオブジェクトに最も近い点までの距離を求め、それをテクスチャ(シャドウマップ)に保存します。
テクスチャは0 ~ 1 までの値しか保存できないので、範囲[0, maxDistance] を [0, 1] へ変換したものをテクスチャに保存します。
影の最大距離(maxDistance) はURP の Pipelineアセットの Shadows の部分から設定できます。
カメラで描画しようとしている点とライト間の距離D、シャドウマップに保存されている距離dを比較して、影かどうかを判定します。
ちなみに、MainLightのシャドウマッピングは Universal RP パッケージ内部の MainLightShadowCasterPass.cs にて実装されており、実装の内容を見ることができます。
以下のようなシーンを作成して、シャドウマップを見てみます。
DrawOpaqueObjects パスからシャドウマップを Ctrl + 左クリックすることで、シャドウマップを確認することができます。
今回は以下のようなシャドウマップが確認できました。
このシャドウマップは、カスケードシャドウマップになっています。
Universal RP の 中を見ると、シャドウマップを利用している処理を見ることができます。
Shadows.hlsl の中身を見ると、シャドウマップをサンプリングしている関数があります。
half MainLightRealtimeShadow(float4 shadowCoord)
{
#if !defined(MAIN_LIGHT_CALCULATE_SHADOWS)
return 1.0h;
#endif
ShadowSamplingData shadowSamplingData = GetMainLightShadowSamplingData();
half4 shadowParams = GetMainLightShadowParams();
return SampleShadowmap(TEXTURE2D_ARGS(_MainLightShadowmapTexture, sampler_MainLightShadowmapTexture), shadowCoord, shadowSamplingData, shadowParams, false);
}
上記のMainLightRealtimeShadow関数は、 Lighting.hlsl にて利用されています。
Light GetMainLight(float4 shadowCoord)
{
Light light = GetMainLight();
light.shadowAttenuation = MainLightRealtimeShadow(shadowCoord);
return light;
}上記のGetMainLight関数は URP の PBRシェーディングを行う関数 UniversalFragmentPBRの中で利用されています。(場所はLighting.hlslです)
Light mainLight = GetMainLight(inputData.shadowCoord, inputData.positionWS, shadowMask);
#if defined(_SCREEN_SPACE_OCCLUSION)
AmbientOcclusionFactor aoFactor = GetScreenSpaceAmbientOcclusion(inputData.normalizedScreenSpaceUV);
mainLight.color *= aoFactor.directAmbientOcclusion;
surfaceData.occlusion = min(surfaceData.occlusion, aoFactor.indirectAmbientOcclusion);
#endif
MixRealtimeAndBakedGI(mainLight, inputData.normalWS, inputData.bakedGI);
half3 color = GlobalIllumination(brdfData, brdfDataClearCoat, surfaceData.clearCoatMask,
inputData.bakedGI, surfaceData.occlusion,
inputData.normalWS, inputData.viewDirectionWS);
color += LightingPhysicallyBased(brdfData, brdfDataClearCoat,
mainLight,
inputData.normalWS, inputData.viewDirectionWS,
surfaceData.clearCoatMask, specularHighlightsOff);
UnityのLinearワークフローとGammaワークフローについて、軽くまとめてみようと思います。
Unity2020.2.0f1
Universal RP 10.2.2
突然ですが、ここで問題です。
フラグメントシェーダーで 0.5 ( RGB = (128, 128, 128 ) ) という色を返した場合、
画面にはどんな色が表示されるでしょうか？ (Linearワークフロー)
fixed4 frag (v2f i) : SV_Target
{
return 0.5;
}
RGB = (188, 188, 188) が表示されます。(明るく表示されます)
表示色が異なる理由はLinearワークフローにあります。
通常のUnityでは、Linearワークフローが採用されており、以下のような計算を行います。
sRGBテクスチャが画面に表示される流れは以下のようになります。
1. sRGBテクスチャはサンプリング時にLinear色空間へ変換される (逆ガンマ補正)
2. シェーダーではLinear色空間で計算を行う
3. 色の計算結果はsRGB色空間へ変換してから画面に表示する(ガンマ補正)
テクスチャは、デフォルトではsRGBにチェックが入った状態になっています。
sRGBのチェックが入っていると、そのテクスチャはsRGB色空間にあるものとして扱われます。
テクスチャのsRGBのチェックを外すと、Linear色空間のテクスチャとして扱われるようになります。
Linear色空間のテクスチャは、テクスチャサンプリング時に逆ガンマ補正がかからなくなります。
画面に表示される際にはガンマ補正がかかります。
結果として、テクスチャは明るく表示されるようになります。
UnityのPlayerSettingsには Color Space という設定項目があります。
ここがLinearの場合、UnityはLinearワークフローでレンダリングを行うようになります。
Gammaだと、UnityはGammaワークフローでレンダリングを行うようになります。。
Gammaワークフローでは、色が画面にそのまま表示されるようになります。(Linearワークフローだとガンマ補正がかかっていました)
Gamma ワークフローでは、テクスチャの色はそのままシェーダーに取り込まれ、シェーダーの計算結果もそのまま画面に表示されます。
Compute Shader で何かを作るシリーズ 第二弾！
今回は、Compute Shader で ノーマルマップ(法線マップ)を作ってみたいと思います。
ノーマルマップとは、3Dモデルの法線情報を画像に保存したものです。
平面メッシュにノーマルマップを適用することで、あたかも凹凸が付いているように陰影をつけることができます。
Unityは物体をレンダリングするときに、物体表面の法線を見て凹んでいるかどうかを判断しています。
(法線は黄色の線で表示しています)
ノーマルマップを使うと、物体の法線を再現することができ、陰影をつけることができます。
Unityは物体をレンダリングするときに、物体の法線を見て凹んでいるかどうかを判断しています。
そのため、法線がバラつくとあたかもその面には凹凸が付いているかのように陰影が付くわけです。
今回、以下のような高低マップ(Heightマップ)から法線マップを作りたいと思います。
以下のような法線マップを作ります。 (下記テクスチャはSubstance Designer で作ったノーマルマップになります)
今回は中心差分法を利用して、Heightマップから勾配を求め、そこから法線を計算します。
求めた法線情報はテクスチャ(ノーマルマップ)に保存します。
ここで、連続な曲線 f(x) 上の接線(勾配)を求めることを考えます。
ある点での接線の傾き(勾配)は、以下の式で近似できます。(中心差分法)
参考 : http://www.icehap.chiba-u.jp/activity/SS2016/textbook/SS2016_miyoshi_FD.pdf
Hiehgtマップの座標(x,y)に保存されている高さ情報をf(x,y)とすると、以下のような図になります。
中心差分法を利用すると二つの勾配ベクトル ,
を求めることができます。
#pragma kernel CSMain
RWTexture2D<float4> Result; // ノーマルマップの書き込み先
Texture2D<float4> HeightMap; // Heightマップ
[numthreads(8,8,1)]
void CSMain (uint3 id : SV_DispatchThreadID)
{
// Heightマップの差分
float dfx = (HeightMap[id.xy + uint2(1, 0)].r - HeightMap[id.xy + uint2(-1, 0)].r);
float dfy = (HeightMap[id.xy + uint2(0, 1)].r - HeightMap[id.xy + uint2(0, -1)].r);
// 法線
float3 n = float3(-dfx, -dfy, 2.0);
n = normalize(n);
// 範囲[-a,a]を[0,1]に変換してからテクスチャに書き込む
float a = 0.02;
n = (n / a + 1.0) * 0.5;
Result[id.xy] = float4(n, 1.0);
}
using UnityEngine; using UnityEngine.UI; public class ComputeNormal : MonoBehaviour { [SerializeField] private ComputeShader shader; // 実行するComputeShader [SerializeField] private Texture _texture; // 入力画像 [SerializeField] private RawImage targetImage; // RenderTextureを割り当てる対象のRawImage private RenderTexture _renderTexture; private int kernel; private void Start() { // RenderTexture作成 _renderTexture = new RenderTexture(_texture.width, _texture.height, 0); _renderTexture.enableRandomWrite = true; _renderTexture.Create(); // 実行したいカーネル(関数のようなもの) kernel = shader.FindKernel("CSMain"); // ComputeShaderへデータを渡す shader.SetTexture(kernel, "HeightMap", _texture); // 元となるテクスチャ shader.SetTexture(kernel, "Result", _renderTexture); // 書き込み先のテクスチャ // スレッドグループサイズの取得 uint sizeX, sizeY, sizeZ; shader.GetKernelThreadGroupSizes(kernel, out sizeX, out sizeY, out sizeZ); shader.Dispatch(kernel, _texture.width / (int)sizeX, _texture.height / (int)sizeY, 1 / (int)sizeZ); targetImage.texture = _renderTexture; } }
Unity C# で作成したメッシュをParticleSystemで使用したとき、頂点カラーの表示が壊れました。
この現象の原因の考察・および回避方法をまとめようと思います。
以下のような頂点カラーを設定すると、ParticleSystemで表示したときに頂点カラーが壊れます。
mesh.colors = colors; // Color[]
Unity 2020.2.0f1
Universal RP 10.2.2
mesh.colorsに頂点カラーを設定してメッシュを作成したとします。
mesh.colors = colors; // Color[]
頂点カラー情報は メッシュに16byte カラーとして保存されます。
このメッシュをMeshRendererで描画した際は、色が正常に表示されます。
メッシュのマテリアルにはシェーダーグラフを使用しており、頂点カラーをMasterノードとして出力しています。
このメッシュをParticleSystemで表示すると色が壊れます。
mesh.colors は Color であるのに対して、Particle Systemでは頂点カラーは Color32 として扱われていることが理由だと考えられます。
以下のように32bitカラーを設定すれば、色が壊れる現象は回避できます。
mesh.colors32 = colors32; // Color32[]
Colors32 は 4byteカラー(32bitカラー)としてメッシュに保存されます。
Unityの ParticleSystemは頂点カラーをColor32として持っているようです。
たとえばParticleSystem.csの中を見ると、ParticleSystem.startColorはColor32型で定義されています。
/// <summary> /// <para>The initial color of the particle. The current color of the particle is calculated procedurally based on this value and the active color modules.</para> /// </summary> public Color32 startColor
ドキュメントが見つからなかったので断言はできませんが、ParticleSystemはメモリ領域からColor32[ ]を読んでいると考えられます。
そして、メッシュの頂点カラー領域にColor[ ] が設定されていた場合、色が壊れます。
RGBA = (0.5, 0.5, 0.5 ,1.0) という灰色を メッシュのColorに設定したとします。
メモリ上では、以下のような32bit Float値が4つ並びます。
ParticleSystemは頂点カラーのことを Color32 だと思っているので、カラー情報を以下のように読み取ります。
1つの16byte カラーは ４つの32bit カラーとして解釈されます。
0.5という32bit float のビット列は、以下のような32ケタの2進数になります。
ParticleSystemはこれをbyte が4つ並んだRGBAカラーとして解釈し、RGBA = (63, 0, 0, 0) になります。
RGBA = (63, 0, 0, 0) は画面上では以下のような色として表示されます。
Rチャンネルが0.6だった場合も考えてみます。
0.6という32bit floatのビット列は以下のようになります。
このビット列を32bit RGBAカラーとして解釈すると、RGBA = (63, 25, 153, 154) になります。
RGBA = (63, 25, 153, 154)は画面上では以下のような色として表示されます。
Color[] を 頂点カラーに設定すると、想定とは異なる色が表示されてしまうことがわかりました。
メッシュを作成するときは以下のように32bitカラーを設定すれば、色が壊れる現象を回避できます。
mesh.colors32 = colors32; // Color32[]
単精度浮動小数点数
https://www.wikiwand.com/ja/%E5%8D%98%E7%B2%BE%E5%BA%A6%E6%B5%AE%E5%8B%95%E5%B0%8F%E6%95%B0%E7%82%B9%E6%95%B0#
【Unity】【シェーダ】小数点の精度と型の使い分けについて（float / half / fixedの話）
https://light11.hatenadiary.com/entry/2018/06/01/001008
Color と Color32 の違い
http://nakamura001.hatenablog.com/entry/20120822/1345658342