HDR это текущее значение буфера освещения. Туда например записывается информация для само-светящихся объектов и для global illumination.
RGBE/RGBM там к сожалению использовать нельзя, т.к. нужен аддитивный блендинг в этот таргет.
Мы сейчас пробуем еще ужать G-Buffer, например используя технику сжатия base color в два канала (YCoCg) как описано в статье The Compact YCoCg Frame Buffer. В данный момент я уверен — наша текущая раскладка G-Buffer не финальная и мы будем её еще ужимать.
Мягкая тень или резкая это зависит от настроек которые сделали художники и от настроек качества графики — мягкие тени более дорогие для производительности.
Я на самом деле точно не помню какие именно настройки в первых картинках влияют на тени. Это либо настройки источников света либо настройки качества при снятии скриншота.
Мы сейчас практически все усилия направляем на оптимизацию, мы снимаем очень много метрик с ЗБТ который идет в данный момент и используем эти данные для оптимизации игры.
На мобильных видеокартах поведение к примеру оказалось не таким как мы расчитывали. Это для нас отдельный и очень важный фронт работ сейчас.
Да, возможно использовать еще один R32F RT и рисовать в него линейную глубину.
Проблема в overdraw при заполнении G-Buffer. Во время заполнения G-Buffer, overdraw обычно больше 1, иногда значительно (например: деревья, трава и т.п.)
Это значит, что информация о глубине будет записана для каждого пикселя больше одного раза, а это неэффективное использование bandwidth.
В случае же «линеаризации» отдельным проходом, мы получаем гарантии, что запись в R32F текстуру будет выполнена один раз для каждого пикселя.
В настоящий момент мы используем Modified AMD Cubemapgen и в нем Cosine filter и наша аналитическая модель освещения полностью совпадает с IBL частью освещения.
У него только один недостаток — очень долгое время работы. Есть несколько альтернатив и презентация от tri-Ace как это делать быстрее.
Если хранить нормали во ViewSpace то точность упаковки нормалей будет изменяться если вращать камеру. Для больших плоскостей (например пол) это выглядит бажно — вращаешь камеру, чуть плавает освещение.
Roughness для типичных материалов у нас указан в гайдлайне для художников. Насколько мне известно в «справочниках» таких данных нет, но можно попробовать использовать MERL BRDF Database и Disney's BRDF explorer что бы подобрать физичные значения.
Картинка в шапке это арт из игры. Что бы получить этот арт персонаж был выставлен в специальную позу в движке и картинка была отрендерена в движке, а после дорисована художниками.
Остальные картинки и видео это рендер движка. В некоторых картинках рендер на ultra high настройках, в некоторых просто на high.
Лучше поздно чем никогда :) вот способ как сделать реверс z-буфер в OGL
https://nlguillemot.wordpress.com/2016/12/07/reversed-z-in-opengl/
Export cost can be more costly than PS execution!
Each fast export is equivalent to 64 ALU ops on R9 290X
Обычно память (особенно на запись, где кеш не помогает) более ограниченный ресурс чем ALU, в том числе и на встроенных/мобильных GPU.
RGBE/RGBM там к сожалению использовать нельзя, т.к. нужен аддитивный блендинг в этот таргет.
Мы сейчас пробуем еще ужать G-Buffer, например используя технику сжатия base color в два канала (YCoCg) как описано в статье
The Compact YCoCg Frame Buffer. В данный момент я уверен — наша текущая раскладка G-Buffer не финальная и мы будем её еще ужимать.
Я на самом деле точно не помню какие именно настройки в первых картинках влияют на тени. Это либо настройки источников света либо настройки качества при снятии скриншота.
На мобильных видеокартах поведение к примеру оказалось не таким как мы расчитывали. Это для нас отдельный и очень важный фронт работ сейчас.
Проблема в overdraw при заполнении G-Buffer. Во время заполнения G-Buffer, overdraw обычно больше 1, иногда значительно (например: деревья, трава и т.п.)
Это значит, что информация о глубине будет записана для каждого пикселя больше одного раза, а это неэффективное использование bandwidth.
В случае же «линеаризации» отдельным проходом, мы получаем гарантии, что запись в R32F текстуру будет выполнена один раз для каждого пикселя.
У него только один недостаток — очень долгое время работы. Есть несколько альтернатив и презентация от tri-Ace как это делать быстрее.
Roughness для типичных материалов у нас указан в гайдлайне для художников. Насколько мне известно в «справочниках» таких данных нет, но можно попробовать использовать MERL BRDF Database и Disney's BRDF explorer что бы подобрать физичные значения.
Остальные картинки и видео это рендер движка. В некоторых картинках рендер на ultra high настройках, в некоторых просто на high.