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

1. Что такое R_SPEEDS?
R_SPEEDS — это специальный параметр, который показывает количество полигонов, видимых игроком на карте. Чем больше полигонов одновременно отображаются, тем меньше FPS (количество кадров в секунду). Если полигонов слишком много, то карта начинает, как говорится, «тормозить». Итак, FPS зависит от количества полигонов, а значит от показаний параметра R_SPEEDS. Чем больше R_SPEEDS (чем больше полигонов), тем меньше FPS и наоборот.

R_SPEEDS параметр динамичный, он меняется в зависимости от положения игрока на карте и от направления его взгляда. Действительно, если Вы будете смотреть в стену или угол, то количество кадров в секунду скорее всего будет максимальным 99-100. Если же Вы выйдете на открытое пространство, то FPS будет уже поменьше, а R_SPEEDS соответственно побольше.

2. Как узнать R_SPEEDS на своей карте?
Итак, как же нам посмотреть R_SPEEDS на своей карте?

Проверьте, что в ярлыке для CS у Вас прописан параметр -console, который позволит нам открыть консоль в игре. Т.е. строка запуска игры выглядит примерно так: C:\Games\HL\hl.exe -game cstrike -console.

Создадим сервер на своей карте. После загрузки уровня, выдвинем консоль и напишем:

developer 1
r_speeds 1

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

Как Вы можете видеть, цифры разбиты на 4 колонки. Нас интересуют колонки со словами wpoly и epoly (это 2 правые колонки).

310 wpoly — (от англ. world polygons) количество полигонов, которые создают браши: земля, стены, крыши, скалы и т.п. Это основной показатель R_SPEEDS. Чем больше wpoly, тем больше тормозит карта.

988 epoly — (от англ. entity polygons) количество полигонов, которые создают модели (руки с оружием, игроки, другие модели). Когда Вы видите на экране 4-5 игроков, то epoly заметно выше, нежели если Вы видите 1 игрока.

Если набрать в консоли команду r_drawviewmodel 0, то это уберет с экрана изображение рук и оружия и тем самым, снизит показатель epoly до нуля (если Вы не видите других игроков). На слабых компьютерах это может значительно повысить FPS (примечание: данная консольная команда была актуальна для CS версии 1.5 и более ранних, в CS 1.6 убрать оружие с экрана нельзя из-за щита).

На двух картинках ниже наглядно продемонстрирована зависимость R_SPEEDS (и FPS) от размера видимого пространства.

Этот скриншот сделан на базе террористов на карте de_aztec. Здесь R_SPEEDS равен 167 полигонам (в данном направлении взгляда). Количество кадров в секунду максимально и равно 99 FPS.

Теперь переместимся ближе к точке закладки бомбы (у воды). Здесь R_SPEEDS гораздо выше и составляет порядка 800-850 wpoly, что вызывает понижение FPS до 50, как видно из рисунка. Компьютер, на котором проводился тест: Pentium III 600 МГц + GeForce 256.

3. Каким должен быть максимальный R_SPEEDS?
Споров на тему максимального R_SPEEDS много. Одни говорят, что параметр wpoly не должен быть больше 600, другие допускают 1000 wpoly, приводя в качестве аргумента тот, факт, что компьютеры на данный момент довольно мощные.

Мы придерживаемся следующего мнения:

1) В местах стычек команд, там, где постоянно происходят перестрелки, количество wpoly должно быть минимально — до 600 (в идеале: 400-450).

2) На базах команд, в тех местах, где игроки появляются редко или встречаются 1 на 1, а не 5 на 5, количество wpoly может быть больше — до 750.

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

И еще один совет, побегайте по стандартным CS картам с включенным параметром R_SPEEDS. Вы увидите, что количество wpoly на них довольно низкое, что позволяет комфортно играть даже на слабых машинах. Итак вывод: чем меньше R_SPEEDS на Вашей карте, тем лучше.

Epoly не такой важный показатель как wpoly, однако слишком высокие значения (больше 4000-5000 epoly) этого параметра также вызывают существенное понижение FPS. В принципе, на показатель epoly внимания обращать не следует. При тестировании карты необходимо учитывать лишь значения wpoly.

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 и выше)
Что касается последнего пункта, то команда -subdivide х (где х — значение от 240 до 512) указывает после какого количества пикселей необходимо разбивать поверхность на полигоны. НО!!! Этот параметр глючит и не дает докомпилировать карту! :( По крайней мере так было с улучшенными компиляторами 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 прыгать слишком высоко и принимайте вовремя меры.

Материал взят с сайта cs-mapper