Учебник по созданию карт CS HL. Ошибки компиляции

ЧАСТЬ 1. Наиболее часто встречающиеся ошибки компиляции



Plane with no normal


Brush with coplanar faces


Leaf portal saw into leaf


Brush 'outside world'


Mixed face contents


=== LEAK in hull 0 ===


Exceeded MAX_PATCHES


Причины медленной работы HLVIS


Причины медленной работы HLRAD (проблемы с MakeScales)


HLRAD failled to allocate a block of memory


Bad Surface Extents


Missing [ in texturedef


MAX_PORTALS_ON_LEAF


MAX_MAP_CLIPNODES




ЧАСТЬ 2. Обзор всех ошибок компиляции



Сводная таблица всех ошибок компиляции

ЧАСТЬ 1. Наиболее часто встречающиеся ошибки компиляции

Пример:

Entity 20, Brush 0, Side 2: plane with no normal
Entity 20, Brush 0, Side 3: plane with no normal

Эта ошибка рождается при неправильной манипуляции с вершинами объекта (вертексами). Как нам всем известно, любая плоскость определяется тремя точками. Если 1 или несколько точек плоскости имеют одинаковые координаты, то это будет уже линия или точка.

Как исправить? Удалить неправильный объект и заменить его новым.

Пример:

Entity 15, Brush 0, Side 1: has a coplanar plane at (-757, -9, 263), texture SA1X_UPKN2C
Entity 15, Brush 0, Side 4: has a coplanar plane at (-757, -32, 263), texture SA1X_UPKN2C

Эта ошибка рождается при неправильной манипуляции с вершинами объекта (вертексами). Рассмотрим, как зарождается данная ошибка. Допустим, что в уровне у нас есть такой объект (смотрите картинку ниже).



На виде сверху (2D top) в режиме работы с вершинами объект будет выглядеть, как показано на рисунке внизу, слева. Допустим, мы решили переделать данный объект в куб. Для этого верхний вертекс (вершину) опускаем вниз (смотрите картинку ниже, справа).



Так вот, так делать запрещено! У нас получилось, что на 1-ой стороне объекта находится две плоскости, а этого быть не должно. Вот как эта ошибка выглядит в трёхмерном виде (смотрите картинку ниже).





Как исправить? Можно, из файла *.ERR с описанием ошибки узнать номер ошибочного браша или энтити-объекта, затем перейти к нему, нажав [Shift-Ctrl-G] в редакторе. При этом мы увидим небольшое окно (смотрите картинку ниже), первая строка позволяет перейти по номеру к энтити-объекту,
вторая — к брашу. Номер объекта, вызвавшего ошибку, указывается в *.ERR файле в следующем виде:
«Entity 15, Brush 0, Side 1....», это означает, что ошибка в пятнадцатом энтити на первой грани.



После того, как вы нашли ошибочный объект, его можно удалить, а можно попробовать исправить. С приведённым выше объектом, можно поступить так: нужно переместить верхнюю среднюю вершину направо или налево, таким образом, мы превратим 2 стороны, лежащие в одной плоскости, в одну грань (смотрите картинку ниже).



После того, как мы перенесём вертекст направо или налево, нам будет задан вопрос: «Merge Vertices?» (что означает: «Совместить вершины?»), обязательно отвечайте «Да».

Эта ошибка рождается, когда программа-компилятор HLVIS.EXE пытается сравнить два портала (leaf portals), которые принадлежат 1-ой видимой вершине (visibility node). См. рис. ниже:



Красный и жёлтый порталы в действительности были одним порталом, которыл был разбит на 2. Оба этих портала должны находиться на одной прямой, но если брать в рассчёт ограниченную точность компьютеров при осуществлении операций с плавающей точкой, данные порталы могут чуть-чуть наклониться друг к другу.

Если происходит данная ситуация, когда два портала принадлежат одной вершине и образуют кривую линию, то возникает ошибка «Leaf portal saw into leaf». Посмотрите, как она выглядит:



На картинке выше наклон одного портала к другому значительно преувеличен (для наглядности). Также есть некоторые друге похожие ситуации, когда рождается данная ошибка, все они — результат ограниченной точности компьютеров в осуществлении операций с плавающей точкой.

Как исправить? Легче всего запустить уровень с ошибкой и поробовать найти, так называемый, эффект зеркального отражения (hall of mirrors effect). Данная ошибка может рождаться, когда координаты одной из вершин браша или брашевой энтити несколько отклоняются от координатной сетки. В данном случае просто пересоздайте неправильный объект, но также можно попробовать использовать параметр -full для программы-компилятора HLVIS.EXE, который помогает сократить число возможных vis-ошибок. Время компиляции с параметром -full обычно увеличивается на 30 процентов. R_speeds (число видимых полигонов) при этом остается примерно таким же, как и при обычной vis-компиляции.

Пример:

Entity 20, Brush 0: outside world(+/-4096): (-9000, -84, 513)-(9000,43,433)

Есть несколько причин возникновения этой ошибки. Во-первых, такая ошибка возможна при наличии повреждённого браша (из-за ошибочной манипуляции с вершинами объекта). В этом случае нужно точно отследить координаты поврежденного браша или энтити, которые сообщаются в *.ERR файле с описанием ошибки. Если какая-то координата равна -9000 или 9000, то такой объект необходимо удалить и создать новый.

Во-вторых, данная ошибка возникает из-за того, что объект находится вне зоны редактирования или около ее границы. Объекты, которые находятся ближе 64 юнитов к границе редактирования, также вызывают эту ошибку, поэтому следите, чтобы уровень не сильно приближался к краю рабочего пространства в редакторе Hammer. Держитесь от краёв подальше.

Пример:

Entity 0, Brush 25: mixed face contents
Texture ROCK_X1 and SKY

Всякий отдельный объект в Counter-Strike можно окрашивать в текстуру только 1-го типа (к примеру, только в текстуру жидкости). К примеру, объект, затекстурированный с 5 сторон обыкновенной текстурой, а
с шестой — текстурой жидкости, вызовет эту ошибку.

Всего есть несколько видов текстур, которые нельзя наносить на браш или энтити вместе с другими. К таким текстурам относятся: SKY, CLIP, ORIGIN и текстуры жидкости. Очень подробно о типах текстур и их совместимости мы рассказываем в материале: «Типы текстур в Half-Life/CS».

Как исправить? Просто перейдите к ошибочному объекту по [Shift-Ctrl-G] и затекстурируйте его со всех сторон текстурами одного вида.

LEAK — дырка на карте. Данная ошибка часто втречается и трудно обнаруживается.

А причина данной ошибки является дырка (зазор) на карте. К примеру, у нас есть 2 браша, между которыми существует зазор. При компиляции компиляторы, обнаружив подобную дырку, думают: «А что находится за этой дыркой?». Они видят зазор между брашами, а дальше... устрашающая пустота :-) — в итоге возникает ошибка LEAK.

На рисунке ниже вы можете видеть пример этой ошибки.



Но не всегда дырка видна так явно, как на картинке выше. Часто дырка имеет очень маленькие размеры, значительно меньше всего лишь одного юнита! Особо много дырок в декомпилированных картах. К примеру, мы захотели маленько изменить De_Dust. Декомпилировали его, затем попытались снова откомпилировать и получили вагон и маленькую тележку ошибок LEAK.

Второй частой причиной, которая вызывает появление этой ошибки, является нахождение точечной энтити за пределами карты. К примеру, вы сделали уровень, создали вокруг него небо и невзначай разместили какой-нибудь энтити-объект (например, ambient_generic) снаружи уровня. В итоге получаем LEAK. Но этот вариант лучше, чем искать дырку на карте, так как отыскать объект значительно проще.

Как исправить? Можно попробовать использовать специальную утилиту LeakMarker. А можно попробовать найти дырку (LEAK) при помощи самой Counter-Strike. Для этого нужно скопировать PTS-файл, который создается в папке с компиляторами при обнаружении дырки на карте, в директорию «cstrike/maps», где лежит ваш недокомпилированный уровень, который всё же работоспособен и, главное, может загружаться. Далее необходимо открыть консоль и ввести: map имя_уровня. После запуска уровня, пишем: pointfile.

После ввода этих нехитрых команд на своём уровне, должна появиться тонкая ломаная линия из черно-белых точек (смотрите картинку ниже).



Эта линия находится около дырки — места с ошибкой LEAK. Запомните это место, откройте Hammer и сосредоточенно осмотрите границы объектов, чётко ли они состыкованы. Попробуйте инструментом для работы с вершинами (Vertex Manipulation) выровнить вершины подозрительных объектов по координатной сетке.

Если при попытке запустить pointfile, Counter-Strike вылетает — это означает, что PTS-файл слишком большой. Придется пробовать иные способы.

Если ничего из выше перечисленного не помогло и найти дырку не удается — попробуйте создать вокруг уровня небо коробкой, то есть поместите весь свой уровень в большую «комнату», окрашенную со всех сторон текстурой SKY. Это должно помочь на 100 процентов :-)

Кстати сказать, если вы случайно не заметили, что компиляторы выдали ошибку LEAK и подумали, что уровень откомпилировался правильно, то обнаружить неладное можно по сильным тормозам на карте, так как HLVIS.EXE не дошёл до оптимизации карты, а освещённость уровня будет очень светлая и монотонная (смотрите картинку выше). Теней от объектов не будет, так как HLRAD.EXE ещё не успел приступить к работе из-за ошибки.

Когда приступает к работе программа-компилятор HLRAD.EXE, который просчитывает освещённость уровня, он разбивает все рисуемые поверхности на маленькие участки, которые называются патчами (patches). В Half-Life существует лимит на максимальное число патчей — в сумме не должно и не может быть больше 65535 патчей.

По умолчанию размер каждого патча составляет 64х64 юнита. Если масштаб текстуры больше или меньше (здесь мы ведём речь не о размере текстуры, а именно о её масштабе), то это оказывает влияние на число патчей. Это означает, что текстура с масштабом два, будет иметь в четыре раза меньше патчей, нежели текстура с масштабом один.

Если сделать небо вокруг уровня большой коробкой, то все внешние области, не видимые игроком, будут всё равно обработаны программой-компилятором HLVIS.EXE. Если у вас большая карта, то это может вызвать данную ошибку (Exceeded MAX_PATCHES), так как число участков или патчей может превысить порог в 65535 шт.

Как исправить? В строчку запуска программы-компилятора HLRAD.EXE можно вписать параметр «-chop 96» или «-chop 128». Данный параметр устанавливает мин. размер патча в юнитах. Напомним, что по умолчанию минимальный размер патча составляет 64х64 юнита. ПОднако, помните, что установка размера патчей более 96 юнитов, приводит к значительному ухудшению качетсва освещённости уровня, может появиться эффект «лесенки» на тенях, отбрасываемых объектами.

Ещё можно увеличить масштаб текстур для сокращения количества патчей, к примеру, больших текстур на скалах или земле. Большие по масштабу текстуры создают гораздо меньше патчей. А если небо у вас — коробка вокруг уровня, то не забудьте закрасить все внешние грани объектов и дно уровня специальной текстурой SKY. Во время компиляции данные SKY-поверхности не просчитываются на освещённость и не создают патчей.

Итоговое время компиляции карты, а именно просчёт её визуальной части программой-компилятором HLVIS.EXE, не должно превышать 50-60 минут при использовании машины уровня PII-300 (да, таких, наверное, уже и не осталось :).

Причиной продолжительной работы HLVIS.EXE может быть окружение карты небом в виде большой коробки. В этом случае HLVIS.EXE обрабатывает большие территории снаружи карты, что увеличивает время его работы. Поэтому в этом случае не забывайте закрашивать внешние стороны объектов и дно карты текстурой SKY.

Второй причиной, котороя сказывается на время компиляции программой HLVIS.EXE может стать архитектура уровня. Это довольно трудно объяснить, поэтому приведем несколько примеров:


• проходы, которые пересекают стены не под прямым углом;
• браши или брашевые энтити, развернутые на произвольный угол;
• высокие неперпендикулярные к полу стены;
• большое число мелких брашей (не энтити) на обширных, открытых пространствах;

Третья причина: большие обширные территории, на которых имеются большое количество проходов в различные комнаты, при условии, что движок все их отрисовывает.

Как избежать долгой компиляции HLVIS.EXE? Просто не делайте описанного выше: не создавайте обширных, открытых пространств; не делайте небо коробкой вокруг карты, а если делает, то окрашивайте текстурой SKY дно и внешние стены уровня; проходы разворачивайте на 30, 45 или 90 градусов, зажимая при вращении клавишу Shift. Конечно, всё это значительные ограничения, но ничего поделать нельзя. Необходимо просто это принять. Counter-Strike довольно старая игра и движок не расчитан на значительное число полигонов. Да, и нужны ли все эти «красоты» игроку? Мы уверены, главное, захватывающий геймплей.

У вас значительное время занимает операции «Make Scales» и «Swap Transfers»? Читайте об этом ниже.

Программа-компилятор HLRAD.EXE требует довольно значительное количество оперативной памяти. Количество памяти нужное для просчёта визуальной матрицы (vismatrix) компилятором HLRAD.EXE экспоненциально зависит от размера данной визуальной матрицы. Формула для расчёта количества необходимой vismatrix-памяти такова: (количество патчей)²/16 = количество vismatrix-памяти в байтах. Если число патчей максимально 65535, то памяти потребуется 256 Мб.

Но память нужна не только для обработки визуальной матрицы. Она также необходима для выполнения операции MakeScales. Количество нужной оперативной памяти для этой операции приблизительно равно 0.5 vismatrix-памяти, то есть на обе операции вместе, в самом наихудшем случае с 65535 патчами, компилятору HLRAD.EXE может понадобиться 256+128=384 Мб памяти.

Когда выполняется операция MakeScales на больших детализированных картах можно не редко наблюдать следующую специфичность: сначала MakeScales доходит до 90 процентов, скажем за 30 минут, а следующие 10 процентов просчитываются несколько часов или даже дней! Происходит это, когда оперативная память исчерпывается, при этом начинается энергичное обращение к файлу подкачки (SWAP-файлу). Данный случай можно поробовать решить, добавив параметр -sparse в строчку запуска программы-компилятора HLRAD.EXE. Это снизит использование оперативной памяти на 10 процентов за счёт увеличения нагрузки на процессор. Ну, а лучше всего прикупить пару планочек оперативки :-)

Для ускорения работы HLRAD.EXE подходят методы, применяющиеся для устранения ошибки «Exceeded MAX_PATCHES», которую мы рассмотрели выше в данном материале. Используя данные методы, можно сократить число патчей, тем самым уменьшить потребность HLRAD.EXE в памяти. Также можно попробовать использовать параметр -bounce 0 для программы-компилятора HLRAD.EXE. При этом на карте останется лишь прямое освещение, а отраженный свет просто-напросто не будет просчитан. Но, помните, данную опцию можно применять только для тестовой компиляции. При финальной (полной) компиляции параметр -bounce всегда должен быть больше нуля.

Также мы советуем использовать опцию -incremental для программы-компилятора HLRAD.EXE. В этом случае, при повторной (но не при первой!) компиляции будут пропущены операции: MakeScales, SwapTransfers и BuildVisLeafs. Использовать данный параметр не просто, а очень просто. В первый раз мы компилируем уровень как обычно, но не забыв добавить параметр -incremental для компилятора HLRAD.EXE. В этом случае создастся файл размером до нескольких десятков мегабайт. При второй и последующих компиляциях уровня с данной опцией этот файл будет использован, что позволит пропустить перечисленные выше стадии. Так что, если у Вас немного системной памяти, то нужно помучиться только один раз (при первой компиляции), а при последующих компиляциях всё будет намного быстрее. Кстати сказать, если мы изменим свойства или расположение источников света (объекты: light_environment, light_spot и light), то не забудьте обновить эту информацию в MAP-файле при помощи параметра -onlyents, прописанного в программе-компиляторе HLCSG.EXE.

Данная ошибка возникает, когда программа-компилятор HLRAD.EXE (просчитывающая освещённость на карте) не смогла продолжить работу из-за недостатка оператвиной памяти. В этом случае нужно увеличить размер виртуальной памяти (файла подкачки, SWAP-файла) или (рекомендуется) установить доп. оперативную память на свой ПК.

В большинстве случаев эта ошибка возникает при нанесении текстур со слишком большим масштабом (более десяти, а обычно более ста). Эту ошибку также можно обнаружить в редакторе Хаммер при нажатии на [Alt-P]. Там о ней будет сообщено, как «Texture axis perpendicular to face».

Есть несколько причин появления этой ошибки:


• 1-на или несколько сторон объекта не имеют никакой текстуры. В Хаммере эти браши или брашевые энтити отображаются полностью белыми, или же если название текстуры состоит только из пробелов.
  Проверьте уровень на ошибки нажатием комбинации клавиш [Alt-P], редактор выдаст эту ошибку как «Invalid texture»

По обыкновению, данная ошибка возникает из-за огромных комнат с большим числом входящих в неё проходов. Также причиной может быть поврежденный браш или браш неправильной формы. Такой браш можно отыскать по [Alt-P].



На рисунке выше изображена комната на виде сверху. Розовое — комната, синее — стены. Комната является одним большим пространством (leaf). Эта комната соединяется с 32-мя маленькими комнатками (углублениями в стенах). Таким образом, у 1 leaf образуется тридцать два портала (portals).

Так как в HL «MAX_PORTALS_ON_LEAF» может быть равным 256-ти, то эта ошибка чаще всего возникает из-за «битого» браша.

Clipnodes — это такие поверхности, которые определяются Counter-Strike'ом, как непроходимые для игрока. Всякий браш, брашевый энтити-объект в уровне (стена, скалы, земля, пол или ящик) «окутывается» clipnode-поверхностями. Благодаря clipnode-поверхностям игрок не падает сквозь землю и не проходит сквозь стены и другие браши.

Значительное количество данных плоскостей может вызвать эту ошибку (MAX_MAP_CLIPNODES). В улучшенных утилитах Зонера — Custom Build автоматом включён режим экономии данных clipnode-плоскостей. Однако, это не страхует от появления этой ошибки.

Если мы делаем небо вокруг карты в виде большой коробки, окрашенной текстурой SKY, то создается большое число clipnode-поверхностей, что может привести к появлению ошибки MAX_MAP_CLIPNODES, к тому же это приводит к изменению времени компиляции HLVIS.EXE в сторону увеличения.

В архиве с официальной версией (не улучшенной) утилит Зонера 2.5.3 есть пример: уровень clipnode.map, в котором показано, как можно сберечь большое количество clipnode-поверхностей.
Давайте рассмотрим рисунок с этого уровня:



На данной картинке HINT и CLIP браши представлены в разрезе. Они имеют совершенно одинаковый размер и расположены вокруг объекта. Если бы мы не разместили эти браши вокруг объекта, то около данного объекта (с большим числом сторон) образовалось бы много clipnodes, которые точно указывают форму объекта, через которую игрок не может пройти. Используя же данный метод с CLIP и HINT брашами, мы сильно уменьшаем число clipnode-плоскостей, уменьшая вероятность возникновения данной ошибки и сокращая время работы программы-компилятора HLVIS.EXE.

Мы поэкспериментировали и откомпилировали уровень с CLIP-брашем и без него. И вот результаты:


• Clipnodes с CLIP-брашем (как на рисунке): 30
• Clipnodes без CLIP-браша: 149

Как видно из примера, результат более чем значительный. Конечно, если уровень маленький и clipnodes порядка 12000-15000, то особого смысла экономить нет, но это данный метод экономии может пригодиться при создании большой карты. Кстати сказать, мы установили, что HINT-браш не влияет на количество clipnode-поверхностей, так что его можно не использовать.

ЧАСТЬ 2. Обзор всех ошибок компиляции