... вот и подошли к самому проблемному делу для мапперов, а именно r_speeds!
Что-же это такое, и с чем его едят? Значит так: r_speeds это количество
полигонов, которые обрабатывает движок. Например на кубе 6 фейсов - уже
есть 6 полигонов.
Так значит зачем-же этот 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 везде и всегда...
Misha-441496727
