Оптимизация карты для Half-life. - Форум
Оптимизация карты для Half-life. - Форум
[ Новые сообщения · Участники · Правила форума · Поиск · RSS ]
Страница 1 из 11
Модератор форума: Scrama 
Форум » Левел-дизайн » WorldCraft и Valve Hammer Editor » Оптимизация карты для Half-life. (С учетом использования компиляторов ZHLT)
Оптимизация карты для Half-life.
ScramaДата: Вторник, 27.01.2009, 08:52 | Сообщение # 1
Группа: Администраторы
Сообщений: 242
Статус: Offline
Повторять написанное здесь глупо, так что только напомню и дополню.
Консольные переменные, которые понадобятся:
developer 1 - режим разработчика, нужен для работы последующих функций. В идеале просто пускать игру с параметром -dev
r_speeds 1 - статистика по полигонам
gl_wireframe 1 и 2 - отображение границ полигонов. 1 только те, что видны непосредсвтенно игроку, 2 все те, что обсчитываются движком.

Причины падения 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'ов

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

 
ScramaДата: Вторник, 27.01.2009, 10:21 | Сообщение # 2
Группа: Администраторы
Сообщений: 242
Статус: Offline
При превращении брашей в сущности образуется множество поверхностей, которые игрок никогда не увидит в нормальных условиях. Эти поверхности (чаще всего между обычным брашем и сущностью) нужно закрасить текстурой NULL. Не ленитесь это делать - на сложных картах прирост производительности весьма существеннен. Вообще, я собираю декорации отдельно от самих помещений - либо в стороне, либо в другом файле. Подходите к декорациям, как к самостоятельным продуктам, прогоняйте их через стадию префаба и это окупится, особенно в сингловых модах, где единый стиль тянется на несколько карт и используются однотипные элементы.

На количество анимированных текстур и лайтмап мы почти никак не можем повлиять, разве что отказаться от части задумок. Главное тут следить, чтоб анимация не появлялась в ненужных нам местах. Нет смысла ставить в комнате несколько источников с разным мерцанием, ведь движок поддерживает только три стиля на полигон, а значит полезут артефакты. Оптимальным является вариант с одним анимированным стилем и одним нормальным - это сгладит неприятный эффект мерцания и в то же время позволит оживить картинку.

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

Спрайты... Да, их тоже никуда не денешь, но и вклад у них не такой большой.

Теперь идем к макроархитектуре. Вообще-то, неплохо написано вот тут, так что коротенько о сути. Нам нужно перекрывать видимость игроку из одной локации в другую. Делать это можно с помощью коридора зигзагом, длинной лестницы или лифта. Т.е. необходимо тщательно продумывать переходы из одной комнаты в другую, а не просто разделять их дверью, иначе может получиться просто шашлык из комнат, одновременно обрабатываемых движком. Посмотрите, сколько поворотов, подъемников, лестниц и прочих вывертов в игровых картах, сделанных профессионалами - это не просто попытка улучшить геймплей, но и реальный метод повышения производительности. Но даже такие решения не всегда справляются, поэтому приходится использовать текстуры HINT и SKIP. Применение HINT-текстуры обычно имеет случайный характер и результат предсказать не всегда возможно - только экспериментальный метод даст результат, так что пробуйте.

На деле же, правильно спланированная карта и аккуратное исполнение приводит к минимизации последующих затрат на оптимизацию. Продумывайте видимость помещений на этапе набросков, аккуратно собирайте префабы, своевременно окрашивая невидимые поверхности NULL'ом и перегоняя части декорации в сущности, и производительность будет зависеть уже только от красоты.

 
kogemyakaДата: Среда, 28.01.2009, 01:30 | Сообщение # 3
Группа: Проверенные
Сообщений: 60
Статус: Offline
А у меня вопрос по оптимизации.)
1) Допустим у меня есть 3 браша, подогнаные в притык, которые я все вместе превращаю в func_wall.
2) То же самые 3 браша, но я превращаю их в func_wall по отдельности.
Есть ли разница между (1) и (2) или польза от (1)? И будет ли польза от (1), если браши не соприкасаются друг с другом?

А чем NOOL от NODRAW отличается?

Quote
сущностей (entity - англ. сущность).
. Больше подходит по-моему подстановка, а не сущьность).


З.Ы. Чем стремнее карта, тем популярнее она станет=). © ZXC
 
ScramaДата: Среда, 28.01.2009, 09:11 | Сообщение # 4
Группа: Администраторы
Сообщений: 242
Статус: Offline
С брашами скрин покажи.
NULL - это текстурка, обрабатываемая компиляторами ZHLT для HL1
NODRAW - это текстурка из Quake 2, Quake 3, Doom 3 и т.д. Возможно, так же называется в Source.

Quote (kogemyaka)
Больше подходит по-моему подстановка, а не сущьность

Словарь говорит так. Да и термин придуман Джоном Кармаком в те годы, когда это 100% были сущности.
 
bot711Дата: Среда, 28.01.2009, 17:57 | Сообщение # 5
Группа: Проверенные
Сообщений: 19
Статус: Offline
Ссылка на статью про макроархитектуру кривит.
Влияют ли визгруппы как-то на оптимизацию карты?
Цитату взял с статьи на сs-mapper.by.ru
Quote
Итак, создавая открытое пространство, не выходите за рамки разумного. Все пути и подходы к такому «нагруженному» месту должны быть или чем-то отгорожены (как на de_cbble огромными толстыми воротами, рис.1), или просто они должны быть изогнутыми (рис.2).

Возможно ли, что приминение этотого способа никоем образом не влияет на wpoly? То есть игре абсолютно всеравно есть ли на карте какие-нибудь подобные препятствия. С чем это может быть связано?


 
kogemyakaДата: Четверг, 29.01.2009, 01:37 | Сообщение # 6
Группа: Проверенные
Сообщений: 60
Статус: Offline
Scrama,

Прикрепления: 5161744.jpg(14Kb)


З.Ы. Чем стремнее карта, тем популярнее она станет=). © ZXC
 
ScramaДата: Четверг, 29.01.2009, 07:54 | Сообщение # 7
Группа: Администраторы
Сообщений: 242
Статус: Offline
Ну, вот рассуждаем так:
Если это именно лесенка и видна с боку. Более нижние ступеньки будут резать боковую сторону при компиляции, следовательно если перегонять их через одну (2 func_wall'а получится), то этого не произойдет, на данной лестнице из трех брашей 4 полигона выигрыша.
Если лесенка с боков не видна (они покрашены NULL'ом и скрыты стенками), а видны только верх и передняя стенка ступеньки, то разницы нет.
А если это не лестница, а браши вообще не соприкасаются, то их очевидно нужно гнать в один func_wall, чтоб сущности не занимали.
 
DIMaN[BBc]Дата: Четверг, 29.01.2009, 22:53 | Сообщение # 8
Группа: Проверенные
Сообщений: 8
Статус: Offline
Quote (Scrama)
следовательно если перегонять их через одну (2 func_wall'а получится)

А смысл? Ведь брашевые энтити не режут на полигоны другие брашевые энтити (свои или чужие) или просто браши. Поэтому можно спокойно превращать всю лестницу в энтитю.

kogemyaka, от того как ты перегонишь браши в функвелы разницы нет (вместе или каждый по отдельности). Другое дело, что есть определенный лимит по количеству энтитей, которого достигнуть очень сложно, если ты не маньяк конечно smile
Но с практической точки зрения, конечно лучше весь объект превратить в энтитю, а не каждый его элемент в отдельности. Но разницы нет и на производительность это влиять не будет.


Сайт русского мода Half-Life: Confession
 
ScramaДата: Пятница, 30.01.2009, 08:59 | Сообщение # 9
Группа: Администраторы
Сообщений: 242
Статус: Offline
DIMaN[BBc], не-не-не

Два браша, один помельче проходит сквозь другой, вместе образуют один func_wall. Меньший браш бьет полигоны большего. Я ж не просто так говорю. Это в Q3 и UE non-structural браши друг друга не трогают.
Прикрепления: 4023381.jpg(16Kb)
 
ScramaДата: Пятница, 30.01.2009, 09:07 | Сообщение # 10
Группа: Администраторы
Сообщений: 242
Статус: Offline
Quote (bot711)
Возможно ли, что приминение этотого способа никоем образом не влияет на wpoly? То есть игре абсолютно всеравно есть ли на карте какие-нибудь подобные препятствия. С чем это может быть связано?

Что-то я твой пост пропустил сначала...
Вот эти самые ворота, как на cbble и дастах очень не всегда правильно просчитываются, а полигоны на полу и потолке режут довольно некрасиво. Ну и движок не совершенен, может ошибаться с видимостью листьев, так что я за капитально изогнутые проходы вместо вот таких ворот.
Кстати, ссылки на статью про макроархитектуру там нет, а кривая должна вести на полигоновскую статью про HINT и SKIP - там еще хорошо рассмотрены принципы видимости частей карты. А статья про макроархитектуру тут.
 
DIMaN[BBc]Дата: Воскресенье, 01.02.2009, 12:26 | Сообщение # 11
Группа: Проверенные
Сообщений: 8
Статус: Offline
Scrama, да, ты прав biggrin
В принципе количество epoly можно и не считать. От - 5-10 полигонов ничего не измениться. Тем более что брашевые энтити не основной их источник, куда больше их от моделей. Да и современные компьютеры с легкостью такое обрабатывают.
В своем моде край был следующий: 1000 wpoly, 30000 epoly в кадре. Наблюдал некоторые лаги. Комп прошлого поколения: Cel 2100, 2Gb DDR1, Ge-Force 7600 256 Mb. Таких цифр добился только два раза, и оба на открытых пространствах. Поэтому считать полигоны особо не приходится smile
Но все же стараюсь не превышать 800 wpoly, 15000 epoly. Считаю что для gldsrc это средний предел. Чтобы никто потом не ругался happy

P.S. Не могу изменить свои личные данные (в частности поставить аватар и подпись) question После сохранения пишет: You are trying to do illegal action!


Сайт русского мода Half-Life: Confession

Сообщение отредактировал DIMaN[BBc] - Воскресенье, 01.02.2009, 12:30
 
ScramaДата: Понедельник, 02.02.2009, 12:10 | Сообщение # 12
Группа: Администраторы
Сообщений: 242
Статус: Offline
DIMaN[BBc], это не epoly, полигоны брашевых объектов всегда считаются в wpoly - можешь тоже проверить. epoly - исключительно модельная штука и считаются отдельно потому, что принцип их рисования немного другой. Метод отрисовки полигона у func_wall и полигона обычного браша один, потому и на скорость они влияют одинаково, если только func_wall не полупрозрачный - тогда сцена усложняется за счет кривоватой отрисовки полупрозрачности в half-life.
Лично для себя не делаю сейчас никаких ограничений по полигонам, но за 2000 редко ухожу. Если эти 2000 идут в основном от обычных полигонов, то все работает нормально. Можешь, кстати, исследовать с r_speeds мой DM-Knot - там лаги возникают не в тех местах, где больше полигонов, а там, где "смотришь" сквозь несколько спрайтов и маскотекстур, а в область видимости попадают шестеренки и мигающий свет. До этой карты я тоже не особенно задумывался и считал, что производительность зависит только от количества полигонов в кадре.

P.S.: сейчас права пользователей проверю.
UPD Проверил, все в порядке, может, глюк какой - попробуй перелогиниться (выйти/зайти) и поменять данные. Я сейчас создал пользователя, залогинился под ним и правил свои данные - все нормально работало.

 
DIMaN[BBc]Дата: Вторник, 03.02.2009, 22:27 | Сообщение # 13
Группа: Проверенные
Сообщений: 8
Статус: Offline
Scrama, ты опять прав. Очень печально, что я думал по другому. sad
Значит в свое время не внимательно читал учебники. Спасибо, что открыл глаза. Посвящу пару дней cs-mapper'у smile


Сайт русского мода Half-Life: Confession
 
ScramaДата: Среда, 04.02.2009, 07:50 | Сообщение # 14
Группа: Администраторы
Сообщений: 242
Статус: Offline
DIMaN[BBc], зато теперь все будет гораздо лучше чем раньше. Прогресс - всегда хорошо wink
 
Форум » Левел-дизайн » WorldCraft и Valve Hammer Editor » Оптимизация карты для Half-life. (С учетом использования компиляторов ZHLT)
Страница 1 из 11
Поиск: