Причины падения FPS

Большое количество полигонов
Большое количество текстур с анимацией или прозрачностью
Анимированные лайтмапы (мигающее освещение)
Большое количество спрайтов и моделей

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

Снижение сложности

Разберемся с полигонами. Движок устроен так, что даже ровные поверхности кромсает на несколько полигонов, основываясь на текстурных координатах. Максимальный полигон имеет размер 240х240 текселей вне зависимости от скейла текстуры. Из этого следует, что привязывая основную геометрию к некоторым достаточно крупным, но не превышающим 240 текселей, размерам уже будет экономить полигоны для кадра. Очень хорошо этот метод виден в Quake 2 (для Quake и Quake 2 многие пункты статьи тоже справедливы, в какой-то степени статья верна и для Source).

Т.е. мы получаем не примитивную шестигранную комнату, а нечто более интересное и в то же время имеем по полигону на поверхность. Иногда имеет смысл сделать текстуру не очень красивого размера - 240 или 480 вместо соответственно 256 и 512 - и расстянуть до нужного. Чаще всего я так делаю таблички, вывески, экраны мониторов и прочие объекты малого размеры, для которых нужна качесвтенная текстура и ее в любом случае сжимать. Некоторые пытались оспорить этот подход, но доказательств в виде скриншотов со счетчиком FPS так и не было.

Чтобы пояснить связку текселей и юнитов редактора (они же - юниты физики в игре), скажу, что при скейле текстуры 1.0 юнит равен текселелю, при скейле 2.0 на один юнит приходится только половинка текселя и поверхность без разбиения может быть уже 480 юнитов. Вообще, в статье пояснения есть.

Кроме того, полигоны кромсаются за счет так называемых Т-пересечений. Колонна или ящик посреди комнаты будут резать полигоны пола своими ребрами (это сязано с самим принципом организации бсп-деревьев). Есть несколько вариантов от этого избавиться. Самый очевидный - не допускать ненужного пересечения брашей, т.е. банально приподнять ящик или отодвинуть колонну на один юнит от пола. Этот метод прелесен сразу двумя аспектами: объект отбрасывает нормальную тень и не сжирает на себя драгоценное число из лимита сущностей (entity - англ. сущность). Конечно, ZHLT позволяет обработать тень от func-объекта, но по какой-то причине делает это гораздо дольше и менее качесвтенно.
Второй метод заключается в уже упомянутом превращении браша в func-объект. Обычно я использую этот метод на мелких деталях, вроде ламп и использую func_illusionary, чтоб попутно облегчить обработку физики в сцене. Кроме банального превращения браша в func-объект, можно еще включить мозг и сэкономить на количестве сущностей - превращать в одну сущность не каждый браш, а делать это группами, следя за пересечениями брашей. Например на следующем скриншоте изгиб трубы состоит из двух func_wall'ов

Также можно комбинировать оба способа. Например, от стены до стены идет труба, имеет смысл не доводить ее до стен на несколько юнитов, а сделать переходники-крепления (см. тот же скриншот с трубами).