マッピング：ビジュアル強化Tips
このページでは、マップの見た目を強化する様々なエンティティや方法を紹介します。
[ポ]＝ポイントエンティティ、[ブ]＝ブラシエンティティ
全般
[ポ] env_cubemap - キューブマップを撮影するポイント
https://developer.valvesoftware.com/wiki/Env_cubemap
テクスチャに風景が映り込む時、その風景として使用されるのが全方位を6枚の画像で表したキューブマップ。
これは予めゲーム内で（マップ作者が）撮影するもので、自動的にbspに埋め込まれる。撮影方法は後述。
つまりその反射する風景は、周りの環境が変化（壁の破壊や、ライトのオン/オフなど）しても変わらないことに注意が必要。
ブラシの反射に使用されるenv_cubemapはコンパイル時に確定され、例えそのブラシが移動しても推移はしない。
モデルの反射には、常に最短距離にあるenv_cubemapが使用される。
フェードなどはせず、モデルが2つのenv_cubemapの中間地点を通過した時点で瞬時に切り替わる。
Sourceエンジンでは、水面のテクスチャと、鏡（func_reflective_glass）以外の反射は全てキューブマップ反射である。
このエンティティをいくつ・どこに配置するかだが、明確なルールというのは存在しない。
また単一/複数のブラシの面をpickすることができる。pickされた面の反射にはそのenv_cubemapのキューブマップが使用される。
また水面も、設定やテクスチャによってはキューブマップ反射が使われることがあるので、
ちなみにそれぞれのenv_cubemapで解像度を変更できる。
言葉で説明すると非常に難しく感じられるが、一度理解してしまえば単純な話である。
[ポ] color_correction - 画面全体の色調を調整する
[ブ] func_reflective_glass - リアルタイム反射の鏡
[ブ] func_precipitation - 雨・雪を降らせる
[ポ] env_fire - 炎
[ポ] env_spark - 火花
[ポ] env_explosion - 爆発
[ポ] info_particle_system - パーティクル
もう少し詳しく説明すると。これは、パーティクルエディターで、素材の画像を「どんな風に出現させる（頻度や位置など）」
env_fireやenv_steamなどもパーティクルの一種だが、使用頻度が高く、ハンマーエディタ内で
[ポ] env_wind - マップ全体の風を設定する
[ポ] env_tonemap_controller
HDRというよりマップ全体の色調が気に入らない？ならばcolor_correctionへGO
ライティング・ライトの表現
[ポ] light_environment - 屋外の環境光を設定する
屋外中心のマップなら全体の雰囲気を決める大切なエンティティ。このエンティティの設定によって時間帯だけでなく、（雰囲気的な）気温や湿度の表現もできる。ただし、やはりスカイボックスのテクスチャと調和するように設定しなければならない。透き通った青空なのに屋外が真っ暗では怖いし、逆も然り。また、「スカイボックスに見える太陽/月の方向に影が伸びている」等といった事態も避けるようにしたい。
なお初心者が良くやりがちな手抜きとして、「Pitch Yaw Roll,PitchとBrightnessしか弄らない」というのが挙げられる。確かにBrightnessだけで光の色や明るさは一応設定できるのだが、よりリアルで美しい自然な環境光の表現には
+
太陽の角度の設定
太陽の角度の設定
方角はスカイボックスの太陽に合わせてしっかり合わせよう。多少ずらすぐらいならバレにくい。高度は方角より自由度がある。
+
SunSpreadAngleについて
SunSpreadAngleについて
言葉で説明するよりこのリンクの画像を見てもらったほうが早いだろう。
http://www.nodraw.net/2011/01/sunspreadangle/
太陽が出ている時間帯のマップでは3～5あたりが使いやすい値だが、もっと数値を下げたほうがいい場合もあるし、逆もある。太陽がかんかんと照りつける昼間を表現したければ思い切って0にしてしまう手もある。
夜のマップでBrightnessを1以上にするなら数値を大きめにしたほうが良い。（Brightnessが0だと方向のある陰影はつかない）
+
Ambientについて
Ambientについて
+
Brightnessについて
Brightnessについて
+
その他の設定項目について
BrightnessHDR, AmbientHDR
HDR有効時のみそれぞれBrightness,Ambientの値をこれで置き換える。デフォルトの[-1 -1 -1 1]のままで良い。
AmbientScaleHDR
値を上げると影が薄くなっていくが、光が当たっている部分も少しずつ明るくなっていく。あまりこの項目は弄らずにBrightness,Ambientのほうで調整したほうが良いだろう。（HDR無効時とのギャップを小さくするためにも）
BrightnessScaleHDR
値を上げると光が当たっている部分がHDRでもっとギラギラする。要はHDRのコントラスト調整みたいなもの。もっと画にメリハリをつけたければ上げて、目に優しくするには下げる。
これらは他のライト（light, light_spot）には影響しないことに注意しよう。
満足の行く設定を見つけるには試行錯誤が必要になるのでゆっくり時間をかけて調整しよう。
屋内オンリーのマップで、外の景色を作る労力が割に合わない場合は
よくtools/toolsblackやtools/toolswhiteテクスチャが使われる。
（必要に応じて単色のテクスチャを自作するのも良い）
テクスチャライト（発光テクスチャ）を使うことで、窓から差し込む日光などを擬似的に表現することもできる。
http://simonbarsky.com/blog/?page_id=29
ただしこれは光が差し込む角度まで再現することはできない。（
この画像
のようにすれば可能）
もちろんこの発光テクスチャには他にも色々な使い道がある。
lightやlight_spotと違い到達距離（Constant/Linear/Quadratic及びfallof distance）が設定できないのは辛いが、
それらの「点」と違って「面」として照らすことができるからだ。（正確には、点を一定の密度で敷き詰めているようだが）
発光テクスチャを貼ったブラシをfunc_brush化して、Don't Renderにすると光源単体で使えることも覚えておこう。
[ポ] light - 全方位を照らすライト
+
以下はlight_spotにも当てはまる注意点。
以下はlight_spotにも当てはまる注意点。
コンパイル時にライトマップに焼きこまれるものなので移動させることはできない。
入力によってライトをオン・オフできるが、コンパイル時に起こりうる全てのパターンを計算する必要があるため限界がある。こればかりは古いエンジンなので仕方が無い。例えば、2個の独立した名前を持つ（≒オン・オフ可能な）ライトがあれば「ABオン」「AオンBオフ」「AオフBオフ」「ABオフ」という4パターン全てのライトマップが焼きこまなければならない。独立した名前を持つライトが更に増えればパターンは増えて行き、すぐに限界（32パターン）にぶち当たってしまうだろう。（※限界に達しなければ良いという訳ではない。パターンが多いほどライトは不自然になる）ライトに名前を付けるだけでコンパイラーは「このライトはオン・オフする可能性があるんだ」と判断してしまう。そのためオン・オフしないライトでも、名前を付けるだけでコンパイル時間・ファイルサイズが増加してしまうことに注意。そして、同時にオン・オフするライトには全て同じ名前をつけること。そうすれば名前1つで複数のライトに入力できる。ということで、少しずつ部屋のライトをつけていくようなマップを作ろうとしているなら今すぐ白紙に戻そう。
Appearanceによって点滅させることができるが、かなりクライアントに負荷が掛かるので乱用は絶対にNG。単純にフレームレートが落ちるだけでなくカクつくようになってしまう。出来ることなら点滅するlightがプレイヤーの視界に同時に複数入ることがないようにしよう。（1つだけでも割と重い）
[ポ] light_spot - ある一点を照らすライト
「example.vmt」を複製し、「example_edit」等と命名する。（名前は自分が分かればなんでも良い）
「example_edit.vmt」をテキストエディタで開き、パラメータの追加や引数の変更を行う。
ハンマーエディタでブラシの面に貼り付けてあるexampleを、example_editに置き換える。
ハンマーディタでマップをコンパイルする。
コンパイルして出来たbspファイルに、Pakratを使用して「example_edit.vmt」を埋め込む。（重要）
といった手順を踏む必要があるが、$reflectivityパラメータのみ編集する場合は、単に
（不安な場合、「example.vmt」を複製し、「example.bak.vmt」等と命名しておけば後で簡単に元に戻せる）
「example.vmt」をテキストエディタで開き、$reflectivityパラメータの追加、または引数の変更を行う。
ハンマーエディタでマップをコンパイルする。
だけで良い。これは、$reflectivityパラメータはマップのコンパイル時のみに参照されるため。
[ポ] light_dynamic - ダイナミックライト
このエンティティは調整がとても難しいらしい。とりあえず上記ページに書いてある注意点だけ転載。
実はこのエンティティのライトは、「モデルのみを照らすライト」と、「ワールド（ブラシ）のみを照らすライト」の2つが合わさって出来ている。そのうちの片方に影響するが、もう片方には影響しないKeyvalueがある。
distanceは照らさせたい物までの距離より大きい数値に設定する必要がある。
brightnessは6か8のどちらかでなくてはならない。他のライト系エンティティで使われるbrightnessはこのエンティティには関係無い。
角度はKeyvalueで手動で設定する必要がある。（point atツールは使ってはいけない。ハンマーエディタの2Dビューで回転させるのは良いのか悪いのか不明）
[ポ] point_spotlight - サーチライトのような光の道筋
https://developer.valvesoftware.com/wiki/Point_spotlight
これは「横から見ると光の道筋が見える」「正面から見るとまぶしい」というだけで、ライトマップには焼きこまれない。
そのため、基本的にlight_spotと併せて置くもの。
但し、lightやlight_spotと違ってこのエンティティは動かすことができるため、
動く乗り物などについているライトを疑似的に表現する時は単体で使うこともある。
あとは高い場所に設置されている上向き（空向き）のサーチライトなんかも、わざわざlight_spotを置いたところで
照らされるオブジェクトが何も無いのでpoint_spotlight単体でもよい。ただしヘリとか通るなら話は別である。
[ポ] env_sprite - 常にこっちを向いているテクスチャ
https://developer.valvesoftware.com/wiki/Env_sprite
例えば現実的なライトを配置するとき、プロップとlightだけではいまいちライト自体が光っているように見えないことがある。
そんな時に使うのがこのエンティティで、これの設置ポイントがプレイヤーの視界内にあって、
何かに遮られないかぎり、設定したテクスチャが正面を向いて主張してくる。
lightの色と近くすれば、まるでプロップがその色に光っているように見えるというわけ。
多少無理はあるが、白のプロップを別の色に光っているように見せることもできる。
また、プロップやlightを設置するほどでもない小さい光源を表現する時にも使う。（イルミネーションなど）
使うRender Modeは基本的にGlowとWorld Space Glowのみ。
なおこちらはStatic Lightと違い、好きなだけAppearanceで点滅させて大丈夫。ほとんど負荷にならない。
[ポ] env_sun - 太陽（たまに月）
マップ内の何処にプレイヤーがいても、視界に入っている場合は同じ方角・角度に表示されるenv_spriteのようなもの。
[ポ] env_lightglow - トンネルの出口とかで眩しくなるやつ
[ポ] env_projectedtexture - プロジェクターのようなもの
+
旧解説
ポイントエンティティで、明るさや角度を設定できるという点ではlight_spotに似ているが、本質的には全くの別物。
Portal2ではこのエンティティがこれでもかというほど多用されているので、イマイチ使いどころが分からないという人はプレイしてみると良い。
[ポ] shadow_control - マップ全体のダイナミックシャドウを設定する
屋外オンリーのマップであれば、light_environmentに調和するように設定すればとりあえずそれだけでも良い。
[設定例]
light_environment
shadow_control
Pitch Yaw Roll (Y Z X)
0 108 0
45 108 0
Pitch
-45
（なし）
しかし不便なことにダイナミックシャドウはマップ全体で同じ角度・色で落とされてしまうので、
Shadow Colorについては少しずつ値を変えて試してみるしかないが、あまり濃い色（暗い色）にすると、
特定のオブジェクトのダイナミックシャドウだけが邪魔な場合は、個別にそのエンティティの方で影を消せばいい。
またライトマップの影と重なる以外にも、ダイナミックシャドウ同士で重なってしまうことに気をつける必要がある。
ゾンビ同士の影が重なる不自然さを軽減したい場合は、Pitchを直下に近づければ重なる頻度を下げられる。例えlight_environmentが夕方の長い影をライトマップに落としていても、ダイナミックシャドウはそこまで長くなくても結構しっくり来るものである。
夜のマップ。早い話がオフで良い。夜に町を歩いている人を想像してみよう。街灯や店、車などの光源によって色んな方向に影が出たり消えたりしているはずだが、これはSourceエンジンでは再現できない。また、現実世界において、肉眼でくっきりと人の影が見えるほど強烈な月明かりは滅多に無い。ただし月明かり以外のライトが少ないようなマップ、つまり自然豊かなマップな場合は薄めにつけてみるのも良い。。この場合、月明かりに指向性を持たせるためlight_environmentのBrightnessは0以外に設定する必要がある。
屋内マップ。これも正直言ってオフで良い。やはり屋内でも、現実世界では光源との位置関係によって様々な影ができるが、これを再現することはできない。どうしてもダイナミックシャドウが欲しいという場合は、影の形がよく分からないほど薄い色にしよう。もちろん角度はほぼ直下に。
[ポ] info_lighting - prop_staticへの光の当たり方を決めるポイントを調整する
https://developer.valvesoftware.com/wiki/Info_lighting
prop_staticを壁にめり込ませて配置した場合、光の当たり方がおかしくなってしまう（大抵の場合、真っ暗）ことがある。
そんな時にprop_staicのLighting Originで、配置したinfo_lightingの名前を指定すると、
そのprop_staticの「ライティングを決める場所」を、このエンティティの場所で上書きすることができる。
また、めり込んだプロップ以外でも、少しだけ光源に近づけたり離したりして、微調整に使うこともできる。
と言ってもよく分からないと思うのでこの
チュートリアル動画
を見ると良い。
普通、対象のprop_staticの近くに配置するものだが、全く別の場所に配置することもできる。
（暗い部屋の真ん中にあるテーブルに、明るい部屋に置いたinfo_lightingを指定させれば、
そのテーブルだけ不気味に明るくできる）
staticproplightingオプションを付けている場合、$bumpmapを使用していないプロップモデルには使用できなくなる。
（$bumpmapを使用していないプロップモデルはVertex Lightingされる）
なおこのエンティティと同様の効果をprop_dynamicで得たい場合はinfo_targetを使う。
煙・霧・埃などの表現
[ポ] env_fog_controller - マップ全体のフォグを設定する
いわゆる霧であるが、サイレントヒルでも作らない限り濃霧など滅多に必要無いので、
フォグは、Fog Startの距離からかかり始め、Fog Endの距離以降の全てのオブジェクトは完全にフォグの色に覆われる。
通常スカイボックスのテクスチャはvmtで$nofog 1とされているため、スカイボックスは絶対にフォグに覆われないが、
3Dスカイボックス内のフォグは、別途sky_camera内の設定項目で設定する必要があるので注意。（多くの場合、env_fog_controllerと同一の設定で良い）
[ブ] func_dustcloud - もやっとした霧・砂埃（砂嵐）を発生させる
[ポ] env_dustpuff - もやっとした霧・砂埃を発生させる（？）
[ポ] env_steam - もくもくと上がる煙・陽炎を発生させる
[ブ] func_smokevolume - もくもくとした煙を発生させる
[ポ] env_smokestack - もくもくと上がる煙を発生させる（？）
[ブ] func_dustmotes - ぱらぱらと舞う埃を発生させる
ロープ
[ポ] move_rope
[ポ] keyframe_rope
効果音・環境音・BGMなど
[ポ] ambient_generic
[ポ] env_soundscape
エンティティ以外の話
ライティング関係のコンパイルオプション
目的がギミック等の動作確認で、ライティングは必要無い場合は$light_exeのチェックを外せば、
簡易的なライティングのテストによく使われるオプション
-fast -luxeldensity * -hdr/-ldr
完成したマップ、最終的なライティングのテストに使われるオプション
-final -textureshadows -staticproppolys -both/-hdr/-ldr -staticproplighting
-fast
品質を犠牲に、ライティングの焼きこみをより短い時間で済ませる。基本的に大まかな雰囲気を見るにはこれで十分だが、場合によっては間接光のライティングが破綻してしまうことがある。その場合は外すこと。
-final
ライティングの焼きこみにより長く時間をかけて綺麗にする。-fastと見比べても違いがほとんど分からないようなケースがあるが、完成したマップをコンパイルする時は必ずこれを使うこと。細かいところではあるが、間接光によって柔らかく照らされている場所が、-fastや標準モードだと黒く潰れてしまったりする。
-luxeldensity *
ライトマップが引数より小さい値に設定されている面を、引数の値に置き換えてコンパイルする。例えば「細かいライトマップを使っている面があるが今回はその点をチェックするわけではない」という場合は-luxeldensity 16が最適だろう。「本当にぱっと見の雰囲気を確かめるだけで良い」という場合は32や64にすれば更に時間は短縮される。
-both
HDRとLDR両方のライトマップを焼きこむ。-hdr, -ldrと併用不可。
-hdr
HDRのライトマップのみを焼きこむ。LDRのライトマップ焼きこみが省かれ、LDR用のキューブマップを撮影する必要も無くなるのでファイルサイズの削減になる。ただし（具体的にどうなるのかは試していないので分からないが）HDRを無効にしている環境では不都合が出るはず。-both, -ldrと併用不可。
-ldr
LDRのライトマップのみを焼きこむ。普通はHDR前提で作るのでテスト目的でもあまり使う機会は無いだろう。完成したマップに使う機会があるとすれば、「HDRが無い時代のクラシックゲーム調」「アニメ調（誤解防止：『アニメ調ならLDR』ではなく『アニメ調ならLDRにする手もあり』ということ。TF2は普通にHDRを使っている）」に作る場合。-both, -hdrと併用不可。
-textureshadows
アルファチャンネルを持つ、すなわち透けている部分があるテクスチャ（格子状など）の透明部分を光が通り抜けるようになる。
-staticproppolys
全てのprop_staticが落とす影が、実際のpropに基づいた形になる。このオプションを使わない場合、影の形はバウンディングボックス（簡易的な衝突判定に使われる大雑把な形の箱）のものになってしまうので、ほぼ必須のオプション。
-staticproplighting
prop_static自体のライティング（prop_static自体が受ける影）がより現実的になる。このオプションを使わない場合の、prop_static自体のライティングについては、このページの項「prop_staticのVertex Lightingについて」を参照すること。基本的にデメリットが無い-textureshadows, -staticproppolysと違って、このオプションを使うとbspのファイルサイズがかなり増加する。とは言え基本的にファイルサイズに関してそこまで神経質になる必要は無いので、特に理由が無ければとりあえずこのオプションも付けておこう。
ライトマップスケール
ライトマップスケールを細かくすることによるデメリットは、コンパイル時間やファイルサイズが倍増すること。
そして一番注意すべきデメリットは、1つのマップに存在できるライトマップのグリッド数には限界があるということ。
なおひとつの面に存在できるライトマップのグリッド数にも限度があり、
まとめ：
デフォルトの16はシャープさとコスト（コンパイル時間・ファイルサイズ）のバランスが一番とれた数値である。
基本的には16のままにしておき、細かいライティングが必要な面のみ小さい数値にするようにすると良い。上述の通り、16より大きい数値にすることによるコストの削減は効果が薄い。（製作段階のマップのコンパイルを早く済ませたい場合はvradコンパイルオプションの-luxeldensityを使うべき）
プレイヤーから見えない面をNodrawテクスチャにすることは、ライトマップのコスト削減にも繋がる。Nodrawの面にはライティングの計算が必要無いため。地面の裏側のテクスチャをそのままにしている人などは大損をしている。
最良の結果を得る方法は、「限界に達しない範囲で」「あなたが許容できるコンパイル時間内で」「シャープにしたい面のスケールを細かくする」ことである。ファイルサイズに関しては確かに倍増するのだが、そもそも上述の限界によって自動的にこれも制限されるため、マップ単体では100MBに達することすら不可能なのでほとんど気にする必要はない。（100MBと聞くと大きく聞こえるかもしれないが、カスタムコンテンツを使えばテクスチャだけで100MBを超えるのは容易である） マップの最適化
しかし最適な最適化を出来るということは、その軽減された負荷の分複雑なマップを作れるということなので、
Nodrawテクスチャにはライトマップも焼きこまれないので、コンパイル時間の短縮にも一役買う。
カスタムコンテンツ
デフォルトで入っているテクスチャなどでは物足りないと思ったら、自分で作った（或いはどこかから取ってきた）
円柱や球体などの曲面を滑らかに見せる
マップに草を生やす
「点」でなく「面」で照らすライト
light_environmentのとこに書いてあります。
スカイボックスの回転
スカイボックス自体は回転できない。マップをある程度作ったあとに、気になってしまうこともあるだろう。
スカイボックスや環境光などの調和
それぞれのパートで散々言ってきたが、つまりはこういうこと。
まずlight_environmentをスカイボックスの明るい方角から、それっぽい色の光が差し込むように設定する。
そしてenv_sunをスカイボックスの明るい部分の方角・角度で、その部分に近い色に設定する。
最後shadow_controlを、ブラシが落とす影に近い色合いになるように調整する。
（別に自分が好きな順番でやっていいです）
左はfunc_physboxなのでダイナミックシャドウ、右は普通のブラシなのでライトマップに焼きこまれた影。
でもここまでダイナミックシャドウを濃くて彩度が高いものにすると、影同士が重なったときに非常に気持ち悪いことになるので、
prop_staticのVertex Lightingについて
Disable Vertex LightingというKeyvalueがあるが、これは基本的にNo（＝Vertex Lightingを使用する）で良い。
Vertex Lightingとは何かという話だが、これは雑に言えばライトマップのprop_static版みたいなものである。
Disable Vertex LightingがYesの状態では、そのプロップモデルが受けるライティングは、そのprop_staticのモデルの「場所（光源に対する距離や角度）」の1点のみで決定される。（それぞれの頂点の位置は関係ない）
3Dスカイボックス
「え、なんでわざわざそんな面倒臭いことする必要があるの？本体に全部作っちゃえばいいじゃん」と思うかもしれない。
sky_camera内で本体に対する3Dスカイボックスの縮尺率を変更できるが、これはデフォルトの1/16のままにしておくのが吉。
位置合わせについては少しでもズレているとおかしなことになるので、しっかりと行うことをお勧めする。
この3Dスカイボックスを作成する際に見落とされがちなのが、「本体と3Dスカイボックスは、お互いライティングに影響しない」ということ。
最終更新：2015年09月28日 02:58
