у Вас карта. Вы узнаете, как посмотреть R_SPEEDS на созданной Вами карте и как его уменьшить в случае,

если карта «тормозит».

Содержание статьи:

• Причины большого R_SPEEDS
  
• Методы снижения R_SPEEDS
  
• Консольные команды
  

4. Причины большого R_SPEEDS?

Итак, мы уже знаем, что количество кадров в секунду зависит от количества полигонов, которое в своем

максимуме должно составлять 500-700 wpoly. А теперь давайте посмотрим от чего же зависит количество

полигонов и вообще из чего получаются полигоны.

4.1 Разбиение на полигоны при соприкосновении брашей

Игровой движок Half-Life устроен таким образом, что при соприкосновении малого браша с более крупным

(например, ящик стоит на земле) происходит разбиение земли на более мелкие полигоны. Вот как это

происходит (белые полосы обозначают границы полигонов).

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

На следующем рисунке ящик превращен в энтити-объект func_wall, а энтити-объекты НЕ РАЗБИВАЮТ браши

на полигоны. Отсюда и первый способ оптимизации карты — мелкие объекты вроде ящиков можно превращать в

func_wall (другие варианты: func_breakable, func_pushable, возможны и другие варианты). Это первое важное

правило, которое необходимо запомнить.

Абсолютно неважно какой энтити-объект Вы используете (func_wall, func_breakable, func_train,

func_illusionary, func_button, func_vehicle или любой другой энтити-объект) — при соприкосновении с

брашами разбиения не происходит!

Еще один пример: светильник, сделанный из нескольких брашей, разбивает стену.

Но если мы превратим светильник в func_illusionary, разбиения уже не будет и несколько полигонов мы тем

самым сбережем.

Кстати, очень часто в узких местах на картах (корридоры, туннели) мелкие объекты (светильники, картины

...) превращают func_illusionary. Это помогает, во-первых, сберечь несколько полигонов, а?

во-вторых, не мешает игроку передвигаться (игрок может спокойно проходить сквозь

func_illusionary).

Из всего этого, конечно же, не следует, что Вы должны все ящики на карте превращать в func_wall. В

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

тот или иной браш в энтити-объект. Вот один из таких примеров.

Допустим, на карте Вы создали великолепные колонны с подставками (см. рис. ниже). Каждая колонна имеет по

16 боковых граней.

Слева и колонна, и подставки оставлены как обычные браши. В этом случае обе подставки (и нижняя, и

верхняя) разбиваются каждая на 16 полигонов (по количеству боковых сторон колонны). Таким образом, на

данном участке карты количество полигонов увеличивается на 32. А если мы сделаем 10 таких колонн?

Полигонов будет уже 320!

Справа обе подставки были превращены в func_wall, саму же колонну мы оставили как браш. Никакого

разбиения не происходит. Мы сэкономили 32 полигона!

На рисунке видно, что для отображения границ полигонов мы запустили CS в режиме OpenGL и ввели

команду gl_wireframe 1 (также можно использовать gl_wireframe 2, тогда объекты станут

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

Другой полезной консольной командой является r_drawflat 1, которую можно использовать только в

режиме Software. В этом случае каждый отдельный полигон окрашивается в свой цвет.

Вот как в этом режиме будет выглядеть левая брашевая колонна:

Вторая же колонна с подставками из func_wall выглядит так:

Необходимо заметить, что в обоих случаях, чтобы можно было использовать указанные консольные команды,

карту следует запускать из консоли (то есть запускаем CS, заходим в консоль и пишем map

имя_карты). Если Вы создадите сервер, как обычно, из меню, то команды работать не будут, т.к. они

запрещены в мультиплеере.

ВАЖНО: никогда не превращайте в энтити-объекты стены (или не дай Бог пол!),

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

рисует все, что находится за ними. Например, если за какой-то стеной находится полкарты и Вы превратите

ее в func_wall, то в этом месте будут большие «тормоза» из-за высокого R_SPEEDS.

4.2 Разбиение на полигоны текстурами

Как Вы знаете, текстуры имеют определенный размер, например, 128х128 пикселей. Давайте представим, что у

нас на карте есть стена с размерами, бОльшими, чем размер текстуры, например, 256х256 юнитов. В этом

случае хоть браш у нас и один, но полигонов будет больше.

Например, если стена имеет размеры 256х256, а текстура 128х128, то данный браш будет разбит на 4

полигона, т.к. площадь текстуры ровно в 4 раза меньше площади браша.

В редакторе Hammer у нас есть возможность менять масштаб текстуры. Делается это (напомним на панели

«Face Properties» в параметре Scale.

Взгляните на картинку ниже, на ней очень хорошо видно, на сколько различается количество полигонов при

использовании различных масштабов текстур.

На левой стене текстуры нанесены с масштабом 4х1 (полигонов всего 6), а справа — 1х1 (полигонов в 16 раз

больше!). Конечно, стенка слева выглядит более размазано, но в случае, когда необходимо уменьшить

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

при увеличении масштаба текстур на вот таких больших по площади брашах (скалах, земле).

4.3 Большие открытые пространства

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

является открытость карты и чрезмерная насыщеность деталями.

Игровой движок Half-Life не расчитан на большие пространства (необязательно, что это открытое

пространство (с небом). Большой пребольшой ангар с массой деталей тоже будет тормозить). Помните для

какой игры Вы создаете карты, это Вам не Unreal Халф любит закрытые помещения, всякого рода

коридорчики и очень расстраивается, когда Вы его заставляете рисовать высоченные горы или 50 многоэтажных

зданий на одной улице. Если, созданная Вами карта тормозит, и R_SPEEDS приближается к нескольким тысячам

wpoly — нужно координальным образом (хирургическими методами изменять карту.

5. Методы снижения R_SPEEDS

Несколько основных методов снижения R_SPEEDS мы только что разобрали в пункте 4. Существуют и другие

хитрости, которых помогут снизить R_SPEEDS на Вашей карте.

• Превращение мелких брашей в энтити (рассмотрено)
  
• Увеличение масштаба текстур (рассмотрено)
  
• Закрытие обзора игрокам
  
• Метод зазора в 1 юнит
  
• Метод с использованием текстур 240х240 пикселей
  
• Применение SKY-текстур
  
• «Разделение» карты на отдельные пространства
  
• Использование HINT-брашей
  

Рассмотрим все оставшиеся пункты кроме последнего восьмого (метод №8, как наиболее сложный — тема

отдельной статьи).

5.1 Закрытие обзора игрокам

Собственно, это даже не метод как таковой. Просто карту необходимо строить таким образом, чтобы не было

больших открытых пространств.

Что понимать под большими открытыми пространствами?

Приведем конкретные примеры.

Приведенные выше примеры показывают, каких максимальных размеров должны быть открытые пространства в CS.

Учтите еще то, что авторы этих карт — профессионалы, которые наилучшим образом оптимизировали свои карты.

Такими же профессионалами можете стать и Вы, для это необходимо всего-то прочитать все статьи нашего

Учебника :).

Итак, создавая открытое пространство, не выходите за рамки разумного. Все пути и подходы к такому

«нагруженному» месту должны быть или чем-то отгорожены (как на de_cbble огромными толстыми воротами,

рис.1), или просто они должны быть изогнутыми (рис.2).

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

Естественно, мы привели лишь несколько вариантов, например, можно еще «поиграть» с рельефом (сделать

подходы наклонными, как на базу контров на de_cbble), тем более, что «многоэтажные» карты очень нравятся

игрокам (de_aztec, de_dust2). Вариантов можно придумать массу, главное понимать, как работает игровой

движок, как он разбивает карту на видимые пространства (более подробно об этом будет рассказано в статье

про 8-й метод с HINT-брашами).

5.2 Метод зазора в 1 юнит

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

над поверхностью земли.

Действительно, если подумать, то в таком случае ящик, висящий над землей на расстоянии всего в 1 юнит, не

касается ее поверхности. А если нет соприкосновения, то нет и разбиения земли на полигоны. К тому же

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

Естественно, в таком случае ящик не нужно превращать в энтити-объект.

Данный метод широко применяется на таких картах как: de_train, de_aztec, cs_backalley. Вот, например,

картинка с de_train:

На картинке видно, что бетонная подставка под столб больше его по площади. А это значит, что при

соприкосновении, она была бы разбита на 4 полигона. Автор карты сделал небольшой промежуток между столбом

и подставкой (1-2 юнита). Теперь соприкосновения нет, и вместо 4 полигонов мы имеем всего 2 («днище»

столба и верх подставки). А если мы закрасим «днище» столба текстурой SKY, которая не создает полигонов,

то будет отрисован всего 1 полигон (об использовании SKY-текстур для оптимизации карты читайте ниже).

Также на этой карте подняты над землей все вагоны и некоторые ящики — это позволило избежать

многочисленных разбиений земли.

На de_aztec не доведены до потолка провода и лампы. Между ними и потолком также есть зазор.

На de_nuke также применен данный метод (см. рис. ниже).

Естетсвенно, не стоит впадать в крайности и подвешивать абсолютно все ящики и пр. объекты. Делайте это в

случае необходимости, при большом R_SPEEDS.

5.3 Метод с использованием текстур 240х240 пикселей

Это очень действенный (супер действенный метод уменьшения количества полигонов. Суть заключается в

том, что движок Half-Life разбивает абсолютно все поверхности через каждые 240 пикселей текстуры.

Неважно, что Вы «натянули» на ящик текстуру 256х256 пикселей, она все равно будет разбита через 240

пикселей.

Сейчас мы вновь воспользуемся запуском карты из консоли и бесценной командой gl_wireframe 1 (режим

OpenGL). На картинке ниже изображен ящик размером 256х256 юнитов с наложенной на него текстурой также с

размерами 256х256, но естественно пикселей. Применив консольную команду gl_wireframe 1, мы с удивлением

замечаем, что вместо 1 полигона (ведь текстура всего лишь 1) у нас отрисовано целых 4! В чем же дело?

Почему на каждой стороне ящика по 4 полигона? Ведь теперь получается, что один единственный ящик создает

аж: 4 х 5 = 20 полигонов (5 — число видимых сторон)???

Как Вы уже знаете, движок Half-Life разбивает все поверхности на полигоны через каждые 240 пикселей

текстуры. Чтобы было понятнее, приведем еще один рисунок. На нем мы видим тот же ящик, но чуть поменьше —

240х240 юнитов. Текстура также наложена в масштабе 1х1. Здесь мы как бы не видим часть текстуры (от нас

скрыты 16 пикселей по ширине и 16 по высоте).

И дело именно в текстурных пикселях, а не размере ящика в юнитах. Вот посмотрите на еще один пример.

Здесь ящик уже совсем маленький 96х96 юнитов, а текстура все таже 256х256. В редакторе мы применили к

текстуре «Fit» (кнопка на панели «Face Properties»), которая сжала нашу большую текстуру до размеров

ящика.

Как видите, даже такая маленькая поверхность ящика разбита на 4 полигона. То есть происходит как бы

отсчет 240 пикселей на текстуре и делается «шов». Таким образом, если ящик имеет 5 видимых сторон (дно мы

не видим), то вместо ожидаемых 5 полигонов мы имеем 20! А если у нас 10 ящиков, следовательно, вместо 50

полигонов у нас будет 200! То же самое касается всех объектов, на которые наложена текстура 256х256

(вобще это сейчас очень популярный размер текстуры, а зря!). Часто мапперы накладывают 256х256 текстуры

на стены, крыши, проходы, скалы — все это ЗНАЧИТЕЛЬНО увеличивает количество полигонов.

Выходы здесь следующие:

• использовать текстуры с размером 240х240 пикселей (лучше всего)
  
• не делать «Fit» для текстур 256х256 (т.е. чтобы видно было лишь 240 пикселей текстуры)
  
• делать стены высотой 240 юнитов, в таком случае часть текстуры 256х256 будет скрыта
  
• использовать параметр -subdivide х для компилятора HLBSP (вместе с ZHLT Custom Build 1.7 и

  выше)
  

после какого количества пикселей необходимо разбивать поверхность на полигоны. НО!!! Этот параметр глючит

и не дает докомпилировать карту! :( По крайней мере так было с улучшенными компиляторами ZHLT Custom

Build версией 1.7. Надеемся, в будущем эту ошибку исправят, и мы сможем использовать текстуры вплость до

512 пикселей, и при этом не будет происходить разбиения на полигоны.

С официальными ZHLT 2.5.3 данный параметр не работает (он появился только в Custom Build). Автор

улучшенных компиляторов замечает, что в режиме Software возможно возникновение проблем из-за этого

параметра, но у нас и многих других мапперов он вообще не работает! В общем задумка неплохая, но

реализация хромает.

5.4 Применение SKY-текстур

Вы уже знаете, что SKY-текстуры применяются для создания неба. Но они обладают еще одним очень хорошим

свойством: стороны объектов, окрашенные текстурой SKY, не создают полигонов! То есть, если мы покрасим

какие-нибудь объекты SKY-текстурой, то они не создадут полигонов, правда, при этом будут абсолютно

прозрачными (через них будет видно небо :).

SKY-текстуры нужно наносить на те поверхности, которые игрок в игре увидеть не может. Что это за

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

не видит.

Действительно, ведь не может же игрок увидеть крыши домов, например, здесь (см. рис. ниже).

В этом случае мы просто берем и закрашиваем все крыши SKY-текстурой (см. рис. ниже).

Теперь у нас на карте полигонов станет поменьше, плюс меньше времени уйдет на компиляцию, т.к.

SKY-поверхности не нуждаются в просчете освещения (они попросту игнорируются).

Все мы замечали, играя например на de_dust, что, если в режиме спектатора подняться чуть выше стен, то

потолки становятся прозрачными (см. рис. ниже).

Это как раз и является доказательством того, что на них была нанесена текстура SKY с целью уменьшения

количества полигонов.

Примечание: если Вы по каким-либо причинам создаете небо в виде большой коробки вокруг карты, то следует

закрасить SKY-текстурой все внешние стороны карты, а также ее дно (см. рис. ниже).

В этом случае мы резко уменьшаем время компиляции (т.к. теперь внешние стороны карты (и ее дно), которые

игрок все-равно никогда не увидит, не просчитываются на освещение).

Ну, а если Вы строите правильное небо (куполом над картой), то делать этого нет необходимости. А вот

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

5.5 Разделение карты на отдельные пространства

Теперь давайте рассмотрим последний метод (в данной статье) — метод разделения карты на отдельные

пространства.

В принципе данный метод по сути является методом создания правильного неба, когда SKY-браши строятся по

периметру карты, как бы повторяя ее внешние и внутренние стены.

Рассмотрим принцип построения карты на примере популярной de_dust2.

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

разделение — каждое пространство отделено от соседнего или воротами, или проходом в стене

Находясь в одном из этих пространств, игрок видит лишь его одно, ну, и незначительную часть соседнего

пространства (остальные области карты движок Half-Life не рисует — отбрасывает). Все это позволяет

добиться отличного R_SPEEDS и прекрасной скорости отрисовки карты.

Пришло время познакомить Вас с еще одной полезной для тестирования карты консольной командой:

r_draworder 1.

Эта команда работает только в режиме Software и при условии, что карту Вы запускаете из консоли, а

не через игровое меню.

При использовании этой команды Вы можете видеть, как работает игровой движок, какие области карты он

отрисовывает.

Вот, например, как будет выглядеть de_dust2 в первой своей области.

Мы находимся у базы контров (бомб-плейс «А»). Движок Half-Life помимо напрямую видимых частей карты,

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

идти не на базу, а налево, там, где спуск и тупик). Все остальное движок не рисует.

Или вот картинка с третьей области (тоже около базы контров, но только у центрального прохода).

Здесь виден весь центральный проход (несмотря на ворота) и часть базы «В». Все остальное также

отбрасывается.

А теперь давайте представим, что было бы, если бы наша карта представляла из себя эдакую коробку, в

которой не было бы никаких внутренних стен и проходов?

В этом случае движок отрисовывал бы всю карту, что, естественно, заметно повысило бы ее «тормознутость».

Вывод из всего этого таков: карту необходимо разбивать на области. Области должны соединяться какими-то

проходами или находиться на разных высотах (одна область ниже, другая выше).

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

рисует пространства, находящиеся за этой стеной. Например, в таком случае:

Игрок, обозначенный фиолетовой фигуркой, на самом деле не видит, что находится за стеной, однако игровой

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

как бы перепрыгивает через это невысокое препятствие, рисует область карты за ним и тем самым увеличивает

количество полигонов.

Какой высоты должна быть стена сказать сложно. Иногда кажется, что ты сделал действительно высокую стену,

скажем 320 юнитов, а движок все-равно рисует то, что находится за ней. А если Вы не хотите делать все

стены на Вашей карте высотой по 400 юнитов? Что делать?

Исправляется это созданием над стеной SKY-браша. Этот SKY-браш повторяет форму стенки и занимает все

пространство от ее верхней части до неба (верхнего SKY-браша).

В другом примере с воротами (см. рис. ниже) данный прием вряд ли поможет сберечь полигоны, т.к. движок

прекрасно «пробирается» сквозь отверстие ворот. Однако, если игрок напрямую не будет видеть ворота (будет

смотреть в сторону), то данный прием также может сработать, и движок «отрежет» часть карты за воротами.

Поэтому и в этом случае рекомендуем создать SKY-браш между воротами и верхним SKY-брашем.

Так необходимо поступить со всей картой — разделить ее SKY-брашами на отдельные области. Кстати, при

создании общего освещения можно сделать лишь 1 объект light_environment, поместить его в любую из

областей, и все области будут нормально освещены, т.е. делать несколько «солнышек» нет необходимости (это

раньше приходилось освещать каждую область отдельно).

Рассказывая про данный метод, мы уже вплотную приблизились к последнему методу повышения FPS на карте —

применению HINT-брашей. Естественно, в данной статье про этот метод мы рассказывать уже не будем (и так

статья получилась просто огромная :), а вот начальные знания о работе игрового движка, полученные в этой

статье, Вам пригодятся.

6. Консольные команды

И в заключении статьи напомним консольные команды, которые мы использовали для тестирования карты.

developer 1 — отображает на экране различные служебные сообщения;
r_speeds 1 — выводит на экран показатели wpoly и epoly;
gl_wireframe 1 / 2 — показывает границы полигонов (OpenGL);
r_drawflat 1 — заменяет текстурные поверхности на цветные (Software);
r_draworder 1 — показывает какие области карты отображает игровой движок (Software)

Последние 3 команды будут работать только в случае запуска карты из консоли (как одиночного уровня

Half-Life).

На этом все. Не позволяйте R_SPEEDS прыгать слишком высоко и принимайте вовремя меры.