Является ли их альтернативой Stencil Pass?
На данный момент я реализовал отложенный рендеринг с использованием OpenGL, это довольно просто. Тем не менее, у меня есть серьезные проблемы с производительностью из-за использования прохода трафарета в данный момент (по крайней мере, в текущем способе, которым я его использую). В основном я использовал учебник ogldev.atspace (только 2 ссылки на пост, извините!) В качестве ссылки наряду с несколькими десятками кусочков информации из других статей.
Это работает как:
- Gbuffer pass (рендеринг геометрии и нормалей заполнения, diffuse, ambient и т. Д.)
- За каждый свет
2а) трафаретный пас
2b) световой проход - Поменять на экран
Дело в том, что использование прохода трафарета таким способом влечет за собой огромные затраты, поскольку мне нужно переключаться между режимом прохода света и режимом трафарета для каждого источника света в сцене. Так что это много государственных свопов.
Альтернативный метод без прохода трафарета будет выглядеть так:
- Gbuffer fill
- Установить световой проход
- Вычислить для всех огней
- Поменять на экран
Это позволяет избежать необходимости менять все состояния OpenGL (и очищать буфер и т. Д.) Для каждого источника света в сцене.
Я протестировал / профилировал это, используя CodeXL и базовый fps’s std :: cout’ng. Функции изменения состояния, использующие метод прохода трафарета, занимают 44% моих вызовов GL (по сравнению с 6% для прорисовки и 6% для текстур), замены / очистки буфера и т. Д. Также стоят довольно много%. Когда я перехожу ко второму методу, изменения в состоянии GL снижаются до 2,98%, а у остальных также уменьшается справедливая маржа. FPS также резко меняется, например, в моей сцене 65 источников света, динамически движущихся. Stencil Pass дает мне около 20-30 кадров в секунду, если мне повезет в режиме релиза (рендеринг занимает большую часть общего времени). Второй метод дает мне ~ 71 (рендеринг занимает меньшую часть общего времени).
Теперь почему бы просто не использовать второй метод? Ну, это вызывает серьезные проблемы с освещением, которые я не получаю с первой. Я понятия не имею, как от них избавиться. Вот пример:
2-я не трафаретная версия (она по существу истекает кровью и накладывается на вещи за пределами своего диапазона):
http://imgur.com/BNn9SP2
1-я версия трафарета (как она должна выглядеть):
http://imgur.com/kVGRwH2
Итак, мой главный вопрос: есть ли способ избежать использования прохода трафарета (и использовать что-то похожее на первый без графического сбоя) без полного изменения алгоритма на что-то вроде мозаичного отложенного рендеринга?
И если нет, то является ли это альтернативным методом отложенного рендеринга, это не слишком похоже на переход от стиля отложенного рендеринга, который я использую?
Избавление от пропуска трафарета не является для меня новой проблемой, я искал альтернативу этому примерно через 6 месяцев назад, когда впервые применил его, и подумал, что это может быть слишком большой нагрузкой на то, что у меня было в уме. Но я не мог ничего найти в то время и до сих пор не могу.
Решение
Еще одна техника, которая используется в Doom3 для освещения, заключается в следующем:
http://fabiensanglard.net/doom3/renderer.php
For each light
render the geometry affected only by 1 light
accumulate the light result (clamping to 255)
В качестве оптимизации вы можете добавить тест на ножницы, чтобы визуализировать только видимую часть геометрии для каждого источника света.
Преимущество этого по сравнению с трафаретным освещением состоит в том, что вы можете выполнять сложные расчеты освещения, если хотите, или просто сохранять простые источники света. И вся работа заключается в графическом процессоре, у вас нет избыточных изменений состояния (вы устанавливаете только 1 шейдер, только 1 vbo и каждый раз перерисовываете, изменяя только однородные параметры освещения и тестовой зоны ножниц). Вам даже не нужен G-Buffer.
Другие решения
detector