「法線マッピング」の版間の差分

(同じ利用者による、間の2版が非表示)

1行目:

'''法線マッピング'''（[[英語]]：normal ~~mapping）とは、[[バンプマッピング]]の発展形で、[[バンプマップ]]では~~[[ピクセル]]~~単位で「高さ」の情報を持つのに対して、[[法線マップ]]では[[ピクセル]]単位で「XYZの[[ベクトル]]」を持つものをいう。~~

'''法線マッピング'''（[[英語]]：normal mapping）とは、陰影処理のために「[[ピクセル]]の向いている方向」を保持するものをいう。

== 概要==

~~バンプマップなしの場合は頂点に~~[[法線]]~~を持たせ、2つの頂点の~~[[法線]]と[[~~ピクセル~~]]~~の位置から大雑把にピクセルの~~[[法線]]~~を算出する。バンプマップありの場合はこれに「高さ」をかけ合わせてもう少し精度をよく算出していた。~~

[[ピクセル]]の[[法線]]は、[[バンプマップ]]なしの場合は[[頂点]]に[[法線]]を持たせ、2つの頂点の[[法線]]と[[ピクセル]]の位置から大雑把に算出する。同様にバンプマップありの場合はこれに「高さ」をかけ合わせてもう少し精度をよく算出していた。

[[ファイル:頂点の法線からピクセルの法線を算出.png|なし|サムネイル|640x640ピクセル]]

一方、法線マッピングでは[[テクスチャマッピング]]の[[画像]]と同じ要領であらかじめピクセル単位で法線ベクトルを計算しておいた[[データ]]を用いる。つまり実行時にピクセル単位の法線を計算しないうえに、推論的なものではないので非常に精度の良いなデータになる。すばらしいね。そんなに精度がいいなら[[ピクセルシェーダー]]で高品質なライティングしたくなる。

一方、法線マッピングでは[[テクスチャマッピング]]の[[画像]]と同じ要領であらかじめピクセル単位で法線ベクトルを計算しておいた[[データ]]を用いる。

つまり実行時にピクセル単位の法線を計算しないうえに、推論的なものではないので非常に精度の良いな[[データ]]になる。すばらしいね。そんなに精度がいいなら[[ピクセルシェーダー]]で高品質なライティングしたくなる。

なお、デメリットもある。まず法線マップの[[データ]]の作成は非常に敷居が高い。 [[ZBrush]]では[[スカルプト]]でゴシゴシやるとモデルと一緒に出力できるらしい。 [[スカルプト]]を使えるツールなど素人には買えるわけがない（無償で使える[[Fusion 360]]で出力できるかもしれないが試してはいない）。

== 値変換 ==

一般的な[[プログラマブルシェーダー]]~~には法線マップ専用の受け口はない。~~

一般的な[[プログラマブルシェーダー]]には法線マップ専用の受け口などない。

~~そのため法線マップは~~[[テクスチャマップ]]に変換して[[シェーダー]]に渡すことになる。

「なんたらマップ」の受け口は一律でテクスチャマップの受け口を利用することになる。

つまり法線マップも[[テクスチャマップ]]に変換して[[シェーダー]]に渡すことになる。

法線は「[[クリップスペース座標]]」で表され「-1.0から1.0」の範囲の「[[正規化]]」された値である。

一方、[[テクスチャ]]の[[RGB]]の[[データ]]は「0.0から1.0」の範囲となっている。

~~この際に法線ベクトルの各値は「-1.0から+1.0」の範囲なのに対して、~~

このためテクスチャとして[[ファイル]]や[[メモリ]]に保持する際には以下のような変換を行う必要がある。

[[~~テクスチャ~~]]の[[~~RGB~~]]~~の[[データ]]は「0.0から1.0」の範囲となっているため以下のような変換を行う必要がある。~~

格納値 = (法線 + 1.0) * 0.5

~~この格納値をプログラマブルシェーダー内で再び法線ベクトルに戻して利用する。~~

この格納値を[[プログラマブルシェーダー]]内で再び法線ベクトルに戻して利用する際には以下のような変換を行う。

法線 = 2.0 * 格納値 - 1.0;

== 上方向 ==

3D空間では「Y軸が上方向」ということが多いが、

~~法線空間では「Z軸が上方向」というのが一般的である。~~

法線空間（[[クリップスペース座標]]）では「Z軸が上方向」となっているのが一般的である。

=== フラット ===

@@ 1行目: / 1行目: @@
-'''法線マッピング'''（[[英語]]：normal mapping）とは、[[バンプマッピング]]の発展形で、[[バンプマップ]]では[[ピクセル]]単位で「高さ」の情報を持つのに対して、[[法線マップ]]では[[ピクセル]]単位で「XYZの[[ベクトル]]」を持つものをいう。
+'''法線マッピング'''（[[英語]]：normal mapping）とは、陰影処理のために「[[ピクセル]]の向いている方向」を保持するものをいう。
 == 概要==
-バンプマップなしの場合は頂点に[[法線]]を持たせ、2つの頂点の[[法線]]と[[ピクセル]]の位置から大雑把にピクセルの[[法線]]を算出する。 バンプマップありの場合はこれに「高さ」をかけ合わせてもう少し精度をよく算出していた。
+[[ピクセル]]の[[法線]]は、[[バンプマップ]]なしの場合は[[頂点]]に[[法線]]を持たせ、2つの頂点の[[法線]]と[[ピクセル]]の位置から大雑把に算出する。 同様にバンプマップありの場合はこれに「高さ」をかけ合わせてもう少し精度をよく算出していた。
 [[ファイル:頂点の法線からピクセルの法線を算出.png|なし|サムネイル|640x640ピクセル]]
-一方、法線マッピングでは[[テクスチャマッピング]]の[[画像]]と同じ要領であらかじめピクセル単位で法線ベクトルを計算しておいた[[データ]]を用いる。 つまり実行時にピクセル単位の法線を計算しないうえに、推論的なものではないので非常に精度の良いなデータになる。 すばらしいね。 そんなに精度がいいなら[[ピクセルシェーダー]]で高品質なライティングしたくなる。
+一方、法線マッピングでは[[テクスチャマッピング]]の[[画像]]と同じ要領であらかじめピクセル単位で法線ベクトルを計算しておいた[[データ]]を用いる。
+つまり実行時にピクセル単位の法線を計算しないうえに、推論的なものではないので非常に精度の良いな[[データ]]になる。すばらしいね。そんなに精度がいいなら[[ピクセルシェーダー]]で高品質なライティングしたくなる。
 なお、デメリットもある。 まず法線マップの[[データ]]の作成は非常に敷居が高い。 [[ZBrush]]では[[スカルプト]]でゴシゴシやるとモデルと一緒に出力できるらしい。 [[スカルプト]]を使えるツールなど素人には買えるわけがない（無償で使える[[Fusion 360]]で出力できるかもしれないが試してはいない）。
 == 値変換 ==
-一般的な[[プログラマブルシェーダー]]には法線マップ専用の受け口はない。
+一般的な[[プログラマブルシェーダー]]には法線マップ専用の受け口などない。
-そのため法線マップは[[テクスチャマップ]]に変換して[[シェーダー]]に渡すことになる。
+「なんたらマップ」の受け口は一律でテクスチャマップの受け口を利用することになる。
+つまり法線マップも[[テクスチャマップ]]に変換して[[シェーダー]]に渡すことになる。
+法線は「[[クリップスペース座標]]」で表され「-1.0から1.0」の範囲の「[[正規化]]」された値である。
+一方、[[テクスチャ]]の[[RGB]]の[[データ]]は「0.0から1.0」の範囲となっている。
-この際に法線ベクトルの各値は「-1.0から+1.0」の範囲なのに対して、
+このためテクスチャとして[[ファイル]]や[[メモリ]]に保持する際には以下のような変換を行う必要がある。
-[[テクスチャ]]の[[RGB]]の[[データ]]は「0.0から1.0」の範囲となっているため以下のような変換を行う必要がある。
   格納値 = (法線 + 1.0) * 0.5
-この格納値をプログラマブルシェーダー内で再び法線ベクトルに戻して利用する。
+この格納値を[[プログラマブルシェーダー]]内で再び法線ベクトルに戻して利用する際には以下のような変換を行う。
   法線 = 2.0 * 格納値 - 1.0;
 == 上方向 ==
 D空間では「Y軸が上方向」ということが多いが、
-法線空間では「Z軸が上方向」というのが一般的である。
+法線空間（[[クリップスペース座標]]）では「Z軸が上方向」となっているのが一般的である。
 === フラット ===