|
|
|
|
Статьи о картостроении
Метод борьбы с ошибкой утечки пространства
на BSP-карте игры
(метод интервалов)
ObaGlaza 7-XII-2010 г.
Вторую неделю корчую всякие недоработки на карте !xxx2.
Удалил большой кожух-коробку вокруг карты, исправил пару десятков утечек пространства, последние
из них оказались самыми труднонаходимыми. Когда-то чтобы найти утечку, я терял часы свободного времени,
а бывало так и бросал дело, от того, что начинало казаться, что это слишком долго и трудно.
Я пробовал искать по пунктирным линиям, клубящимся по уровню,
когда в редакторе Hammer щёлкаешь в меню Map->Load Pointfile или когда набираешь в консоли игры команду pointfile.
Часто линии уходят в стены вроде бы и рядом от места утечки, а просвета между блоками не заметно, и не
поймёшь где именно.
В этот раз опять пришлось вспомнить надёжный способ, которым
быстро находишь проблему. Он известен как метод интервалов, когда материал делится на две части, выявляется, в какой части проблема, и ту часть опять делим пополам, чтобы узнать, где там скрывается проблема. И так ведём разделение до победного конца над проблемой.
Допустим компиляция в hlbsp прошла плохо и вместо " BSP generation successful" выдала ошибку вроде такой:
"Warning: === LEAK in hull 0 ===
Entity light_spot @ (2520,-1533, 13)
Error:
A LEAK is a hole in the map"
Проблема в деталях:
В движках игр, родственных Quake (в т.ч. Half-Life), предварительно просчитывается невидимая непроходимая и непростреливаемая
структура стен, короче говоря — каркас границ столкновений (clip hull).
Этих каркасов в Half-Life создаётся по четыре (в Quake по 3) для просчёта
| столкновений с точечным объектом | нулевой размер | "hull 0" |
| столкновений с игроком в полный рост | размер цилиндра 32x32x72 | "hull 1" |
| столкновений с крупным объектом (монстром) | размер цилиндра 64x64x72 | "hull 2" |
| столкновений с игроком на корточках | размер цилиндра 32x32x36 | "hull 3" |
Ошибка "LEAK in hull 0" означает утечку пространства в каркасе границ столкновений для точечных объектов (в игре есть малосущественное исключение: когда задаёшь "размер точки" объекту типа func_pushable, то вместо точечного там обсчитывается минимальный объём 16x16x16).
Очевидно, что самым подробным будет каркас для просчёта реакции на точечные объекты, а чем крупнее объект берётся, тем более грубой будет
объёмная структура и сильнее будут срезаться некоторые углы, потому что, например,
не везде, где пролезет точечный объект, пройдёт и игрок на корточках.
Иначе говоря, в место утечки может завалиться точечный объект, а возможно даже более крупный.
И тогда при просчёте падения или движения свободного полёта он улетит опасно далеко для работы игрового движка — для того это и отслеживается при компиляции карты.
Способ исправления методом интервалов:
Смотришь на виде сверху — в плоскости осей X0Y — положение обозначенного в ошибке объекта (в нашем примере с x=2520,
y=-1533), до которого добежала утечка. Одну половину уровня временно закрываешь огромным брашевым параллелепипедом.
И компилируешь только первыми двумя компиляторами hlcsg и hlbsp. Для ускорения компиляции в настройки к hlbsp можно дописать параметр -leakonly. Т.к. их работа проходит быстро, то секунд через 5,
на крайний случай минуты через полторы уже решаешь по принципу "недолёт-перелёт" что делать дальше: если нет утечки,
уменьшаешь параллелепипед, если есть — увеличиваешь. И продолжая так сканировать гранями временного блока, не проходит и пятнадцати минут, как ты уже смотришь на источник
заморочек и обрадованно думаешь: "Попался, который скрывался!"
Ещё как вариант можете попробовать программку LeakMarker,
которая рисует красный блок в месте утечки. Хотя она тоже не панацея.
PS: Дописывая статью, узнал, что метод перекрытия параллелограммами маппер Skaarj тоже давно использует и всем рекомендует.
|
|
|
