Pull to refresh

Comments 45

Самый простой спостоб — premultiply by alpha. То есть умножить картинку на альфу.
UFO just landed and posted this here
UFO just landed and posted this here
Умножить RGB на альфу, все равно будет RGB. И явно они будут не такого цвета, как пограничные пиксели. Так что это ничуть не поможет.

Например, если у нас спрайт белый. Мы умножаем прозрачные пиксели на альфу (0) и получаем идеально черный цвет прозрачных пикселей. Далее имеем ровно то же самое, что я описал в статье.
Сталкивался с такой проблемой, боролся аналогичным образом.
UFO just landed and posted this here
Вроде как, Fireworks лучше сохраняет png, чем некоторые версии Photoshop.
Он, наверное, сохраняет не «лучше», а меньше оптимизирует. Ибо ФШ при сохранении — заливает прозрачные области таким цветом, чтобы эти области образовывали большие квадраты и желательно примыкали к реальным пикселям. Чтобы это дело лучше ужималось.
Вы прав, конечно. Но по-моему в данном случае эпитет «лучше» подходит.
Ну, это для этих целей, может, и «лучше». А вот с точки зрения конечного размера — может, и «хуже» :)
На девайсе, как я понимаю процесс, без разницы — все пикселы в памяти занимают столько места, сколько задано настройками, например, при kCCTexture2DPixelFormat_RGBA8888 получается 32 бита на пиксел. Так?
Есть еще форматы с компрессией ;)
Если уж брать фотошоп, то лучше не делать 1% прозрачность, а после блура нижнего слоя перепременить исходную маску к склееному изображению и сохранить PNG классическим способом а не Save-For-Web. Такой способ сохранения не убивает изображение в прозрачных областях.

Но, главный вопрос к автору, зачем понадобилось иметь тайл, окруженный прозрачностью?
UFO just landed and posted this here
Странно, что вы задаете такие вопросы. На первой же картинке явно нарисованы изометрические тайлы. Именно они должны быть с прозрачностью.

Более того — даже квадратные 2д тайлы все равно клеятся в единые атласы и получаются с прозрачностью.
Действительно, смотрю в книгу, вижу фигу. Про изометрию даже не подумал.
А вот квадратными какая проблема, так и не пойму.
Квадратные спрайты вы склеите в атлас (не по отдельной же текстуре на каждый спрайт будете юзать?). Соответственно, вокруг квадратный тайлов — все равно будет прозрачность атласа (если атлас будете клеить с промежутками). А если склеите без промежутков — так вообще получите рядом пиксель соседнего спрайта. И словите все тот же батхёрт.
В 3D играх тоже бывает нужна прозрачность с резкой границе (например сетка забора) и для решения этой проблемы при выводе примитива можно нужным образом настроить альфа-тест. В случае, приводимом автором, надо не рисовать пиксели, прозрачность которых ниже некоторого порогового значения, чуть меньшего чем 1. В качестве бонуса это иногда работает быстрее чем блэндинг.
Тогда просто дырки будут.
я так понял, что цель автра топика как раз состоит в том чтобы получить аккуратные «дырки наоборот» без швов.
При наличии в игре спрайтов с плавным уходом в альфу это даст нежелательные эффекты.

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

Да вы сами подумайте, что будет быстрее? Без альфатеста:

dest = res

или с альфатестом

if (res.a > 0.5) dest = res

Лишний «if» — это всегда потеря скорости. А тут этот «иф» будет производиться для каждого пикселя.
Разные настройки для вывода для разных типов объектов это нормально — смена алтаса же не представляется геммороем.

В случае FFP alpha-test будет работать достаточно хорошо.

В конвейере с шейдерами вместо if нужно делать floor альфа-канала
Я вам о том, что альфатест — это все равно иф. И шейдер с альфатестом работает медленнее шейдера без альфатеста. Проверенн.
В ffp железе это не было if'ом.
Вы floor вместо if в шейдере писать пробовали или нет? if очевидно медленно работает, но желаемого эффекта в шейдере можно добиться и без его помощи.
На самом деле, alpha-test — это все равно if. Хоть и железный, но все равно — «иф».

Тут все зависит от того, сколько у вас прозрачных пикселей. По моим наблюдением, если прозрачных больше 20% — можно смело юзать альфатест — получите прирост.

А вот если прозрачных меньше 20% — то альфатест может только замедлить процесс отрисовки.
Эх как же было хорошо во времена fixed pipeline — врубил и скорости только прибавилось.
Честно говоря, написанное не соответствует действительности, имхо.
Во-первых:
>> Вся загвоздка в том, что полностью прозрачные пиксели все равно имеют какое-то значение в канале цвета.
не «имеют», а «могут иметь». В других случаях — могут и не иметь.
Во-вторых:
из приведённого изображения никак не следует, что «прозрачные пиксели имеют белый цвет».
Швы в тайлах действительно имеют место быть при масштабировании, но это, как вы справедливо заметили, следствие резкого перехода к прозрачности, а не плавного. Тот факт, что GPU отдельно обрабатывает канал цвета и альфу ту ни при чём.
> Тот факт, что GPU отдельно обрабатывает канал цвета и альфу ту ни при чём.

Проблема все-таки именно в этом. Прозрачные пиксели никак не должны влиять на цвет непрозрачных, а для этого нужно учитывать альфа-канал при масштабировании.
Нет. Во-первых — пиксели именнь «имеют» цвет. Всегда. Каждый пиксель сохранен как rgba. И даже при а=0, значения rgb все равно будут указаны.

И швы — именно следствие такого упрощенного масщтабирования. Если бы GPU при скейле взвешивал цвета по альфе, такого бы не было. Но он этого не делает. Отсюда — и артефакты.
Насчёт фотошопа не знаю, но многие другие графические редакторы реализуют прямо отдельную опцию, сохранять ли цвет прозрачных пикселей. Я ещё гадал, нафига это может потребоваться. :-)
В Unity3D при импорте таких PNGшек прозрачные пиксели приобретают цвет своих непрозрачных соседей.
Именно в юнити я и работаю. Никто ничего не преобретает. Только то, что есть в файле.
image

В самом файле пиксели черные.
Нет. Юнити как раз показывает розрачные пиксели! Это именно тот цвет, который у вас в прозрачности. Откройте png сохраненный фотошопом и сможете увидеть как ФШ моптимизирует цвета прозрачных областей.

Юнити не меняет цвет озоачных пикселей. Он просто его показывает.
Это просто у вас софтина, с помощью которой вы экспортанули эту красную штуку — как раз сделала то, о чем я писал в статье — закрасила красным прозрачные пиксели. Не знаю уж — везение это или продуманность софтины. Но я сталкивался с полной радугой в прозрачности (правда, и картинки были более разноцветными).
В фотошопе можно указать matte при сохранении png-8 и gif, это тот самый цвет который будет назначен прозрачным пикселям. png24 и вовсе лишен подобных недостатков. Сохранять через save for web & devices.
Ненене, вы не поняли в чём соль. )
Matte — это вообще не то. Это если вы хотите ВМЕСТО прозрачности залить каким-то цветом.
С конца 90-х знал про такую фишку в GIF… Но не задумывался о причинах. А оказывается вон оно что… Спасибо!
Я когда-то просто выключал antialiasing при сохранении картинок в редакторе. И вполне хорошо выглядело, кроме краевых спрайтов.
В бытность программистом на J2ME работал над другой задачей.

Рендер даёт картинку с каналом прозрачности. Обрезать канал до однобитного. Желательно интерактивно: т.е. художник карандашиком может убрать или добавить пиксель, где нужно.
Как это я делал, я в упор не помню. Помню только, придумал два способа в зависимости от того, что нужно: либо края чистого цвета, либо смешанные с фоном. В одном из этих способов (вроде в первом) я использовал простенькую самописную программу, которая убивала альфа-канал PNG.
Sign up to leave a comment.

Articles

Change theme settings