Pull to refresh

Comments 19

Надо вам программистам из KSP 2 помочь. Там на релизе после четырех лет после разработки на Unity, с FPS прямо беда. Провал года.

Артем, ваша анонимность под угрозой ) Или это просто ник, а ваше истинное имя так и остается тайной?

Там, вроде, и имя и фамилия написаны, так что об анонимности вообще речь не идет :)

Хранить геометрию в текстурах тот еще извращение, неужели нет какого ни будь стандартного kd-tree/BSP сразу для gpu, и с геометрией, и оптимальным форматом данных, и интегрированный в движки? Казалось бы для игр с открытым миром самое то, сразу весь мир хранишь, вон Скайрим давно вышла, должен был уже промышленный стандарт сформироваться.

Я вам не скажу за все движки, но мне кажется что еще никто не сделал движок для открытых миров. Везде надо разбираться в механизмах работы движка и писать много когда что-бы получить быстро подгружающийся открытый мир. Если бы это было не так, то гемдизайнерам не приходилось бы в 2023 году вставлять кучу бутылочных горлышек для подгрузки следующего уровня.

у меня встал выбор: либо хранить png и тратить около 30 ms на его декомпрессию, либо хранить «чистые» данные и создавать текстуру за 3 ms.

Эээ? Можно хранить DDS в каком-нибудь сжатом формате (конкретный формат зависит от цели использования: DXT1, DXT5, BC5, сотни их), и прям в сыром виде хреначить его в видюху.

Они все с потерями, а тут была важна максимальная точность.

Все верно. Внутри одного канала 1й бит может определять типа поверхности, а следующие 7 бит высоту здания. Поэтому используются только текстуры без потери качества.

Еще можно было попробовать переработать контент под несколько унифицированных типов геометрии (бокс, цилиндр и т.п) и собирать все постройки из них (это еще и размер данных уменьшит). Потом это все можно через инстансинг гнать, даже без GameObject - через Graphics.DrawMesh() и сотоварищей.

Была такая мысль, но от нее быстро отказались. Несмотря на то что 76% домов 4 сторонние, они все равно не идентичны (грубо говоря у них даже не всегда прмямые углы). Но даже если матрицей трансформации подгонять дома не до 100% соответсвтия, а до приемлемого уровня, то в зависимости от этажности паребрик у всех домов будет разной высоты и фассады не будут соответствовать своему дому - у всех будет 1 текстура. И опять же помимо 76% домов есть еще куча другой геометрии. GPU instancing мы все таки используем, но об этом надо писать отдельную статью.

Что можно сделать ещё, чего я не увидел в статье.

  1. Сменить пайплайн с built-in на URP. SRP-batcher даёт очень сильный буст при использовании разных мешей с одинаковым шейдером.

  2. Отказаться от GameObject и использовать CommandBuffer для отрисовки объектов.

  3. Отказаться от хранения данных в текстуре. Эпоха dx9 давно ушла. Используете structured buffer.

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

  5. Файлы с данными можно запаковать с помощью Deflate или GZip.

Ушла да не ушла. Если есть требование работы не только под винду, но и под другие платформы - начинаются проблемки: для macos/ios нужен metal (вроде как и не проблема уже, но все зависит от требований заказчика по поддержке старых девайсов), для linux/android нужен vulkan.

Структурные буферы поддерживаются на всех платформах и для всех графических апи. Для доступа к ним из вершинного шейдера нужна Shader Mode 5.0 и выше. Единственное исключение это мобильники из низкого ценового сегмента, работающие на OpenGL ES 2.0.

1) Эта работа была проделана 2015 году, тогда еще не было никаких URP. Сейчас у самого руки чешутся написать свой SRP, но пока нет для этого времени (хотя задачи под него уже висят).

2) Уже отказываемся от GameObject как можем )

4) В данный момент текстура утилизируется на 100% - т.е. там нет ни одного бита который бы простаивал и данных которые туда не влезли. Сейчас есть задачи по изменению/расширению формата хранения под новые требования. Когда подойду к ее выполнения проверю Ваш вариант - возможно он действительно будет более оптимальным.

5) Уже сделано - сжимается еще лучше чем в png )

  1. Сцена с парой миллионов трегольников так и просит чтобы по ней прошлись RayMarching вместо Raytracing. Ну или использовать ещё какой вариант отсечения геометрии. Использовать BSP как вариант.

  2. Мобильный геймдев довольно долгое время использует всякие сжатые форматы текстур типа PVR(TC) или S3TC. Возможно это поможет сократить время обработки.

Очень воодушевляющая статья, спасибо! Будите и во мне оптимизационные фетиши!

Сначала засовываем все вычисления в видеокарту, а потом на Xbox Series S достичь 60fps не представляется возможным...

Собственно, если требуется быстрая подгрузка с разными уровнями детализации, себя прекрасно показывают различные отсекающие пространство деревья. Сохраняем кастомный бинарный блоб с хэдером и по нему шагаем. За логарифм пришагаем. В зависимости от размера фруструма, лезем в более глубокие слои с более высокой детализацией. В нодах можно хранить не только геометрию, но и сами текстуры (а ещё лучше — индексы для обращения к атласу, который уже подгружен в памяти).

Ещё можно сам рендеринг пересмотреть и описать формы зданий через signed distance field. Тогда всё совсем хорошо на текстуры перенесётся и видеокартой прожуётся. Особенно если использовать несколько каналов.

Sign up to leave a comment.

Articles