Компьютерная графика

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Компьютерная графика » Программирование графики и GPU » Важно! Обсуждение статьи про отложенное освещение.


Важно! Обсуждение статьи про отложенное освещение.

Сообщений 1 страница 30 из 113

1

http://steps3d.narod.ru/tutorials/ds-tutorial.html - вот ссылка на статью. Первую опечатку сразу вижу: в коде первых шейдеров (вершинного и фрагментного) написано "Vertex Shader for deferred shading pass 1" и "Fragment Shader for deferred shading pass 1" (всё правильно, шейдерам соответствует проход 1). Дальше в вершином шейдере написано "Vertex Shader for deferred shading pass 2", а вот фрагментном "Fragment Shader for deferred shading pass 1". Так вот, в последнем должен быть pass (проход) 2!

Это раз. Вот вторых, нельзя ли автору прочитать статью ещё раз и подкорректировать её: написанно местами странновато и оттого подозрения...

0

2

Спасибо, вечером поправлю
А вычитать конечно давно пора, ну и добавить нового материала, постараюсь.

0

3

Steps3D написал(а):

Спасибо, вечером поправлю
А вычитать конечно давно пора, ну и добавить нового материала, постараюсь.

Вечер настал - исправлений нет.

Ещё тебе подкину дров: "(а значит и убожество под названием m$ vi$ta)". Ты уж не извращайся и пиши как надо: "а значит и убожество под названием ms vista"

0

4

А есть какие-нибудь конкретные пожелания по поводу этой статьи (кроме M$) ?

0

5

Steps3D написал(а):

А есть какие-нибудь конкретные пожелания по поводу этой статьи (кроме M$) ?

Ну а как же  :D .

"(...обычно используется система координат, (связанная с камерой), ..." - зачем писать "(связанная с камерой)" в скобках?

"Другой подходж основан на том, что у нас и так уже есть информация о глубине для каждого пиксела, хранщаяся в буфере глубины"
Видишь опечатку во втором слове?

Ну а это вобщем мелочи.

На самом деле проблемы куда глубже.

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

Непонятно, зачем использовать два прохода. Причину надо отметить в статье.

Прочти пожалуйста текст около этих слов:"При этом нам достаточно вывести просто большой прямоугольник (quad) с простейшим вершинным шейдером. Фрагментный шейдер по координатам источника света, положению точки, соответствующей обрабатываемому фрагменту и нормали в этой точке, вычисляет освещенность с использованием заданной модели освещения." Здесь какой-то соскок с темы на тему:"при этом"- при чём таком этом?

Отредактировано DungeonLords (2009-05-07 21:42:04)

0

6

Опечатки правлю

>Так непонятно, зачем использовать рендинг в текстуры, ведь можно создать массив и хранить всё там.

Имеется в виду texture array ?
Насколько я помню в texture array все текстуры дорлжны быть одинакового формата, что в DS регулярно мешается. Например в STALKER:CS вообще используется два render target'а с разным чилом бит на пиксел

0

7

Steps3D написал(а):

>Так непонятно, зачем использовать рендинг в текстуры, ведь можно создать массив и хранить всё там.
Имеется в виду texture array ?
Насколько я помню в texture array все текстуры дорлжны быть одинакового формата, что в DS регулярно мешается.

Спасибо, с этим ясно.

Steps3D написал(а):

Например в STALKER:CS вообще используется два render target'а с разным чилом бит на пиксел

Ага, ты либо Моналит, либо Бармен, либо разработчик СТАЛКЕРа  :nope: .

А как насчёт этого:

Зачем использовать два прохода?

Прочти пожалуйста текст около этих слов:"При этом нам достаточно вывести просто большой прямоугольник (quad) с простейшим вершинным шейдером. Фрагментный шейдер по координатам источника света, положению точки, соответствующей обрабатываемому фрагменту и нормали в этой точке, вычисляет освещенность с использованием заданной модели освещения."
Здесь какой-то соскок с темы на тему:"при этом"- при чём таком этом?

Отредактировано DungeonLords (2009-05-08 16:52:45)

0

8

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

0

9

Steps3D написал(а):

А насчет двух проходов мне казалось все ясно - один проход строит G-буфер, а второй - накладывает освещение

Спасибо, теперь это ясно.

Кстати, ты действительно разработчик СТАЛКЕРа?

0

10

Нет
Но игра мне очень нравится

0

11

Очень жалко, что ты никак не исправишь тот кривой абзац! Может ты всё же сделаешь это? Ведь тема невероятно интересна!

Steps3D написал(а):

Нет
Но игра мне очень нравится

Мне, кстати, тоже. Но откуда такие познания по внутреннему устройству?

0

12

Есть очень хорошая статья в GPU Gems II как раз от разработчика - Deferred Shading in STALKER, сейчас она в свободной доступе на developer.nvidia.com
Кроме того на gamedev.ru был хороший разбор сталкера

0

13

Steps3D написал(а):

Есть очень хорошая статья в GPU Gems II как раз от разработчика - Deferred Shading in STALKER, сейчас она в свободной доступе на developer.nvidia.com

Вижу название и автора: http://developer.nvidia.com/object/gpu_ … ome.html#1 , но где ссылка на статью?

0

14

Вот - http://http.developer.nvidia.com/GPUGem … ter09.html

0

15

Steps3D написал(а):

Вот - http://http.developer.nvidia.com/GPUGem … ter09.html

Да, спасибо, но русскоязычный* человек мог бы писать и по русски!  :angry:  Всмысле, на Nvidia статью посылать конечно на английском, но неужели нельзя выложить внизу ссылку на английский вариант.

*- украинское наречие можно в данном случае опустить.

Но вернёмся к статье. Умоляю, скажи ДЛЯ ЧЕГО ИСПОЛЬЗУЕТСЯ ПРЯМОУГОЛЬНИК ИЗ ТОГО ЧЁРТОВОГО АБЗАЦА!!!?  :angry:

Отредактировано DungeonLords (2011-01-06 04:41:50)

0

16

Это просто способ вызвать фрагментный шейдер, отвечающий за расчет освещения, для каждого пиксела

0

17

Steps3D написал(а):

Это просто способ вызвать фрагментный шейдер, отвечающий за расчет освещения, для каждого пиксела

Погоди ка, т.е. это поверхность, которая всегда будет повёрнута лицом к зрителю? А не лучше ли тогда выводить сразу в буфер кадра?

А это вообще баян:
Ниже приводятся вершинный и фрагментный шейдеры.

//
// Deferred Shading pass 1
//

varying vec3 pos;
varying vec3 n;
varying vec3 t;
varying vec3 b;

uniform sampler2D diffMap;
uniform sampler2D bumpMap;

void main (void)
{
    vec3 nn = 2.0*texture2D ( bumpMap, gl_TexCoord [0].xy ).xyz - vec3 ( 1.0 );

    gl_FragData [0] = vec4 ( pos.z );
    gl_FragData [1] = vec4 ( normalize ( nn.x * t + nn.y * b + nn.z * n ), 1.0 );
    gl_FragData [2] = texture2D ( diffMap, gl_TexCoord [0].xy );
}

//
// Deferred Shading pass 2
//
#extension GL_ARB_texture_rectangle: enable

varying vec3 pos;
uniform vec3 lightPos;
uniform sampler2DRect posMap;
uniform sampler2DRect normalMap;
uniform sampler2DRect colorMap;

void main (void)
{
    float z  = texture2DRect ( posMap,    gl_FragCoord.xy ).r;
    vec3  n  = texture2DRect ( normalMap, gl_FragCoord.xy ).xyz;
    vec3  c  = texture2DRect ( colorMap,  gl_FragCoord.xy ).xyz;
    vec3  pp = pos * z / pos.z;
    vec3  l  = normalize ( lightPos - pp );
    vec3  v  = normalize ( -pp );
    vec3  h  = normalize ( l + v );
    float diff = max     ( 0.2, dot ( l, n ) );
    float spec = pow     ( max ( 0.0, dot ( h, n ) ), 40.0 );

    gl_FragColor = vec4 ( diff * c + vec3 ( spec ), 1.0 );

Каким боком здесь оказались текст вершинного шейдера первого прохода и фрагментного шейдера второго прохода!? Может первоначально было запланировано поместить текст вершинного шейдера 1-ого и 2-ого прохода и фрагментного шейдера 1-ого и 2-ого прохода :yep: ?

Отредактировано DungeonLords (2009-05-14 21:25:42)

0

18

С номерами проходов были опечатки, просто исправленный текст еще не готов - я хочу вставить туда новый пример.
А прямоугольник выводится именна как "срез" пирамиды видимости, чтобы в фрагментный шейдер передавались настоящие 3D координаты и по ним было легко восстановить точки по значениям из буфера глубины

0

19

Steps3D написал(а):

просто исправленный текст еще не готов - я хочу вставить туда новый пример.

Заклинаю тебя, пиши быстрее.

0

20

Если вдумчиво читать, то статья написана достаточно понятно. Если не придираться к мелочам.

Алексей, лично мне кажется, что стоило бы добавить пример с использование stencil для определения освещаемых пикселей, так как это не очень очевидно.

Так же, использование разных форматов текстур в MRT приводит к критическому падению производительность (во всяком случае на nVidia 8400GS и 9600GT). Честно взятый триал gDebugger хотспотом отмечает glClear. Конкретно на ваших примерах это не очень заметно, т.к. размер фреймбуффера невелик.
Однако на более реальных разрешениях это становится очень заметно. Оптимальным по скорости является вариант с RGBA8 targets и текстурой в GL_DEPTH24(32) (или же с depth buffer в виде render buffer), не смотря на несколько более тяжелый фрагментный шейдер второго прохода.

Отредактировано crsib (2009-05-18 20:20:21)

0

21

Добавиьт стенисл наверное действительно стоит,
не уверен что проседание производительности связанно именно с использованием разных форматов, хотя вполне возможно что не стоит мешать вместе floating-point форматы и обычные (например GL_RGBA8).

Кстати на самом деле glClear можно сильно сократить - реально он нужен только для буфера глубины и только в первом проходе - все остальное все равно будет полностью переписано. Единственная потенциальная проблема в этом случае будет небо, но его скорее всего нужно будет помечать при помощи stencil-а

Надо будет сделать хорошую сцену  и на большом разрешение профилировать ее.

0

22

glClear на depth проход хотспота и не создает. Проблема именно в очистке collor-attachments. 

Steps3D написал(а):

не уверен что проседание производительности связанно именно с использованием разных форматов, хотя вполне возможно что не стоит мешать вместе floating-point форматы и обычные (например GL_RGBA8)

Очень возможно, что так и есть, 3xRGBA16F дает значительно лучший по производительности результат нежели  R32f+LA16f+RGBA8 даже на 8400gs c 64 битной шиной памяти.

0

23

Так color attachments можно вообще не очищать, нужно только depth очистить
Насчет сравнения - попропбую погонять тесты.
Но в Вашем примере может быть проблема в другом - просто смешаны форматы с разным размером, собственно поддержка этого появилась только с G80 и вполне возможно, что хоть это и поддерживается, но не лучшим образом. Также проблема м.б. в смешиании floating-point форматов и не -fp.
Надо будет потестировать это

0

24

Форматы были одного размера, в  том то все и дело. Поддержки формата различной битности еще не появилось...
Про возможность не чистить color attachments - моя вина, не додумался)) Очистка depth buffer стоит копейки.

0

25

Про разное число битов - ошибся
Однако форматы разной битности должны держать все карты с SM4, т.е. GeForce 8xxx  и старше

0

26

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

0

27

Спасибо, исправил

0

28

Рис 5. Варианты раскладки G-буфера.

За счет этих изменений нам удалось в 4 раза сократить объем памяти под G-буфер (а значит и соответственно уменьшить fillrate).

Ниже приводятся соответствующим образом модифицироанные вершинный и фрагментный шейдеры.
Опять у тебя только два фрагментных шейдера 1-ого и 2-ого прохода! А где же вершиные!?

0

29

А вершинные шейдеры не изменились

0

30

Steps3D написал(а):

А вершинные шейдеры не изменились

Если так, зачем писать:"Ниже приводятся соответствующим образом модифицироанные вершинный и фрагментный шейдеры."? Просто напиши:"Ниже приведены соответствующим образом модифицироанные фрагментный шейдеры первого и второго прохода.  Вершинные шейдеры обоих проходов не изменились.".

0


Вы здесь » Компьютерная графика » Программирование графики и GPU » Важно! Обсуждение статьи про отложенное освещение.


создать форум