Содержание

Введение

Что происходит, когда мы запускаем компиляцию уровня? В начале компилятор создает bsp дерево (что это такое - читай ниже). Создание bsp является базовым при создании того, что мы увидим в игре. Это стены с текстурами, итемы, движущиеся части уровня (двери, платформы), а также вода на уровне (под этим также понимается лава и слизь). В процессе проверяется целостность уровня, то есть он должен быть замкнутым и не иметь утечек (leaked) во <внешний вакуум>. Соответственно, все итемы должны находиться в пределах созданного нами мира (также к утечке приведет итем, находящийся в стене). Иначе на уровне возникают дикие визуальные глюки и сильно падает скорость.

Затем на основе бсп дерева компилятор считает vis таблицы, которые хранят информацию о том, какие поверхности и с каких мест должны быть видны в данный момент. Если мне не изменяет память, то впервые они были использованы Кармаком в игре DOOM, правда в виде дополнительного патча. Его применение сильно увеличивало скорость на 386 процессорах (на теперешних, понятное дело, мы этого и не заметили бы :-).

Последний этап - это расчет освещения - наложение lightmap-ов (то есть, наложение карт теней) и расчет вертексного освещения (это просто равномерное освещение каждого пикселя текстуры. Проще говоря, приемлемая картинка при минимальных затратах). Этот процесс, как правило, самый длительный из всех предыдущих.

Binary Space Partitioning (BSP) Tree - стандартное бинарное дерево, используемое для сортировки и поиска многоугольников и многогранников в n-мерном пространстве. Взятое в целом BSP-дерево представляет собой все пространство, а каждый его узел ограничивает выпуклое подпространство. Каждый из узлов дерева хранит информацию о «гиперплоскости», делящей пространство узла на 2 части (переднюю и заднюю, что определяется направлением вектора нормали этой плоскости), а также ссылки на два новых узла, представляющих эти части. Заодно в узлах может храниться информация об одном или нескольких полигонах, лежащих в этой «гиперплоскости».

Для компиляции карт обычно исползуется компиляторQ3map2. Разумной альтернативы нет. Последнюю версию компилятора 2.5.17, к сожалению, достаточно сложно найти, но её можно скачать вместе с редакторомNetRadiant.

Управление параметрами компиляции осуществляется через командную строку. В редакторах radiant в меню есть подраздел build, в котором уже прописаны основные параметры компиляции. в 99% случаев их бывает достаточно. Если требуется задать какие-то сецифические параметры компиляции удобно воспользоваться распространенными программами для управления компилятором, как например Q3Btc или Q3Map2Build

Базовый вид bat файла q3map2.exe -ключ -ключ -ключ mymap.map - этой строкой мы переводим карту из понятного редактору формата map в формат bsp. -ключ - это параметры компиляции bsp дерева.

q3map2.exe -vis -ключ -ключ mymap.bsp - теперь на основе полученного bsp дерева мы расчитываем порталы видимости (таблицы vis). -vis - этим ключом мы даем знать компилятору, что надо расчитывать vis порталы. Ну, а -ключ - это разумеется снова определенные параметры расчета :-).

q3map2.exe -light -ключ -ключ mymap.bsp - ну вот, мы добрались до финальной стадии компиляции. -ligth - переключает компилятор в режим расчета освещения, ну, а остальное, я думаю, вам уже понятно:-).

Параметры компиляции bsp

-threads (n) - указывает количество процессоров в системе, на которой проходит компиляция (выставляется автоматически);

-leaktest - этот ключ позволяет остановить полностью компиляцию при нахождении утечки на уровне. Bsp дерево не создается;

-meta - это очень полезный ключ. Он перестраивает видимые части брашей в треугольные поверхности, тем самым увеличивая эффективность bsp: Удаляет совпадающие вертексы. Также, он, соединяя поверхности, не создает при этом больших монолитных поверхностей. Это позволяет более эффективно создавать lightmaps«ы без падения разрешения (большой samplesize). Если вы используете этот ключ, то при расчете путей ботов ОБЯЗАТЕЛЬНО используете ключ -forcesidesvisible. Иначе боты будут стоять на месте респаунов и ничего не делать.

-fulldetail - при активации этого ключа все детальные браши (пояснение ниже) будут просчитаны как структурные;

-nodetail - детальные браши не обсчитываются компилятором и соответственно не появляются на уровне;

-nocurves - криволинейные поверхности не просчитываются на уровне;

-nofog - расчет уровня без тумана;

-nowater - ну, а это, как вы уже поняли, не считает воду на уровне;

-nosubdivide - если использовать этот ключ, то видимые поверхности не будут разделены. Обычно Q3map делит видимые поверхности согласно shader tessellation. Если мы используем этот ключ, то все грани брашей будут считаться как одно целое. Пример действия этого ключа - лава на уровне q3dm7;

-onlyents - пересчитывает на карте только итемы. Используется, если надо в построенной карте передвинуть итемы;

-patchmeta - создает мета-поверхности из патчей (т.е., криволинейных брашей);

-flares - этот ключ создает корону у источника света. Не работает в Quake3, RTCW.(раньше использовался в q3test, но в последствии был от туда удален). Используется в играх SoF2 и JK2;

-verboseentities ( -v ) - выводит информацию о ходе построения bsp;

Detail Brash (создается в редакторе комбинацией клавиш CTRL+M) - эти браши не просчитываются vis»ом, и, следовательно, уменьшается время компиляции. Детальные браши НЕ ДОЛЖНЫ ИМЕТЬ ГРАНИЦ С ВНЕШНЕЙ СРЕДОЙ. В противном случае на карте возникает утечка.

Параметры расчёта vis

-fast - создание только первичных порталов видимости. Это позволяет сильно сэкономить время компиляции, но движок игры начинает считать больше полигонов;

-saveprt - не удаляет .prt файл (в нем хранится информация о vis порталах);

-hint - не присоединяет hint порталы при использовании ключа -merge;

-merge - почти тоже, самое что и -fast;

-nopassage - выключение алгоритма Это также увеличивает скорость расчета vis, но делает его более плотным, чем обычный алгоритм;

-nosort - это отключает сортировку сложных порталов. Информация о них берется на основе менее сложных соседних порталов. Это также ускоряет расчет vis;

-v (-verbose) - вывод отладочной информации о процессе расчета.

Параметры расчета освещения (light)

-threads (n) - указывает количество процессоров в системе на которой проходит компиляция(выставляется автоматически);

-fast - просчет освещения без зоны затухания (fallout). Сильно экономит время расчета, но в результате освещение сильно страдает. Можно использовать на картах с большим количеством самосветящихся поверхностей;

-border - отладочная команда. Создает видимый бордюр на краях лайтмэпов;

-bounce (n) - Включает расчет радиосити. Позволяет создать самое лучшее, и ровное освещение,(n) количество проходов радиосити от 1 до 8. По умолчанию 3. Эта функция самая прожорливая из всех. Расчет может занимать огромное время даже на очень сильных компьютерах;

-bouncegrid - расчет радиосити на lightgrid (световая сетка). Световая сетка используется для освещенияитемов и моделей на уровне;

-fastbounce - быстрый проход радиосити. Визуально я его даже и не увидел на карте :-( ;

-fastgird - быстрый расчет световой сетки;

-nogird - световая сетка не расчитывается;

-super (n) (-extra) - Включение суперсэмплинга (то есть антиаллиастнига) при расчете лайтмэпов.Позволяет получать гладкие края теней и тд. N- количество семплов по умолчанию 2. Этот параметр тоже значительно увеличивает время расчета;

-extrawide - используется с ключом -super 2. Делает резко выраженные края текстур. Короче часто это очень большая гадость;

-filter - смазывание теней по Гаусу (аналго фотошоповского blur);

-notrace - выключается световая трассировка. Результат -тени отсутствуют;

-novertex - не считается вертексное освещение. Очень полезно если карта не планируется использоваться в режиме вертексного освещения, тк сильно экономится время;

-nosurf - не трассируются детальные браши (см -notrace );

-patchshadows - расчет теней от кривых поверхностей;

-export - экспортирование внутренних лайтмэпов в tga файлы;

Заключение

Это все о базовых часто используемых ключах q3map2. Использование данного компилятора позволяет получать гораздо более красивые результаты по сравнению со стандартным компилятором. Я намеренно опустил описание некоторых ключей, т.к. они не являются ходовыми и вряд ли вам понадобятся.

Автор: Kirk Barnes, дополнил GT-Agressor