ハンマー・エディターで地図を最適化する方法

カスタム マップのパフォーマンスを高速化し、レンダリングの不具合に悩まされず、コンパイル時間を短縮したいですか?

1

部屋を封鎖する。 これは必須だ。 マップに少しでも漏れがあると、コンパイラーはマップの境界を判断できず、マップ内のすべてを一度にレンダリングしようとします。 さらに悪いことに、マップ内のエリアポータル、ヒントブラシ、オクルーダーは機能しなくなり、役に立たなくなります。 また、マップに漏れがあると、水は正しくレンダリングされません。

• 図1aでは、部屋は明らかに密閉されていません。 もしこの漏れがある状態でこのマップをコンパイルすると、vvis（コンパイルの可視性データを決定する部分）はマップの境界を決定することができません。
• 図 1b では、部屋は密閉されており、正しくコンパイルされます。
• 漏れをチェックするには、まず、マップ内に少なくとも 1 つのエンティティ (「info_player_start」など) があることを確認してください。 F9を押すか、File -> Run MapでBSPを保存してコンパイルします。 Run BSPは "Normal "を選択し、Run VISとRun RADは "No "を選択する（"Don't run the game after compiling "にもチェックを入れる）。 コンパイルが完了したら、コンパイルログを閉じて、Map -> Load Point Fileに進みます。 漏れがある場合、操作の確認を求められるので（例："Load default pointfile? [C:\Program Files------->]"）"Yes "を選択すると、一番近いエンティティ（※）から漏れのある範囲に赤い線が出る。 (*これが、マップにブラシかポイントのエンティティが必要な理由です。 ワールドブラシやディテールブラシでは動作しません)。 リークを封印し、BSPを再コンパイルし、ポイントファイルをロードする。 すべてが封印されたなら、SteamsteamappsのPerl GAMERTAG GAMERTAG GAMEMapsrcフォルダーの空のフォルダーに行くだけです。

2

"tools/toolsnodraw" でブラシを作成してください。 必ず最初に「tools/toolsnodraw」テクスチャでブラシを作成し、その後、プレイヤーの視点から見えるものだけにテクスチャを適用してください。

3

ブラシと面の数を減らします。 可能な限り、1,000 個の小さなブラシではなく、数個の大きなブラシでジオメトリを作成するようにしましょう。 ブラシが多ければ面数も多くなり、面数が多ければパフォーマンスやコンパイル時間が低下します。 結論: 1 つか 2 つのブラシで複雑なジオメトリを作成できるのであれば、それ以上のブラシを使用する必要はありません。

• 図 3a では、2 つのブラシがあります。左側のブラシはアーチ ツールを使用して作成され、40 面の 8 面ブラシを作成しました。 後者はクリッピングツール（Shift + X）を使って作成した。 後者を実現するには、まず参考のためにアーチ・ツールから希望の幾何学的形状を作成することをお勧めする。 次に、基準となるアーチと同じ長さ、幅、高さのブラシを作成し、基準の少し上に配置します。 ブラシを選択し、角度をクリップする。 (グリッド サイズを変更するか ("-" で小さく、"+" で大きく)、手動で参照アーチの頂点 (Shift + V) を動かして、最も近いグリッド ポイントにスナップする必要があるかもしれません)。

4

詳細ブラシをうまく活用しましょう。 ワールドブラシは視界を遮り、マップを封印し、BSPを「葉」に分割します。これは基本的に、コンパイラが任意の時間と場所で何が見えて、何が見えないかを決定する方法です。 ディテールブラシは、基本的にコンパイラから「見えない」ように設計されています。 ワールドブラシであるべきなのは、部屋の壁、床、天井だけです。 部屋の中で、作業用のエンティティでなく、プレイヤーの視界を大きく遮らない他のほとんどすべては、func_detailブラシに結びつけるべきだ（Ctrl + Tで結びつける）。 ディテールブラシは視界を遮らないので、vvisの計算にコンパイルされず、マップをより多くのvisleaveに分割することもありません（これはほとんどの場合良いことです）。 しかし、マップを密閉するわけでもないので注意してください。

5

エリア ポータルとヒント ブラシを適切に使用してください。 エリア・ポータルとヒント・ブラシは、正しく行えば、視認性を制限し、パフォーマンスを向上させる素晴らしい方法です。 しかし、すべての廊下や窓にこれらを配置すべきではありません。何がいつレンダリングされるべきかを計算する量が、部屋全体を一度にレンダリングする量を上回る可能性が非常に高いからです。 その代わり、ディテールの多い部屋だけを分けてください。

6

オクルーダーを (控えめに) 使用します。 オクルーダーは、その背後にあるものをレンダリングしないので、クローズド・エリア・ポータルに似ています。 しかし、部屋を密閉する必要がなく（ワールドブラシに触れず、自立させることができる）、3Dモデル（別名プロップ）のみをブロックするという点で、クローズドエリアポータルとは異なります。 このツールはメモリ使用量の点で非常にコストがかかるので、エリアポータルで密閉できない自立した壁の後ろに高価な3Dモデルがある場合にのみ、オクルーダーを使うべきです。

7

3D スカイボックスを追加します。 完全に必要というわけではありませんが、FPS（フレーム/秒）を劇的に遅くすることなく、マップをより大きく見せるのに役立ちます。 3Dスカイボックスは通常 "大きな "屋外マップのために作られますが、窓越しに外が見えるような屋内マップのために作ることも可能です。 3Dスカイボックスはレンダリングが非常に安く、小さなマップを最大16倍大きく見せることができます。なぜなら、3DスカイボックスはHammerで1/16スケールに設定され、コンパイル時にスケールアップされるからです。

8

フォグを追加します。 大きな屋外マップでは、霧はレンダリングされるディテールの量を制限することができ、その過程でマップをよりリアルに見せることができます。 マップに env_fog_controller エンティティを追加します。 Object Propertiesタブの "Enable Fog "オプションで "Yes "を選択します。 これにより、その距離以降のすべてのブラシが削除され、エンジンが不要なオブジェクトをレンダリングすることがなくなります (Far Z Clip Plane の値は Fog End の値よりも大きくする必要があります)。

9

Lightmap Scale に夢中にならないでください。 ライトマップ スケールは、基本的に、ジオメトリにレンダリングされるシャドウのシャープさやぼやけ具合を決定します。 数値を大きくするとシャドウの質は低下しますが、パ フォーマンスは向上します。 反対に、ライトマップのスケールを小さくすると、シャドウのビジュアルは向上しますが、パフォーマンスが著しく低下します。 ライトマップスケールが大きすぎても小さすぎても、それぞれ鈍すぎたり鋭すぎたりする非現実的な照明効果を生み出す可能性があります。 すべてのブラシのデフォルトのライトマップ スケールは 16 で、これはビジュアルとパフォーマンスの間でバランスのとれた領域です。

10

マップに水がある場合、「water_lod_control」エンティティをマップに配置します。 このエンティティは、「高価な」水が「安価な」水に移行するために、「高価な」水からどのくらい離れなければならないかを決定します。 高価な水は安価な水よりもはるかにリアルに見えるため、コンピュータのメモリ使用量や計算量が多くなります。 より短い遷移距離は、より短い距離でより安い水を生成し、したがって、遠くにいるときの視覚的な品質はかなり失われますが、パフォーマンスも向上します。

この記事は、CC BY-NC-SA の下で公開された "How to Optimize a Map in Hammer Editor" を修正して作成されました。 特に断りのない限り、CC BY-NC-SAの下で利用可能です。