[Stage3D] Texture.uploadFromBitmapData обнуляет RGB канал у прозрачных пикселей

[VisualDima]

Хочу использовать полпрозрачную текстуру с альфаканалом.
Загружаю из png. Создаю текстур формата Context3DTextureFormat.BGRA. Вызываю Texture.uploadFromBitmapData.
Ставлю обычный альфа-блендинг:

context3D.setBlendFactors(Context3DBlendFactor.SOURCE_ALPHA, Context3DBlendFactor.ONE_MINUS_SOURCE_ALPHA);

И наблюдаю такую картину: RGB каналы всех прозрачных пикселей (у которых альфа равна 0) заменяются черным цветом (нулями тоесть).
В результате, если увеличить объекты, становятся видны черные края (это происходит из-за сглаживания)

Свой BitmapData я проверил, там все нормально: во всех пикселях (даже в полностью прозрачных) белый цвет.
Должно быть вот-так: (изображение получено из обычного флеша)


Покопав дальше вообще обнаружил, что uploadFromBitmapData весьма своеобразно делает текстуры из полупрозрачных битмапов. Он какбы ренедерит их на черном фоне и записывает полученый результат в RGB канал (альфу при этом копирует правильно).
Т.е. если есть белое полупрозрачное облачко, то после uploadFromBitmapData получаем текстуру с СЕРЫМ полупрозрачным облаком. Дурдом! За такое руки отрывать надо, ИМХО.

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

[Zebestov]

Ничего подобного Stage3D при загрузке текстуры из битмапы не делает, это же форменный произвол!
Ты в шейдере часом не умножаешь RGB на A?

[VisualDima]

Чтобы еще раз все перепроверить, сделал отдельный проект где содержится только то, что нужно для теста.
Вот исходная картинка, как она выглядит в редакторе (фактически, редактировался только альфа-канал, цвет же везде белый 0xffffff):


Шейдер максимально простой (только XYZ и UV)

			var vertexShaderAssembler:AGALMiniAssembler = new AGALMiniAssembler();
			vertexShaderAssembler.assemble ( Context3DProgramType.VERTEX,
				"m44 op, va0, vc0\n" +
				"mov v0, va0\n" +			// XYZ -> v0
				"mov v1, va1\n"				// UV -> v1
			);      
			var fragmentShaderAssembler:AGALMiniAssembler = new AGALMiniAssembler();
			fragmentShaderAssembler.assemble ( Context3DProgramType.FRAGMENT,  
				"tex ft0, v1, fs0 <2d,repeat,nomip,linear>\n" +  
				"mov oc, ft0\n"                  
			);
			m_pShaderProgram = m_pContext3D.createProgram();
			m_pShaderProgram.upload(vertexShaderAssembler.agalcode, fragmentShaderAssembler.agalcode);

Создание текстуры (mipmapping'а нет):

			m_pTexture = m_pContext3D.createTexture(m_pBitmap.width, m_pBitmap.height,
                                          Context3DTextureFormat.BGRA, false);
			m_pTexture.uploadFromBitmapData(m_pBitmap.bitmapData, 0);

Вывожу два квада. Слева без блендинга:

setBlendFactors(Context3DBlendFactor.ONE, Context3DBlendFactor.ZERO)

Справа с обычным блендингом:

setBlendFactors(Context3DBlendFactor.SOURCE_ALPHA, Context3DBlendFactor.ONE_MINUS_SOURCE_ALPHA)

Внизу просто addChaild'ом добавил копию загруженной битмапы, чтобы проверить, что она загрузилась правильно (собственно, при выводе с блендингом должна быть именно такая картинка).
Вот что получилось в результате:


Либо я чего-то не понимаю, либо да, произвол. Слов нет кроме матерных.
Могу выложить весь проект (сделан в FlashDevelop'е)

[Zebestov]

Если не затруднит, запакуй в zip и выложи непосредственно тот PNG, который ты используешь.

[Gerbert]

Я не понял до конца, но если у Вас белый круг в черном квадрате, который Вы пытаетесь скрыть,
то черная обводка это нормально. Если в фотошопе нарисовать белый круг на черном квадрате,
а потом увеличивать, то появятся серые пиксели, это так программа видит масштаб. И ничего с этим не поделать.

[Zebestov]

Нет. Здесь речь идет скорее всего о premultipled alpha при экспорте изображения в PNG. Поэтому и прошу показать именно файл изображения.

Забегая вперед, если таки да, то вот решение.

[VisualDima]

Вот ссылка на исходный png в архиве. https://cloud.mail.ru/public/b2c21a360e37/Bitmapa.zip
Вот на всякий случай весь проект: https://cloud.mail.ru/public/b3343d1...adTexCheck.zip

Zebestov, точно эффект именно как при premultipled alpha. Но такое впечатление, что происходит он именно в момент uploadFromBitmapData.
Ведь на нижнем изображении на картинке эффект не наблюдается, т.е. исходный bitmapData нормальный.

Добавлено через 14 минут
Кстати, Zebestov. Огромное спасибо за ссылку! Как запасной вариант подойдет (устраняет проблему). Но меня смущает лишняя операция деления в шейдере. Не привык я разбрасываться ресурсами системы. Продолжаю копать.
Никак не пойму, почему кто-то в адоб решил что он лучше знает, как должна выглядеть моя текстура. Просто бы скопировали цвветовые данные как я прошу - быстро и просто. Нет, самодеятельность какую-то придумали.

[Партизан]

Вроде решает проблему....

m_pContext3D.setBlendFactors(Context3DBlendFactor.SOURCE_ALPHA, Context3DBlendFactor.ONE);

[Zebestov]

Сообщение от VisualDima

Но меня смущает лишняя операция деления в шейдере. Не привык я разбрасываться ресурсами системы.

Совершенно с тобой согласен. И кстати, файл таки без premultipled… странно все это.

Добавлено через 2 минуты
Партизан, не решает, потому что в данном случае совершенно идентично — SOURCE_ALPHA же у нас ноль, значит ONE_MINUS_SOURCE_ALPHA и так ONE.

Добавлено через 25 минут
Итак, вот что вычитал уважаемый Волгоградец (автор сайта, который указан выше).

Все пиксели в объекте BitmapData сохраняются как предварительно умноженные значения цвета.
…
Все методы BitmapData принимают и возвращают неумноженные значения.

Таким образом любое изображение, которое вставляется во Flash (будь то элемент из библиотеки в IDE или изображение, вставленное с помощью тега embed), превращаясь в BitmapData сразу же подлежит предварительному умножению. Таки да. Произвол. Понятно, зачем это сделано, но нам пофиг!

Как видно, никакими getPixel32/setPixel32 ты это не исправишь. Остается лишь пробежаться по содержимому BitmapData как по ByteArray и переделить все RGB на A. И лишь после этого можно отгружать текстуру в GPU.

Однако наш коллега комментирует это так:

– можно переделить, но одно деление в шейдере — это ничто, наносекунды, даже меньше, даже на отстойных телефонах;


P.S.
И да, ты был прав, Flash таки мутит свои дела, оправдывая это вероломство какими-то нелепыми отмазками типа ускорения отрисовки сцены, пфф!

[Партизан]

ну как-бы результат такой...