r_speeds или турбокарта
Автор: Smash
... вот и подошли к самому
проблемному делу для мапперов, а именно 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 везде и всегда...
Smash
|
Напиши
мне
