Умножить RGB на альфу, все равно будет RGB. И явно они будут не такого цвета, как пограничные пиксели. Так что это ничуть не поможет.
Например, если у нас спрайт белый. Мы умножаем прозрачные пиксели на альфу (0) и получаем идеально черный цвет прозрачных пикселей. Далее имеем ровно то же самое, что я описал в статье.
Он, наверное, сохраняет не «лучше», а меньше оптимизирует. Ибо ФШ при сохранении — заливает прозрачные области таким цветом, чтобы эти области образовывали большие квадраты и желательно примыкали к реальным пикселям. Чтобы это дело лучше ужималось.
На девайсе, как я понимаю процесс, без разницы — все пикселы в памяти занимают столько места, сколько задано настройками, например, при kCCTexture2DPixelFormat_RGBA8888 получается 32 бита на пиксел. Так?
Если уж брать фотошоп, то лучше не делать 1% прозрачность, а после блура нижнего слоя перепременить исходную маску к склееному изображению и сохранить PNG классическим способом а не Save-For-Web. Такой способ сохранения не убивает изображение в прозрачных областях.
Но, главный вопрос к автору, зачем понадобилось иметь тайл, окруженный прозрачностью?
Квадратные спрайты вы склеите в атлас (не по отдельной же текстуре на каждый спрайт будете юзать?). Соответственно, вокруг квадратный тайлов — все равно будет прозрачность атласа (если атлас будете клеить с промежутками). А если склеите без промежутков — так вообще получите рядом пиксель соседнего спрайта. И словите все тот же батхёрт.
В 3D играх тоже бывает нужна прозрачность с резкой границе (например сетка забора) и для решения этой проблемы при выводе примитива можно нужным образом настроить альфа-тест. В случае, приводимом автором, надо не рисовать пиксели, прозрачность которых ниже некоторого порогового значения, чуть меньшего чем 1. В качестве бонуса это иногда работает быстрее чем блэндинг.
Очевидно, что для спрайтов с плавной альфой описанной в статье проблемы нет и для них альфа-тест надо выключать.
Про альфа-тест в шейдере ничего сказать не могу, так как мои знания по этому вопросу определённо устарели.
Альфа-тест можно включить только целиком для натягивающего текстуры шейдера. Иметь два шейдера для разных спрайтов — геморрой. И да, это действительно медленно.
Да вы сами подумайте, что будет быстрее? Без альфатеста:
dest = res
или с альфатестом
if (res.a > 0.5) dest = res
Лишний «if» — это всегда потеря скорости. А тут этот «иф» будет производиться для каждого пикселя.
В ffp железе это не было if'ом.
Вы floor вместо if в шейдере писать пробовали или нет? if очевидно медленно работает, но желаемого эффекта в шейдере можно добиться и без его помощи.
На самом деле, alpha-test — это все равно if. Хоть и железный, но все равно — «иф».
Тут все зависит от того, сколько у вас прозрачных пикселей. По моим наблюдением, если прозрачных больше 20% — можно смело юзать альфатест — получите прирост.
А вот если прозрачных меньше 20% — то альфатест может только замедлить процесс отрисовки.
Честно говоря, написанное не соответствует действительности, имхо.
Во-первых:
>> Вся загвоздка в том, что полностью прозрачные пиксели все равно имеют какое-то значение в канале цвета.
не «имеют», а «могут иметь». В других случаях — могут и не иметь.
Во-вторых:
из приведённого изображения никак не следует, что «прозрачные пиксели имеют белый цвет».
Швы в тайлах действительно имеют место быть при масштабировании, но это, как вы справедливо заметили, следствие резкого перехода к прозрачности, а не плавного. Тот факт, что GPU отдельно обрабатывает канал цвета и альфу ту ни при чём.
> Тот факт, что GPU отдельно обрабатывает канал цвета и альфу ту ни при чём.
Проблема все-таки именно в этом. Прозрачные пиксели никак не должны влиять на цвет непрозрачных, а для этого нужно учитывать альфа-канал при масштабировании.
Нет. Во-первых — пиксели именнь «имеют» цвет. Всегда. Каждый пиксель сохранен как rgba. И даже при а=0, значения rgb все равно будут указаны.
И швы — именно следствие такого упрощенного масщтабирования. Если бы GPU при скейле взвешивал цвета по альфе, такого бы не было. Но он этого не делает. Отсюда — и артефакты.
Насчёт фотошопа не знаю, но многие другие графические редакторы реализуют прямо отдельную опцию, сохранять ли цвет прозрачных пикселей. Я ещё гадал, нафига это может потребоваться. :-)
Нет. Юнити как раз показывает розрачные пиксели! Это именно тот цвет, который у вас в прозрачности. Откройте png сохраненный фотошопом и сможете увидеть как ФШ моптимизирует цвета прозрачных областей.
Юнити не меняет цвет озоачных пикселей. Он просто его показывает.
Это просто у вас софтина, с помощью которой вы экспортанули эту красную штуку — как раз сделала то, о чем я писал в статье — закрасила красным прозрачные пиксели. Не знаю уж — везение это или продуманность софтины. Но я сталкивался с полной радугой в прозрачности (правда, и картинки были более разноцветными).
В фотошопе можно указать matte при сохранении png-8 и gif, это тот самый цвет который будет назначен прозрачным пикселям. png24 и вовсе лишен подобных недостатков. Сохранять через save for web & devices.
В бытность программистом на J2ME работал над другой задачей.
Рендер даёт картинку с каналом прозрачности. Обрезать канал до однобитного. Желательно интерактивно: т.е. художник карандашиком может убрать или добавить пиксель, где нужно.
Как это я делал, я в упор не помню. Помню только, придумал два способа в зависимости от того, что нужно: либо края чистого цвета, либо смешанные с фоном. В одном из этих способов (вроде в первом) я использовал простенькую самописную программу, которая убивала альфа-канал PNG.
У прозрачных пикселей тоже есть чувства или артефакты png'шек с прозрачностью