Так значит зачем-же этот r_speeds нужен? А-а-ааа, он-то как раз и не нужен никому - чем он выше, тем меньше FPS. Чтобы узнать r_speeds на вашей карте, для начала запустите ее, потом откройте (опустите) консоль и пропишите в ней следующее:
developer 1
r_speeds 1
...и после этого вы узреете в вверху экрана бегущие циферки:

1. Это ваш ФПС.
2. А это нам не нужно...
3. Вот это и есть количество полигонов (wpoly).
4. А вот это тоже не нужно =).

Говорил когда-то Клиф, что количество wpoly нигде не должно превышать 600. Но это было давно - тогда еще компы слабые были Теперь уже можно и побольше допустить...

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

Ну вы уже поняли что это такое? Тогда начнем разговор о самом основном - о советах про снижение r_speeds на карте.

1. Движок обрабатывает все что видит игрок, и все что находится за энтитями. Например если у вас ящик - энтити, то движек прорисует все что есть за ящиком. Понятно? Так что старайтесь, не делать на карте стены func_wall'ами Так, поехали дальше...

2. Старайтесь не делать больших открытых пространств, и переграждайте видимость игрока всевозможными ящиками, стенами, ну и т.д.... Также не следует создавать на карте множество мелких предметов. Почему? Во-первых, больше обьектов - больше полигонов - больше r_speeds - меньше FPS -больше тормозит карта:( - поэтому много мелких частей (да и не только мелких) о-очень мешают игре. Во-вторых все браши соприкасающиеся с другими, разбивают их на дополнительные полигоны. Вот взгляните на эту "схему", и вы все сразу поймете:

Как видите, соприкасающиеся браши бьются на дополнительные полигоны. Так что вы уже, наверное, поняли почему нельзя создавать на карте очень много мелких предметов (тем более, если они соприкасаются с другими объектами). Хотя эта проблема разрешима! Нужно просто делать отступы между брашами в размере 1-го юнита. Тогда браши не соприкасаются, и соответственно не разбиваются на дополнительные полигоны. Способ второй: сделать мелкие браши энтитями. Энтити не разбивают соприкасающиеся с ними объекты на дополнительные полигоны:

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

3. Рассмотрим следующую конструкцию:

Тут просто браши-колонны. R_speeds равен 146 полигонов. Теперь сделаем верхние и нижние части колонн func_wall'ами:

На рисунке: части обведенные краным - func_wall'ы, а там где обведенно зеленым - отступ в 1 юнит, который делать было и не надо (мы-же перевели "подставки" в func_wall, а энтити не разбивает браши при компиляции (было показано только для примера!)). Но если бы вы не сделали "подставки" энтитями - то отступ не помешал (тогда бы браш не "разбился" на более мелкие). Эффект очевиден! - после этой несложной процедуры r_speeds упал со 146 полигонов до 102.

Вывод: мелкие частицы (как уже упоминалось) лучше переводить в func_wall'ы. Тогда r_speeds снижается, причем неплохо снижается. Но! - энтити не отбрасывают теней. Поэтому если вы сделаете ящик энтитей, то тени не увидите, хотя r_speeds сбросите.

А выход оказывается есть, но только если у вас ZHLT выше версии 2.2. Если так и есть, то в параметрах энтитис (solid-based entity's), есть такой параметр, как Light Flags (Zhlt 2.2+), и по дефолту его значание установленно Normal, а если поставить Opaque + Embedded Fix, то появятся тени! Поняли? Дальше...

4. Есть один прикол: SKY-фэйсы (ну, окрашенные SKY-текстурой). Как известно, SKY-фэйсы и SKY-браши не обрабатываются движком как полигоны (например небо - за полигоны не считается:) ). Так вот: если у вас, например, есть на карте высокий ящик, верхний фэйс которого никто не сможет увидеть ни откуда (разве-что с выключенным sv_gravity:) ), то окрасьте этот фэйс текстурой SKY - он не обработается как полигон, и wpoly будет меньше. Конечно, один полигон вас не спасет, но если таких мест на мапе много, то этот способ о-очень пригодится, тем более если у вас завышенные показатели wpoly.

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

А вот так:

Во первых вид в игре красивее. А во вторых иногда получается что wpoly бывает и меньше... Как видите, сущевствует куча методов снижения r_speeds.

5. Сущевствует еще один метод снижения r_speeds - браши с HINT и SKIP текстурами. Но об этом вскоре будет отдельная статья (потому-что очень долго расказывать и показывать).

Фууух! Вот и рассказал немного:) про полигоны... Так что перед тем как создавать новую карту - подумайте, можно ли будет ее реализовать с таким количеством полигонов, которое не будет превышать предельно допустимую норму.

Суть всего вышеизложенного должна быть вам понятна

Желаю вам низкого r_speeds везде и всегда...

Источник: http://alien.cs-mapping.com.ua/stat_3.php