Войти
Urho3DФорумЗАДАВАЙТЕ ВОПРОСЫ

[АРХИВ] Шейдеры, техники, rendering path'ы

Страницы: 1 2 323 24 Следующая »
#0
21:20, 27 ноя. 2015

Наверное самая сложная и запутанная часть движка, всё пытаюсь разобраться, но много мутных мест.
Материал Mushroom.xml использует технику Diff.xml и содержит строки:

<pass name="base" />
<pass name="litbase" psdefines="AMBIENT" />
<pass name="light" depthtest="equal" depthwrite="false" blend="add" />
Если оставить только
<pass name="base" />
то объект будет освещен только фоновым освщением. Это понятно и логично. Если оставить только
<pass name="litbase" psdefines="AMBIENT" />
то объект будет освещен фоновым освещением и ОДНИМ из источников света. То есть этот проход заменяет собой первый проход.
Далее, если удалить пасс litbase
<pass name="base" />
<pass name="light" depthtest="equal" depthwrite="false" blend="add" />
то объект будет освещен фоновым освещением и всеми источниками света. Зачем тут нужен пасс litbase вообще? Конечно можно предположить, что он оставлен по недосмотру, но вряд ли. В справке http://urho3d.github.io/documentation/HEAD/_materials.html написано
litbase: Renders the first per-pixel light, ambient light and fog for an opaque object. This is an optional pass for optimization.
Как лишний проход может оптимизировать рендеринг?

EDIT:
Далее в справке написано

light: Renders one per-pixel light's contribution additively for an opaque object.

Я понял эту фразу - что добавляется вклад от одного истоника света, но в примере выше видно, что на объект действуют все источники света в этом проходе.


#1
21:59, 27 ноя. 2015

Также в документации часто используется термин pingponging. Нпример

The refract pass requires pingponging the scene rendertarget to a texture,
Что он означает?

#2
22:37, 27 ноя. 2015

1vanK
> Что он означает?
Текстура обработанная шейдером снова рендериться в текстуру. Вроде так.

#3
22:40, 27 ноя. 2015

1vanK
> Как лишний проход может оптимизировать рендеринг?
Этот проход видимо не всегда рабртает, а только при наличии освещения от одного источника.

#4
2:02, 28 ноя. 2015

> Текстура обработанная шейдером снова рендериться в текстуру. Вроде так.

понятнее не стало )

#5
2:45, 28 ноя. 2015

1vanK, камера смотрит на воду, эта картинка рендерится в текстуру при этом обрабатывается шейдером реализующим преломление и далее полученная текстура проецируется на плоскость воды.
Я не смотрел еще реализацию.

#6
2:50, 28 ноя. 2015

Вот что удалось накопать (а было трудно найти что-то помимо информации о настольной игре :)

http://hub.jmonkeyengine.org/t/framebuffers-and-the-ping-pong-technique/28459
http://www.seas.upenn.edu/~cis565/fbo.htm#feedback2
http://xboxforums.create.msdn.com/forums/p/47136/282386.aspx
https://research.ncl.ac.uk/game/mastersdegree/graphicsforgames/po… rocessing.pdf
А также Source/Urho3D/Graphics/View.cpp

Если кому-то понадобится эта информация, то объясню, как я это понял. Допустим мы отрендерили сцену и результирующее изображение нужно обработать несколькими шейдерами, чтобы наложить всякие эффекты постобработки, например размытие, bloom и так далее. Но так как читать текстуру и одновременно записывать в нее нельзя, то получается цепочка:
текстура1 > шейдер > текстура2 > шейдер > текстура3 > шейдер > ...
Держать кучу текстур неэффективно, поэтому используют технику
текстура1 > шейдер > текстура2 > шейдер > текстура1 > шейдер > ...
То есть текстура-источник и целевая тексутра меняются местами.

В контексте двойной буферизации (абзац Page flipping в статье https://en.wikipedia.org/wiki/Multiple_buffering) этот термин имеет как ни странно противоположное значение. Там ping-pong обозначает метод ИЗБЕГАНИЯ пересылки данных между текстурами

EDIT: Хотя если определить пинг-понг как процесс свапа указателей, то этот термин будет обозначать одно и тоже )

#7
22:50, 28 ноя. 2015

1vanK
По твоей же ссылке нашел, имхо самое наглядное объяснение того что такое "Пинг - Понг"

#define POST_PASSES 10
for (int i = 0; i < POST_PASSES; ++i) 
{
    glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, bufferColourTex[1], 0);
    glUniform1i(glGetUniformLocation(currentShader->GetProgram(), "isVertical"), 0);
    quad->SetTexture(bufferColourTex[0]);
    quad->Draw();
    //Now to swap the colour buffers , and do the second blur pass
    glUniform1i(glGetUniformLocation(currentShader->GetProgram(), "isVertical"), 1);
    glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, bufferColourTex[0], 0);
    quad->SetTexture(bufferColourTex[1]);
    quad->Draw();
}

А кто-нибудь разбирался нахреназачем лампочки только в стеснил писать?

void Renderer::OptimizeLightByStencil(Light* light, Camera* camera)
И каким образом это оптимизирует просчет освещения ?
Нашел какой-то пример по использованию стенсила для свето-оптимизаций, наверное у ухе что-то подобное?

#8
23:12, 28 ноя. 2015

> Нашел какой-то пример по использованию стенсила для свето-оптимизаций, наверное у ухе что-то подобное?

Вряд ли, в видео про отложенное освещение (deffered), а в исходнике используется в ветке "case CMD_FORWARDLIGHTS"

#9
14:02, 29 ноя. 2015

Как я понял, почитав всякую литературу по упреждающему (forward) рендерингу, что для каждого источника света, который есть в сцене делается отдельный проход. А как я понял из справки litbase объединяет проход с фоновым освещением и одним из источников света в один проход. Но  есть ли в этом смысл? Окупается ли экономия одного прохода (и не факт, что она будет, так как есть всякие ограничения) кучей всяких проверок, сортировкой источников света и прочей возней?

EDIT: Видимо окупается, так как в юнити походу тоже самое: http://docs.unity3d.com/ru/current/Manual/RenderTech-ForwardRendering.html

* Базовый проход применяет один направленный попиксельный источник света и все повертексные/SH источники света.
  • Остальные попиксельные источники света рендерятся в дополнительных проходах, один проход на один источник света.
  • EDIT2:

    Базовый проход
    Базовый проход рендерит объект используя один попиксельный направленный источник света и все SH источники. Этот проход также добавляет любые карты освещения, освещение окружения и излучающее освещение от шейдера. Направленный свет, который рендерится в этом проходе, может иметь тени. Учтите, что объекты, к которым применены карты освещения, не получают освещение от SH источников освещения.

    Дополнительные проходы
    Каждый действующий на объект попиксельный источник света приводит к рендерингу дополнительных проходов. Источники света в этих проходах не могут иметь теней (в итоге, упреждающий рендеринг поддерживает один направленный источник света с тенями).

    А в урхо кучу направленных источников с тенями можно сделать )

    #10
    14:39, 29 ноя. 2015

    >А в урхо кучу направленных источников с тенями можно сделать )
    А в юнити разве нет? как-то делал там простую сценку и ходячим ботом но что-то не обратил внимания на это.

    >Как я понял, почитав всякую литературу по упреждающему (forward) рендерингу
    Я вот склоняюсь к тому что использование Deffered RenderPath'a предпочтительнее. т.к. батчи так катастрофически не растут с каждой новой лампочкой в сцене.

    #11
    14:51, 29 ноя. 2015

    > А в юнити разве нет? как-то делал там простую сценку и ходячим ботом но что-то не обратил внимания на это
    хз, последний раз тыткал юнити, когда там тени только в ПРОверсии были, которой у меня не было)

    >Я вот склоняюсь к тому что использование Deffered RenderPath'a предпочтительнее. т.к. батчи так катастрофически не растут с каждой новой лампочкой в сцене.
    Читаю щас http://www.gamedev.ru/code/forum/?id=85393 и что-то он мне не нравится))

    #12
    10:49, 30 ноя. 2015

    Ну при теплозрении попиксельное освещение не нужно, мне кажется отсюда и прирост фпс

    #13
    11:55, 30 ноя. 2015

    >Поэтому думаю что увлекаться шейдерами сильно не стоит.
    Напротив, стоит иначе картинка будет г. да и зная тонкости написания шейдеров можно иной раз сильно оптимизировать ту или иную прорисовку )
    Просто можно динамически управлять постпроцессом (включать и выключать пассы по тегам)
    И потом, в качестве оптимизации можно некоторые пассы (чтобы не переключать Framebuffer на другие RT каждый кадр) переделать в дополнительные MRT таргеты для записи в стандартных проходах.

    #14
    5:07, 1 дек. 2015

    Я правильно понял, что порядок пассов в технике вообще не имеет значения?

    Страницы: 1 2 323 24 Следующая »
    Urho3DФорумЗАДАВАЙТЕ ВОПРОСЫ

    Тема в архиве.