Метод борьбы с ошибкой утечки пространства на BSP карте игры (метод интервалов)

Вторую неделю корчую всякие недоработки на карте !xxx2. Удалил большой кожух-коробку вокруг карты, исправил пару десятков утечек пространства, последние из них оказались самыми труднонаходимыми. Когда-то чтобы найти утечку, я терял часы свободного времени, а бывало так и бросал дело, от того, что начинало казаться, что это слишком долго и трудно.​

Я пробовал искать по пунктирным линиям, клубящимся по уровню, когда в редакторе Hammer щёлкаешь в меню Map->Load Pointfile или когда набираешь в консоли игры команду pointfile. Часто линии уходят в стены вроде бы и рядом от места утечки, а просвета между блоками не заметно, и не поймёшь где именно.

В этот раз опять пришлось вспомнить надёжный способ, которым быстро находишь проблему. Он известен как метод интервалов, когда материал делится на две части, выявляется, в какой части проблема, и ту часть опять делим пополам, чтобы узнать, где там скрывается проблема. И так ведём разделение до победного конца над проблемой.
Допустим компиляция в hlbsp прошла плохо и вместо "BSP generation successful" выдала ошибку вроде такой:

C++:
Please, Log in or Register to view codes content!

Проблема в деталях:

В движках игр, родственных 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, которая рисует красный блок в месте утечки. Хотя она тоже не панацея.
 
Back
Top