Counter-Strike 1.6

Флудилочка мапперов:)

Cooller^_^ — Mon, 24 Jan 2022 03:45:02 GMT

Форум: Маппинг CS
Описание темы: Общаемся здесь:)
Автор темы: Cooller^_^
Автор последнего сообщения: Ellipse
Количество ответов: 679

Проблемы с VHE

chakki056skrip — Mon, 08 Jan 2018 17:47:04 GMT

Он у меня не открывает одну карту, а раньше открывал!
Выдает ошибку. Скрин снизу.
Но как я ее открываю в worldcraft, а не vhe 3.4 то она успешно открывается!

Вот что там написано:

Помогите пожалуйста.

Добавлено (2014-05-13, 13:16)
---------------------------------------------
Closed

Извлечение текстур.

chakki056skrip — Mon, 08 Jan 2018 17:46:47 GMT

Всем привет.
Я тут исходник сделал карты de_alexandra, и теперь я хочу взять с карты в css для cs 1.6.
Один вопрос. Как Извлечь текстуры из карт в CSS или текстур там нет вообще?

Все об r_speeds

VedMak — Mon, 08 Jan 2018 17:46:30 GMT

Все об R_SPEEDS

В данной статье речь пойдет об очень важном параметре 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

Нужен помощник

chakki056skrip — Mon, 08 Jan 2018 17:46:14 GMT

Нужен помощник по маппингу в cs 1.6
Писать в skype: skrip.chikatilo

Задача помощника:
1. Оптимизация карты
2. Решение ошибок при компиляции и в cs
3. Ну вот и все:)

Кому несложно, пишите. Буду признателен.

Нужно узнать доп.контакты

chakki056skrip — Mon, 08 Jan 2018 17:44:42 GMT

Нужно узнать доп.контакты одного замечательного маппера!!!
Скайп вроде Dimex-By, но там он вроде бы его забросил!
Если есть доп.контакты пишите ниже
Вот фото

Добавлено (2014-03-09, 10:16)
---------------------------------------------
Closed
Нашел)

Оптимизация карты.

chakki056skrip — Wed, 30 Aug 2017 02:55:55 GMT

Всем привет!
Я давно создал красивую карту 35hp_party_2
Но на ней слишком много wpoly и epoly.(FPS маленький)
Кто сможет ее оптимизировать, писать сюда или в скайп zloy.kot56
карта
Спасибо.

Добавлено (2014-08-26, 17:15)
---------------------------------------------
wpoly - 2500
epoly - 2500-8000

Добавлено (2014-08-27, 14:44)
---------------------------------------------
Это срочно.

Вопросы и ответы по маппингу

Kzanders — Sat, 16 Apr 2016 06:47:44 GMT

Приветствую начинающих и опытных мапперов!
В этой теме задаем вопросы возникшие при создании карты!
Ну и конечно же отвечаем на вопросы других мапперов!

Ну вобщем я начну:
У меня такой вопрос! Как же создать арку, как на de_duste2 или de_inferno?

Выкладывайте свои работы!

Kzanders — Sun, 07 Feb 2016 20:52:41 GMT

В эту тему выкладывайте свои работы!
Пишем так:
1)Название -
2)Скриншет -
3)Описание -
4)Ссылка на скачивание -

И не забываем оценивать и коментировать работы других мапперов

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

Создаем свою первою карту

Kzanders — Sat, 14 Mar 2015 10:29:10 GMT

Для того, чтобы создать мапу вам нуно:
1.Хотябы чуть-чуть знать англ. язык
2.Уметь читать
3.Ну и конечно же терпение и сила воли

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

Мы надеемся, что Вы внимательно читали все предыдущие статьи Учебника, а следовательно умеете создавать простые браши, вставлять точечные энтити, умеете текстурировать объекты и имеете представление о компиляции (желательно BAT-файлом). Также от Вас потребуется знание следующих энтити-объектов:

info_player_deathmatch
info_player_start
light
Запустите редактор и создайте новый файл [Ctrl-N]. Выберите инструмент для работы с текстурами (разноцветный кубик). На появившейся панели Face Properties нажмите кнопку Browse. Внизу, в поле Filter наберите следующее: FIFTIES_WALL12 (это мы выбираем текстуру для стен будущей комнаты). Если у Вас подключен halflife.wad, то такая текстура найдется, если нет — подключите halflife.wad (он находится в директории valve с Half-Life). Выберите самую первую текстуру.

Закройте окно с выбором текстур. Установите вид сверху (2D top), выберите инструмен Блок [Shift-B] и постройте квадрат с размерами 384х384 юнита (размер контролируйте в строке состояния, внизу). Переключитесь на вид спереди (2D front) и удлинните прямоугольник также до 384 юнитов. Завершите создание браша нажатием на Enter.

Выделите только что созданный браш и нажмите [Ctrl-H]. Сейчас мы применим функцию Hollow, рассмотренную в прошлой статье. В появившемся окошке оставьте значение 32 и нажмите «OK».

Таким образом, у нас появилась комната с размерами 384х384х384 юнита и толщиной стенок 32 юнита (см. рис. ниже).

Теперь можно посмотреть на карту в виде 3D textured, залететь внутрь комнаты. Для перемещения в 3D-виде один раз нажмите Z и пользуйтесь кнопками W, A, S, D и мышью. В результате всех операций Ваша комната в трехмерном виде должна выглядеть приблизительно так (см. рис. ниже):

ЗАПОМНИТЕ! Не нужно применять функцию Hollow к каждому брашу на карте! Мы это сделали, чтобы быстро создать комнату, внутри которой можно будет бегать. Представьте, что браш — это обычная строительная плита. Так зачем же каждую плиту превращать в комнату, зачем каждую стенку на карте превращать в комнату (мы все равно там бегать не собираемся :), зачем превращать в комнату пол на карте — это абсолютно не нужно! Здесь же нам нужна была именно комната, внутри которой мы могли бы бегать, поэтому мы применили функцию Hollow. Точно такую же комнату можно получить, создав 6 стен по отдельности.

Теперь настало время вставить 3 объекта, о которых мы говорили в начале статьи. Первым вставим источник света, т.е. объект light. Выберите инструмент Entity Tool [Shift-E], затем на панели New Objects в списке выберите объект light (см. рис. ниже).

Поставьте вид сверху (2D top), подведите курсор к центру комнаты и нажмите левую кнопку мыши (см. рис. ниже).

Переключитесь на вид спереди (2D front) и поместите объект light под потолок (см. рис. ниже). Затем нажмите Enter, чтобы закончить создание источника света.

Итак, лампочку мы сделали. Теперь у нас на карте будет светло. Теперь остается создать точки появления контров и террористов. Как Вы уже знаете этими точками являются объекты info_player_deathmatch (террорист) и info_player_start (контр). Один объект — одна точка рождения. Чтобы на карте могли играть несколько игроков, необходимо ставить несколько точек для контров и для террористов.

Также как и в случае с лампочкой выберите в списке info_player_deathmatch и установите, как показано на рисунках ниже.

Обратите внимание, что объекты info_player_deathmatch и info_player_start не должны касаться стен (см. рис. ниже, вид top), друг друга и быть приподняты на некоторое расстояние над землей (см. рис. ниже, вид front). Это необходимо делать, чтобы игроки не умирали в начале раунда сами по себе и могли свободно двигаться. Вы замечали на некоторых картах при большом пинге и лагах, как игроки в начале раунда как бы падают на землю? Это происходит как раз потому, что между игроком и землей имеется некоторое расстояние. При качественном соединении такие «приземления» практически незаметны.

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

Все! Первая полностью рабочая карта создана! Конечно ее еще надо откомпилировать, но пока сравните то, что получилось у Вас, с нашей картинкой. Если все приблизительно так, сохраните карту под именем my1map (или любым другим) в формате RMF и затем в формате MAP, чтобы можно было откомпилировать.

Чтобы откомпилировать карту нужно создать BAT-файл. Скопируйте приведенные ниже строки в Блокнот и сохраните файл как COMPILE.BAT (подробно процесс создания BAT-файла описан в статье «Как компилировать?»).

Ниже мы приводим пример простенького BAT-файла, которым Вы сможете откомпилировать свою первую карту.

@echo off
set WADROOT=c:\games\half-life
set mapname=my1map.map
hlcsg.exe "%mapname%"
hlbsp.exe "%mapname%"
hlvis.exe "%mapname%"
hlrad.exe "%mapname%"

Поместите COMPILE.BAT к компиляторам, туда же скопируйте карту в формате *.MAP и запускайте BAT-файл. Через пару секунд в этой же директории будет готовая BSP-карта.

Замечание: если имя карты не my1map, то измените его в строке set mapname=my1map.map, а также измените путь к директории с Half-Life, если он другой.

И последнее, сохраните Вашу первую карту на память. Позже, месяцев так 5-6 спустя, посмотрите на нее. Мы уверены, Вы как минимум улыбнетесь