Провел небольшой тест. Сделал шахматную доску из секторов.
В первом варианте сектора не стал джоинить.
А во втором сджоинил все одинаковые (по-сути теперь их всего двое).
Кто вдруг может не в курсе, но если на вашей локации есть сектора с одинаковыми текстурами,
уровнем высоты, свойствами и.т.п., их можно все выделить и объединить
(кнопка j, или shift-j, если вам нужно слить соседствующие сектора в один).
Так вот. Самих квадратов 8351.
Это немного тепличные условия для возможности оптимизировать,
но всё же выявил несколько особенностей:
* Размер карты.
Продублирую информацию в тексте:
test_no_join весит 10мб, а test_join 2 мб.
Логично, что с джоинами нам нужно хранить меньше информации.
Причем, когда я постепенно расширял в 2 раза эти шахматы,
размер не сджойненной был всего 3 мб, а сджойненной - 1 мб.
Т.е. увеличение оптимизированной карты O(log n).
* FPS.
Характеристики:
Скрытый текст:
Проц: AMD Ryzen 7 2700 (8 ядер по 3.20ггц)
ОЗУ: 8гб
ГПУ: AMD Radeon 7770 HD
Видеокарта по тем временам (~2013) нормальная.
Но сет в принципе еще хорош для GZDoom.
Для общего вида (а сам вид одинаковый в обоих вариантах):
test_join (39 fps):
test_no_join (25 fps):
Экономия вышла в ~14 fps в пользу join.
Спешу еще сообщить, что на участке карты оно не плавало, все ровно.
По моим предположениям движку не надо было подтягивать лишнюю информацию
к кэшам на GPU/CPU. От того такой прирост.
* Компиляция карты
Пользуюсь ZenNode, Doom Builder 2.
Процесс шел намного быстрее над test_join.
Оно опять неудивительно, записывать и связывать нужно меньше.
* Загрузка карты в редактор
Вот тут загрузка test_no_join оказалась по-шустрее.
Походу редактор где-то в своих недрах ищет и создает индивидуальные сущности для объединенных частей.
Может для того чтобы мы могли быстро разбить или собрать наши сектора.
Сформирую такой итог - если у вас большая карта или просторная локация, лучшим вариантом будет такая оптимизация.
Но важно помнить, что объединять надо строго в одном сформированном помещении.
Иначе монстры вас внезапно начнут искать с другого конца карты. Этот приём, кстати, хорошая альтернатива
служебным коридорам, которые надо подводить от места спавна или игрока к монстрам.
Вообще с джоинами в ваниле можно много других фишек сделать, но это уже немного другая история.
более-менее предметное обсуждение начинается где-то с поста Eternal 23.04.07 03:03:53 и продолжается дальше на следующей странице. Ссылка от Hitherto жива до сих пор )
По хорошему бы разобраться, как рендерит гозза все эти стены/полы, как обычные полигоны? Т.е. есть вершина, линия, фейс и тд
Если да, то не удивительно почему объединение дает прирост, в обычном 3д все так же, 1 объект какой бы он большой не был, если у него 1 материал (1 текстура) это 1 дроуколл, если его разбить на кучу мелких, дроуколлов больше, как следствие фпс ниже, если еще и материалов больше, то еще хуже.
Опять же если рендерит как обычные полигоны, то теоретически сектора различного рода так называемые нгоны, (когда больше 4 вершин у сектора) так же должны замедлять фпс т.к. рендер должен сам раз решить как разбить на трисы этот ngon..
Еще помню когда тестил большие тяжелые ландшафты под гоззу, замечал что она ведет себя лучше если вертексы секторов будут на одной высоте, как-то так, подробности жаль уже не помню.
Всегда стараюсь объединять одинаковые сектора, если конечно они не разбросаны в разных концах карты, а расположены более менее в близкой области.
Есть и плюсы, и минусы. Из минусов - если потом нарисовать сектора внутри объединенных, то придется сперва обвести один из таких секторов, чтобы отделить его от остальных. Так что лучше объединять, когда твердо знаешь, что не будешь в этом месте что-то еще править.
Насчет производительности гоззы - заметил, что односторонние стенки ее повышают заметно. Чем больше двусторонних секторов попадает в зону видимости игрока - тем ниже фпс. А когда часть карты перекрывает 1-сторонняя стена, то производительность повышается.
Примеры:
1. Вид на открытую локацию с большим числом 2-сторонних секторов, 3д полов и линией горизонта
Скрытый текст:
2. Та же локация, но игрок смотрит на здание (это двусторонняя стенка, но за ней чуть дальще - одностороняя).
Скрытый текст:
Соответственно для построения больших "природных" карт можно использовать такой трюк: делать S-образные переходы ("каньоны") между большими кусками карты, чтобы в обзор игроку попадала не вся карта, а только конкретный ее кусок, отделенный от другого этим S-образным коридором. А на обширных локациях, где это возможно, в центре ставить здания с односторонними стенками, которые будут брокировать обзор игрока на всю локацию.
Зандронум просчитывает *все* спрайты в секторе, если виден хоть краешек сектора. В прошлых бетах EDAY возникала лютая просадка fps на карте 17 после большой резни: БД срёт десятками спрайтов-ошмётков от каждого убитого монстра или каждой пальмы, раздавленной гусеницами танка (спрайты-листья, кучи их). В ранних инкарнациях *все* улицы "Порченого пригорода" представляли собой единый сектор (за исключением пешеходных зебр) и движок бросался просчитывать все те базильёны спрайтов, стоило бросить один взгляд за окно на улицу из любого дома.
Это я к чему: всё хорошо в меру и всё работает в каких-то рамках условий.
Правила 
Поиск
