Как стать автором
Обновить

Комментарии 30

Крутая реализация, спасибо за подробное объяснение.
А как обрабатывали меши?
Тоже руками сшивали и переписывали индексы и UV?
Или есть еще какие то возможности хаков?

Мы тривиально объединяли несколько мешей в один копированием содержимого и исправлением индексов и UV, да. Без каких-либо дополнительных хитростей.

"сравнив наш новый вариант атласа с наивной реализацией" - Наивной? :)

Интересная статья, спасибо!

Слово "наивный" тут используется в значении "простой".

Скорее "решение в лоб".

Спасибо что оформили в виде публичной статьи, это очень крутое решение!

Отличная статья, спасибо!

Хранение блоков pvr текстуры сразу в z curve order-е, скорее всего, только сэкономит одно преобразование image layout-а на этапе загрузки. На семплинг это не должно вляить (в теории).

Нет, потому что наши целевые платформы полноценно не поддерживали копирование. Нам нужно было универсальное решение, которое работать будет везде, а у CopyTexture довольно много ограничений. Например, банально не поддерживается PVRTC, который нам был нужен.

И я сейчас могу ошибаться, но мне помнится, что в момент изучения этой функции в качестве альтернативы, меня гугл привел к мысли, что на мобильных платформах она в принципе не работает со сжатыми форматами.

Интересное решение.

Мы решали немного другую, но схожую задачу в Pathfinder: Wrath of the Righteous. У нас атлас изначально собирается из несжатых текстур, и кроме того атласы бывают разного размера (в зависимости от настроек качества графики), поэтому по такой технологии как у вас их вроде бы трудно будет собрать.

Поэтому мы ограничились сжатием в рантайме в DXT как раз, портировав на Burst StbDxtSharp. То есть сначала атлас собирается в рендертекстуру (плюс там ещё всякая покраска хитрая, что тоже мешает из заранее сжатых текстур атлас собрать), потом мы из неё GPU Readback'ом читаем результат и сжимаем его (асинхронно), после окончания сжатия (на PC и консолях оно получается типа 25мс на 1024 текстуру) - удаляем несжатую версию.

Я всё собираюсь нашу версию DXT-сжатия выложить в открытый доступ, но руки не доходят оформить всё удобно.

Хочется отметить, что для реализации "настроек качества графики" можно просто пропускать несколько мипов и объединять не с нулевого, а с 1-2-3-etc.

А касаемо dxt компрессии - у вас все-таки ПК и консоли, а не мобилки. Ваши 25мс превращаются у нас в куда более значимые цифры на low-end'ах.

Покраска вставляет палки в колеса, да, но часто ее можно сделать в шейдере арифметикой или текстурной маской. С ней я тоже уже намучался в нескольких проектах.

А чтобы не делать медленный readback, я бы посоветовал перевести компрессию на compute, чтобы все ресурсы оставались на стороне GPU. Я где-то уже читал про DXT на GPU в рантайме (пример, пример2, но это просто беглый поиск, а не то, что я читал).

Хм, да, согласен насчёт объединения мипов, сработает пожалуй.

На GPU было бы здорово сделать, я читал что-то от NVidia (кажется) тогда на эту тему, но у нас был свободный generalist (я), а свободного граф. программиста не было, поэтому я пошёл тем путём, который понимаю без долгого въезжания в тему. Нас скорость пока устраивает (пара секунд на фоне общей загрузки большого уровня погоды не делают), но буду держать в этот вариант в уме, на случай если когда-нибудь время появится.

А можно узнать зачем вам там вообще эти оптимизации? Я играл в вашу игру и на мой взгляд она и так не должна особо тормозить. Персонажей на экране обычно не очень много, а всякие монстрики скорей всего уже и так одним мешем сделаны.

Хм. Интересно, в какую именно нашу игру Вы играли, если говорите про "монстриков" ) В Warface: GO нет никаких монстриков, там же "реализъм!". Монстрики есть в Left to Survive, но там и не используется таких оптимизаций, потому что не нужны, да. Там персонажи фиксированы в своей экипировке, моделька всегда едина.

А если все-таки речь про WarfaceL GO, то тут история такая. Не знаю, на чем именно Вы играли, но спектр устройств очень широкий. Особенно, когда речь заходит про Андроид. Нам приходится затачиваться под самые слабые и старые устройства, чтобы на них возможно было играть.

Далее, если рассуждать в ключе "обычно не много персонажей", есть шанс напороться на кучу негативных отзывов от игроков в тот момент, когда дизайнер решит сделать какую-нибудь мелкую арену, где вдруг станут видны все 8 персонажей. Или банально соберутся 8 человек по договоренности поиграть вместе и придут все в одну точку. Что в этот момент будет с игрой?

А еще есть такой нюанс, что любая лишняя нагрузка на CPU/GPU приводит к лишнему же потреблению энергии аккумулятора на мобильном устройстве и нагреву этого устройства. И лучше не выполнять какие-то расчеты per-frame, чем выполнять.

Ну и в целом, рассмотренный в статье подход - он про атласы, которые сами по себе не имеют отношения к производительности. Они имеют отношение к оперативной памяти и упихивании нужного контента в ее ограниченный объем. На старых устройствах мы еле-еле влезаем в лимиты, чтобы не быть прибитыми lmkd или jetsam.

Или это вообще про Pathfinder? )

Да, я про Pathfinder, отвечал MaxEdZX, непонятно почему ответ поставился вам.

Но вашу статью я тоже прочитал с большим интересом.

Это скорее я накосячил, а не ответ проставился ) Прошу прощения.

Но считайте, что я ответил "за себя и за того парня".

На консолях last gen (PS4/XBox One) по меркам современного PC-гейминга очень мало памяти (по статистике Стима сейчас чаще всего 16Гб стоит + 4-6Гб на GPU; на PS4 примерно 4.5Гб CPU+GPU), вот и приходится крутиться. Тем более что на PC если ты выжрал всю память - Windows сначала что-нибудь в swap скинет, и может быть даст тебе пик проскачить (ценой подтормаживания), а на консоли - сразу падение.

В столице, например, стоят все компаньоны разом, а это 12 переодеваемых персонажей, по 3 атласа на каждого (дифьюз, нормали, маски). Тут уже приходится оптимизировать хоть как-то (в идеале, конечно, переписать всё на какой-то стримминг, но поскольку первая игра изначально делалась под PC, да и в целом Unity и стримминг совместимы с большим трудом, то трудозатраты на это пока что неподъёмны).

Я думал что вся идея с атласами нужна для уменьшения числа батчей, а не оптимизации памяти? По идее, атласы то должны как раз занимать в целом больше памяти, за счет пустого пространства, разве нет?

Атласы - для скорости, сжатые атласы - для памяти (и все ещё скорости).

Эх, а когда-то это было очевидным инженерным решением. А теперь с разработчиками с «ассетным» мышлением зачастую сложно обсуждать трюки, выходящие за рамки стандартных возможностей Unity или UE.

Эх, а когда-то это было очевидным инженерным решением.

Скучайте по временам когда ваши "уникальные" навыки были кому-то нужны, а теперь вам приходиться ныть на форуме, что ваши навыки потеряли актуальность?

А теперь с разработчиками с «ассетным» мышлением зачастую сложно обсуждать трюки, выходящие за рамки стандартных возможностей Unity или UE.

Вы их не обсуждайте. Статья и так рассказывает как реализовать это "очевидное инженерное решение", а вы просто припёрлись в тред с криками "удаляйте статью, таким умным и уникальным разработчикам как я, такие статьи не нужны".

Как насчет того, что бы пройти мимо и не высказывать своё никому не нужное мнение о том, что все вокруг тупее вас?

вы просто припёрлись в тред с криками «удаляйте статью, таким умным и уникальным разработчикам как я, такие статьи не нужны».
Ого, что ещё за меня додумаете?

Скучайте по временам когда ваши «уникальные» навыки были кому-то нужны, а теперь вам приходиться ныть на форуме, что ваши навыки потеряли актуальность?
Нет, просто сетую на то, что из решения интересных задач это становится обыкновенной рутиной, где даже такие вещи как в статье выделяются на фоне.

Вы их не обсуждайте.
Что ещё мне нельзя делать?

В юнити, вроде, виртуальные текстуры завезли. Или это не оно? Или там ограничения какие?

Виртуальные текстуры немного для другого, но, в целом, можно было бы, наверное, и на них сделать, да. Мне, правда, кажется, что тут совсем другой инструмент и для других целей. Как стрельба из пушки по воробьям.

Текстурные массивы разве не поддерживает gles 3.1? Они куда лучше.

Интересно, почему речь про gles 3.1? Я писал в статье про iphone 6 и даже 5s на старте, а там нет поддержки текстурных массивов. На Андроиде наверняка много устройств современных поддерживает 3.1, но мы целимся на 3.0. Более того, до прошлого года у нас еще и gles2 был в ходу.

Помимо этого у текстурных массивов есть как плюсы, так и минусы. Кесарю кесарево. Почему вдруг "они куда лучше" так вот безапелляционно? Они, к примеру, требуют одинаковых размеров исходных текстур. Если Вы посмотрите на атласы из статьи, то заметите, что там текстуры разного размера (перчатки, ботинки, даже одна голова есть). Приводить все к одному размеру - это будет сильно разная плотность пикселей на разных участках персонажа, будет слишком бросаться в глаза.

Если что, я даже сослался прям в тексте на статью Пиксоников про текстурные массивы - там можно почитать и про ограничения в том числе.

Left to Survive

Warface: GO

Вижу, фантазией в именовании продуктов ваша компания не настолько отличается, как в профессионализме программистов)

Спасибо за статью, добавил в закладки, надо разобрать с живым проектом.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий