「マッピング：マップの見栄えを良くする方法」の編集履歴（バックアップ）一覧はこちら

「マッピング：マップの見栄えを良くする方法」(2015/09/28 (月) 02:58:34) の最新版変更点

追加された行は緑色になります。

削除された行は赤色になります。

*マッピング：ビジュアル強化Tips
このページでは、マップの見た目を強化する様々なエンティティや方法を紹介します。
軽く知ったかぶりして主観的に書いた部分もあるので絶対正しいとは思わないでおいてください。
説明が長くて細かい項目ほどその傾向が強いです。

[ポ]＝ポイントエンティティ、[ブ]＝ブラシエンティティ
----
#contents
----
*全般
**[ポ] env_cubemap - キューブマップを撮影するポイント
https://developer.valvesoftware.com/wiki/Env_cubemap
テクスチャに風景が映り込む時、その風景として使用されるのが全方位を6枚の画像で表したキューブマップ。
これは予めゲーム内で（マップ作者が）撮影するもので、自動的にbspに埋め込まれる。撮影方法は後述。
つまりその反射する風景は、周りの環境が変化（壁の破壊や、ライトのオン/オフなど）しても変わらないことに注意が必要。
ブラシの反射に使用されるenv_cubemapはコンパイル時に確定され、例えそのブラシが移動しても推移はしない。
モデルの反射には、常に最短距離にあるenv_cubemapが使用される。
フェードなどはせず、モデルが2つのenv_cubemapの中間地点を通過した時点で瞬時に切り替わる。

Sourceエンジンでは、水面のテクスチャと、鏡（func_reflective_glass）以外の反射は全てキューブマップ反射である。
つまり、表面の「反射≒光沢感」の表現にはほぼ必ずキューブマップが使われるということ。

このエンティティをいくつ・どこに配置するかだが、明確なルールというのは存在しない。
よっぽど変な配置にしない限り不自然にはならないので、そこまで神経質になる必要はない。
ちなみにマップを作りながら置いていくより、ほぼ作り終わってから最後に置くほうが良い。
屋外では適当に置いてしまえばOK。特に理由が無ければプレイヤーのアイレベルである地上64ユニットがおすすめ。
屋内では、1部屋につき1つというのが定番。部屋の構造やサイズに応じて増やそう。
天井がプレイヤー2人が縦に入らないぐらいの高さの部屋では、アイレベルに配置するより、
地面と天井のちょうど中心に配置するほうがより自然に見えるだろう。

また単一/複数のブラシの面をpickすることができる。pickされた面の反射にはそのenv_cubemapのキューブマップが使用される。
窓は一般的に反射した風景が目立ちやすいので、すぐ前にenv_cubemapを配置してpickしておくといいだろう。
pickされていない面は、コンパイル時に最短距離のenv_cubemapを使用する。基本的にpickするのは窓と水面（下記）だけで良いが、
同一面（ここでは高さが同じという意味）を複数のブラシが構成している場合に、
使用されるenv_cubemapが異なっている「境界」が出来て目立ってしまうことがある。
この場合は付近のenv_cubemapを削除し1個に絞るか、もしくは手作業で面をpickしていくしかない。（前者はあまりお勧めしない）
またその面の裏側にあるenv_cubemapが使われてしまっている場合にも手動でpickしてやる必要がある。

また水面も、設定やテクスチャによってはキューブマップ反射が使われることがあるので、
必ず水面上（最適な高さは場合によって異なるのでなんとも言えない）の中心近くにenv_cubemapを配置してpickすること。
複数のブラシを繋げて単一の水面を表現するときは、それぞれにenv_cubemapを配置するよりも、
単一のenv_cubemapで複数pickしたほうが自然に見える場合が多い。これは上記の「境界」が目立ってしまうことが多いから。
逆に、それぞれにenv_cubemapを配置したほうが良いのは、
「地下水路・洞窟など単一水面上で場所によって（反射すべき）景色が大きく変わる場合」である。

ちなみにそれぞれのenv_cubemapで解像度を変更できる。
大きくすればするほど反射する風景が精細になるが、その分ファイルサイズが大きくなるので注意しよう。多少は負荷も上がる。
また解像度が高いということは細かい部分まで見えてしまうということなので、逆に不自然になってしまうこともある。
デフォルトの解像度は多くの状況においてバランスが取れている。悩むようならば変更しなくて良い。

言葉で説明すると非常に難しく感じられるが、一度理解してしまえば単純な話である。
いまいち理解できないという人は、公式マップでSako85を持って歩き回ってみるといい。スコープの反射に注目。

※キューブマップはコンパイル毎に、HDR用とLDR（非HDR）用のものをゲーム内で撮影しなければいけない。
https://developer.valvesoftware.com/wiki/Cubemaps

**[ポ] color_correction - 画面全体の色調を調整する
https://developer.valvesoftware.com/wiki/Color_correction_%28entity%29
カラーコレクション略してカラコレ
ゲーム内で実際に試しながら調整できるので非常にお手軽。
ただし実際の効果が作った時（調整した時）より強くなってしまうことがあるらしい。
（その場合の対処法も下のリンクに書いてある）
仕上げの際は是非試してみよう。ちょっと色調を変えたいけど、ライトを弄るのは面倒くさいなんて時にも使える。
これを使っても希望の色調にできないというときは手間はかかるがライトの設定を見直していこう。
ただし設定で色調整をオフにしているプレイヤーには効果が無いので注意。
https://developer.valvesoftware.com/wiki/Color_correction
ブラシエンティティはcolor_collection_volume。面倒なので別項目作りません。
https://developer.valvesoftware.com/wiki/Color_correction_volume

**[ブ] func_reflective_glass - リアルタイム反射の鏡
https://developer.valvesoftware.com/wiki/Func_reflective_glass
あまり安定したエンティティでは無いので、配置によっては鏡が乱れてしまうことがある。
それと言うまでもないかもしれないが、映り込むオブジェクトが多い場合はその分負荷もかかる。

**[ブ] func_precipitation - 雨・雪を降らせる
https://developer.valvesoftware.com/wiki/Func_precipitation
Precipitation Type：Snowは謎の雨っぽい何かなので雪はSnowfallのほうを使おう。
Density最大でも物足りない時は、ブラシを複製して重ねてみよう。

**[ポ] env_fire - 炎
https://developer.valvesoftware.com/wiki/Env_fire
説明不要。lightと一緒に置くと良い。

**[ポ] env_spark - 火花
https://developer.valvesoftware.com/wiki/Env_spark
説明不要。

**[ポ] env_explosion - 爆発
https://developer.valvesoftware.com/wiki/Env_explosion
どっかーん

**[ポ] info_particle_system - パーティクル
https://developer.valvesoftware.com/wiki/Info_particle_system
パーティクルというのは、ある地点から振ってくる枯れ葉であったり、ある地点から空に向かう炎だったりする。

もう少し詳しく説明すると。これは、パーティクルエディターで、素材の画像を「どんな風に出現させる（頻度や位置など）」
「どんな風に消滅させる（消滅までの時間やフェードアウトなど）」「どんな風に動かす（速度や方向など）」
「重力の影響を受ける/受けない」「地面やプレイヤー等と接触する/しない」などの設定をしてやることで、
動くパーティクルになる。素材の画像と、様々な「挙動の設定」が組み合わさって1つの動くパーティクルになっているのである。

やはりと言うか、パーティクルディターは非常に複雑で難しいが、希望であれば自分でパーティクルを作成することもできる。
とりあえず自分に作れるか判断したい場合はこの動画を見ると良い。
https://www.youtube.com/watch?v=70GhO6z5aKM
40分あるが、これを見れば使いこなせるようになるというようなものでもない。

env_fireやenv_steamなどもパーティクルの一種だが、使用頻度が高く、ハンマーエディタ内で
色々パラメーターを弄れたほうが便利なので独立したエンティティになっているというわけ。
NMRiHでよく見かけるinfo_particle_systemとしてはパトカーの回転灯がある。

**[ポ] env_wind - マップ全体の風を設定する
https://developer.valvesoftware.com/wiki/Env_wind
詳細不明。主にロープを揺らす用？

**[ポ] env_tonemap_controller
https://developer.valvesoftware.com/wiki/Env_tonemap_controller
HDRについて定義するエンティティだが私はまだ使ったことがないので詳しいことはよく分からない。
どうやら光彩の開け閉め（のシミュレーション）のしきい値を設定するらしい。
そもそも普通は皆デフォルトのHDRに合わせてライティングを組んでいると思うので、基本的には使う必要は無いだろう。
どうしてもHDRの挙動が鼻についた時は使ってみると良いかと。下のページも参考に。
https://developer.valvesoftware.com/wiki/HDR_Lighting_Settings

HDRというよりマップ全体の色調が気に入らない？ならばcolor_correctionへGO

----
*ライティング・ライトの表現
**[ポ] light_environment - 屋外の環境光を設定する
https://developer.valvesoftware.com/wiki/Light_environment
日中ならば太陽光、夜中ならば月明かりの色調や角度を設定する。ライトマップに焼きこまれる。このエンティティによって設定されるライトは、スカイボックステクスチャを貼った場所全てが光源になる。

屋外中心のマップなら全体の雰囲気を決める大切なエンティティ。このエンティティの設定によって時間帯だけでなく、（雰囲気的な）気温や湿度の表現もできる。ただし、やはりスカイボックスのテクスチャと調和するように設定しなければならない。透き通った青空なのに屋外が真っ暗では怖いし、逆も然り。また、「スカイボックスに見える太陽/月の方向に影が伸びている」等といった事態も避けるようにしたい。

なお初心者が良くやりがちな手抜きとして、「Pitch Yaw Roll,PitchとBrightnessしか弄らない」というのが挙げられる。確かにBrightnessだけで光の色や明るさは一応設定できるのだが、よりリアルで美しい自然な環境光の表現には
他のKeyvalueでの調整が不可欠である。詳しくは下で説明するが、重要なのはBrightnessよりもAmbientである。

#region(太陽の角度の設定)
太陽の角度の設定
まずPitch Yaw Roll (Y Z X)のYaw(Z)で太陽の方角を指定する。これのPitch(Y)は無視されるし、Roll(X)も普通は使わないので0で良い。次にPitchで太陽の高度を指定する。マイナスの値で上からの光、プラスの値で下からの光になる。後者の使い道はあまり無い。

方角はスカイボックスの太陽に合わせてしっかり合わせよう。多少ずらすぐらいならバレにくい。高度は方角より自由度がある。
#endregion

#region(SunSpreadAngleについて)
SunSpreadAngleについて
言葉で説明するよりこのリンクの画像を見てもらったほうが早いだろう。
http://www.nodraw.net/2011/01/sunspreadangle/
太陽が出ている時間帯のマップでは3～5あたりが使いやすい値だが、もっと数値を下げたほうがいい場合もあるし、逆もある。太陽がかんかんと照りつける昼間を表現したければ思い切って0にしてしまう手もある。
夜のマップでBrightnessを1以上にするなら数値を大きめにしたほうが良い。（Brightnessが0だと方向のある陰影はつかない）
#endregion

#region(Ambientについて)
Ambientについて
スカイボックスの全方向からマップ全体を包み込むように照らしてくる光。
#endregion

#region(Brightnessについて)
Brightnessについて
上で説明した、指定した方角・高度からのみ平行に照らしてくる光。基本的に太陽または月明かりを表現するのに使う。
曇り・霧の日や、夜のマップでは小さい数値またはゼロでもよい。
#endregion

#region(その他の設定項目について)
その他の設定項目について
http://www.youtube.com/watch?v=ot8Wjvx7b6A
を見れば分かるはず。一応以下に言葉でも書いておく。
|BrightnessHDR, AmbientHDR|HDR有効時のみそれぞれBrightness,Ambientの値をこれで置き換える。デフォルトの[-1 -1 -1 1]のままで良い。|
|AmbientScaleHDR|値を上げると影が薄くなっていくが、光が当たっている部分も少しずつ明るくなっていく。あまりこの項目は弄らずにBrightness,Ambientのほうで調整したほうが良いだろう。（HDR無効時とのギャップを小さくするためにも）|
|BrightnessScaleHDR|値を上げると光が当たっている部分がHDRでもっとギラギラする。要はHDRのコントラスト調整みたいなもの。もっと画にメリハリをつけたければ上げて、目に優しくするには下げる。|
これらは他のライト（light, light_spot）には影響しないことに注意しよう。
またビジュアルにこだわる以上当たり前のことであるが、マップを作るときはHDR有効時を基準にしよう。
#endregion

満足の行く設定を見つけるには試行錯誤が必要になるのでゆっくり時間をかけて調整しよう。
せっかく造形はよく出来ているのにライティングが残念なせいで全体的に安っぽくなってしまっているマップも見かける。
逆にライティングによってある程度手抜きっぽさを軽減することだってできる。（特に夜のマップ）

屋内オンリーのマップで、外の景色を作る労力が割に合わない場合は
よくtools/toolsblackやtools/toolswhiteテクスチャが使われる。
（必要に応じて単色のテクスチャを自作するのも良い）
テクスチャライト（発光テクスチャ）を使うことで、窓から差し込む日光などを擬似的に表現することもできる。
http://simonbarsky.com/blog/?page_id=29
ただしこれは光が差し込む角度まで再現することはできない。（[[この画像>http://www.simonbarsky.com/blog/wp-content/uploads/2007/03/lightingShaft.jpg]]のようにすれば可能）
もちろんこの発光テクスチャには他にも色々な使い道がある。
lightやlight_spotと違い到達距離（Constant/Linear/Quadratic及びfallof distance）が設定できないのは辛いが、
それらの「点」と違って「面」として照らすことができるからだ。（正確には、点を一定の密度で敷き詰めているようだが）
発光テクスチャを貼ったブラシをfunc_brush化して、Don't Renderにすると光源単体で使えることも覚えておこう。

**[ポ] light - 全方位を照らすライト
https://developer.valvesoftware.com/wiki/Light
主に室内のライトに使う。ライトマップに焼きこまれる。
light_spot（+light_environment）と合わせて、ライトマップに焼きこまれるライトを「Static Light」と言う。
あまり壁に近づけるとそこが明るくなりすぎるので、いろいろ試しながら最適な位置・到達距離を見極めよう。

#region(以下はlight_spotにも当てはまる注意点。)
以下はlight_spotにも当てはまる注意点。
-コンパイル時にライトマップに焼きこまれるものなので移動させることはできない。
-入力によってライトをオン・オフできるが、コンパイル時に起こりうる全てのパターンを計算する必要があるため限界がある。こればかりは古いエンジンなので仕方が無い。例えば、2個の独立した名前を持つ（≒オン・オフ可能な）ライトがあれば「ABオン」「AオンBオフ」「AオフBオフ」「ABオフ」という4パターン全てのライトマップが焼きこまなければならない。独立した名前を持つライトが更に増えればパターンは増えて行き、すぐに限界（32パターン）にぶち当たってしまうだろう。（※限界に達しなければ良いという訳ではない。パターンが多いほどライトは不自然になる）ライトに名前を付けるだけでコンパイラーは「このライトはオン・オフする可能性があるんだ」と判断してしまう。そのためオン・オフしないライトでも、名前を付けるだけでコンパイル時間・ファイルサイズが増加してしまうことに注意。そして、同時にオン・オフするライトには全て同じ名前をつけること。そうすれば名前1つで複数のライトに入力できる。ということで、少しずつ部屋のライトをつけていくようなマップを作ろうとしているなら今すぐ白紙に戻そう。
-Appearanceによって点滅させることができるが、かなりクライアントに負荷が掛かるので乱用は絶対にNG。単純にフレームレートが落ちるだけでなくカクつくようになってしまう。出来ることなら点滅するlightがプレイヤーの視界に同時に複数入ることがないようにしよう。（1つだけでも割と重い）
#endregion

**[ポ] light_spot - ある一点を照らすライト
https://developer.valvesoftware.com/wiki/Light_spot
ライトマップに焼きこまれる。下向きの街灯や、車のヘッドライトなどに使う。

室内の天井に付いているライトはlightで無いといけないと思い込んでいる人が多いが、実は下向きのlight_spotでも良い。
しかし普通に下向きのlight_spotを置くだけだと天井が真っ暗になってしまう可能性が高い。
これは、床（直接光が当たっている場所）から照り返す光が少なすぎるからである。この照り返しのことを「Bounce」と言う。
このBounceする量（強さ）は、デフォルトではテクスチャのvtfファイルに埋め込まれているが、
vmtファイルの$reflectivityパラメータで上書きすることができる。
https://developer.valvesoftware.com/wiki/$reflectivity
http://www.nodraw.net/2011/02/reflectivity/
通常、既存のテクスチャのvmtファイルのパラメータを編集したい場合、
（例として、パラメータを編集するvmtは「example.vmt」とする。）
+「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パラメータはマップのコンパイル時のみに参照されるため。
念のため逆の言い方もしておくと、コンパイル後に$reflectivityを編集しても効果は無い。

**[ポ] light_dynamic - ダイナミックライト
https://developer.valvesoftware.com/wiki/Light_dynamic
ライトマップに焼きこまれない、ゲーム側でリアルタイムで計算されるダイナミックライト。
ライトの光の形はlight_spotと同じスポットライト型で、lightのような無指向性のダイナミックライトは作れないらしい。
light_spotとの違いは、「Parentingして動かせる」「色を変えられる」「オン・オフに制限が無い」
「ゲーム側の負荷が高い」「見た目はlight_spotに比べてかなり簡易的」といったところ。

このエンティティは調整がとても難しいらしい。とりあえず上記ページに書いてある注意点だけ転載。
|実はこのエンティティのライトは、「モデルのみを照らすライト」と、「ワールド（ブラシ）のみを照らすライト」の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のみ。
Glowは距離に関わらず同じサイズで表示される。主に遠景に使う。近づくとフェードアウトするようにして、
「遠くからみると眩しかったが、近づいたら目が慣れた」という表現をしたい場合にも使える。
World Space Glowは近づけば大きく、離れれば小さくなる。こっちのほうが使う機会は多いんじゃないかな。

なおこちらはStatic Lightと違い、好きなだけAppearanceで点滅させて大丈夫。ほとんど負荷にならない。
「だったらStatic Lightはつけっぱなしでenv_spriteだけ点滅させればいんじゃね？」「やめたほうがいいかと」

**[ポ] env_sun - 太陽（たまに月）
マップ内の何処にプレイヤーがいても、視界に入っている場合は同じ方角・角度に表示されるenv_spriteのようなもの。
スカイボックスの中にあるように見えるenv_spriteと言ったほうが伝わりやすいだろうか。
このエンティティは必須では無い。使う場合はligh_environmentと同じく、スカイボックスのテクスチャに対して
自然に見える色・角度を設定しなければならない。（必ずしも全く同じPitch Yaw Rollで無ければいけない訳では無い）
使用するスカイボックスに太陽が描き込まれていない場合、描き込まれているが大げさに表現したい場合などが主な用途。
特に後者の場合は角度合わせに細心の注意を払う必要がある。

**[ポ] env_lightglow - トンネルの出口とかで眩しくなるやつ
https://developer.valvesoftware.com/wiki/Env_lightglow
元々HDRの効果で、暗いところから明るいところを見ると眩しく見えるが、それをより大げさに演出したいときに使う。
別にトンネル出口に限ったことではないが、主に使われるのはトンネルや洞窟だろう。
用途としてはenv_spriteに似ているがこちらはテクスチャを使わず、Keyvaluesで形を設定する。

**[ポ] env_projectedtexture - プロジェクターのようなもの
https://developer.valvesoftware.com/wiki/Env_projectedtexture
一応使えるが、影の解像度が低くノイズのような不気味なザラザラが乗るので使用に値しない。
#region(旧解説)
ポイントエンティティで、明るさや角度を設定できるという点ではlight_spotに似ているが、本質的には全くの別物。
このエンティティは、プレイヤーのフラッシュライトと同じ原理でテクスチャを投射する。ライトマップには焼きこまれない。
light_spotで無くこちらを選択する意味は「オン/オフしてもライトマップを増やさない」「移動ができる」
「遮られた部分が影になるので、動的・精細な影を作れる」の3つ。
ちなみにshadow_controlでダイナミックシャドウをオンにしている場合は影が不自然になってしまう可能性があるので注意しよう。
また光が直接当たっていないところも反射して柔らかく明るくするlight_spotなどと違い、遮られた部分は全く明るくされない。
env_projectedテクスチャを使うエリアの元々の明るさをしっかり調整しておく必要がある。
$bumpmapが指定されていないモデルはこのエンティティによって照らされず、不自然に暗くなってしまう。

Portal2ではこのエンティティがこれでもかというほど多用されているので、イマイチ使いどころが分からないという人はプレイしてみると良い。
#endregion

**[ポ] shadow_control - マップ全体のダイナミックシャドウを設定する
https://developer.valvesoftware.com/wiki/Shadow_control
ダイナミックシャドウとは、マップ内で動くオブジェクト（prop_physic,prop_dynamicなど）が落とす影のこと。
「動くオブジェクト」とは、prop_dynamic, prop_physics, func_physboxに加えてプレイヤーやNPCなども該当する。

屋外オンリーのマップであれば、light_environmentに調和するように設定すればとりあえずそれだけでも良い。
|[設定例]|light_environment|shadow_control|
|Pitch Yaw Roll (Y Z X)|0 108 0|45 108 0|
|Pitch|-45|（なし）|
しかし不便なことにダイナミックシャドウはマップ全体で同じ角度・色で落とされてしまうので、
屋外と屋内が混在するマップなどでは非常に厄介なことになる。
（例えば夕方の人から伸びる影はとても長いが、屋内に入っても影の長さが同じだったら不気味なのは想像に難くないだろう）
そういうマップでは「角度を直角（直下）に近づける」「彩度を下げる」「ダイナミックシャドウをオフにする」などの妥協が必要になってくるだろう。
ただし角度を完全な直角にするのはやめたほうがいい。人の影の形がかなり不自然に見えちゃうの。最低5度ぐらい？はずらしましょう。
あと最大距離も大きくしすぎると上の階の影が貫通して見えてしまったりする（ダイナミックシャドウには「遮られる」という概念が無い）ので小さ目に。

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の「ライティングを決める場所」を、このエンティティの場所で上書きすることができる。
また、めり込んだプロップ以外でも、少しだけ光源に近づけたり離したりして、微調整に使うこともできる。
と言ってもよく分からないと思うのでこの[[チュートリアル動画>http://www.youtube.com/watch?v=aV4rBlRJ5Bo]]を見ると良い。
普通、対象のprop_staticの近くに配置するものだが、全く別の場所に配置することもできる。
（暗い部屋の真ん中にあるテーブルに、明るい部屋に置いたinfo_lightingを指定させれば、
そのテーブルだけ不気味に明るくできる）

-staticproplightingオプションを付けている場合、$bumpmapを使用していないプロップモデルには使用できなくなる。
（$bumpmapを使用していないプロップモデルはVertex Lightingされる）

なおこのエンティティと同様の効果をprop_dynamicで得たい場合はinfo_targetを使う。
prop_physicsにはLighting Originを設定できないので同様の効果を得ることは不可能。

----
*煙・霧・埃などの表現
**[ポ] env_fog_controller - マップ全体のフォグを設定する
https://developer.valvesoftware.com/wiki/Env_fog_controller
まず聞かれる前に書いておくが、マップの特定の場所にのみフォグを発生させるエンティティは残念ながら無い。

いわゆる霧であるが、サイレントヒルでも作らない限り濃霧など滅多に必要無いので、
実際にはFar Z（最大描画距離）の設定による負荷軽減が目的で使われることが多い。
もちろん、これに頼る前にできる限りの最適化をしたほうが絵的に映えるのは言うまでもない。
本来霧や負荷軽減が必要ないマップでも、弱めに（遠めに）フォグをかけてやると雰囲気を高めることができるかも。

フォグは、Fog Startの距離からかかり始め、Fog Endの距離以降の全てのオブジェクトは完全にフォグの色に覆われる。
Far Zを設定した場合は、その距離以降のオブジェクトは描画されない。（大抵の場合、スカイボックスが透けて見える）
そのためFar ZはFog Endより大きな値にするのが普通であるが、Far Z≦Fog Endで不自然さが無いマップもあるので一概には言えない。
Far Z設定の如何に関わらず、フォグの色は覆われたオブジェクトの裏に見えるスカイボックスの色に近づけたほうがよい。

通常スカイボックスのテクスチャはvmtで$nofog 1とされているため、スカイボックスは絶対にフォグに覆われないが、
スカイボックスのテクスチャを自作する場合はその記述を削除することによってフォグに覆われるようにすることができる。
どんなときにこれをする意味があるかというと、空も見えないような濃い霧を表現する場合である。
ただし、「どうせフォグに覆われるからスカイボックスのテクスチャ（vtf）は何でもいい」と考えるのは間違い。
何故ならば、プレイヤーがスカイボックステクスチャの貼られた面に近づいた際は見えてしまうから。
つまり、この場合はスカイボックスのテクスチャはフォグと同一色の単色テクスチャにすれば良いということ。
この方法を採った場合、Far Zを（Fog Endより遠い距離に）設定するデメリットが全く無いので、忘れず設定しよう。

3Dスカイボックス内のフォグは、別途sky_camera内の設定項目で設定する必要があるので注意。（多くの場合、env_fog_controllerと同一の設定で良い）

**[ブ] func_dustcloud - もやっとした霧・砂埃（砂嵐）を発生させる
https://developer.valvesoftware.com/wiki/Func_dustcloud
でもなんだかテクスチャの境界が目立ってるような気がする・・・
func_smokevolumeのほうを選んだ方が良いような。

**[ポ] env_dustpuff - もやっとした霧・砂埃を発生させる（？）
https://developer.valvesoftware.com/wiki/Env_dustpuff
詳細不明。
試しに置いてみたら何も起こらなかった。機能してないのかも。使わなくていいでしょう。

**[ポ] env_steam - もくもくと上がる煙・陽炎を発生させる
https://developer.valvesoftware.com/wiki/Env_steam
煙突から上がる煙、車の排気ガスなどに使う。
陽炎（炎の上で奥が歪んで見えたりするアレ）を発生させることもできる。

**[ブ] func_smokevolume - もくもくとした煙を発生させる
https://developer.valvesoftware.com/wiki/Func_smokevolume
「ブラシエンティティ版env_steam」とでも言うべきか・・・
非常に薄い霧っぽいものを作る時はfunc_dustcloudよりこちらのほうが良い気がする。
スモークグレネードの煙用のテクスチャがデフォルトだが、これが案外バカにできない。
速度や透明度を弄ることで様々な用途に使える。

**[ポ] env_smokestack - もくもくと上がる煙を発生させる（？）
https://developer.valvesoftware.com/wiki/Env_smokestack
「低速・風の影響を受ける版env_steam」らしい。詳細不明。使わなくてよろしいかと。

**[ブ] func_dustmotes - ぱらぱらと舞う埃を発生させる
https://developer.valvesoftware.com/wiki/Func_dustmotes
地下室でライトに照らされながら舞ってそうな感じのあれ。
もしくは窓から差し込む光に照らされながら舞ってそうな感じのあれ。
工夫次第ではライトに群がる虫を再現できるかも？（若干くどいが）

----
*ロープ
https://developer.valvesoftware.com/wiki/Cables_and_Ropes
電線・ケーブルなどに。下記2つのエンティティを使って作れる。

**[ポ] move_rope
https://developer.valvesoftware.com/wiki/Move_rope
**[ポ] keyframe_rope
https://developer.valvesoftware.com/wiki/Keyframe_rope

----
*効果音・環境音・BGMなど
**[ポ] ambient_generic
https://developer.valvesoftware.com/wiki/Ambient_generic
単純に簡単に効果音や音楽を流すのはこっち。
wavと違って「ハンマーエディタ内で試聴できない」「ループできない」という制約がある(?)が、普通にmp3も使える。

**[ポ] env_soundscape
https://developer.valvesoftware.com/wiki/Env_soundscape
単純じゃないのはこっち。いろんな音のセットをランダムに流したりする。
スクリプトを書かないといけないので面倒くさい。でも書式は簡単。

----
*エンティティ以外の話
**ライティング関係のコンパイルオプション
https://developer.valvesoftware.com/wiki/VRAD
http://www.nodraw.net/2010/12/lighting-compile-options/
Expertコンパイルで、必要に応じて$light_exeのパラメーターにこれらのオプション（コマンド）を追加することで
コンパイルしたマップの用途に適した結果・コンパイル所要時間を得ることができる。

目的がギミック等の動作確認で、ライティングは必要無い場合は$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|アルファチャンネルを持つ、すなわち透けている部分があるテクスチャ（格子状など）の透明部分を光が通り抜けるようになる。&br()&br()ただしこのオプションを追加するだけだとprop_staticに効果が無い。prop_staticにも効果を及ぼさせるには、まず-staticproppolysと併用することが必要。そして"nmrih\light.rad"をテキストエディタで開き、一番上に新たな行を作成し（行を追加する場所はどこでもいいのだが、一番上にしておけば、後で自分が追加した行を見つけやすいだろう）&br()forcetextureshadow #&br()と書く。#には、「"nmrih\models\"以下の、効果を適用させたいモデル（mdl）のパス」を入れる。&br()例：forcetextureshadow props_foliage/tree_dead01.mdl&br()効果を適用させたいモデルが複数ある場合は、全てそれぞれ記述しなければならない。|
|-staticproppolys|全てのprop_staticが落とす影が、実際のpropに基づいた形になる。このオプションを使わない場合、影の形はバウンディングボックス（簡易的な衝突判定に使われる大雑把な形の箱）のものになってしまうので、ほぼ必須のオプション。|
|-staticproplighting|prop_static自体のライティング（prop_static自体が受ける影）がより現実的になる。このオプションを使わない場合の、prop_static自体のライティングについては、このページの項「prop_staticのVertex Lightingについて」を参照すること。基本的にデメリットが無い-textureshadows, -staticproppolysと違って、このオプションを使うとbspのファイルサイズがかなり増加する。とは言え基本的にファイルサイズに関してそこまで神経質になる必要は無いので、特に理由が無ければとりあえずこのオプションも付けておこう。|

**ライトマップスケール
https://developer.valvesoftware.com/wiki/Lightmap
テクスチャツールでブラシの面ごとにライトマップスケールを設定できる。
ライトマップスケールを細かく（小さい数値に）すればするほどその面のライティングがシャープになる。
これはグラデーションの表現力が失われる訳ではない。本来シャープになるべき場所がシャープになるだけ。
（正確にはグラデーションについても階調数が上がるためより綺麗になるが、見比べないと分からないレベル）

ライトマップスケールを細かくすることによるデメリットは、コンパイル時間やファイルサイズが倍増すること。
（※コンパイル時間はライティング計算にかかる時間、ファイルサイズはライトマップのサイズである）
単純にある面のライトマップスケールを16→1に変更すれば、その面のライティングに必要な時間とファイルサイズは16倍になる。
またライトマップが細かくコンパイルされたマップほど一度に多くの情報を描画するためゲーム側での負荷も上がるが、
これは極わずかであり一般的に体感できないレベル。

そして一番注意すべきデメリットは、1つのマップに存在できるライトマップのグリッド数には限界があるということ。
「リークなどのコンパイルエラーが発生していないのに、コンパイルのライティング計算が一瞬で終わり、
出来たマップをロードしてみるとmat_fullbright 1状態」であったらおそらく限界を超えてしまっている。
全ての面のライトマップスケールをデフォルトの16で作っている限りは、よほど巨大なマップでない限り限界には達しない。
しかし部分的にでも（デフォルトより）細かいスケールを使った場合案外簡単に達してしまう。

なおひとつの面に存在できるライトマップのグリッド数にも限度があり、
これを超えた場合はコンパイル時に自動でブラシが分割される。
これは基本的に特に気にする必要は無いが、切断された部分の線がゲーム内で見えてしまうことがある。
しかしそうなってしまったところで対処法は（スケールを大きい数値にする以外には）無いので、やはり気にしなくてよい。

まとめ：
-デフォルトの16はシャープさとコスト（コンパイル時間・ファイルサイズ）のバランスが一番とれた数値である。
基本的には16のままにしておき、細かいライティングが必要な面のみ小さい数値にするようにすると良い。上述の通り、16より大きい数値にすることによるコストの削減は効果が薄い。（製作段階のマップのコンパイルを早く済ませたい場合はvradコンパイルオプションの-luxeldensityを使うべき）
-プレイヤーから見えない面をNodrawテクスチャにすることは、ライトマップのコスト削減にも繋がる。Nodrawの面にはライティングの計算が必要無いため。地面の裏側のテクスチャをそのままにしている人などは大損をしている。
-最良の結果を得る方法は、「限界に達しない範囲で」「あなたが許容できるコンパイル時間内で」「シャープにしたい面のスケールを細かくする」ことである。ファイルサイズに関しては確かに倍増するのだが、そもそも上述の限界によって自動的にこれも制限されるため、マップ単体では100MBに達することすら不可能なのでほとんど気にする必要はない。（100MBと聞くと大きく聞こえるかもしれないが、カスタムコンテンツを使えばテクスチャだけで100MBを超えるのは容易である）

**マップの最適化
シンプルで小規模なアリーナ型マップ（どこにいてもマップの全体が見渡せるようなマップ）を作っているうちは
あまり意識する必要は無いが、現実的で大規模なマップを作るとなると「いかにコンパイル時間を短縮するか」
「いかにクライアントのフレームレートを稼ぐか」ということが割と重要になってくる。
そんな時はこれらのリンクを参考にしよう。（丸投げ）
[[Souce SDK wiki： コンパイルの高速化とパフォーマンスのアップ方法>http://wikiwiki.jp/sourcesdk/?%A5%B3%A5%F3%A5%D1%A5%A4%A5%EB%A4%CE%B9%E2%C2%AE%B2%BD%A4%C8%A5%D1%A5%D5%A5%A9%A1%BC%A5%DE%A5%F3%A5%B9%A4%CE%A5%A2%A5%C3%A5%D7%CA%FD%CB%A1]]
https://developer.valvesoftware.com/wiki/Tool_textures
https://developer.valvesoftware.com/wiki/Func_detail
https://developer.valvesoftware.com/wiki/Func_brush
https://developer.valvesoftware.com/wiki/Visibility_optimization
https://developer.valvesoftware.com/wiki/Areaportal
https://developer.valvesoftware.com/wiki/Func_areaportal
https://developer.valvesoftware.com/wiki/Func_areaportalwindow
https://developer.valvesoftware.com/wiki/Func_occluder
https://developer.valvesoftware.com/wiki/Hint_brush
色々な手段があるが、大体は「プレイヤーから見えない部分のポリゴンやテクスチャを描画させないようにする」ということ。
難しいことは良くわからなくても、プレイヤーから見えない部分のテクスチャをNodrawにする、
細かい装飾ブラシ（プレイヤーの視界を塞ぐだけの大きさが無いブラシ）をfunc_detailにするぐらいはやっておこう。

しかし最適な最適化を出来るということは、その軽減された負荷の分複雑なマップを作れるということなので、
もしかすると一番最初に習得しておいたほうが良いのかもしれない・・・
まあ時間も手間も掛かるのだが、どこで区切るかを考えたりするのはパズル的で結構楽しかったりする。

Nodrawテクスチャにはライトマップも焼きこまれないので、コンパイル時間の短縮にも一役買う。
prop_staticのフェード距離や、env_fog_controllerのFar Zを設定するのも効果的。（詳しくはそれぞれのページで）

**カスタムコンテンツ
デフォルトで入っているテクスチャなどでは物足りないと思ったら、自分で作った（或いはどこかから取ってきた）
カスタムコンテンツを入れるしかない。
しかしこれはとても面倒な作業で、何より面倒くさいのがコンパイル後のbspにそれらを埋め込む作業である。
埋め込む方法については「BSPZIP」や「Pakrat」と検索すると良い。
（Pakratは大抵のカスタムコンテンツを自動で埋め込んでくれるが、一部モデルのテクスチャなど、
自動では埋め込んでくれないものもある。そういう時は手動で探して埋め込む）

カスタムテクスチャのvmtファイルの書き方について日本語で解説しているサイト。
http://www.schuzak.jp/cs-s/tutCustomTex.html

**円柱や球体などの曲面を滑らかに見せる
https://developer.valvesoftware.com/wiki/Smoothing_groups
https://developer.valvesoftware.com/wiki/Hammer_Smoothing_Groups_Dialog
滑らかに見せたい面を全部選択してSmoothing Groupに入れるだけ。簡単だね。
ライトマップスケール16ではあまり滑らかに見えないが、細かくすればするほど滑らかに見えようになる。

**マップに草を生やす
https://developer.valvesoftware.com/wiki/Detail_prop
https://www.youtube.com/watch?v=mkZuSVgQFFo
マップに生やす草を（func_detailと紛らわしいが）detail props、もしくは単にdetailと言う。
これらを単独で配置する場合はprop_detailというエンティティ。
https://developer.valvesoftware.com/wiki/Prop_detail

**「点」でなく「面」で照らすライト
light_environmentのとこに書いてあります。

**スカイボックスの回転
スカイボックス自体は回転できない。マップをある程度作ったあとに、気になってしまうこともあるだろう。
そんな時にどうするかというと単にマップ全体を選択して90度単位で回転させる。おしまい。

**スカイボックスや環境光などの調和
それぞれのパートで散々言ってきたが、つまりはこういうこと。
&ref(a.jpg,,width=600)
まずlight_environmentをスカイボックスの明るい方角から、それっぽい色の光が差し込むように設定する。
そしてenv_sunをスカイボックスの明るい部分の方角・角度で、その部分に近い色に設定する。
最後shadow_controlを、ブラシが落とす影に近い色合いになるように調整する。
（別に自分が好きな順番でやっていいです）

左はfunc_physboxなのでダイナミックシャドウ、右は普通のブラシなのでライトマップに焼きこまれた影。
意識すると気づくと思うけど、プレイ中にぱっと見た分には気づかないレベルではなかろうか。
SunSpreadAngle：0にして、ライトマップスケール：1にするともっと区別がつきにくくなる。
もちろん、あくまでライトマップの影がメインなので何もダイナミックシャドウの方に合わせる必要は無いのだが。

でもここまでダイナミックシャドウを濃くて彩度が高いものにすると、影同士が重なったときに非常に気持ち悪いことになるので、
実際に遊ぶマップを作るときはもう少し大人しい色にするのが普通。

**prop_staticのVertex Lightingについて
Disable Vertex LightingというKeyvalueがあるが、これは基本的にNo（＝Vertex Lightingを使用する）で良い。

Vertex Lightingとは何かという話だが、これは雑に言えばライトマップのprop_static版みたいなものである。
Disable Vertex LightingがNoの状態では、プロップモデルのそれぞれの面が、ワールドブラシのようにある程度精細にライティングされる。（正確に言うと、それぞれの頂点ごとに光の色が焼き込まれる）
なおVertex Lightingは、$bumpmapと$phongを（片方でも）使用しているプロップモデルには対応していないらしい。

Disable Vertex LightingがYesの状態では、そのプロップモデルが受けるライティングは、そのprop_staticのモデルの「場所（光源に対する距離や角度）」の1点のみで決定される。（それぞれの頂点の位置は関係ない）

ちなみに、prop_static以外のプロップエンティティにはDisable Vertex LightingのKeyvalueが無い事から分かる通り、prop_dynamicやprop_physics、武器やプレイヤーキャラクター等はVertex Lightingされず、Ambient lightと呼ばれる全く別の方法でライティングされる。
https://developer.valvesoftware.com/wiki/Ambient_light

**3Dスカイボックス
http://wikiwiki.jp/sourcesdk/?Skybox
「プレイヤーが歩きまわるマップ本体」と完全に独立した場所に、「ミニチュアサイズの遠景（3Dスカイボックス）」を作り、
実際のゲーム内ではそのミニチュア遠景を拡大して、本体の背景にピッタリ当てはめるというもの。

「え、なんでわざわざそんな面倒臭いことする必要があるの？本体に全部作っちゃえばいいじゃん」と思うかもしれない。
しかし、3Dスカイボックスはミニチュアサイズという特性上「等倍（本土）では再現できないほどの広さを再現できる」
「テクスチャが小さくなる分負荷を減らせる」という特徴がある。

sky_camera内で本体に対する3Dスカイボックスの縮尺率を変更できるが、これはデフォルトの1/16のままにしておくのが吉。
理由は3Dスカイボックス用に作られた1/16サイズのモデルを配置できるのは、1/16の3Dスカイボックスだけだからである。
モデルを拡大・縮小することが出来ないSourceエンジンでは、3Dスカイボックス用のモデルを本土に使うことも、その逆もできない。

位置合わせについては少しでもズレているとおかしなことになるので、しっかりと行うことをお勧めする。
あくまで遠景なので、本体に接続された（ように見える）3Dスカイボックス領域に、そのままプレイヤー等が立ち入ることは出来ない。
テレポーターを使えばプレイヤーが入ることが出来るが、ネタ以外でやる意味は無い。

この3Dスカイボックスを作成する際に見落とされがちなのが、「本体と3Dスカイボックスは、お互いライティングに影響しない」ということ。
「本体のブラシの影が3Dスカイボックスに出来ない」という問題は、本体から3Dスカイボックス領域に持っていった
（本来位置合わせ用としてのみ使う）ブラシを削除せずにBlock Lightテクスチャを貼ることで回避できる。

*マッピング：ビジュアル強化Tips
このページでは、マップの見た目を強化する様々なエンティティや方法を紹介します。
軽く知ったかぶりして書いた部分もあるので絶対正しいとは思わないでおいてください。
説明が長くて細かい項目ほどその傾向が強いです。

[ポ]＝ポイントエンティティ、[ブ]＝ブラシエンティティ
----
#contents
----
*全般
**[ポ] env_cubemap - キューブマップを撮影するポイント
https://developer.valvesoftware.com/wiki/Env_cubemap
テクスチャに風景が映り込む時、その風景として使用されるのが全方位を6枚の画像で表したキューブマップ。
これは予めゲーム内で（マップ作者が）撮影するもので、自動的にbspに埋め込まれる。撮影方法は後述。
つまりその反射する風景は、周りの環境が変化（壁の破壊や、ライトのオン/オフなど）しても変わらないことに注意が必要。
ブラシの反射に使用されるenv_cubemapはコンパイル時に確定され、例えそのブラシが移動しても推移はしない。
モデルの反射には、常に最短距離にあるenv_cubemapが使用される。
フェードなどはせず、モデルが2つのenv_cubemapの中間地点を通過した時点で瞬時に切り替わる。

Sourceエンジンでは、水面のテクスチャと、鏡（func_reflective_glass）以外の反射は全てキューブマップ反射である。
つまり、表面の「反射≒光沢感」の表現にはほぼ必ずキューブマップが使われるということ。

このエンティティをいくつ・どこに配置するかだが、明確なルールというのは存在しない。
よっぽど変な配置にしない限り不自然にはならないので、そこまで神経質になる必要はない。
ちなみにマップを作りながら置いていくより、ほぼ作り終わってから最後に置くほうが良い。
屋外では適当に置いてしまえばOK。特に理由が無ければプレイヤーのアイレベルである地上64ユニットがおすすめ。
屋内では、1部屋につき1つというのが定番。部屋の構造やサイズに応じて増やそう。
天井がプレイヤー2人が縦に入らないぐらいの高さの部屋では、アイレベルに配置するより、
地面と天井のちょうど中心に配置するほうがより自然に見えるだろう。

また単一/複数のブラシの面をpickすることができる。pickされた面の反射にはそのenv_cubemapのキューブマップが使用される。
窓は一般的に反射した風景が目立ちやすいので、すぐ前にenv_cubemapを配置してpickしておくといいだろう。
pickされていない面は、コンパイル時に最短距離のenv_cubemapを使用する。基本的にpickするのは窓と水面（下記）だけで良いが、
同一面（ここでは高さが同じという意味）を複数のブラシが構成している場合に、
使用されるenv_cubemapが異なっている「境界」が出来て目立ってしまうことがある。
この場合は付近のenv_cubemapを削除し1個に絞るか、もしくは手作業で面をpickしていくしかない。（前者はあまりお勧めしない）
またその面の裏側にあるenv_cubemapが使われてしまっている場合にも手動でpickしてやる必要がある。

また水面も、設定やテクスチャによってはキューブマップ反射が使われることがあるので、
必ず水面上（最適な高さは場合によって異なるのでなんとも言えない）の中心近くにenv_cubemapを配置してpickすること。
複数のブラシを繋げて単一の水面を表現するときは、それぞれにenv_cubemapを配置するよりも、
単一のenv_cubemapで複数pickしたほうが自然に見える場合が多い。これは上記の「境界」が目立ってしまうことが多いから。
逆に、それぞれにenv_cubemapを配置したほうが良いのは、
「地下水路・洞窟など単一水面上で場所によって（反射すべき）景色が大きく変わる場合」である。

ちなみにそれぞれのenv_cubemapで解像度を変更できる。
大きくすればするほど反射する風景が精細になるが、その分ファイルサイズが大きくなるので注意しよう。多少は負荷も上がる。
また解像度が高いということは細かい部分まで見えてしまうということなので、逆に不自然になってしまうこともある。
デフォルトの解像度は多くの状況においてバランスが取れている。悩むようならば変更しなくて良い。

言葉で説明すると非常に難しく感じられるが、一度理解してしまえば単純な話である。
いまいち理解できないという人は、公式マップでSako85を持って歩き回ってみるといい。スコープの反射に注目。

※キューブマップはコンパイル毎に、HDR用とLDR（非HDR）用のものをゲーム内で撮影しなければいけない。
https://developer.valvesoftware.com/wiki/Cubemaps

**[ポ] color_correction - 画面全体の色調を調整する
https://developer.valvesoftware.com/wiki/Color_correction_%28entity%29
カラーコレクション略してカラコレ
ゲーム内で実際に試しながら調整できるので非常にお手軽。
ただし実際の効果が作った時（調整した時）より強くなってしまうことがあるらしい。
（その場合の対処法も下のリンクに書いてある）
仕上げの際は是非試してみよう。ちょっと色調を変えたいけど、ライトを弄るのは面倒くさいなんて時にも使える。
これを使っても希望の色調にできないというときは手間はかかるがライトの設定を見直していこう。
ただし設定で色調整をオフにしているプレイヤーには効果が無いので注意。
https://developer.valvesoftware.com/wiki/Color_correction
ブラシエンティティはcolor_collection_volume。面倒なので別項目作りません。
https://developer.valvesoftware.com/wiki/Color_correction_volume

**[ブ] func_reflective_glass - リアルタイム反射の鏡
https://developer.valvesoftware.com/wiki/Func_reflective_glass
あまり安定したエンティティでは無いので、配置によっては鏡が乱れてしまうことがある。
それと言うまでもないかもしれないが、映り込むオブジェクトが多い場合はその分負荷もかかる。

**[ブ] func_precipitation - 雨・雪を降らせる
https://developer.valvesoftware.com/wiki/Func_precipitation
Precipitation Type：Snowは謎の雨っぽい何かなので雪はSnowfallのほうを使おう。
Density最大でも物足りない時は、ブラシを複製して重ねてみよう。

**[ポ] env_fire - 炎
https://developer.valvesoftware.com/wiki/Env_fire
説明不要。lightと一緒に置くと良い。

**[ポ] env_spark - 火花
https://developer.valvesoftware.com/wiki/Env_spark
説明不要。

**[ポ] env_explosion - 爆発
https://developer.valvesoftware.com/wiki/Env_explosion
どっかーん

**[ポ] info_particle_system - パーティクル
https://developer.valvesoftware.com/wiki/Info_particle_system
パーティクルというのは、ある地点から振ってくる枯れ葉であったり、ある地点から空に向かう炎だったりする。

もう少し詳しく説明すると。これは、パーティクルエディターで、素材の画像を「どんな風に出現させる（頻度や位置など）」
「どんな風に消滅させる（消滅までの時間やフェードアウトなど）」「どんな風に動かす（速度や方向など）」
「重力の影響を受ける/受けない」「地面やプレイヤー等と接触する/しない」などの設定をしてやることで、
動くパーティクルになる。素材の画像と、様々な「挙動の設定」が組み合わさって1つの動くパーティクルになっているのである。

やはりと言うか、パーティクルディターは非常に複雑で難しいが、希望であれば自分でパーティクルを作成することもできる。
とりあえず自分に作れるか判断したい場合はこの動画を見ると良い。
https://www.youtube.com/watch?v=70GhO6z5aKM
40分あるが、これを見れば使いこなせるようになるというようなものでもない。

env_fireやenv_steamなどもパーティクルの一種だが、使用頻度が高く、ハンマーエディタ内で
色々パラメーターを弄れたほうが便利なので独立したエンティティになっているというわけ。
NMRiHでよく見かけるinfo_particle_systemとしてはパトカーの回転灯がある。

**[ポ] env_wind - マップ全体の風を設定する
https://developer.valvesoftware.com/wiki/Env_wind
詳細不明。主にロープを揺らす用？

**[ポ] env_tonemap_controller
https://developer.valvesoftware.com/wiki/Env_tonemap_controller
HDRについて定義するエンティティだが私はまだ使ったことがないので詳しいことはよく分からない。
どうやら光彩の開け閉め（のシミュレーション）のしきい値を設定するらしい。
そもそも普通は皆デフォルトのHDRに合わせてライティングを組んでいると思うので、基本的には使う必要は無いだろう。
どうしてもHDRの挙動が鼻についた時は使ってみると良いかと。下のページも参考に。
https://developer.valvesoftware.com/wiki/HDR_Lighting_Settings

HDRというよりマップ全体の色調が気に入らない？ならばcolor_correctionへGO

----
*ライティング・ライトの表現
**[ポ] light_environment - 屋外の環境光を設定する
https://developer.valvesoftware.com/wiki/Light_environment
日中ならば太陽光、夜中ならば月明かりの色調や角度を設定する。ライトマップに焼きこまれる。このエンティティによって設定されるライトは、スカイボックステクスチャを貼った場所全てが光源になる。

屋外中心のマップなら全体の雰囲気を決める大切なエンティティ。このエンティティの設定によって時間帯だけでなく、（雰囲気的な）気温や湿度の表現もできる。ただし、やはりスカイボックスのテクスチャと調和するように設定しなければならない。透き通った青空なのに屋外が真っ暗では怖いし、逆も然り。また、「スカイボックスに見える太陽/月の方向に影が伸びている」等といった事態も避けるようにしたい。

なお初心者が良くやりがちな手抜きとして、「Pitch Yaw Roll,PitchとBrightnessしか弄らない」というのが挙げられる。確かにBrightnessだけで光の色や明るさは一応設定できるのだが、よりリアルで美しい自然な環境光の表現には
他のKeyvalueでの調整が不可欠である。詳しくは下で説明するが、重要なのはBrightnessよりもAmbientである。

#region(太陽の角度の設定)
太陽の角度の設定
まずPitch Yaw Roll (Y Z X)のYaw(Z)で太陽の方角を指定する。これのPitch(Y)は無視されるし、Roll(X)も普通は使わないので0で良い。次にPitchで太陽の高度を指定する。マイナスの値で上からの光、プラスの値で下からの光になる。後者の使い道はあまり無い。

方角はスカイボックスの太陽に合わせてしっかり合わせよう。多少ずらすぐらいならバレにくい。高度は方角より自由度がある。
#endregion

#region(SunSpreadAngleについて)
SunSpreadAngleについて
言葉で説明するよりこのリンクの画像を見てもらったほうが早いだろう。
http://www.nodraw.net/2011/01/sunspreadangle/
太陽が出ている時間帯のマップでは3～5あたりが使いやすい値だが、もっと数値を下げたほうがいい場合もあるし、逆もある。太陽がかんかんと照りつける昼間を表現したければ思い切って0にしてしまう手もある。
夜のマップでBrightnessを1以上にするなら数値を大きめにしたほうが良い。（Brightnessが0だと方向のある陰影はつかない）
#endregion

#region(Ambientについて)
Ambientについて
スカイボックスの全方向からマップ全体を包み込むように照らしてくる光。
#endregion

#region(Brightnessについて)
Brightnessについて
上で説明した、指定した方角・高度からのみ平行に照らしてくる光。基本的に太陽または月明かりを表現するのに使う。
曇り・霧の日や、夜のマップでは小さい数値またはゼロでもよい。
#endregion

#region(その他の設定項目について)
その他の設定項目について
http://www.youtube.com/watch?v=ot8Wjvx7b6A
を見れば分かるはず。一応以下に言葉でも書いておく。
|BrightnessHDR, AmbientHDR|HDR有効時のみそれぞれBrightness,Ambientの値をこれで置き換える。デフォルトの[-1 -1 -1 1]のままで良い。|
|AmbientScaleHDR|値を上げると影が薄くなっていくが、光が当たっている部分も少しずつ明るくなっていく。あまりこの項目は弄らずにBrightness,Ambientのほうで調整したほうが良いだろう。（HDR無効時とのギャップを小さくするためにも）|
|BrightnessScaleHDR|値を上げると光が当たっている部分がHDRでもっとギラギラする。要はHDRのコントラスト調整みたいなもの。もっと画にメリハリをつけたければ上げて、目に優しくするには下げる。|
これらは他のライト（light, light_spot）には影響しないことに注意しよう。
またビジュアルにこだわる以上当たり前のことであるが、マップを作るときはHDR有効時を基準にしよう。
#endregion

満足の行く設定を見つけるには試行錯誤が必要になるのでゆっくり時間をかけて調整しよう。
せっかく造形はよく出来ているのにライティングが残念なせいで全体的に安っぽくなってしまっているマップも見かける。
逆にライティングによってある程度手抜きっぽさを軽減することだってできる。（特に夜のマップ）

屋内オンリーのマップで、外の景色を作る労力が割に合わない場合は
よくtools/toolsblackやtools/toolswhiteテクスチャが使われる。
（必要に応じて単色のテクスチャを自作するのも良い）
テクスチャライト（発光テクスチャ）を使うことで、窓から差し込む日光などを擬似的に表現することもできる。
http://simonbarsky.com/blog/?page_id=29
ただしこれは光が差し込む角度まで再現することはできない。（[[この画像>http://www.simonbarsky.com/blog/wp-content/uploads/2007/03/lightingShaft.jpg]]のようにすれば可能）
もちろんこの発光テクスチャには他にも色々な使い道がある。
lightやlight_spotと違い到達距離（Constant/Linear/Quadratic及びfallof distance）が設定できないのは辛いが、
それらの「点」と違って「面」として照らすことができるからだ。（正確には、点を一定の密度で敷き詰めているようだが）
発光テクスチャを貼ったブラシをfunc_brush化して、Don't Renderにすると光源単体で使えることも覚えておこう。

**[ポ] light - 全方位を照らすライト
https://developer.valvesoftware.com/wiki/Light
主に室内のライトに使う。ライトマップに焼きこまれる。
light_spot（+light_environment）と合わせて、ライトマップに焼きこまれるライトを「Static Light」と言う。
あまり壁に近づけるとそこが明るくなりすぎるので、いろいろ試しながら最適な位置・到達距離を見極めよう。

#region(以下はlight_spotにも当てはまる注意点。)
以下はlight_spotにも当てはまる注意点。
-コンパイル時にライトマップに焼きこまれるものなので移動させることはできない。
-入力によってライトをオン・オフできるが、コンパイル時に起こりうる全てのパターンを計算する必要があるため限界がある。こればかりは古いエンジンなので仕方が無い。例えば、2個の独立した名前を持つ（≒オン・オフ可能な）ライトがあれば「ABオン」「AオンBオフ」「AオフBオフ」「ABオフ」という4パターン全てのライトマップが焼きこまなければならない。独立した名前を持つライトが更に増えればパターンは増えて行き、すぐに限界（32パターン）にぶち当たってしまうだろう。（※限界に達しなければ良いという訳ではない。パターンが多いほどライトは不自然になる）ライトに名前を付けるだけでコンパイラーは「このライトはオン・オフする可能性があるんだ」と判断してしまう。そのためオン・オフしないライトでも、名前を付けるだけでコンパイル時間・ファイルサイズが増加してしまうことに注意。そして、同時にオン・オフするライトには全て同じ名前をつけること。そうすれば名前1つで複数のライトに入力できる。ということで、少しずつ部屋のライトをつけていくようなマップを作ろうとしているなら今すぐ白紙に戻そう。
-Appearanceによって点滅させることができるが、かなりクライアントに負荷が掛かるので乱用は絶対にNG。単純にフレームレートが落ちるだけでなくカクつくようになってしまう。出来ることなら点滅するlightがプレイヤーの視界に同時に複数入ることがないようにしよう。（1つだけでも割と重い）
#endregion

**[ポ] light_spot - ある一点を照らすライト
https://developer.valvesoftware.com/wiki/Light_spot
ライトマップに焼きこまれる。下向きの街灯や、車のヘッドライトなどに使う。

室内の天井に付いているライトはlightで無いといけないと思い込んでいる人が多いが、実は下向きのlight_spotでも良い。
しかし普通に下向きのlight_spotを置くだけだと天井が真っ暗になってしまう可能性が高い。
これは、床（直接光が当たっている場所）から照り返す光が少なすぎるからである。この照り返しのことを「Bounce」と言う。
このBounceする量（強さ）は、デフォルトではテクスチャのvtfファイルに埋め込まれているが、
vmtファイルの$reflectivityパラメータで上書きすることができる。
https://developer.valvesoftware.com/wiki/$reflectivity
http://www.nodraw.net/2011/02/reflectivity/
通常、既存のテクスチャのvmtファイルのパラメータを編集したい場合、
（例として、パラメータを編集するvmtは「example.vmt」とする。）
+「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パラメータはマップのコンパイル時のみに参照されるため。
念のため逆の言い方もしておくと、コンパイル後に$reflectivityを編集しても効果は無い。

**[ポ] light_dynamic - ダイナミックライト
https://developer.valvesoftware.com/wiki/Light_dynamic
ライトマップに焼きこまれない、ゲーム側でリアルタイムで計算されるダイナミックライト。
ライトの光の形はlight_spotと同じスポットライト型で、lightのような無指向性のダイナミックライトは作れないらしい。
light_spotとの違いは、「Parentingして動かせる」「色を変えられる」「オン・オフに制限が無い」
「ゲーム側の負荷が高い」「見た目はlight_spotに比べてかなり簡易的」といったところ。

このエンティティは調整がとても難しいらしい。とりあえず上記ページに書いてある注意点だけ転載。
|実はこのエンティティのライトは、「モデルのみを照らすライト」と、「ワールド（ブラシ）のみを照らすライト」の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のみ。
Glowは距離に関わらず同じサイズで表示される。主に遠景に使う。近づくとフェードアウトするようにして、
「遠くからみると眩しかったが、近づいたら目が慣れた」という表現をしたい場合にも使える。
World Space Glowは近づけば大きく、離れれば小さくなる。こっちのほうが使う機会は多いんじゃないかな。

なおこちらはStatic Lightと違い、好きなだけAppearanceで点滅させて大丈夫。ほとんど負荷にならない。
「だったらStatic Lightはつけっぱなしでenv_spriteだけ点滅させればいんじゃね？」「やめたほうがいいかと」

**[ポ] env_sun - 太陽（たまに月）
マップ内の何処にプレイヤーがいても、視界に入っている場合は同じ方角・角度に表示されるenv_spriteのようなもの。
スカイボックスの中にあるように見えるenv_spriteと言ったほうが伝わりやすいだろうか。
このエンティティは必須では無い。使う場合はligh_environmentと同じく、スカイボックスのテクスチャに対して
自然に見える色・角度を設定しなければならない。（必ずしも全く同じPitch Yaw Rollで無ければいけない訳では無い）
使用するスカイボックスに太陽が描き込まれていない場合、描き込まれているが大げさに表現したい場合などが主な用途。
特に後者の場合は角度合わせに細心の注意を払う必要がある。

**[ポ] env_lightglow - トンネルの出口とかで眩しくなるやつ
https://developer.valvesoftware.com/wiki/Env_lightglow
元々HDRの効果で、暗いところから明るいところを見ると眩しく見えるが、それをより大げさに演出したいときに使う。
別にトンネル出口に限ったことではないが、主に使われるのはトンネルや洞窟だろう。
用途としてはenv_spriteに似ているがこちらはテクスチャを使わず、Keyvaluesで形を設定する。

**[ポ] env_projectedtexture - プロジェクターのようなもの
https://developer.valvesoftware.com/wiki/Env_projectedtexture
一応使えるが、影の解像度が低くノイズのような不気味なザラザラが乗るので使用に値しない。
#region(旧解説)
ポイントエンティティで、明るさや角度を設定できるという点ではlight_spotに似ているが、本質的には全くの別物。
このエンティティは、プレイヤーのフラッシュライトと同じ原理でテクスチャを投射する。ライトマップには焼きこまれない。
light_spotで無くこちらを選択する意味は「オン/オフしてもライトマップを増やさない」「移動ができる」
「遮られた部分が影になるので、動的・精細な影を作れる」の3つ。
ちなみにshadow_controlでダイナミックシャドウをオンにしている場合は影が不自然になってしまう可能性があるので注意しよう。
また光が直接当たっていないところも反射して柔らかく明るくするlight_spotなどと違い、遮られた部分は全く明るくされない。
env_projectedテクスチャを使うエリアの元々の明るさをしっかり調整しておく必要がある。
$bumpmapが指定されていないモデルはこのエンティティによって照らされず、不自然に暗くなってしまう。

Portal2ではこのエンティティがこれでもかというほど多用されているので、イマイチ使いどころが分からないという人はプレイしてみると良い。
#endregion

**[ポ] shadow_control - マップ全体のダイナミックシャドウを設定する
https://developer.valvesoftware.com/wiki/Shadow_control
ダイナミックシャドウとは、マップ内で動くオブジェクト（prop_physic,prop_dynamicなど）が落とす影のこと。
「動くオブジェクト」とは、prop_dynamic, prop_physics, func_physboxに加えてプレイヤーやNPCなども該当する。

屋外オンリーのマップであれば、light_environmentに調和するように設定すればとりあえずそれだけでも良い。
|[設定例]|light_environment|shadow_control|
|Pitch Yaw Roll (Y Z X)|0 108 0|45 108 0|
|Pitch|-45|（なし）|
しかし不便なことにダイナミックシャドウはマップ全体で同じ角度・色で落とされてしまうので、
屋外と屋内が混在するマップなどでは非常に厄介なことになる。
（例えば夕方の人から伸びる影はとても長いが、屋内に入っても影の長さが同じだったら不気味なのは想像に難くないだろう）
そういうマップでは「角度を直角（直下）に近づける」「彩度を下げる」「ダイナミックシャドウをオフにする」などの妥協が必要になってくるだろう。
ただし角度を完全な直角にするのはやめたほうがいい。人の影の形がかなり不自然に見えちゃうの。最低5度ぐらい？はずらしましょう。
あと最大距離も大きくしすぎると上の階の影が貫通して見えてしまったりする（ダイナミックシャドウには「遮られる」という概念が無い）ので小さ目に。

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の「ライティングを決める場所」を、このエンティティの場所で上書きすることができる。
また、めり込んだプロップ以外でも、少しだけ光源に近づけたり離したりして、微調整に使うこともできる。
と言ってもよく分からないと思うのでこの[[チュートリアル動画>http://www.youtube.com/watch?v=aV4rBlRJ5Bo]]を見ると良い。
普通、対象のprop_staticの近くに配置するものだが、全く別の場所に配置することもできる。
（暗い部屋の真ん中にあるテーブルに、明るい部屋に置いたinfo_lightingを指定させれば、
そのテーブルだけ不気味に明るくできる）

-staticproplightingオプションを付けている場合、$bumpmapを使用していないプロップモデルには使用できなくなる。
（$bumpmapを使用していないプロップモデルはVertex Lightingされる）

なおこのエンティティと同様の効果をprop_dynamicで得たい場合はinfo_targetを使う。
prop_physicsにはLighting Originを設定できないので同様の効果を得ることは不可能。

----
*煙・霧・埃などの表現
**[ポ] env_fog_controller - マップ全体のフォグを設定する
https://developer.valvesoftware.com/wiki/Env_fog_controller
まず聞かれる前に書いておくが、マップの特定の場所にのみフォグを発生させるエンティティは残念ながら無い。

いわゆる霧であるが、サイレントヒルでも作らない限り濃霧など滅多に必要無いので、
実際にはFar Z（最大描画距離）の設定による負荷軽減が目的で使われることが多い。
もちろん、これに頼る前にできる限りの最適化をしたほうが絵的に映えるのは言うまでもない。
本来霧や負荷軽減が必要ないマップでも、弱めに（遠めに）フォグをかけてやると雰囲気を高めることができるかも。

フォグは、Fog Startの距離からかかり始め、Fog Endの距離以降の全てのオブジェクトは完全にフォグの色に覆われる。
Far Zを設定した場合は、その距離以降のオブジェクトは描画されない。（大抵の場合、スカイボックスが透けて見える）
そのためFar ZはFog Endより大きな値にするのが普通であるが、Far Z≦Fog Endで不自然さが無いマップもあるので一概には言えない。
Far Z設定の如何に関わらず、フォグの色は覆われたオブジェクトの裏に見えるスカイボックスの色に近づけたほうがよい。

通常スカイボックスのテクスチャはvmtで$nofog 1とされているため、スカイボックスは絶対にフォグに覆われないが、
スカイボックスのテクスチャを自作する場合はその記述を削除することによってフォグに覆われるようにすることができる。
どんなときにこれをする意味があるかというと、空も見えないような濃い霧を表現する場合である。
ただし、「どうせフォグに覆われるからスカイボックスのテクスチャ（vtf）は何でもいい」と考えるのは間違い。
何故ならば、プレイヤーがスカイボックステクスチャの貼られた面に近づいた際は見えてしまうから。
つまり、この場合はスカイボックスのテクスチャはフォグと同一色の単色テクスチャにすれば良いということ。
この方法を採った場合、Far Zを（Fog Endより遠い距離に）設定するデメリットが全く無いので、忘れず設定しよう。

3Dスカイボックス内のフォグは、別途sky_camera内の設定項目で設定する必要があるので注意。（多くの場合、env_fog_controllerと同一の設定で良い）

**[ブ] func_dustcloud - もやっとした霧・砂埃（砂嵐）を発生させる
https://developer.valvesoftware.com/wiki/Func_dustcloud
でもなんだかテクスチャの境界が目立ってるような気がする・・・
func_smokevolumeのほうを選んだ方が良いような。

**[ポ] env_dustpuff - もやっとした霧・砂埃を発生させる（？）
https://developer.valvesoftware.com/wiki/Env_dustpuff
詳細不明。
試しに置いてみたら何も起こらなかった。機能してないのかも。使わなくていいでしょう。

**[ポ] env_steam - もくもくと上がる煙・陽炎を発生させる
https://developer.valvesoftware.com/wiki/Env_steam
煙突から上がる煙、車の排気ガスなどに使う。
陽炎（炎の上で奥が歪んで見えたりするアレ）を発生させることもできる。

**[ブ] func_smokevolume - もくもくとした煙を発生させる
https://developer.valvesoftware.com/wiki/Func_smokevolume
「ブラシエンティティ版env_steam」とでも言うべきか・・・
非常に薄い霧っぽいものを作る時はfunc_dustcloudよりこちらのほうが良い気がする。
スモークグレネードの煙用のテクスチャがデフォルトだが、これが案外バカにできない。
速度や透明度を弄ることで様々な用途に使える。

**[ポ] env_smokestack - もくもくと上がる煙を発生させる（？）
https://developer.valvesoftware.com/wiki/Env_smokestack
「低速・風の影響を受ける版env_steam」らしい。詳細不明。使わなくてよろしいかと。

**[ブ] func_dustmotes - ぱらぱらと舞う埃を発生させる
https://developer.valvesoftware.com/wiki/Func_dustmotes
地下室でライトに照らされながら舞ってそうな感じのあれ。
もしくは窓から差し込む光に照らされながら舞ってそうな感じのあれ。
工夫次第ではライトに群がる虫を再現できるかも？（若干くどいが）

----
*ロープ
https://developer.valvesoftware.com/wiki/Cables_and_Ropes
電線・ケーブルなどに。下記2つのエンティティを使って作れる。

**[ポ] move_rope
https://developer.valvesoftware.com/wiki/Move_rope
**[ポ] keyframe_rope
https://developer.valvesoftware.com/wiki/Keyframe_rope

----
*効果音・環境音・BGMなど
**[ポ] ambient_generic
https://developer.valvesoftware.com/wiki/Ambient_generic
単純に簡単に効果音や音楽を流すのはこっち。
wavと違って「ハンマーエディタ内で試聴できない」「ループできない」という制約がある(?)が、普通にmp3も使える。

**[ポ] env_soundscape
https://developer.valvesoftware.com/wiki/Env_soundscape
単純じゃないのはこっち。いろんな音のセットをランダムに流したりする。
スクリプトを書かないといけないので面倒くさい。でも書式は簡単。

----
*エンティティ以外の話
**ライティング関係のコンパイルオプション
https://developer.valvesoftware.com/wiki/VRAD
http://www.nodraw.net/2010/12/lighting-compile-options/
Expertコンパイルで、必要に応じて$light_exeのパラメーターにこれらのオプション（コマンド）を追加することで
コンパイルしたマップの用途に適した結果・コンパイル所要時間を得ることができる。

目的がギミック等の動作確認で、ライティングは必要無い場合は$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|アルファチャンネルを持つ、すなわち透けている部分があるテクスチャ（格子状など）の透明部分を光が通り抜けるようになる。&br()&br()ただしこのオプションを追加するだけだとprop_staticに効果が無い。prop_staticにも効果を及ぼさせるには、まず-staticproppolysと併用することが必要。そして"nmrih\light.rad"をテキストエディタで開き、一番上に新たな行を作成し（行を追加する場所はどこでもいいのだが、一番上にしておけば、後で自分が追加した行を見つけやすいだろう）&br()forcetextureshadow #&br()と書く。#には、「"nmrih\models\"以下の、効果を適用させたいモデル（mdl）のパス」を入れる。&br()例：forcetextureshadow props_foliage/tree_dead01.mdl&br()効果を適用させたいモデルが複数ある場合は、全てそれぞれ記述しなければならない。|
|-staticproppolys|全てのprop_staticが落とす影が、実際のpropに基づいた形になる。このオプションを使わない場合、影の形はバウンディングボックス（簡易的な衝突判定に使われる大雑把な形の箱）のものになってしまうので、ほぼ必須のオプション。|
|-staticproplighting|prop_static自体のライティング（prop_static自体が受ける影）がより現実的になる。このオプションを使わない場合の、prop_static自体のライティングについては、このページの項「prop_staticのVertex Lightingについて」を参照すること。基本的にデメリットが無い-textureshadows, -staticproppolysと違って、このオプションを使うとbspのファイルサイズがかなり増加する。とは言え基本的にファイルサイズに関してそこまで神経質になる必要は無いので、特に理由が無ければとりあえずこのオプションも付けておこう。|

**ライトマップスケール
https://developer.valvesoftware.com/wiki/Lightmap
テクスチャツールでブラシの面ごとにライトマップスケールを設定できる。
ライトマップスケールを細かく（小さい数値に）すればするほどその面のライティングがシャープになる。
これはグラデーションの表現力が失われる訳ではない。本来シャープになるべき場所がシャープになるだけ。
（正確にはグラデーションについても階調数が上がるためより綺麗になるが、見比べないと分からないレベル）

ライトマップスケールを細かくすることによるデメリットは、コンパイル時間やファイルサイズが倍増すること。
（※コンパイル時間はライティング計算にかかる時間、ファイルサイズはライトマップのサイズである）
単純にある面のライトマップスケールを16→1に変更すれば、その面のライティングに必要な時間とファイルサイズは16倍になる。
またライトマップが細かくコンパイルされたマップほど一度に多くの情報を描画するためゲーム側での負荷も上がるが、
これは極わずかであり一般的に体感できないレベル。

そして一番注意すべきデメリットは、1つのマップに存在できるライトマップのグリッド数には限界があるということ。
「リークなどのコンパイルエラーが発生していないのに、コンパイルのライティング計算が一瞬で終わり、
出来たマップをロードしてみるとmat_fullbright 1状態」であったらおそらく限界を超えてしまっている。
全ての面のライトマップスケールをデフォルトの16で作っている限りは、よほど巨大なマップでない限り限界には達しない。
しかし部分的にでも（デフォルトより）細かいスケールを使った場合案外簡単に達してしまう。

なおひとつの面に存在できるライトマップのグリッド数にも限度があり、
これを超えた場合はコンパイル時に自動でブラシが分割される。
これは基本的に特に気にする必要は無いが、切断された部分の線がゲーム内で見えてしまうことがある。
しかしそうなってしまったところで対処法は（スケールを大きい数値にする以外には）無いので、やはり気にしなくてよい。

まとめ：
-デフォルトの16はシャープさとコスト（コンパイル時間・ファイルサイズ）のバランスが一番とれた数値である。
基本的には16のままにしておき、細かいライティングが必要な面のみ小さい数値にするようにすると良い。上述の通り、16より大きい数値にすることによるコストの削減は効果が薄い。（製作段階のマップのコンパイルを早く済ませたい場合はvradコンパイルオプションの-luxeldensityを使うべき）
-プレイヤーから見えない面をNodrawテクスチャにすることは、ライトマップのコスト削減にも繋がる。Nodrawの面にはライティングの計算が必要無いため。地面の裏側のテクスチャをそのままにしている人などは大損をしている。
-最良の結果を得る方法は、「限界に達しない範囲で」「あなたが許容できるコンパイル時間内で」「シャープにしたい面のスケールを細かくする」ことである。ファイルサイズに関しては確かに倍増するのだが、そもそも上述の限界によって自動的にこれも制限されるため、マップ単体では100MBに達することすら不可能なのでほとんど気にする必要はない。（100MBと聞くと大きく聞こえるかもしれないが、カスタムコンテンツを使えばテクスチャだけで100MBを超えるのは容易である）

**マップの最適化
シンプルで小規模なアリーナ型マップ（どこにいてもマップの全体が見渡せるようなマップ）を作っているうちは
あまり意識する必要は無いが、現実的で大規模なマップを作るとなると「いかにコンパイル時間を短縮するか」
「いかにクライアントのフレームレートを稼ぐか」ということが割と重要になってくる。
そんな時はこれらのリンクを参考にしよう。（丸投げ）
[[Souce SDK wiki： コンパイルの高速化とパフォーマンスのアップ方法>http://wikiwiki.jp/sourcesdk/?%A5%B3%A5%F3%A5%D1%A5%A4%A5%EB%A4%CE%B9%E2%C2%AE%B2%BD%A4%C8%A5%D1%A5%D5%A5%A9%A1%BC%A5%DE%A5%F3%A5%B9%A4%CE%A5%A2%A5%C3%A5%D7%CA%FD%CB%A1]]
https://developer.valvesoftware.com/wiki/Tool_textures
https://developer.valvesoftware.com/wiki/Func_detail
https://developer.valvesoftware.com/wiki/Func_brush
https://developer.valvesoftware.com/wiki/Visibility_optimization
https://developer.valvesoftware.com/wiki/Areaportal
https://developer.valvesoftware.com/wiki/Func_areaportal
https://developer.valvesoftware.com/wiki/Func_areaportalwindow
https://developer.valvesoftware.com/wiki/Func_occluder
https://developer.valvesoftware.com/wiki/Hint_brush
色々な手段があるが、大体は「プレイヤーから見えない部分のポリゴンやテクスチャを描画させないようにする」ということ。
難しいことは良くわからなくても、プレイヤーから見えない部分のテクスチャをNodrawにする、
細かい装飾ブラシ（プレイヤーの視界を塞ぐだけの大きさが無いブラシ）をfunc_detailにするぐらいはやっておこう。

しかし最適な最適化を出来るということは、その軽減された負荷の分複雑なマップを作れるということなので、
もしかすると一番最初に習得しておいたほうが良いのかもしれない・・・
まあ時間も手間も掛かるのだが、どこで区切るかを考えたりするのはパズル的で結構楽しかったりする。

Nodrawテクスチャにはライトマップも焼きこまれないので、コンパイル時間の短縮にも一役買う。
prop_staticのフェード距離や、env_fog_controllerのFar Zを設定するのも効果的。（詳しくはそれぞれのページで）

**カスタムコンテンツ
デフォルトで入っているテクスチャなどでは物足りないと思ったら、自分で作った（或いはどこかから取ってきた）
カスタムコンテンツを入れるしかない。
しかしこれはとても面倒な作業で、何より面倒くさいのがコンパイル後のbspにそれらを埋め込む作業である。
埋め込む方法については「BSPZIP」や「Pakrat」と検索すると良い。
（Pakratは大抵のカスタムコンテンツを自動で埋め込んでくれるが、一部モデルのテクスチャなど、
自動では埋め込んでくれないものもある。そういう時は手動で探して埋め込む）

カスタムテクスチャのvmtファイルの書き方について日本語で解説しているサイト。
http://www.schuzak.jp/cs-s/tutCustomTex.html

**円柱や球体などの曲面を滑らかに見せる
https://developer.valvesoftware.com/wiki/Smoothing_groups
https://developer.valvesoftware.com/wiki/Hammer_Smoothing_Groups_Dialog
滑らかに見せたい面を全部選択してSmoothing Groupに入れるだけ。簡単だね。
ライトマップスケール16ではあまり滑らかに見えないが、細かくすればするほど滑らかに見えようになる。

**マップに草を生やす
https://developer.valvesoftware.com/wiki/Detail_prop
https://www.youtube.com/watch?v=mkZuSVgQFFo
マップに生やす草を（func_detailと紛らわしいが）detail props、もしくは単にdetailと言う。
これらを単独で配置する場合はprop_detailというエンティティ。
https://developer.valvesoftware.com/wiki/Prop_detail

**「点」でなく「面」で照らすライト
light_environmentのとこに書いてあります。

**スカイボックスの回転
スカイボックス自体は回転できない。マップをある程度作ったあとに、気になってしまうこともあるだろう。
そんな時にどうするかというと単にマップ全体を選択して90度単位で回転させる。おしまい。

**スカイボックスや環境光などの調和
それぞれのパートで散々言ってきたが、つまりはこういうこと。
&ref(a.jpg,,width=600)
まずlight_environmentをスカイボックスの明るい方角から、それっぽい色の光が差し込むように設定する。
そしてenv_sunをスカイボックスの明るい部分の方角・角度で、その部分に近い色に設定する。
最後shadow_controlを、ブラシが落とす影に近い色合いになるように調整する。
（別に自分が好きな順番でやっていいです）

左はfunc_physboxなのでダイナミックシャドウ、右は普通のブラシなのでライトマップに焼きこまれた影。
意識すると気づくと思うけど、プレイ中にぱっと見た分には気づかないレベルではなかろうか。
SunSpreadAngle：0にして、ライトマップスケール：1にするともっと区別がつきにくくなる。
もちろん、あくまでライトマップの影がメインなので何もダイナミックシャドウの方に合わせる必要は無いのだが。

でもここまでダイナミックシャドウを濃くて彩度が高いものにすると、影同士が重なったときに非常に気持ち悪いことになるので、
実際に遊ぶマップを作るときはもう少し大人しい色にするのが普通。

**prop_staticのVertex Lightingについて
Disable Vertex LightingというKeyvalueがあるが、これは基本的にNo（＝Vertex Lightingを使用する）で良い。

Vertex Lightingとは何かという話だが、これは雑に言えばライトマップのprop_static版みたいなものである。
Disable Vertex LightingがNoの状態では、プロップモデルのそれぞれの面が、ワールドブラシのようにある程度精細にライティングされる。（正確に言うと、それぞれの頂点ごとに光の色が焼き込まれる）
なおVertex Lightingは、$bumpmapと$phongを（片方でも）使用しているプロップモデルには対応していないらしい。

Disable Vertex LightingがYesの状態では、そのプロップモデルが受けるライティングは、そのprop_staticのモデルの「場所（光源に対する距離や角度）」の1点のみで決定される。（それぞれの頂点の位置は関係ない）

ちなみに、prop_static以外のプロップエンティティにはDisable Vertex LightingのKeyvalueが無い事から分かる通り、prop_dynamicやprop_physics、武器やプレイヤーキャラクター等はVertex Lightingされず、Ambient lightと呼ばれる全く別の方法でライティングされる。
https://developer.valvesoftware.com/wiki/Ambient_light

**3Dスカイボックス
http://wikiwiki.jp/sourcesdk/?Skybox
「プレイヤーが歩きまわるマップ本体」と完全に独立した場所に、「ミニチュアサイズの遠景（3Dスカイボックス）」を作り、
実際のゲーム内ではそのミニチュア遠景を拡大して、本体の背景にピッタリ当てはめるというもの。

「え、なんでわざわざそんな面倒臭いことする必要があるの？本体に全部作っちゃえばいいじゃん」と思うかもしれない。
しかし、3Dスカイボックスはミニチュアサイズという特性上「等倍（本土）では再現できないほどの広さを再現できる」
「テクスチャが小さくなる分負荷を減らせる」という特徴がある。

sky_camera内で本体に対する3Dスカイボックスの縮尺率を変更できるが、これはデフォルトの1/16のままにしておくのが吉。
理由は3Dスカイボックス用に作られた1/16サイズのモデルを配置できるのは、1/16の3Dスカイボックスだけだからである。
モデルを拡大・縮小することが出来ないSourceエンジンでは、3Dスカイボックス用のモデルを本土に使うことも、その逆もできない。

位置合わせについては少しでもズレているとおかしなことになるので、しっかりと行うことをお勧めする。
あくまで遠景なので、本体に接続された（ように見える）3Dスカイボックス領域に、そのままプレイヤー等が立ち入ることは出来ない。
テレポーターを使えばプレイヤーが入ることが出来るが、ネタ以外でやる意味は無い。

この3Dスカイボックスを作成する際に見落とされがちなのが、「本体と3Dスカイボックスは、お互いライティングに影響しない」ということ。
「本体のブラシの影が3Dスカイボックスに出来ない」という問題は、本体から3Dスカイボックス領域に持っていった
（本来位置合わせ用としてのみ使う）ブラシを削除せずにBlock Lightテクスチャを貼ることで回避できる。