Не совсем так — спекуляр управляется двумя параметрами — яркость блика и размер блика.
На матовой хорошо отражающей поверхности будет яркий блик большого размера, на темном металле — блик будет тусклый и небольшой. Но на светлом металле блик будет небольшой, но яркий.
Поэтому либо нужны два вспомогательных канала для спекуляра (если мы используем deferred shading с g-буфером из трех текстур — можно использовать альфу диффуза и альфу нормалей), либо, если у нас нет двух «лишних» каналов — строим индекс материалов и храним в свободном канале число, по которому шейдер сможет понять, какой набор параметров использовать. Например, в движке X-Ray (который в S.T.A.L.K.E.R.'е) использовался второй подход.
В том-то и дело. Да, нашу плоскую геометрию можно считать какбы g-буфером, но построение g-буфера — это составная часть deferred-техники. А в статье она не описывается.
А раз g-буфер не строится — то уже не получится описать восстановление мировых координат по g-буферу, а это весьма любопытный момент.
Т.е. у нас тут получается строго 2D-ситуация. Неинтересно же, 3D гораздо веселее :)
Это все, разумеется, интересно и познавательно, но описанная техника не имеет никакого отношения к deferred lighting :)
Суть всех deferred-техник в разделении отрисовки на отрисовку вначале только данных геометрии, а затем — наложении освещения на отрисованную геометрию.
Поясню поподробнее.
1. На первом этапе мы отрисовываем в отдельные текстуры информацию о нормалях в каждой точке экрана и о глубине в каждой точке экрана.
Мы получаем карту глубины:
и карту нормалей:
2. На втором этапе мы, пользуясь данными из этих текстур, восстанавливаем положение точки пространства в каждом пикселе экрана, а также нормаль. Зная нормаль и координаты точки в мировом пространстве — не составляет труда посчитать освещенность этой точки. Одновременно с этим мы можем наложить теневую карту, если хотим стоить тени. Таким образом, пройдясь по всем источникам света, мы получаем карту освещения:
3. Мы объединяем карту освещения с неосвещенной геометрией:
И в итоге получаем готовую картинку:
Чем хороша такая техника?
Тем, что освещение в каждом пикселе считается единожды. Вся невидимая геометрия отсекается на этапе построения буфера геометрии. Если бы мы использовали обычный forward lighting — пришлось бы для каждого источника света заново отрисовывать каждый объект. Если источников света много — видеокарточка просто захлебнется.
Поэтому, используя deferred-технику, можно отрисовывать в каждом кадре дикое число источников света (тысячи) с человеческой производительностью. А столько источников света позволяют получить сложные визуальные эффекты — как пример, таким образом можно реализовать непрямое освещение.
Чем же плоха такая техника?
1. Повышаются требования к пропускной способности видеопамяти, т.к. нам теперь приходится, в нагрузку к всему прочему, еще и текстуры буфера геометрии, а они достаточно большие, т.к. по размеру равны размеру экрана.
2. Как несложно понять — deferred-техники фактически вычисляют освещение некой сплошной поверхности. Т.е. если у нас некоторые объекты полупрозрачны — мы не сможем их отрисовать, потому что нам потребуется считать в одном и том же пикселе сразу две освещенности: для полупрозрачного объекта, и для того объекта, который находится за ним. А если у нас за одним полупрозрачным объектом находится еще один полупрозрачный… Этот недостаток обходится, но…
3. В реальности карты нормалей и карты глубины не хватает — нужна еще карта материалов. Дело в том, что на соседних пикселях могут находится объекты с совершенно разными материалами — один, к примеру, блестящий металлический, а другой — матовый пластиковый. И чтобы мы могли корректно вычислить освещенность — нам придется хранить дополнительную карту, считывать в шейдере ее значение и в зависимости от него использовать разные формулы.
Приведу примеры игр с deferred shading и deferred lighting: S.T.A.L.K.E.R. (только в режиме динамического освещения), Crysis 2 (в первом Crysis освещение было прямым), Метро 2033. Список, разумеется, неполный :)
А в данной статье, по факту, рассматривается обычный forward shading с простейшей оптимизацией — просчет более одного источника света за проход (кстати говоря, движок Crysis использовал именно такую технику).
Автору: статья-то хорошая, но озаглавлена некорректно :) Ждем новой статьи, тем более что поднятая тема весьма любопытна для многих, я уверен :)
дизан дигга - движок - плигга, причем ничем особенным не отличающийся, ни одной новой примочки. даже стандартная функциональность обрезана. можно на такой машине далеко уехать?
На матовой хорошо отражающей поверхности будет яркий блик большого размера, на темном металле — блик будет тусклый и небольшой. Но на светлом металле блик будет небольшой, но яркий.
Поэтому либо нужны два вспомогательных канала для спекуляра (если мы используем deferred shading с g-буфером из трех текстур — можно использовать альфу диффуза и альфу нормалей), либо, если у нас нет двух «лишних» каналов — строим индекс материалов и храним в свободном канале число, по которому шейдер сможет понять, какой набор параметров использовать. Например, в движке X-Ray (который в S.T.A.L.K.E.R.'е) использовался второй подход.
А раз g-буфер не строится — то уже не получится описать восстановление мировых координат по g-буферу, а это весьма любопытный момент.
Т.е. у нас тут получается строго 2D-ситуация. Неинтересно же, 3D гораздо веселее :)
Суть всех deferred-техник в разделении отрисовки на отрисовку вначале только данных геометрии, а затем — наложении освещения на отрисованную геометрию.
Поясню поподробнее.
1. На первом этапе мы отрисовываем в отдельные текстуры информацию о нормалях в каждой точке экрана и о глубине в каждой точке экрана.
Мы получаем карту глубины:
и карту нормалей:
2. На втором этапе мы, пользуясь данными из этих текстур, восстанавливаем положение точки пространства в каждом пикселе экрана, а также нормаль. Зная нормаль и координаты точки в мировом пространстве — не составляет труда посчитать освещенность этой точки. Одновременно с этим мы можем наложить теневую карту, если хотим стоить тени. Таким образом, пройдясь по всем источникам света, мы получаем карту освещения:
3. Мы объединяем карту освещения с неосвещенной геометрией:
И в итоге получаем готовую картинку:
Чем хороша такая техника?
Тем, что освещение в каждом пикселе считается единожды. Вся невидимая геометрия отсекается на этапе построения буфера геометрии. Если бы мы использовали обычный forward lighting — пришлось бы для каждого источника света заново отрисовывать каждый объект. Если источников света много — видеокарточка просто захлебнется.
Поэтому, используя deferred-технику, можно отрисовывать в каждом кадре дикое число источников света (тысячи) с человеческой производительностью. А столько источников света позволяют получить сложные визуальные эффекты — как пример, таким образом можно реализовать непрямое освещение.
Чем же плоха такая техника?
1. Повышаются требования к пропускной способности видеопамяти, т.к. нам теперь приходится, в нагрузку к всему прочему, еще и текстуры буфера геометрии, а они достаточно большие, т.к. по размеру равны размеру экрана.
2. Как несложно понять — deferred-техники фактически вычисляют освещение некой сплошной поверхности. Т.е. если у нас некоторые объекты полупрозрачны — мы не сможем их отрисовать, потому что нам потребуется считать в одном и том же пикселе сразу две освещенности: для полупрозрачного объекта, и для того объекта, который находится за ним. А если у нас за одним полупрозрачным объектом находится еще один полупрозрачный… Этот недостаток обходится, но…
3. В реальности карты нормалей и карты глубины не хватает — нужна еще карта материалов. Дело в том, что на соседних пикселях могут находится объекты с совершенно разными материалами — один, к примеру, блестящий металлический, а другой — матовый пластиковый. И чтобы мы могли корректно вычислить освещенность — нам придется хранить дополнительную карту, считывать в шейдере ее значение и в зависимости от него использовать разные формулы.
Приведу примеры игр с deferred shading и deferred lighting: S.T.A.L.K.E.R. (только в режиме динамического освещения), Crysis 2 (в первом Crysis освещение было прямым), Метро 2033. Список, разумеется, неполный :)
А в данной статье, по факту, рассматривается обычный forward shading с простейшей оптимизацией — просчет более одного источника света за проход (кстати говоря, движок Crysis использовал именно такую технику).
Автору: статья-то хорошая, но озаглавлена некорректно :) Ждем новой статьи, тем более что поднятая тема весьма любопытна для многих, я уверен :)