Оптимизация текстур

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

Я ща ковыряю проект под WebGL и там есть 3д модели. Собственно текстур пока не много 4, и на них проще будет объяснить. Текстуры эти изначально были пожаты, как на картинке один. То есть юнити автоматом подбирало причём достаточно высокие настройки компресии. Я просто заметил, что на визуал модели это не влияет никак. Вес билда 6.44 мб.

Во втором случае я переписал настройки для текстур с альфой (albedo + roughness) на картинку 2 и без альфы (metallic и ambient occlusion) на картинку 3. Визуально различия не особо заметны, но тем не менее вес билда теперь 4.44 мб.

Два мегабайта, без изменения разрешения текстур чисто на более тонкой настройке текстур. Конечно я не рекомендую ставить именно такие настройки, так как нужно понимать к чему это ведёт. Но для веба 2мб веса — это много и важно. Поэтому последним шагом разработки и для оптимизации билда лучше пройтись по всем текстурам и всё пожать. Если на это есть время. Либо же когда "на фичу не хватает пару мб". Так как то, что выбирает юнити автоматом редко бывает оптимально)

Почему красивый код и оптимальный — это две разные вещи

Собственно сейчас всё ещё ковыряя графы, у меня появился пример. Вообще амбицию засунуть 150к вершин графа в WebGL я оставил. Ну точнее это реально, но с бекендом, правильным маппингом типа BSP и т.п. Так как браузер по памяти тупо не вывезет даже на уровне данных о графе с позициями вершин. Понятное дело что трансформы и прочее можно было бы вынести в пулл, но тут как я считал, что оптимальна система "мозг бек — фронт рисует". Так и собственно оказалось. Но думаю 10к запихаем)

А причём здесь оптимальный и красивый код? Ну можно посмотреть на картинку 1 и картинку 2. Я откатился к картинке 2, так как цели теперь не такие зверские и в целом можно пережить, но в чём между ними разница? Кроме компактности записи и каких-то странных буфферов? (хотя всё написано в комментах)

Так как приложение однопоточное (веб жеж) мы можем использовать хак заведя просто статические буфферы для некоторых операций (важно чтобы в начале операции буффер очищался, чтобы буфферы были стейтлесс) И тогда вот возникает какой нюанс. На 168к вершин (именно такой граф я по началу ковырял) — Linq каждый расчёт позиций граффа аллоцирует 8мб в кучу. А хак буфферы 40 байт (можно свести к нулю, но это надо избавится от хешсета, чтобы не было аллокации его итератора)

Это очень хитрый контракт, не самый лучший код, но когда мы идём к каким-то краевым задачам, то появляются такие вот вещи. Поэтому оптимальный код и красивый/удобный код — это две разные вещи :) Да, такой код очень опасен и неудобен, но при этом он работает на порядок быстрее реализации на LINQ. Можно конечно изменить модель данных, чтобы получать соседей без LINQ конструкций, но с графами есть такие нюансы, что в зависимости от используемой модели есть свои плюсы и минусы) Скажем если вершины знают своих соседей, а не это ответственность структуры графа. Но в моей задаче это не так важно. При решении конкретной задачи я бы подбирал модель данных под неё :)

Выступил на круглом столе и про графику в AR :)