Не знаю, насколько будет уместным сравнение. Но выскажу точку зрения. Есть куча музыкальных инструментов, но фортепиано — классика. Кроме того, оно наиболее универсально во всех музыкальных смыслах (ну кроме портативности:). Ударные непревзойдённо решают свою узкую задачу, духовые — свою, струнные незаменимы в своей области. Но фортепиано, рояль были и остаются классикой.
Аналогичное место, как мне кажется, на данный момент занимает С в мире разработки.
Если разархивировать АПК, то найти там текстуры в приемлемом для чтения формате мне не удалось. Судя по всему, Unity хранит их в формате, далёком от привычных для человека. Быть может, в моих словах кроется ошибка...?
Кстати, по поводу ETC1 вот что говорит Unity:
Наша графика не так проста. Тот кусочек — лишь кусочек большого изображения. 40% картинок по типу dl.dropboxusercontent.com/u/3232059/jungle_bg_1920x1200.png (здесь все кроме RGB24 несказанно портит качество), а остальное — с прозрачностью и тоже с хорошим градиентом. То есть, о других форматах кроме RGBA32, RGB24 и местами RGBA16 речи пока не идёт.
Но в общем Ваш совет я понял!
Какими атласами Вы пользуетесь? от сторонних плагинов или родной packer от Unity?
Ну, кроме прочего, всё равно мы работаем в условиях соблюдать pixel-perfect и все же стараться снизить размер билда. От этого пока никуда не деться :)
Нельзя работать с текстурами мимо юнити
Ну там мы работаем несколько сложнее… Хотя будем ревизировать.
Поэтому нужно следить именно за размером оперативной памяти,
Да, это другая сторона медали. За этим следим чётко.
Видимо, надо было в статье прописать чёткие условия работы: характер картинок, требования pixel-perfect, чтобы это не казалось вредными советами;)
Добрый день! Большое спасибо за интересные советы и дельную критику! Анализирую предложенное!
И заодно попробую объяснить, почему мы используем некоторые «вредные» методики и, судя по всему, вынуждены это делать и в дальнейшем.
для текстур без альфы автокомпрессию — на android они автоматически сожмутся в ETC1,
1) Для ETC1 картинка должна быть NPOT. У нас так просто невозможно. Если заимпотрить её как NPOT, то идею pixel-perfect можно похоронить. Ведь так?
2) вот такие видимые артефакты даёт ETC1 на нашей графике. Так что ухудшение качества сильное, к сожалению.
TrueColor (или RGB 24): AutoCompressed (ETC1):
Таким образом, в нашем случае — точно не AutoCompressed.
Второй пока неразгаданный факт.
юнити переводит текстуру в RGBA16 / RGBA32 только при наличии альфа-канала
Графика у нас отличная и без альфа канала. Всё происходит так, как Вы и пишете. Но перед сборкой мы её иногда скейлим и реимпортируем с использованием средств C#… после этого изображения без альфа-канала начинают восприниматься как RGBA 32. Наверное, альфа-канал появляется во время скейла. Будем искать. Благодарю за это замечание.
Для непрозрачных текстур всегда автокомпрессия
Опять же, есть риск получить покорёженную графику, когда она будет автоматом конвертиться в ETC1. У нас 2D игра с pixel-perfect… артефакты недопустимы. Потому всё так же выставляем RGBA32 -> RGBA16 в зависимости от качества или AutomaticTruecolor (если стоит выбор между RGBA32 или RGB24).
Получается, в этом случае Texture2D.LoadImage() тоже вполне подходит, потому что у нас RGB32/RGB24 и потребление памяти всё равно никак не снизить.
Все держать в wav — это позволит выбирать метод компрессии и битрейт прямо в юнити
Низкий битрейт в настройках импорта не влияет на размер сборки, только на потребление памяти. Зато если сформировать файл с низким битрейтом извне, то его размер будет меньше.
Всё-таки используемые методы снижения размера сборки зависят от особенностей графики проекта, и это играет определяющую роль
Аналогичное место, как мне кажется, на данный момент занимает С в мире разработки.
Да, да, конечно POT! запарился, простите.
Кстати, по поводу ETC1 вот что говорит Unity:
Наша графика не так проста. Тот кусочек — лишь кусочек большого изображения. 40% картинок по типу dl.dropboxusercontent.com/u/3232059/jungle_bg_1920x1200.png (здесь все кроме RGB24 несказанно портит качество), а остальное — с прозрачностью и тоже с хорошим градиентом. То есть, о других форматах кроме RGBA32, RGB24 и местами RGBA16 речи пока не идёт.
Но в общем Ваш совет я понял!
Какими атласами Вы пользуетесь? от сторонних плагинов или родной packer от Unity?
Ну, кроме прочего, всё равно мы работаем в условиях соблюдать pixel-perfect и все же стараться снизить размер билда. От этого пока никуда не деться :)
Ну там мы работаем несколько сложнее… Хотя будем ревизировать.
Да, это другая сторона медали. За этим следим чётко.
Видимо, надо было в статье прописать чёткие условия работы: характер картинок, требования pixel-perfect, чтобы это не казалось вредными советами;)
И заодно попробую объяснить, почему мы используем некоторые «вредные» методики и, судя по всему, вынуждены это делать и в дальнейшем.
1) Для ETC1 картинка должна быть NPOT. У нас так просто невозможно. Если заимпотрить её как NPOT, то идею pixel-perfect можно похоронить. Ведь так?
2) вот такие видимые артефакты даёт ETC1 на нашей графике. Так что ухудшение качества сильное, к сожалению.
TrueColor (или RGB 24):
Таким образом, в нашем случае — точно не AutoCompressed.
Второй пока неразгаданный факт.
Графика у нас отличная и без альфа канала. Всё происходит так, как Вы и пишете. Но перед сборкой мы её иногда скейлим и реимпортируем с использованием средств C#… после этого изображения без альфа-канала начинают восприниматься как RGBA 32. Наверное, альфа-канал появляется во время скейла. Будем искать. Благодарю за это замечание.
Опять же, есть риск получить покорёженную графику, когда она будет автоматом конвертиться в ETC1. У нас 2D игра с pixel-perfect… артефакты недопустимы. Потому всё так же выставляем RGBA32 -> RGBA16 в зависимости от качества или AutomaticTruecolor (если стоит выбор между RGBA32 или RGB24).
Получается, в этом случае Texture2D.LoadImage() тоже вполне подходит, потому что у нас RGB32/RGB24 и потребление памяти всё равно никак не снизить.
Низкий битрейт в настройках импорта не влияет на размер сборки, только на потребление памяти. Зато если сформировать файл с низким битрейтом извне, то его размер будет меньше.
Всё-таки используемые методы снижения размера сборки зависят от особенностей графики проекта, и это играет определяющую роль
Снова буду очень рад конструктивной критике!