Оптимизация скайбокса
Каждый картодел создаёт неправильные скайбоксы просто делая полую коробку вокруг карты, или делая отдельные браши, ставя их вместе в форме коробки.
В другом случае этот "Коробочный метод" в корне не тот метод, который вы должны использовать в качестве создания скайбокса, так как карты, которые могут иметь такой тип скайбокса, малы до такой степени, чтобы вы могли видеть её всю. Не беря в счёт эти карты, скайбоксы должны быть сделаны правильно.
Теперь, чтобы показать вам, почему "Коробочный метод" плохой, я покажу вам карту справа и я буду использовать два способа создания скайбокса на ней. Это простенькая карта: несколько путей с тремя большими комнатами и стенами, отделяющие их.
Note:Это простые примеры, которые могут/должны быть улучшены.Это не такая уж и красивая карта, но она служит быть примером. Также заметьте, что непосредственно пол самой карты состоит из некоторого количества смещений, а не из одного целого. Это довольно таки распространено, далее мы увидим, как это затронет наш скайбокс.
"Коробочный метод" выглядит именно так, как на картинке ниже.
Сам пол карты исчезает неспроста, он заостряет внимание на том, что пол не именно там в простом понимании. Смещения не блокируют видимость, и VVIS не просчитает visleafs, который останавливает поверхности от смещения, visleafs проигнорирует их. Если вы бы сделали стену, состоящую только из смещений, то ваш компьютер прорисовывал бы постоянно все модели, игроков и геометрию позади их. Только геометрия карты - в этом случае стены - будут блокировать видимость и создавать visleafs, контролирующий предметы от их прорисовки.
Теперь давайте взглянем на более лучший метод создания скайбокса, взгляните на картинку ниже:
Скайбокс теперь огибает весь уровень, и nodraw текстуры будут использованы под всеми стенами и полом, вместо текстуры скайбокса. Это уменьшает количества расчётов (КОЛОССАЛЬНО уменьшая время компиляции), потому что скайбокс не содержит в себе пустое пространство для генерации. Nodraw текстуры будут использованы, потому что нам не надо освещать поверхности за картой, и мы не хотим увидеть ошибки в прорисовке, которые появятся при освещении смещений снизу.
Все эти методы колоссально влияют на компиляцию:
Portal Clusters: 73 »» 16
Numportals: 201 »» 19
Total Clusters Visible: 3981 »» 134
Average Clusters Visible: 54 »» 8
Average Clusters Audible: 73 »» 13
VisDataSize: 2048 »» 196
Для такой маленькой карты эти изменения довольно существенны, и также существенно добавляют производительности к карте.
Когда не надо делать секции
Делать скайбокс, который будет поверх всех стен карты, не очень правильная идея. Есть несколько случаев, в которых вы должны оставлять некоторые стены без скайбоксов, чтобы видеть другие секции вашей картыю, например.
Я поставил высокие браши в середине карты, картинка справа это показывает. Однако, если скайбокс будет там присутствовать, то башня будет то появляться, то исчезать время от времени из-за работы скайбокса. Обрезка скайбокса в требующих местах неоходима, чтобы другие части карты были видны от всех углов камеры игрока.
Убирая и обрезая стены скайбокса мы можем увидеть эту башню от всех углов карты и используя nodraw текстуры внизу карты мы не позволим свету выглядывать. Результат выглядит таковым:
Также вы можете попробовать ограничить зону прорисовки башни. Просто вытяните несколько стен, так чтобы вблизи этих стен вы не заметили бы башню:
Правильно сделанный скайбокс с продвинутым картостроением добавляет очень большой прирост производительности детализированной карте. Это не очень умная идея создавать коробчатые скайбоксы, когда вы начинаете делать уровень. Лучше используйте инструмент Cordon, пока вы не достигнете стадии разработки карты, в которой вы не будете работать над финальной версией скайбокса.
Прочие плюсы
Прочие причины делать правильный скайбокс:
- Простота в создании areaportal'ов
- Простота в организации тригерров soundscape
- Прорисовка большего количества детализированных пропов на смещениях
