|
Оптимизация пространства в Source Гостям скачивать запрещено Просмотров: 2024 Комментариев: 0 Рейтинг: 0.0 Добавил: Гость Дата добавления: 16.04.2024 Читать больше про CS: Source Маппинг Оптимизация пространства в Source.  1. Правильный скайбокс Смысл
в том, чтоб максимально уменьшить пространство. В сорсе это почти
основное, ведь карты сорса это binary SPACE partition (резка
пространства). КОНТРОЛЬ ВИДИМОСТИ, пожалуй это главное в оптимизации. 1. Карта в разрезе. Оптимально оптимизирована. Черный- геометрия карты, синий- скай (toolskybox). 2. Нубский неправильный скайбокс. Много лишнего пространства, которое будет просчитываться и тратится время и т. д. 3. НЕ В КОЕМ СЛУЧАЕ! Тонны неиспользуемого пространства.. и под уровнем. 4. Не забываем о 3D скайбоксах. Все лишние здания, которые игрок не может обойти, прячем в них. Но не забывайте, аккуратнее располагайте эти куски ская возле высоких помещений, ибо через это скаевский браш не видно ничего кроме неба. Ваше здание может исчезнуть). 2. Фиксим лики В принципе все мы умеем это делать. Когда после компила мы видим пол карты, или вода не имеет отражений то на карте лик (Leak). Жмем Map -> Load pointfile, и идем по появившейся красной линии. Вот где-то возле линии и есть лик. Вот ещё толковый короткий тутор по фиксу. 3. Не делайте накладывания брашей - оверлеп (overlap). Это
прекрасно известно всем мапперам КС 1.6 и ХЛ1. Если один браш входит в
другой, то он разрезается компилятором (детэйлы не режутся. Об этом
дальше) и на это тратится время. Так что это главная причина делать
геометрию на 4 и 8-й размере сетки. 4. Не делайте накладывание/пересекание дисплейсментов. Дисплейсменты
подобно детэйлам не режутся компилом и рендерятся как вы их создали. И
не делайте слишком большие дисплейсменты. Примерно средние диспы бывают
размером 5х10 метров. Так у Valve. 5. Не перебарщивайте с динамическим светом (dynamic lights). ...ибо все просчеты проводит двиг, так что это плохо скажется на производительности. 6. Делайте браши стандартных размеров. Кпримеру
размеры стороны 8,16,32,64,96,128,256,512. К примеру не делайте 15х15,
сделайте 16х16 и т. д. Будет быстрее компилить т. к. процу так легче
просчитать. ЛИЧНО мною проверено. 7. Правильная резка брашей.  Слева неправильно (я такое солнышко видел на карте Кенни). Будут лики, микролики и т. д. Справа сначала вырезана квадратная дырка для круглой дырки. А потом в полученоим квадрате делаем такую дыру. Потом vertex manipulation тулом (манипуляция вертексами) приравниваем к такой форме. 8. Не перебарщивайте с водой Делайте "дешевую" (cheap) воду (серая). Она немного хуже, но она рендерится проще и будет меньше лагов. Уменьшайте размеры брашей воды и не давайте пересекаться с геометрией. Вода будет прорендерена но не будет видна. Такое бывает. Только некоторым энтитям разрешено касаться воды. Модель, касающаяся воды, будет прорендерена дважды! Один раз нормально, другой раз с спец. водяными эффектами. mat_showwatertextures 1 показывает модели, которые рендерятся с эффектами. Ещё ставим энтитю water_lod_control чтоб включить управление качеством воды на расстоянии к игроку. ВНИМАНИЕ! Воду НЕ ЖЕЛАТЕЛЬНО превращать в func_water_control ибо появляются много багов, ищезают эффекты воды вплоть до полной её невидимости. Часто такое бывает. Воду ставим простой World геометрией. 9. Избегайте открытых пространств. Почти всегда можно поставить здание, тем самым уменьшить вид открытого пространства. Причем так проще будет оптимизировать. 10. Средства оптимизации в Hammer. Nodraw Всем известно про эту текстуру. Она делает чтоб фейсы покрыты этой текстурой не рендерились в игре. Через эту текстуру вы не увидите неба как в toolskybox, но увидите то, что находится за этим брашем. Закрашиваем все невидимые игроком фейсы. Func_detail Возможно это самое сложное что есть в оптимизации. Возможно... Это те самые детэйлы о которых все говорят. Есть 2 вида основной геометрии: World Geometry - простая основная геометрия не конвертированная в браш энтити. Режется компилятором. Func_detail - браш энтитя (конвертируется ctrl+t). Не режется компилятором, уменьшает количество разрезанных фейсов компилятором (на которое тратится так много времени). Браш энтити (детэйлы, func_wall и т. д.) НЕ РЕЖУТСЯ компилятором. Резка совершается компилятором VVIS (от Visibility видимость). Возьмем комнату:  4 колонны и один столб. Эта комната будет разрезана на сотни вис (VIS) листов.  Наша задача уменьшить их количество. Переводим КАЖДЫЙ объект (4 колонны и столб) в Func_detail. Получится один вис лист на весь объем комнаты. Мы ускорили скорость VVIS компила в 100 раз!) (Чтоб посмотреть на листы в игре - команда mat_leafvis 1.  Если есть какой-нибудь объект (стенд какой-нить из 5-ти брашей примерно или стол) то лучше превратить КАЖДУЮ деталь этого стола в функ детэйл чем весь стенд или стол. Ибо компил будет резать сам объект по фейсам всех его деталей. mat_wireframe 1 показывает что рендерится, а что нет. Аналогично ступеньки:  без оптимизации:  Ужснах! Сотни лишних вислистов. Оптимизируем:  К тому же, ВОТ как правильно делать геометрию ступенек:  Браш должен быть ДЕТЭЙЛОМ если:
Имеем комнату:  и три вислиста. создаем браш с текстурой tools\toolsskip (скип некак не рендерится), ОДИН файс её (который будет резать листы) покрываем текстурой tools\toolshint.  Создаем один браш в этом месте:  Теперь с листа 1 нам не будет видно листа 3. И наоборот. При таком раскладе лист 3 и все объекты в нем НЕ БУДУТ рендерится ВООБЩЕ. Ещё примеры:  Зеленая точка - игрок. Красная линия - фейс браша с текстурой tools\toolshint. Func_aeroportal Имеем две отрезанные комнаты соединенные дверьми. Пишем в консоле mat_wireframe 1 и видим НЕОБРЕЗАННУЮ геометрию за стенами.  ставим в дверях функ_аеропортал:  C помощью системы О\I (аутпутов) и триггеров (или аутпутов от двери) мы открываем и закрываем этот портал. Имеем комнату:Закрытый портал обрезает ВСЁ что в той комнате. Что нам и нужно:   Слева будет лик, т. к. нужно закрыть пространство. Справа 2 портала. Всё правильно. Хинты  Синий прямоугольник- игрок находится в нем, и с него видны другие листы в комнатах:  Ставим хинт:  в дверном проеме (синий)  Комната остается обрезаной от остальных и не будет рендерится если игрок не стоит в синем прямоугольнике(см. выше):  Скрываем видимость хинтом из-за угла. Имеем угол:  Там два листа:  Разрежем на три:  Наша задача отрезать от рендеринга 1 и 2-й лист. 3-й лист виден везде и всегда. Ставим треугольную трапецию (браш):   Так же юзаем хинт и скип. Правильное расположение:  Только справа правильно! Окклудеры (Occluders) Они помогают отключать объекты (к примеру физ. бочки) от рендеринга. Окклудер установленый в дверях:  Синие бочки не рендерятся. Юзаем консольные команды r_occlusion 1 и r_occlusion 0 чтоб видеть что рендерится , а что нет:  Лайтмапы ОЧЕНЬ сильно влияют на скорость компиляции. По дефолту лайтмап скейл = 16.  2. Выбираем фейс и смотрим какой скейл. Чем меньше скейл- тем точнее просчитается тень на этот браш от всех объектов и тем дольше будет идти компиляция. Порталфайлы После ПОЛНОЙ компиляции карты загружаем из меню порталфайл, жмем ок. И сразу видно где нужно расставлять хинты и проч. системы оптимизации.  В статье возможны некоторые неточности. Stridemann |
| Всего комментариев: 0 | |
Добавлять комментарии могут только зарегистрированные пользователи.