Представим, что вы запустили Hammer Editor и создали новый файл для создания карты. А теперь стоп! Скажите, какая из следующих двух картин предстоит перед вашими глазами?

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

Многие начинающие картоделы используют редактор в подобном тесном формате, даже не подозревая о бо́льшем пространстве, что, давайте дружно признаем, может отталкивать от работы в нём.

В данном случае предлагаю изменить то, что первым делом бросается в глаза:

1. Сместим и настроим размер боковых панелей справа;
   
2. Избавимся от ползунков двухмерных окон;
   
3. Скроем список «Manifests».

Панели можно легко перемещать мышью — просто наведите на границу панели, зажмите левую кнопку мыши и переместите на своё усмотрение.

Некоторым панелям можно не только менять расположение, но и их размер, вытащив из зоны панелей и изменив как обычное окно рабочего стола.

Кроме того, вы также можете и скрыть их, вытащив из зоны панелей и нажав на соответствующую кнопку в правом верхнем углу.



Как правило, вы не будете использовать ползунки для перемещения камеры внутри окон, поскольку есть и более простые варианты, такие как перемещение сочетанием «Пробел + Зажатая левая кнопка мыши» и колёсиком мыши, например. Следовательно, давайте уберём эти ползунки в настройках редактора.

Чтобы перейти в настройки, нажмите на «Tools» (инструменты) в левом верхнем углу и в развернувшемся списке нажмите на «Options» (настройки). Попав в меню настроек, перейдите во вкладку «2D views» (двухмерные окна) и уберите галочку с «Display scrollbars» (отображать ползунки), а после подтвердите изменения, нажав «ОК».



Манифесты (manifests) — это один из способов разбития карты на разные «зоны» или «этапы», что может быть использовано как во избежание случайных ошибок, так и для совместной работы картоделов над одной картой, но в разных местах.

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

Скрыть панель списка манифестов очень просто — вытащите панель из зоны панелей и закройте как обычное окно.



Если вы случайно закрыли не ту панель и хотите её вернуть, нажмите на «View» (вид) в левом верхнем углу, в развернувшемся списке наведите на «Screen Elements» (элементы экрана) и поставьте галочку у интересующей вас панели. Убрав галочку, вы скроете элемент.

Итак, вы начали заниматься картой: создали что-то вроде улицы, какой-то забор и захотели ровно развернуть какой-то объект и... что-то идёт не так, а в процессе вы даже затрагиваете что-то лишнее.

Обычно, это следствие ненастроенного редактора, который мы частично настроим, а именно:

1. Уберём излишне плавное и неровное вращение объектов;
   
2. Ограничим выделение объектов только по нажатию или выделению их центральной точки;
   
3. Включим возможность перемещения объектов с помощью стрелок на клавиатуре;
   
4. Включим автоматическое перенаправление примитивов в зависимости от активного двухмерного окна;
   
5. Включим автоподтверждение выделения в двухмерных окнах;
   
6. Скроем вершины брашей.

Решив повернуть какой-то объект, вы наверняка столкнётесь с проблемой неровности результата: где-то он будет чуть под наклоном, где-то слегка правее или левее нужного, что добавляет хлопот. Может вам и нужно будет более плавное вращение, но чаще всего — нет.

Кроме того, ни редактор, ни движок Source неровности не любят: как в плане скорости компиляции, стабильности и лимитов, так в плане оптимизации и освещения. Поэтому чем меньше градус поворота объекта, тем хуже.

По умолчанию вольное вращение является основным режимом, а 15-градусное — вторичным, который доступен при зажатой клавише «Shift». Перейдя в настройки двухмерных окон (Tools → Options → 2D views), установите галочку у «Default to 15 degree rotations» (15-градусное вращение по умолчанию), что поменяет эти режимы местами.




Нередко бывает такое, что картоделы случайно выделяют не тот объект или группу объектов. Чтобы избежать подобного и выходящих из этого последствий, давайте ограничим выделение объектов только по их центральной точке, а не по любому краю.

Перейдите в настройки двухмерных окон и поставьте галочку у «Select objects by center handles only» (выбор объектов только по центральным опорным точкам).

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

Перейдите в настройки двухмерных окон и поставьте галочку у «Arrow keys nudge selected object/vertex» (клавиши-стрелки перемещают выбранный объект или вершину).

Создавая примитивы в Hammer Editor вы можете столкнуться с тем, что они направлены не в ту сторону, которую хотелось бы. Помочь с этим может автоматическое перенаправление, которое будет создавать их в соответствии с направлением активного двухмерного окна: если активно окно с видом сверху — вертикально, спереди — горизонтально, сбоку — горизонтальны с поворотом на 90 градусов.

Перейдите в настройки двухмерных окон и поставьте галочку у «Reorient primitives on creation in the active 2D view» (перенаправление примитивов при создании в активном двухмерном окне).

Скорее всего, после пары часов работы в редакторе вам надоест постоянно нажимать на Enter после каждого выделения тех или иных объектов. Можно сделать этот процесс автоматическим.

Перейдите в настройки двухмерных окон и поставьте галочку у «Automatic infinite selection in 2D windows (no ENTER)» (автоматическое бесконечное выделение в двухмерных окнах (без Enter)).

Кстати, вы можете выделять сразу несколько разных объектов, зажимая клавишу «Ctrl» после каждого выделения группы или индивидуального объекта.

При работе в Hammer Editor можно начать теряться при наличии большого количества брашей, особенно когда у каждого видны их вершины, что может ещё больше усугубить ситуацию.

Перейдите в настройки двухмерных окон и уберите галочку у «Draw Vertices» (отображать вершины).

Выбор размеров брашей является одной из главных проблем начинающих картоделов, и главных ошибок. Начиная работать в редакторе, многие забывают о таких вещах как пропорции и соотношение размеров, в связи с чем начинают делать карту, которая на выходе получается неверных размеров, из-за чего её либо исправлять, либо начинать сначала. Словом, сплошное разочарование.

Разметочная сетка — главный ориентир для построения любых объектов в Hammer Editor. Только вот, она является и главным ограничителем ваших работ, в хорошем смысле. Понимаете, редактору тем легче работать с вашей картой, чем больше вы придерживаетесь сетки, а конкретно её больших значений (проще говоря, «крупных квадратов») — это один из базовых принципов. Разберём теперь как его придерживаться...

Знакома ли вам надпись «Snap: On (или Off) Grid: 64» (Привязка: вкл. (или выкл.) Сетка: 64) в правом нижнем углу? Если нет, то она информирует вас о состоянии привязки сетки и её размерах в юнитах, и лучше следите, чтобы она всегда была включена, а иначе редактор будет работать по минимальному значению сетки, то есть 1 юниту, что, исходя из вышесказанного, не очень хорошо, да и не очень удобно.

---

Включить или выключить привязку к сетке можно сочетанием «Shift + W» или нажав на «Map» в правом верхнем углу и в раскрывшемся списке поставить или убрать галочку у «Snap to Grid» (привязка к сетке).

---

Как правило, для построения стен, крыш, ландшафта и прочих элементов лучше брать бо́льшие размеры сетки, а для размещения различных предметов или детализации построек — меньшие. Классификацию размеров сетки можно следующим образом, но не ограничиваясь ею:

• 1, 2 — детальное размещение статичных, физических и динамических объектов, создание тонких оконных и дверных рам и прочих малых элементов;
  
• 4, 8 — создание деталей для зданий, дорог и прочих построек;
  
• 16, 32 — создание тонких и толстых стен, крыш и полов зданий, тротуаров и дорог;
  
• 64, 128 — создание набросков и муляжей зданий, крупных ландшафтных зон, больших ограждений и границ карты;
  
• 256, 512 — создание очень грубых набросков, первичная подготовка к созданию больших зон карты.

Важно: создание очень тонких (менее 2 юнитов) стен и схожих элементов мало того, что визуально смотрятся сомнительно, так ещё и программы VVIS (оптимизация и рендер) VRAD (освещение) могут неверно их воспринимать, что может привести к ошибкам.


Если с привязкой и размерами сетки разобрались, то что же насчёт соотношения размеров по отношению к игроку? Для базового понимания размеров можно использовать сущности (или же энтити). В виде таковой может выступать базовая сущность «info_player_start».

Данная сущность имеет высоту 72 юнита, а ширину и длину — по 32. Минимальные размеры проёма для прохождения игроком равны 74 юнитам в высоту и 33 в ширину, а вприсядку — 38 и 33 соответственно (в других играх значения могут отличаться).

Конечно, не стоит делать проёмы по их минимальным значениям, ведь это как минимум неудобно, а как максимум — некрасиво. Однако, ориентироваться только по этой конкретной сущности и модели не стоит. Например, двери имеют размер 109 в высоту, 49 в ширину и 12 в длину. Так какие же размеры стоит выбирать? Однозначного ответа для каждого случая нет, но есть некоторые базовые размеры, которых придерживаются картоделы, основываясь на текстурах разработчиков:

• 128 юнитов в высоту — стены, заборы (оптимальная длина — 16, 32 юнита);
  
• 40 юнитов в высоту — перегородки, перила;
  
• 32, 64 (и прочие кратные двум) в высоту, ширину, длину — коробки, ящики;
  
• 8 или 16 в высоту и длину — ступеньки, бордюры, уступы, на которые можно подняться;
  
• 112 в высоту и 56 в ширину — двери (с учётом рам).

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

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

В разделе выше упоминалось, что размеры нужно подбирать в соответствии с сеткой, а теперь отмечу, что не только размеры, но и положение брашей должно соответствовать сетке, хотя бы её минимальному значению в 1 юнит. Конечно, принцип «чем больше размер сетки, тем лучше» здесь тоже действует.

Кстати может показаться, что с сетки сойти нельзя, ведь даже при выключенной привязке объект всё ещё движется по ней в значении 1-го юнита. На самом деле это возможно, например, зажав клавишу «Alt» при перемещении либо изменяя вершины или разрезая браш.

---

Другой частой ошибкой является построение брашей друг в друге. Во многих редакторах других игровых движков, это, конечно либо вообще не приводит ни к чему плохому, либо остаётся на уровне визуальных ошибок.

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

---

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

Проблема арки заключается в том, что она создаёт множество брашей для создания нужной формы, а цилиндр — один. Во-первых, это сулит долгим наложением текстуры на каждый отдельный браш, а во-вторых — плохой оптимизацией и уменьшением лимитов.

Для сравнения возьмём два идентичных полустолпа и два закруглённых тротуарных поворота, один из которых из арки, а второй — из цилиндра. На столп из арки ушло 12 брашей по 5 граней каждый (60 граней итого), а из цилиндра — 1 браш по 11 граней. На тротуарный поворот из арки ушло 11 брашей по 5 граней каждый (55 граней итого), а из цилиндра — 1 браш по 12. Разница весьма заметна.

Создание закруглённых форм из цилиндра — довольно лёгкий процесс. Вам всего-то нужно создать цилиндр с расчётом на то, что потом обрежете его инструментом обрезки (Clipping Tool).

Хотите сделать закруглённый конец забора? Создайте равный со всех сторон цилиндр так, чтобы одна половина находилась внутри конца забора, а другая — снаружи, а после обрежьте внутреннюю половину. Тротуарный поворот на 90 градусов? Почти тоже самое, только вместо половины нам требуется отделить лишь четверть.

---

Пускай не столь частой, но всё же ошибкой можно назвать постоянное использование техники «соприкасающиеся углов брашей». Вопросы «Зачем?» и «Для чего?» обычно не приводили к чётким обоснованным ответам, и представляли собой: «Мне так показали / Я так увидел в интернете».

Сама техника является достаточно полезной: позволяет сэкономить некоторое количество граней (faces), что оказывает позитивный эффект на оптимизацию, и облегчает процесс текстурирования. Негативными эффектами являются увеличенная затрата лимита брашевых сторон (brushsides), дополнительная трата времени и неудобство изменения.

На заготовочных этапах создания карты, когда происходит обильное изменение структур и подгонка брашей под нужные размеры, её использование крайне не рекомендуется, поскольку это замедлит процесс, а также сделает неудобным дальнейшее редактирование.

Кроме того, не стоит её использовать там, где этого не требуется: как правило, не нужно использовать эту технику, если угол меж двумя брашами покрыт (или должен быть) текстурой «NoDraw», поскольку она уже удаляет покрытые ею грани из-за чего данная техника окажет лишь свои негативные эффекты.
Кстати, хоть она чаще используется для брашей в вертикальном положении, всё сказанное применимо и к горизонтальному: разницы между ними нет.

---

Не отходя далеко от предыдущей ошибки разберём примерно такой же момент со ступеньками. Да, отрезать половину ступенек и заместить под ними область одним брашем имеет точно такой же смысл, как в случае с соединением углов: экономия граней, удобство текстурирования. Из минусов — больше брашевых сторон, трата времени, неудобство изменения и больше брашей.

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

Если у ступенек видны только верхние и передние грани, то эта техника окажет лишь негативные эффекты. В таком случае можно либо оставить их в изначальном виде, либо протянуть каждую ступеньку до пола, где второй вариант более желателен для облегчения работы редактора.

Внимание: все невидимые игроку грани необходимо покрывать текстурой «NoDraw», иначе сказанное выше при любом раскладе не будет давать должного положительного эффекта. Для надёжности и удобства рекомендуется создавать браши сразу с этой текстурой, а уже потом менять на другую.

---

Ещё одной не менее редкой ошибкой является создание вогнутых брашей. Дело в том, что редактор не способен обрабатывать подобные фигуры, вследствие чего они просто не появляются на скомпилированной карте. Как правило, такие браши появляются только вследствие использования инструмента вершин или обрезки, поскольку все примитивы представляют собой выгнутые фигуры.

Если есть необходимость в создании вогнутой фигуры, то можно создать псевдовогнутую, состоящую из нескольких выгнутых фигур.

Обнаружить вогнутые фигуры можно не только после компиляции карты, но и до неё. Для этого нажмите на «Map» в левом верхнем углу, а после в развернувшемся списке на «Check for Problems» (проверка наличия проблем). Если на карте существуют вогнутые фигуры, то в открывшемся меню вы увидите строчки «Invalid solid structure» (недопустимая твёрдая структура).

Выбрав строку и нажав на кнопку «Go to error» (перейти к ошибке), все окна переместятся на место вогнутой фигуры. Кнопка «Fix» (исправить) в свою очередь либо устранит изъян не совсем предсказуемым образом, либо удалит браш, поэтому лучше исправлять вручную.

Хотя это стоит знать в первую очередь, многие до сих пор совершают эту вопиющую ошибку — отсутствие герметичности. Карты на движке Source нельзя, повторяю, вообще нельзя делать негерметичными. Что же это значит?

Отсутствие герметичности — это наличие утечек в пустоту. Пустота — это то, что вы видите при создании новой карты изначально, а именно чёрное и абсолютное ничего. Готовая карта обязана быть отделена от этой пустоты соединёнными брашами.

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

Главным и единственным способом герметизации карты является её отделение от пустоты соединёнными между собой брашами. Казалось бы, всё просто, но тут некоторые особо «хитрые» люди просто делают «коробку» (как правило, из текстуры неба) вокруг карты и думают, что всё нормально, хотя это совсем не так.

Она действительно герметизирует карту, это правда. Правда и то, что за большую цену:

• создаётся лишняя зона карты, которую потом придётся изолировать, дабы игроки туда не проникли;
  
• идёт ухудшение оптимизации уровня, так как ничего не даёт понять VVIS, что карта разделена на различные локации;
  
• происходит более долгая компиляция, поскольку VVIS начинает прорабатывать рендер с учётом этого пустого лишнего пространства, а VRAD — освещение.

Как же тогда лучше герметизировать карту? Если говорить о зданиях и проходах, то тут вроде понятно — следите за тем, чтобы между стенами, потолками и полами не было утечек.

С уличными просторами всё несколько иначе. Скажем, у вас есть условная локация с какими-то условными границами. Хорошим вариантом будет ограничивать её брашами с текстурой неба по её краям: стенам, заборам, крышам зданий или ещё чему.

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


Внимание: брашевые сущности (func_detail, func_brush и др.) и рельефные браши (известные как «дисплейсменты») не способны герметизировать карту.

---

Остаётся вопрос: «Как не упустить эти утечки?». Обычную аккуратность и внимательность, разумеется, никто не отменял, но есть и другой способ — указательный файл (Pointfile). Данный файл создаётся в процессе обработки карты программой VBSP, и указывает на месторасположение утечки относительно ближайшей к ней сущности.

Важно: файл не создастся, если на карте нет ни одной сущности.

Использовать этот файл можно нажатием на «Map» в верхнем левом углу, а после на «Load Pointfile» (загрузить указательный файл). Если же файла не существует (то есть утечки нет), откроется окно, предлагающее выбрать его вручную.

После открытия файла во всех окнах появится красная указательная линия, которая и подскажет, где находится утечка, но только одна за файл. Если утечек несколько, то и компилировать придётся несколько раз.

Совет: при поиске утечек выключайте программы VVIS и VRAD, оставив лишь VBSP. Так вы потратите меньше времени на их поиск, сократив длительность компиляции.

Проверять карту на наличие утечек таким образом, конечно, можно, но достаточно и просто заглянуть в журнал компиляции, в котором также будет об этом сообщено.

Ищите текст, гласящий «**** leaked ****» (есть утечка), где-то в начале журнала в разделе программы VBSP.

В Hammer Editor есть различные функции, что так или иначе расширяют его возможности или облегчают его работу. Есть правда и «плохие функции», что вредят общему положению вещей, и чьё использование крайне нежелательно или, можно сказать, запрещено.

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

• функция вырезки (Carve);
  
• функция «сделать полым» (Make Hollow).

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

Эта функция уже успела вдоволь прославиться своими проблемами, ей даже уделено развлекательное видео, которое хоть несколько и преувеличено, но от правды недалеко.

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


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

Любой игре, программе, коду, видео и даже файлам GIF необходима оптимизация. Карты — не исключение. Любой, кто скажет обратное, будет абсолютно неправ.

Карта — это фундамент любой одиночной или сетевой игры, от которого зависит то, как будет работать всё остальное и сколько это самое «остальное» может позволить себе потреблять ресурсов. В Source, чем лучше оптимизирована карта, тем больше на ней может быть. Соответственно, тем большей на ней может быть игроков и третьих элементов, добавленных, скажем, посредством дополнений.

Если вы уже как-то знакомы с такими вещами, как текстуры «Hint» и «Areaportal», а также с сущностью «func_detail», то о них речи здесь не будет, поскольку не они являются первичной оптимизацией, а то, как вы строите карту.

Во-первых, ключевую роль здесь играет то, правильное ли у вас построение брашей. Если да, то программе VVIS, отвечающей за оптимизацию, будет проще обработать информацию и выстроить её в правильном виде — виде оптимизированной карты. Кроме того, чем больше браши соответствуют форме куба и идут по сетке, тем лучше.

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

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

---

Скажем, вы ещё не знаете что такое визуальные листья и порталы, а также как работает оптимизация. Если вкратце, оптимизация в Source работает так: рендеринг происходит в зависимости от области, в которой вы находитесь, а не от точки вашего расположения и поворота камеры. Эти области — визуальные листья, а места соприкосновения — порталы.

Если вы находитесь в визуальном листе, то он будет отображать все объекты, что находятся в «видимых» ему листах, независимо от вашего расположения внутри него. Все отображаемые объекты будут так или иначе снижать производительность игры, пускай и чуть меньше, чем при прямом их виденье.

---

Если вы строите браши неправильно или создаёте области на пересечении этих линий, то готовьтесь к увеличению количества визуальных листьев и порталов. Само по себе это не вызывает явных проблем при игре, разве что вес карты будет чуть больше, чем мог бы быть, а вот в процессе компиляции и дальнейшей оптимизации через текстуру «Hint» ещё какие проблемы.

При неправильном построении брашей может произойти многократное увеличение листьев и порталов, что означает увеличение длительности компиляции, а в запущенных случаях — бесконечная компиляция. В свою очередь текстура «Hint» из-за этого будет ограничена в использовании, поскольку будет создавать ещё большее их количество, чем нужно бы.

Построение на пересечении автоматических линий разреза в свою очередь может как привести к увеличению визуальных листьев и порталов, так и быть использовано как инструмент, а именно как неполный аналог текстуре «Hint».

Избежать появления большого количества листьев можно построением брашей так, чтобы ваши проходы, а вернее границы их стен, шли по линиям разреза, а не параллельно им.

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

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

В начале многие рекомендуют использовать обычное окно (Normal) компиляции, а не экспертное (Expert), которое ещё называют расширенным (Advanced). Я советую забыть об обычном и сразу переходить на расширенный, правда сперва разберём ошибки с обычным, поскольку они идентичны в обоих случаях.

Открыв окно вы увидите разные программы с разными режимами компиляции.

Первым сверху вы увидите раздел с программой VBSP, отвечающей за структуру карты, построение визуальных листьев и порталов, размещение сущностей и... в общем, за основу карты. В обычном окне у неё есть три режима компиляции:

• No (Нет) — не запускает программу. Не используйте этот режим, поскольку все остальные программы компиляции не будут без него работать, а карта не создастся.
  
  
• Normal (Обычный) — обычный режим. Производит полную проработку карты и находящихся в нём объектов. Полученный результат после передаётся остальным программам, если они включены. Как правило, является основным режимом для этой программы, а процесс занимает от пары секунд до нескольких минут.
  
  
• Only entities (Только сущности) — режим, который компилирует только сущности на карте, что позволяет изменить их в уже готовой карте, без необходимости полной компиляции. При выборе этого режима программы VVIS и VRAD необходимо выключать.

Вторым вы увидите раздел программы VVIS, отвечающей за визуальный рендеринг объектов и его оптимизацию. Имеет три режима:

• No (Нет) — не запускает программу. Как правило, если вы не планируете проверять карту на визуальный рендеринг и оптимизацию, то её стоит выключать, поскольку на больших и открытых картах этот процесс может занимать длительное время.
  
  
• Normal (Обычный) — обычный режим. Производит полную проработку визуального рендеринга и его оптимизации. Является основным режимом при окончательной компиляции или проверке результата оптимизации, а процесс занимает от нескольких секунд до пары часов (на особо больших и сложных картах).
  
  
• Fast (Быстрый) — режим, сравнимый с выключенным режимом. Прорабатывает рендеринг максимально поверхностно, что можно сравнить с отсутствием проработки. Не используйте этот режим при финальной компиляции или проверке оптимизации, поскольку результат будет равносилен выключенному режиму, за исключением длительности.

Третьим будет раздел программы VRAD, отвечающей за проработку освещения:

• No (Нет) — не запускает программу. Как правило, если вы не планируете проверять карту на освещение, то её стоит выключать, поскольку этот процесс, как правило, занимает больше всего времени.
  
  
• Normal (Обычный) — обычный режим. Производит полную проработку освещения. Как правило, является основным режимом при окончательной компиляции или детальной проверке освещения, а процесс занимает от нескольких минут до нескольких часов, в зависимости от количества источников света.
  
  
• Fast (Быстрый) — упрощённый режим, прорабатывающий освещение в менее точной манере. Полезен при частых проверках освещения, поскольку занимает чуть меньше времени взамен менее точного освещения.
  
  
• HDR — режим расширенного динамического диапазона (High Dynamic Range). Если коротко, он добавляет эффект «привыкания к свету», придаёт более насыщенные цвета и их градиентов. Требует дополнительной отладки и настройки и, как правило, не рекомендуется к использованию начинающим, поэтому здесь рассмотрен не будет. Увеличивает длительность компиляции вдвое, поскольку происходит вторая компиляция уже в этом режиме, помимо обычного, а также увеличивает размер карты.

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

Крайне долгая компиляция VVIS в обычном режиме может быть результатом плохой структуризации карты и её построения, а также неиспользованием таких сущностей, как «func_detail». Это также относительно нормальное явления для очень больших загруженных карт.

Бесконечная компиляция VVIS в обычном режиме является исключительно личной виной: только карты со сложными неоптимизированными постройками или нарушением правил построения могут привести к подобному, а жертвование оптимизацией, используя быстрый режим или не использую VVIS вообще в конечной карте, — прямой знак наплевательского отношения к конечному пользователю.

Перейдём к расширенному окну компиляции, нажав на кнопку «Expert...».

Оно содержит примерно всё тоже самое и даже больше, но единственное, что мы затронем, так это один конкретный параметр и как пользоваться окном.

В левом верхнем углу есть список конфигурации (Configurations), где вы обнаружите всё те же режимы компиляций и пару дополнительных. Как было описано выше, быстрые режимы лучше не использовать, а режим HDR начинающему картоделу, как правило, не требуется. В связи с этим мы будем использовать стандартную конфигурацию (Default), которая равна выставлению всех программ в обычный режим без HDR.

---

• Строка «$bsp_exe…» — программа VBSP. Снятие галочки равно её выключению.
  
• Строка «$vis_exe…» — программа VVIS. Снятие галочки равно её выключению.
  
• Строка «$light_exe…» — программа VRAD. Снятие галочки равно её выключению.
  
• Строка «Copy File» — копирование файла. Снятие галочки приведёт к тому, что карта не будет обновлена в директории игры, а только в папке, где располагаются остальные её файлы.
  
• Строка «$game_exe» — запуск игры после компиляции. Рекомендуется выключать из-за неудобства и запуска игры в «чистом виде», которое может привести к неточной оценке состояния карты. Без галочки равна выставлению галочки у «Don't run the game after compiling» (не запускать игру после компиляции) в обычном окне.

---

Перейдём к главной причине использования расширенного режима, а не обычного. Помимо того, что вы рано или поздно перейдёте в него из-за многих дополнительных возможностей что он даёт, вам может потребоваться один параметр на начальных этапах, особенно если ваш компьютер не отличается хорошим процессором. Речь идёт о параметре «-threads <кол-во>», выставляющим максимальное количество потоков процессора.

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

Важно: программы компиляции могут использовать не более 16 потоков.

Если ваш процессор имеет от 2 до 8 потоков, то рекомендуется выставлять ограничение вдвое меньшее, поскольку это будет оптимальным решением как для компьютера, так и для компиляции. Если более 8 потоков — рекомендуется уменьшать на 4 или 6 потоков, а если более 16 — то не более 16, поскольку редактор их использовать не сможет.

Вводить этот параметр нужно в раздел параметров (Parameters) программ VBSP, VVIS и VRAD, перед всеми другими с пробелом в конце.



Примечание: количество потоков отмечено в журнале компиляции как «<кол-во> threads».

https://gtm.you1.cn/sharedfiles/filedetails/?id=2891705807
https://gtm.you1.cn/sharedfiles/filedetails/?id=2415740261

Если у вас есть вопросы, вам есть чем дополнить руководство или вы не согласны с написанной здесь информацией, пишите в раздел «Комментарии».

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