Оптимизация r_speeds
| Оптимизация r_speeds Основы Чем меньше нужно грузить полигонов движку, тем быстрее он будет работать. Для начала вспомним разновидности полигонов:
epoly (Entity Polygons) - это полигоны сущностей; Полигонов сущностей может быть достаточно много и при этом они могут почти не нагружать клиент, в отличии от полигонов обычных брашей. Каждый браш обладает 6 сторонами => 1 браш = 6 wpoly, так же и 1 entity браш = 6 epoly. Если игрок какие либо полигоны не видит, то они в расчет не берутся. Например, возьмем стену. С 1 позиции игрок может видить только 1 сторону стены, а значит в это время вторая сторона не просчитывается. Так же, если игрок какой то полигон не увидит никогда, то имеет смысл покрасить в текстуру с названием NULL. При покраске в NULL, память отведенная под текстуры будет меньше заниматься, т.к. NULL говорит компилятору, что этой стороне вообще никакой просчет не нужен. Эта экономия памяти опять же увеличивает скорость обработки карты на стороне клиента. Ещё стоит вспомнить, что при постановке рядом двух неравных по размеру брашей, старший браш порежется на 2 полигона. Первый полигон будет по уровню младшего браша, во втором полигоне будет заключаться все остальное пространоство. Если минимизировать подобные взаимодействия и постараться делать соседние границы одинаковыми, то при компиляции нарезка полгонов будет значительно меньше. Метод оптимизации r_speeds Стыкуем браши таким образом, что бы несостыковок по размеру не было. Например вот так:  
Оранжевые линии указывают на те места где подобную состыковку провести нельзя, т.к. уже произведена состыковка перпендикулярных стен подобным образом; Зеленые линии указывают на то, в этих местах никакого разбиения полигонов не будет, т.к. образуются одинаковые поверхности; Таким образом у нас на первом скрине получается 11 полигонов на этой стене + n полигонов, которые появятся при разбиение брашей через k текселей при компиляции, где k это значение параметра subdivide в компиляторе (по стандарту 240 текселей). Посмотрим на декомпилированную карту:   Примерное разбиение на полигоны, которое будет производиться при компиляции показано розовыми линиями. Таким образом, в первом случае, получается ~28 полигонов + n полигонов разбитых по текселям. Разница довольно ощутимая. Подводя итоги Сравним реальное количество полигонов на компилированных картах:     Самые большие показатели полигонов на картах:   Физический размер 2ух карт:  P.S. При востановлениее оригинала на 100% физический размер может увеличиться или уменьшится, но не на много. Из этого следует, что я не баснословен и результат действительно от всего этого есть, хоть карта в редакторе и выглядит не особо эстетично. Достоинства и недостатки метода: + Увеличивается производительность на слабых пк; + Уменьшается расход трафика, как клиентского так и серверного; + Из перечисленных плюсов следует, что пинг на оптимизированной карте будет меньше, особенно у слабых клиентов; + Поиск решений оптимизации бывает действительно интересным; - Поиск действительно хорошего варианта оптимизации может затянуться; - Редактирование оптимизированных мест осложняется; Постарался объяснить все доступно. Надеюсь кому то этот способ понадобится 
| |
|
| |
| Просмотров: 925 | |
| Всего комментариев: 0 | |
Категории раздела
| Разное [6] |
|
Маппинг
[4]
Здесь вы найдете статьи,связанные с созданием карт.
|
|
Фишки,наблюдения,опыт игроков,советы
[4]
Всё по поводу геймплея
|
