Оптимизация - сделайте нам быстро!

Итак, движок Халвы оперирует 2 типами объектов — энтити и браши. Первое — все активные объекты, вторые, грубо говоря — части уровня, т.е. блоки. Первые подгружаются из сохранялок, вторые непосредственно из BSP-файла. Вся геометрия разбивается на грани, которые разбиваются на треугольники — элементы граней (почему? потому что просчёт выпуклых многоугольников проще и быстрее, а треугольник — единственный всегда выпуклый многоугольник.

Простая логика подсказывает, что чем больше этих треугольников, тем большую работу приходится выполнять движку по отрисовке одного злосчастного кадра. Как узнать количество граней на уровне? Наберите в консоли gl_wireframe 1 или 2. Впечатляет? Тогда идём дальше — как всё это привести в порядок.

Любой маппер всегда разрывается между двумя задачами — сделать самый навороченный и одновременно самый шустрый уровень. Сделать уровень шустрым может либо упрощение геометрии, либо убирание паразитных граней, образованных в результате BSP-компиляции.

Движок Халфы устроен так, что не допускает наложений граней, поэтому любая грань объекта попадающая в плоскость с другой, эту самую другую разбивает на новые грани. Нетрудно подсчитать, что два пересекающихся прямоугольника по 6 граней каждый в лучшем случае наплодят 9х6=32 грани. Особенно много паразитных граней вызывают колонны. Это просто бич какой-то.

Методы борьбы чрезвычайно просты. Поскольку энтити не учавствуют в BSP компиляции, они не разбивают геометрию. Следовательно все трубы, колонны и объекты сложной геометрии следует делать func_wall'ами (а в недоступных для трогания местах даже неосязаемыми func_illusionary). Прирост производительности иногда бывает достаточно ощутимым.

Впрочем не только браши вызывают дробление геометрии, но и обычные.. текстуры. Чем выше масштаб текстуры, тем на большее число многоугольников разбивается многострадальная грань. Т.е при девятикратном уменьшении масштаба текстуры 256х256, многоугольник такого же размера превращается в 9 многоугольников.

Ладно, текстуры у вас ужасно растянуты и чуть ли не весь уровень стал "стенками". Что ещё?

Много чего. Начнём с того, что при BSP-компиляции все грани с наружной стороны уровня, принадлежащие т.н. HULE 0 удаляются. Удаляются они, если на уровне нет дыр. А если есть дыры, и маппер обтянул уровень большой коробкой во избежание утечек пространства (LEAK'ов), то удаляется лишь внешняя сторона этой самой коробки, и уровень жутко тормозит, хотя мог бы быть обрезан компилятором минимум вдвое. Так же хорошего прироста производительности дает Vis, запущенный с параметром -full, но начинающие мапперы им редко пользуются, т.к. он долгий, и после него ужасно тормознуто работает rad. Хочу сказать этим маперам, что применение Виза на завершающем этапе компиляции просто ОБЯЗАТЕЛЬНО, хоть он и работает час-полтора.

Если карта продолжает тормозить, возможно на уровне много ентить с большим количеством граней, как-то монстров, высокодетализированных моделей оружия, и импортированных моделей в объектах типа monster_furniture, monster_generic и cycler.

Простой совет: наберите в консоли r_speeds 1

Значение w_poly (world) не должно в идеале превышать 800 - 1000 граней, а e-poly (ентити) — 10000 - 20000 граней. Очевидно, что чем больше отрисовывается движком, тем вероятнее перегрузка и заметнее подтормаживание.

Вот в общем и всё. Красивых и (главное) шустрых вам карт, товарищи мапперы!