Comments 26
я написал, что чуть позже выложу на битбакет, пока не имею возможности
К чему такая спешка? :) Опубликовали б статью, когда появится возможность выложить куда-нибудь.
Не то чтобы спешка… Просто посчитал что статья и без сорсов имеет ценность, и их можно позже приложить.
1. Альфа-атласы, собранные по 3 текстуры нужно тоже жать в etc1 / pvrtc (просто выбрав compressed) — должно получиться по размеру соизмеримо с уменьшением в 2 раза + RGB16. Проще шейдеры, проще пайплайн.
2. Собирая в разные материалы мы теряем главное преимущество нгуя над штатной новой недоделкой uGui — это качественный батчинг с гибкой настройкой. Если пожертвовать изменением цвета (tint, подкраска) спрайта, то в нем можно хранить маску выбора альфа-канала путем записи туда опорного цвета (R00, 0G0, 00B). Останется немного подхачить штатные шейдеры на использование i.color во фрагментном шейдере как маски и готово — батчинг сохранен, все поют и танцуют.
1. Пробовал, сильно страдает качество в местах перехода в прозрачность, а так же каналы перемешиваются, в результате непрозрачность появляется там, где ее быть не должно.
2. Разве? на весь UIDrawcall по прежнему один материал, он не меняется в рантайме, так что все продолжает батчится. С вертексным цветом я работаю как и работал, кроме вышеупомянутой сложности с изменением атласа — работа с НГУИ никак не изменилась.
каналы перемешиваются, в результате непрозрачность появляется там, где ее быть не должно.

Так порядок упаковки важен :) Но вообще странно, что уменьшение размера текстуры в 2 раза не убивает качество, а сжатие полноразмерной — убивает. Тут важно то, чтобы использовать 3 канала, а не 4. Как для дифуза, так и для альфы.
на весь UIDrawcall по прежнему один материал, он не меняется в рантайме

В принципе согласен, но это требует ручной настройки всех виджетов на правильный материал. С подменой цветов и использованием штатной механики атлас-префабов оно получится проще и без настройки внешних материалов.
Хотя ерунду написал про настройку виджетов — префаб атласа должен это на себя взять.
Да, так и есть, материал поменяется только на префабе и нгуи дальше с ним работает :)
Но вообще странно, что уменьшение размера текстуры в 2 раза не убивает качество, а сжатие полноразмерной — убивает
Простите за некропост, но не удержался. Так же в Юнити 5.5 было и с лайтамапами. Лайтмапа на 2048 с компрессией выглядела плохо, были заметны квадраты. Потом делаешь ее же на 1024 без компрессии, весит меньше, а качество — значительно лучше.
Тут сжатие относилось только к альфа-каналу, а не к дифузу — возник как раз вопрос, что уменьшение разрешения в 2 раза не убило прозрачность на краях.
Да, я понял. Я впринципе говорю, что заметил, что уменьшение в два раза часто убивает качество значительно меньше, чем сжатие полноразмерной картинки.
>качественный батчинг с гибкой настройкой
Что имеется в виду? Никакого качественного батчинга я там не наблюдаю. Гибкой настройки как бы тоже. Может я что-то не знаю?
Свойство DepthOrder можно менять для виджета любого уровня вложенности, выводя виджеты одного атласа в одну плоскость (блок по Z) — они будут сбатчены в 1дк. В случае uGui это просто невозможно — рендер смотрит GameObject-ы линейно и последовательно, согласно иерархии. Как только встречается виджет из другого атласа — батч будет прерван и начат новый. Единственное решение для получения такой же оптимизации — не пользоваться иерархией и все держать в одно GameObject, выставляя порядок руками как надо.
Например, 2 кнопочки, задник, иконка, надпись, привязка по левому/правому углу экрана, иконки в отдельном атласе. В случае uGui это будет 6дк, в случае нгуя — 3дк (задникам кнопок ордер=1, иконкам ордер=2, надписям ордер=3). Не пользоваться иерархией — проще не пользоваться новым гуем.
Ну во-первых, точно так же себя ведет и NGUI и при встрече другого материала draw call «разрывается».
А во-вторых, в моем случае необходимость ручной настройки наоборот напрягает. Вручную можно настроить только простенький UI, а со сложным это становится не просто сложно, а иногда и невозможно. А если учесть, что художник тоже хочет делать UI, но о понятии draw call не знает…
А прикрутить к UGUI хитрый автоматический батчинг — дело несложное. Главное, что при этом не придется трогать уже сделанный UI.
Ну во-первых, точно так же себя ведет и NGUI и при встрече другого материала draw call «разрывается».

Ну а во-вторых — разговор был что это настраивается одной циферкой (мы же про гибкость начали говорить, нет?) и есть такая возможность, в отличие от.
А если учесть, что художник тоже хочет делать UI, но о понятии draw call не знает…

А это его проблемы. Должен быть технический контроль над артовиками, описаны правила сборки или нечто подобное. Если такого нет ибо пиляется в одно лицо — ну что же, печально, но в случае uGui такой возможности нет в принципе.
А прикрутить к UGUI хитрый автоматический батчинг — дело несложное. Главное, что при этом не придется трогать уже сделанный UI.

А вот отсюда поподробнее. Рендер спрайтов разве управляем и полностью представлен пользовательским кодом, куда можно залезть и подхачить? К тому же — это нужно писать + поддерживать все будущие апдейты, юнитеки любят часто ломать то что уже работает (видел стенды для проверки проектов на 6-8 версиях юнити). Я честно пробовал использовать это поделие, но через пару месяцев откатился на нгуй, чему рад несказанно — весь код доступен и может быть пофикшен / можно понять почему проявляется какой-либо side-эффект. Да, там есть косяки с динамическими шрифтами в редакторе на превью, которые автор почему-то игнорирует, но в силу открытости фикс написать оказалось довольно просто за полчаса изучения проблемы.
>Должен быть технический контроль над артовиками
Ну это лишнее время, а значит и деньги.
>разговор был что это настраивается одной циферкой
в разных контекстах эта циферка должна меняться, а значит статически задать это невозможно. Точнее получится неоптимальное решение. И представьте, что вы решили поменять атласы по той или иной причине, и это приведет к необходимости ручной правки всех префабов!
>А вот отсюда поподробнее
Я им не занимался, поэтому не скажу. Я имею в виду, что приделать могут и сами Unity, если захотят. К NGUI приделать тоже реально, на самом деле.
>это нужно писать + поддерживать все будущие апдейты
Ну так и NGUI приходится сильно-сильно дорабатывать. Правда апдейты к нему реже выходят.
Мы ведь обсуждаем что уже существует, а не сферического коня в вакууме, верно? Так можно дорассуждать, что можно написать все, что угодно и в 1дк :) Ждать что-то полезное от юнитеков — как у моря погоды, от автора нгуя — аналогично. Поведение примерно идентично в дефолтном исполнении, разница в том, что в нгуе уже есть крутилки для тонкой настройки, если кому потребуется и кто умеет это использовать. Собственно, обсуждение этой настройки и было ответом на
Что имеется в виду? Никакого качественного батчинга я там не наблюдаю. Гибкой настройки как бы тоже. Может я что-то не знаю
Ну я не могу назвать это качественным батчингом, ибо, как мы выяснили, он там точно такой же, просто надо руками все выставлять.
Значит батчинг в uGui вообще «некачественный», раз не предоставляет даже возможности в такой настройке. Тут упор был в настройку, а не в «качество», неверно выразился в том посте.
> выйгрыш в качестве арта виден невооруженным глазом

А есть ли версия вашей игры про карманных войнов под андройд?
Очень круто и очень хочется тоже использовать этот подход. Но у меня стандартный GUI и стандартный Sprite Packer. Как-то можно использовать это подход в таком случае?
Однозначно ответить сложно, знаю только, что есть т.н. CustomPackerPolicy, и это очень похоже на точку, в которой можно вмешаться в создание атласа. Но я не пробовал.
Кроме того, сейчас на новом проекте мы решили отложить использование разложения атласов до лучших времен (чтобы не тратить время при пересборке атласов), и просто используем обычную компрессию, но с отключенными мипмапами на атласах — именно второй мип смотрится хуже всего. Ухудшения качества не заметили, но, возможно, дело в том что стилистика арта поменялась. Это я к тому, что описанное в статье — не панацея. Что меня сейчас волнует больше — так это то, что все атласы у нас 2к, и компрессия каждого занимает около 20-ти минут на билд-машине. В итоге игра в хушем случае собирается около 3-х часов. И здесь неплохо бы опробовать способ Leopotam.
Жопа с артефактами сильно от стиля зависит, это понятно. У меня на проектах просто катастрофа ((
Only those users with full accounts are able to leave comments. Log in, please.