Комментарии 48
А «space screen» — это принятая формулировка? Как-то режет глаз, все время думал что «screen-space» (ssao — screen-space ambient occlusion/obscurance).
Мне многие вещи в статье непонятны, а понять хочется. Особенно мне непонятно, когда вы говорите, что вот, мол, пример, показываете картинку, но не обьясняете на что смотреть. Был бы признателен, если бы вы дописали к картинкам комментарии, что надо искать на них, и как это что-то относится к обсуждаемой теме.
Жду не дождусь raytracing в realtime. Судя по Brigade 3, осталось совсем недолго. Причем сразу со вторичкой, или по крайней мере с AO.
Играю в GTA 5 и не парюсь. Впрочем как 4,3,2,1
А не парюсь благодаря таким умным людям, которые постоянно приближают графику к реальности.
А не парюсь благодаря таким умным людям, которые постоянно приближают графику к реальности.
По чему-то ни слова не сказано, что взрослые дяди в место
При этом прошлый HDR кадр блюрится по мипам и выбор мипа зависит от шерохофватости отражающей поверхности (ну или просто можно сделать контрейсинг).
GetColor(nuv.xy).rgb;берут цвет из прошлого HDR кадра с репроекцией текстурных координат.
При этом прошлый HDR кадр блюрится по мипам и выбор мипа зависит от шерохофватости отражающей поверхности (ну или просто можно сделать контрейсинг).
HDR в этой статье не описан и даже не затронут, репроекция координат это есть nuv. GetColor(UV).rgb — релеватно tex2D(GBufferColorMap, UV).rgb.
В классическом варианте SSLR берется текущий кадр, а не прошлый, блюр происходит после SSLR-алгоритма.
В классическом варианте SSLR берется текущий кадр, а не прошлый, блюр происходит после SSLR-алгоритма.
Текущий брать нельзя, ведь он не дорендерен. Блюрить после применения тоже нельзя — замажем то что находится под отражениями (например мостовая под лужей).
Я ведь писал в статье, что любой Screen Space эффект является пост-процессингом? А пост-процессинг выполняется после рендера основной сцены. В этом и прелесть SSLR, что можно создать локальные отражения основываясь на текущем Scene RT. А размывается не вся картинка, а только SSLR RT, которая содержит в себе информацию только об отражении.
Этот Screen Spac эффект влияет на освещение сцены, его нельзя рассматривать в вакуме. По крайне мере для честного true Physically Based Render. По этому в серьезных движках и берут прошлый HDR кадр (обязательно делая репроекцию) и заменяют им текущий Environment Specular (спекуляр от окружения, если очень упрощенно — от кубмапы).
Так ведь в статье вообще не описано освещение как таковое. Насчет Environment-отражения — где есть эффект Френеля используют RLR (SSLR), где происходит весомый Information Lost — lerp'ят отражения от статической кубмапы.
Я не совсем понимаю, причем тут прошлый HDR (и причем тут вообще идеология HDRR) кадр, если эта методика есть Screen Space post-process и завязанная на информации в уже отрендерином GBuffer (а если еще с DS, то вообще на готовой сцене с Normal и Depth картами). Можно какие-нибудь статьи про то, что вы говорите? Я правда Вас не понимаю.
Я не совсем понимаю, причем тут прошлый HDR (и причем тут вообще идеология HDRR) кадр, если эта методика есть Screen Space post-process и завязанная на информации в уже отрендерином GBuffer (а если еще с DS, то вообще на готовой сцене с Normal и Depth картами). Можно какие-нибудь статьи про то, что вы говорите? Я правда Вас не понимаю.
Вот пример — есть не освещенная комната, на полу которой мы хотим отрендерить SSLR. В итоге получим сияющий в темноте пол. А если бы мы взяли информацию с прошлого кадра, то все освещение склеилось бы.
То что описано в статье было бы приемлемо лет пять назад. Сейчас расчет освещения шагнул значительно в перед. Аппроксимации усложнились. BRDF и Physically Based Render уже несколько лет в любом «ААА» проекте.
Повторю ссылки:
www.neogaf.com/forum/showthread.php?t=557670&page=8
docs.unrealengine.com/latest/INT/Resources/Showcases/Reflections/index.html
То что описано в статье было бы приемлемо лет пять назад. Сейчас расчет освещения шагнул значительно в перед. Аппроксимации усложнились. BRDF и Physically Based Render уже несколько лет в любом «ААА» проекте.
Повторю ссылки:
www.neogaf.com/forum/showthread.php?t=557670&page=8
docs.unrealengine.com/latest/INT/Resources/Showcases/Reflections/index.html
Вот пример — есть не освещенная комната, на полу которой мы хотим отрендерить SSLR. В итоге получим сияющий в темноте пол. А если бы мы взяли информацию с прошлого кадра, то все освещение склеилось бы.
Мы очевидно говорим о разном, либо вы не понимаете. Как мы можем получить сияющий пол, если Scene RT — не содержит света вообще?
Ладно, попробую объяснить в перспективе алгоритм:
1) рисуем геометрию, строим GBuffer, получаем Color, Normal, Depth
2) строим Light map, используя Deferred Shading.
3) объеденяем Light map с Color map и получаем Scene RT
Теперь все бы ничего, у нас есть красиво освещенная комната, но хочется отражений.
4) запускаем наш SSLR, передавая туда только Scene RT, Normal, Depth и получаем SSLR map
5) размываем SSLR map с учетом веса в альфе канале.
6) объеденяем Scene RT и SSLR map с учетом свойств материала.
И спрашивается, причем тут вообще прошлый кадр? Что не отрендерино? GBuffer на стадии четыре у нас не отрендерен? Причем тут освещение вообще (про HDRR зачем-то написали)? Я правда не понимаю, о чем вы говорите. Я написал статью с рассказом о том, как происходит аппроксимации путем Deferred Rendering — отражений (а конкретно реализация SSLR-алгоритма). Заголовок статьи же не: «делаем AAA-игру за 2 минуты».
Сейчас расчет освещения шагнул значительно в перед.
Основной метод остался тем же, как и пять лет назад. Появились методики Global Illumination и Ambient Occlusion (тот же SSAO, но для удовлетворения вашего аппетита возьмем HBAO).
И да, BRDF это не один шейдер, а целый chain из пост-процессинга.
Так расскажите нам отдельной статьей :-)
Мне кажется, после отражения изображение должно быть более блеклым и тёмным. То есть не совсем нормально, когда яркость отражённой коробки больше, чем яркость оригинальной.
В жизни такое может быть, но это очень редкий эффект, который лучше избегать.
В жизни такое может быть, но это очень редкий эффект, который лучше избегать.
Мне вот интересно, когда все-же игровая графика сделает заметный революционный, а не размытый в годах эволюционный скачок? Half-Life 2, который вышел 10 лет назад выглядит ничуть не лучше современных игр, с их проблемами и артефактами.
Вы серьезно упоминаете half life 2 в контексте графики? Он уже вскоре после выхода выглядел устаревшим. Сейчас это динозавр, так же как source engine. Сейчас пришли времена physically-based rendering и какого никакого рилтаймового global illumination. Если брать half life 2, то революционный скачок на лицо. А так, все плавно и постепенно улучшается, отчего выглядит медленно и незаметно. Хороший пример недавний call of duty, который как никто другой смог приблизиться к фотореализму. Заодно это, по моему, первый коммерческий опыт использования нашумевшей технологии рендера лиц www.iryoku.com/next-generation-life
Для начала введу такое понятие как Deferred Rendering (не путать с Deferred Shading, т.к. последнее относится к освещению)
Странная фраза какая-то. Сколько не читал на эту тему, всю жизнь под Deferred Rendering подразумевался скорее общий подход к разделению рендера на стадии рендера геометрии и собственно шейдинга. Deferred Shading уже является классической реализацией в 2 прохода, которую описали вы. Альтернативная реализация, которая можно сказать уже вытеснила с рынка классическую, это light pre-pass или deferred lighting уже с 3 проходами.
Собственно, CryEngine 3, который впервые показал миру SSLR (возможно даже сами crytek являются авторами, не знаю), использует deferred lighting.
Deferred Rendering — построение GBuffer'a.
Deferred Shading — расчет освещения на основе данных GBuffer'a.
Их часто путают.
DR может включать DS, а может и не включать.
А вот DS включает в себя стадию DR всегда.
Deferred Shading — расчет освещения на основе данных GBuffer'a.
Их часто путают.
DR может включать DS, а может и не включать.
А вот DS включает в себя стадию DR всегда.
Что-то какая-то путаница.
Deferred Shading не требует предварительного препаса геометрии, по этому он будет быстрее. И как раз в CryEngine 3 перешли на него.
Вот тут хорошо расписано blog.gamedeff.com/?p=642
Deferred Shading не требует предварительного препаса геометрии, по этому он будет быстрее. И как раз в CryEngine 3 перешли на него.
Вот тут хорошо расписано blog.gamedeff.com/?p=642
Наоборот и по вашей ссылке так и написано. В CryEngine 3 использует 3-проходный light prepass. Несмотря на дополнительный проход он как раз считается более эффективным подходом нежели deferred shading. В основном из-за куда более гуманных требований к шине. Прошлое поколение консолей доминировало на рынке игр, а там это было очень важно, отчего все современные движки использовали именно deferred lighting.
Сейчас вот forward+ от AMD набирается обороты и уже засветился в парочке крупных проектов. Не знаю, что с ним там на самом деле, но из крупиц информации выглядит очень вкусно.
Сейчас вот forward+ от AMD набирается обороты и уже засветился в парочке крупных проектов. Не знаю, что с ним там на самом деле, но из крупиц информации выглядит очень вкусно.
Я дико извиняюсь, но из статьи:
Отложенное освещение требует обязательного препаса глубины. В деферед шейдинге геометрия рендерится лишь один раз. Что более гуманно к шине?
В Крайзис 2 пришли к схеме deferred lighting
aka light pre-pass rendering
Значит, новый релиз крайзиса – новый тек! Два прохода геометрии жаба душит, хочется один проход
Толстый gbuffer не хочется, хочется тонкий
Итого получился deferred shading!
Отложенное освещение требует обязательного препаса глубины. В деферед шейдинге геометрия рендерится лишь один раз. Что более гуманно к шине?
Я серьезно не понимаю о чем речь.
Что тут не так написано:
Deferred Rendering — один проход по геометрии с созданием GBuffer (Color+Normal+Depth).
Deferred Shading — один проход (рисование квада в самом простейшем случае) на один источник света с реконструированием позиции (исходя из Depth-буфера), с последующим посчетом освещения в Light Map
И собственно микс Light map с Albedo (Color). Где тут ошибка? Три прохода. На каждый DS — light pre-pass.
Что тут не так написано:
Deferred Rendering — один проход по геометрии с созданием GBuffer (Color+Normal+Depth).
Deferred Shading — один проход (рисование квада в самом простейшем случае) на один источник света с реконструированием позиции (исходя из Depth-буфера), с последующим посчетом освещения в Light Map
И собственно микс Light map с Albedo (Color). Где тут ошибка? Три прохода. На каждый DS — light pre-pass.
Deferred Shading и Deferred Lighting это две разновидности Deferred Rendering.
В Deferred Shading заполняем г-буффер, рендерим все освещение (квадом).
В Deferred Lighting делаем препроцес всей геометрии с заполнением в г-буффере карты нормалей и спекуляра. Рендерим освещение (квадом). Еще раз рендерим всю геометрию применяя к ней рассчитанное в прошлом шаге освещение.
В Deferred Shading заполняем г-буффер, рендерим все освещение (квадом).
В Deferred Lighting делаем препроцес всей геометрии с заполнением в г-буффере карты нормалей и спекуляра. Рендерим освещение (квадом). Еще раз рендерим всю геометрию применяя к ней рассчитанное в прошлом шаге освещение.
Я хоть и интересуюсь темой всех этих технологий, но ответить на ваш вопрос прямо со всеми подробностями вряд ли смогу. Вот ссылка gamedevcoder.wordpress.com/2011/04/11/light-pre-pass-vs-deferred-renderer-part-1/. Ну и сам факт, что именно на консолях именно light pre-pass стал, по сути, единственным подходом к шейдингу. Подавляющее большинство игр его использовало и именно он использует ся в cryengine 3. Хотя вот эта ссылка вносит путаницу во все это gameangst.com/?p=141 Но реальные коммерческие проекты говорят совсем не в пользу deferred shading — даже эксклюзивы той же пс3. Uncharted как раз на light pre-pass.
>Поэтому стоит хранить в карте глубины не позицию пикселя, а только глубину.
Нужно использовать аппаратную карту глубины, а не делать свой велосипед.
>Одно из правил MRT — размерность всех Render Target должна быть одинаковой.
Во-первых, не размерность, а битовая глубина (можно забиндить вместе R8G8B8A8 и RGB10A2). Во-вторых, это верно только для DX 9-level API, в DX 11 таких ограничений нет.
>position.x = UV.x * 2.0f — 1.0f;
>position.y = -(UV.y * 2.0f — 1.0f);
Такие вещи стоит зашивать в матричку
Предложенное размытие в реальной игре работать будет плохо, т. к. разные материалы будут блидить друг на друга.
Ну и главная проблема SSR — вовсе не локальность. Во-первых, SSR довольно дорого, особенно фулрез хорошего качества. Во-вторых, артефакты из-за объектов, которые не касаются пола (появляются хало и прочее) — как следствие, видимые стыки между SSR и кубмапом.
Нужно использовать аппаратную карту глубины, а не делать свой велосипед.
>Одно из правил MRT — размерность всех Render Target должна быть одинаковой.
Во-первых, не размерность, а битовая глубина (можно забиндить вместе R8G8B8A8 и RGB10A2). Во-вторых, это верно только для DX 9-level API, в DX 11 таких ограничений нет.
>position.x = UV.x * 2.0f — 1.0f;
>position.y = -(UV.y * 2.0f — 1.0f);
Такие вещи стоит зашивать в матричку
Предложенное размытие в реальной игре работать будет плохо, т. к. разные материалы будут блидить друг на друга.
Ну и главная проблема SSR — вовсе не локальность. Во-первых, SSR довольно дорого, особенно фулрез хорошего качества. Во-вторых, артефакты из-за объектов, которые не касаются пола (появляются хало и прочее) — как следствие, видимые стыки между SSR и кубмапом.
Я не очень хорошо разбираюсь в программировании и реал-тайм движках, но похожий эффект очень пригодился бы в некоторых ситуациях на посте… Например в Нюке… Такую штуку можно как плагин продавать… Нюк поддерживает пайтон (питон)… )))
Прошу прощения, если здесь это неуместно, но хотел бы поблагодарить за отличные статьи!
Тот случай, когда читаешь статью про технологии, вроде даже не старую статью, которая заканчивается словами " сейчас в реалтайме подобное (при сложной геометрии) сделать невозможно." и понимаешь, что уже возможно…
А я вот понять не могу. Если нам не хватает изображения на экране, так давайте всю сферу рендерить.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
SSLR: Screen Space Local Reflections в AAA-играх