Данный блог автоматически транслируется в у меня в ЖЖ, для тех кому его удобнее читать там.

Будем рассуждать логически, в нашем мире обычные фотоаппараты “мыльницы” - как раз имеют ярко выраженный эффект, который в играх называют HDR. Засвечивают очень яркие области или и полностью затемняют очень темные. При этом если направлять камеру с ярких областей на темные, то отлично видно эффект адаптации “глаза” к освещенности. При этом мыльницы получают с матрицы ну максимум по 12 бит на канал, а старые по 8. Как же они это делают?

Камера постоянно производит матричный замер экспозиции, используя одно или несколько значений с матрицы, оценивая таким образом общую яркость/контрастность кадра. И используя полученное значение, в зависимости от заданного режима съемки производит коррекцию экспозиции в нужную сторону. Таким образом, камера итеративно подбирает нужное значение экспозиции. Это и есть та самая нужная нам, “адаптация глаза к свету”, которую в играх выдают за HDR эффект.

Что же мешает делать нам тоже самое, а не использовать дорогой рендер в рендертаргет с плавающей точкой? Правильно, ничего не мешает - давайте попробуем.

Итак алгоритм следующий:

• Рисуем в рендертаргет R8G8B8(X8) все что захотим, с одним отличием - перед тем как вернуть финальный цвет из пиксельшейдера умножаем его коэфицент яркости (Exposure Adjustment)

• После того, как кадр нарисован, производим оценку яркости кадра (основная хитрость как сделать это быстро, об этом ниже)

• В зависимости от посчитанной яркости кадра изменяем Exposure Adjustment, если кадр слишком темный, повышаем наш множитель. Если слишком светлый, понижаем.

• Далее, повторяем все заново.

Как видно, алгоритм очень простой. Но нам нужно оценивать яркость отрисованного кадра, для правильного сдвига Exposure Adjustment. Обычно, для оценки яркости кадра используется гистограмма, но мы же хотим сделать быстрый HDR и желательно без использования CPU, а классическая гистограмма для этого не лучший вариант.

Вот мой вариант быстрого экспозамера кадра на GPU:

• Копируем полученный кадр в квадратную текстуру, меньшего размера чем экран, при этом производим оценку яркости каждого пикселя следующим образом: считаем яркость пикселя и в завсисмости от яркости в разные каналы RGB кладем разные значения. В R канал кладем коэфицент, что пиксель недосвечен, в B канал кладем коэфицент, что пиксель пересвечен, в G канал кладем нормализованный остаток: 1.0 - R - G. Таким образом, полностью черный пиксель превратится во float3(1, 0, 0) а полностью белый во float3(0, 0, 1). Сумма 3-х компонентов RGB всегда нормализованна и равна 1.0. Фактически это оценка данного пикселя 3 функциями dark, medium и light colors (гистограмма с 3 корзинами). Таким способом, мы получили оценку каждого пикселя отдельно, но нам нужна оценка всей картинки вцелом.

• Входные данные при предыдущем шаге сформированны таким образом, что теперь оценку освещенности для всего кадра, можно сделать очень быстро. Рисуем получившуюся текстуру с коэфицентами, в текстуру с разрешением в два раза меньше (в следующий mip). При этом используем LINEAR фильтрацию текстур и делаем каждую нашу выборку между текселями. GPU при этом автоматически сэмплирует 4 текселя и т.к. мы используем LINEAR фильтрацию фактически проведет нормализацию результата (tex1 + tex2 + tex3 + tex4 * 0.25). Результат: оценка яркостной составляющей блока пикселей 2×2. Повторяем шаг до размера размера текстуры 2×2

• Теперь у нас есть гистограмма всей картинки (правда всего на 3 корзины) и нам нужно сдвинуть нашу коррекцию экспозиции. Т.к. зачитывать данные от GPU к CPU не хочется (данных хоть и мало, но синхронизация GPU с CPU это вообще всегда медленно), заводим текстуру Exposure Adjustment размером 1×1 пиксель (по идее надо float текстуру заводить, но я попробовал хватает точности и у обычной 8 битной). Данная текстура всегда будет лежать в текстурном кеше GPU и фактически является константой. Эту текстуру и используем как множитель Exposure Adjustment.

• Теперь у нас есть две текстуры: 1×1 текстура “множитель” для HDR и текстура 2×2 гистограмма разложенная в 3 buckets. Оцениваем какая из часть гистограммы “перекошена” и сдвигаем значение в текстуре в нужную нам сторону - обычный рендер в текстуру, без зачитывания данных в CPU.

• Результат: в зависимости от яркости кадра мы сдвинули Exposure Adjustment в нужную нам сторону, очень быстро, полностью на GPU и используя только текстуры 8 бит на канал.

Так выглядит текстура с коэфицентами яркости
=================================================

Вот тут, можно скачать демо со всеми исходниками (37.7Мб) - в котором HDR реализован описанным выше способом. Демо работает на PC и на X360 (у кого есть XDK + Devkit могут тоже потестировать). Там совсем простой алгоритм экспо-коррекции (обычный сдвиг), можно подумать и сделать похитрее. Также, развивая идею дальше: коэфицент Exposure Adjustment не обязательно должен быть константным для всего кадра. Мне кажется, если сделать для различных зон экрана разную коррекцию экспозиции (например сеткой 16×16) то будет еще лучше.

Управление: зажав правую кнопку мыши можно крутить головой и летать с помощью WASD.

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

update: обновил демку, на экран для отладки выводятся результаты анализа картинки и искуственно добавил тормозов для CPU, иначе при FPS > 1000 float дельта тайм себя плохо ведет

http://www.CaptainBloodGame.com/
Всем добро пожаловать!

В системах частиц и всяких спецэффектах часто нужно рисовать с различным блендингом,
классически это add blend и alpha blend.

Обычно рисуют сортированные (по эмиттерам или по частицам) партиклы с alpha blend, а потом поверх кладут частицы с add blend (их уже можно не сортировать).

Но, художникам иногда очень хочется нарисовать партикл с add blend, а поверх него с alpha blend.

И уж точно программистам всегда хочется рисовать все частицы за один batch, независимо от их блендинга.

Итак, немного простой математики:
Формула блендинга destColor = sourcePixel * srcBlend + screenPixel * dstBlend;

Для add blend задают srcBlend и dstBlend как one, получая:

//blend function
destColor = sourcePixel + screenPixel;

Для alpha blend задают srcBlend как srcAlpha и dstBlend как invSrcAlpha, получая:

//blend function destColor = sourcePixel * srcAlpha + screenPixel * invSrcAlpha;

_Winnie C++ Colorizer

Так как же совместить эти два режима блендинга в одном ?

Задаем srcBlend как one и dstBlend как invSrcAlpha, получаем:

//blend function
destColor = sourcePixel + screenPixel * invSrcAlpha;

Теперь, следите за руками несколько манипуляций в pixel shader:

//0.0 это Add blend
//1.0 это Alpha blend
float addOrBlend = 0.0; 

float4 ps_test( PS_INPUT pix ) : COLOR0
{
   float4 texel = tex2D(baseMap, pix.texCoord0);
   texel.rgb = texel.rgb * texel.a;
   texel.a = texel.a * addOrBlend;
   return texel;
}

Посмотрим, что же получилось и самое главное, как.

Итак наша формула блендинга destColor = sourcePixel + screenPixel * invSrcAlpha;
при значении addOrBlend = 0.0; получаем (с учетом математики в pixel shader):

//blend function
destColor = sourcePixel * srcAlpha  + screenPixel;

при значении addOrBlend = 1.0; получаем (с учетом математики в pixel shader):

//blend function
destColor = sourcePixel * srcAlpha  + screenPixel * invSrcAlpha;

Как видно, add blend получается не совсем “чистый”, цвет текстуры умножается на альфу, но это дает нам возможность плавно менять addOrBlend соответственно плавно изменяя режим блендинга.

Если вдруг нужно только бинарное значение и хочется “чистый” блендинг, можно немного изменить наш шейдер: texel.rgb = texel.rgb * lerp (texel.a, 1.0, addOrBlend);

С помощью данной техники у нас в Приключениях капитана Блада сделаны партиклы.
Партикловый художник может графиком задавать блендинг у каждой частицы, при этом все частицы сортированные и рисуются за один batch.

Надеюсь это пригодится и в вашем проекте.

Профайлер подсказал, что все дело в использовании стандартного strcmp. После использования самописного аналога - Intel и AMD снова работают как и ожидалось. Как приятный бонус скорость DynamicCast подросла почти на 50% и на моем AMD 3000+ в 4.5 раза быстрее чем стандартный cast.

Так же в качестве бонуса, по подсказке my.name,  сделал автоматическое определение базового класса (без указания его в макросе объявляющим метаданные) и перенес определение рефлекшн аттрибутов в хидер.

В общем вот: новая версия reflectionLibrary_v2

Первая проблема в том, что все функции оперирующие или выдающие как результат множества объектов должны работать с базовым типом, каким нибудь IEntity. Для примера: выбрали мы из мира с помощю AABB набор игровых объектов и хотим нанести урон, всем кто поддерживает интерфейс IDamageable, для этого обычно используют dynamic_cast или какой нибудь getType. На консолях, где RTTI в релизном билде обычно запрещен - приходится изобретать свои методы (см. библиотеку от Insomniac).

Вторая проблема, отсутсвие в С++ Property и средств для работы с ними. Движки по типу Unreal Engine3 и CryEngine приучают творческих людей работать с набором параметров у любого игрового объекта - будь то объект миссии, текстура или спецэффект, что совершенно логично и удобно.

Но вот незадача, в C++ отсутсвует возможноть получить какие либо метаданные класса - что бы узнать его поля / свойства и использовать это для управления объектом в реальном времени. Т.е. написание удобного и визуального средства редактирования C++ классов становится проблемой.

Существует множество вариантов решения, кто-то пишет уникальные редакторы для уникальных объектов, кто-то использует кодогенерацию мета-информации и классов, кто-то просто игнорирует проблему или пишет редактируемые объекты на скриптовых языках с поддержкой Reflection.

Третья проблема, система автоматического save / load любых объектов. Делают её обычно банально через virtual ::save(file * f) и virtual ::load (file *f) для всех объектов которым нужно уметь сохраняться, и с разной степенью успеха борются с проблемой при загрузке - как, имея имя класса в const char * создать экземпляр класса.

Чтобы решить эти проблемы один раз и навсегда, я написал маленькую библиотеку С++ reflection (скачать тут) которая позволяет удобно добавлять произвольную метаинформацию к любым классам, не требует специального препроцессора или кодогенерации и намного быстрее существующих средств в языке (dynamic_cast) или библиотек.

Вот пример объявления метаданных внутри cpp файла.

BEGIN_REFLECTION_METADATA(foo_class, base_class)
    ATTRIBUTE_FLOAT("myFloatProperty", &foo_class::setFloatFunc, &foo_class::getFloatFunc);
    ATTRIBUTE_INT("myIntProperty", &foo_class::setIntFunc, &foo_class::getIntFunc);
END_REFLECTION_METADATA(foo)

Немного макрос-магии и метаданные готовы. Для скорости, все строковые параметры используются вместе с хешами, вычисляемыми на этапе компиляции. Это дает реальный выигрыш в скорости по сравнению с dynamic_cast или альтернативами.

Пример использования dynamic_cast

base * base_ptr = new foo();
foo * foo_ptr = base_ptr->DynamicCast<foo>();

Плюсы и минусы библиотеки:
+ можно создавать классы по текстовому имени класса
+ получать список всех классов с метаинформацией и создавать их по метаинформации
+ получать список аттрибутов (property) для любого класса
+ быстрый dynamic_cast
+ получать метаинформацию из созданного экземпляра класса
+ аттрибуты поддерживают наследование
+ вся информация строится в compile time

- нужно писать небольшие макросы
- не поддерживается множественное наследование (для меня это фича)
- незначительно увеличивается время компиляции (нужно все таки хеши считать)

Вот несколько примеров скорости работы:

"Xenon X360 (3.2 GHz)"
-------------------
dynamic_cast 9.52M casts per second
reflection::cast 18.94M casts per second

прирост быстродействия x 1.99

"AMD 64X2 3800+ (2.0GHz)"
-------------------
dynamic_cast 12.02M casts per second
reflection::cast 35.50M casts per second

прирост быстродействия x 2.95

"Core2Duo E6750 (2.66GHz)"
-------------------
dynamic_cast 26.49M casts per second
reflection::cast 45.70M casts per second

прирост быстродействия x 1.73

Буду рад мнениям и результатам тестов - скомпилированный тест производительности лежит внутри архива. Повторяю ссылку, что бы не искать её выше по тексту. (Библиотека reflection)

UPDATE: Обновил архив, ускорил получение метаданных из указателя на объект.

Как потом выяснилось часть оверхеда была от использования D3D Effects в качестве шейдерной системы. Большое количество Load Hit Store и двойное копирование всех констант, были одной из проблем.

Итак, задача: 30 тысяч строк написанных и отлаженых шейдеров которые нельзя менять и желание иметь в runtime подобие PS3 libGCM и полностью контролировать генерацию command buffer.
Я начал рыть в сторону PrecompiledCommandBuffer т.к. там явно была возможность записать CommandBuffer и потом отправить его в GPU. К сожалению, изменять параметры у записанного CB можно очень ограниченно, поэтому данный метод не подошел.

В результате экспериментов я получил дамп памяти GPU буфера и стал его разбирать ручками. К счастью, Xenos это развитие чипа ATI R500, а на R500 документация открыта (спасибо AMD/ATI). Очень быстро был готов парсер CB, который выдавал полную информацию, о том что лежит в буфере.

Выяснилось, что часть операций которые можно делать из D3D совсем по другому мапяться в железо, да и Runtime D3D сохраняет зеркальные стейты GPU, что тоже не бесплатно. Также паралельно выяснилось, что размер CB на каждом батче слишком большой, т.к. частично шейдеры эмбедились в CB и устанавливалось очень много констант (они всегда эмбедятся в буфер).

Как результат всех эксперементов я написал компилятор на входе берущий D3D Effect файл и генерирующий из него кусочки CB (кусочки что бы можно было не сабмитить уже установленные в GPU данные), так же runtime ремапинг адресов, сабмишн данных в GPU и всякий дополнительный код.

Теперь рендер батча стал просто заполнением буфера памяти, поборовшись Load-Hit-Store на заполнении памяти и сделав кеширование CB в системной памяти (общая память CPU и GPU на X360 и на PC в режиме WriteCombined, что отключает все кеши и ведет к разным пенальти из за непоследовательной записи) я получил хороший прирост производительности.

После всех основных оптимизаций, батчи стали стоить до 4ms на кадр (вместо 25ms), профайлинг показывал узкое место на доступе к памяти (констант было от 200 до 400 на батч). У ATI GPU есть очень приятная фича, на вход микрокода вершинного шейдера приходит номер индекса, и сборка вершины происходит в шейдере с возможностью random read из потока вершин. Я переделал большинство констант на vertex stream (данные vertex stream заполнялись в другом cpu потоке) и избавился от 90% констант при отрисовке, результат: 1-2ms из секунды это расходы на отрисовку 1000 батчей, на этом и остановился.

В теории успех можно было развить дальше, т.к. можно вести отрисовку с нескольких потоков (при рендере мы просто работаем с памятью, не трогая D3D вообще, D3D нужен только для сабмишена данных в GPU) - но на текущем проекте этого не потребовалось. CPU лимит в миллион батчей в секунду кажется мне достаточным, да и PC такого не переживет - надо все таки и о второй платформе помнить.

Итого:

Было: D3D Effects + D3D runtime
0.02ms batch * 1000 = 20ms на кадр (50000 batches per second)

Стало: Своя библиотека работы с GPU:
0.001ms batch * 1000 = 1ms на кадр (1000000 batches per second)