Войти
ПрограммированиеФорумГрафика

Как вы управляете источниками света в своём движке?

Страницы: 1 2 Следующая »
#0
16:19, 25 июля 2015

У меня в движке нет никакой системы освещения, а я просто руками передаваю во все шейдеры параметры источников света. Очевидно, что так жить нельзя, и это должен делать движок. Но тогда нужно всё продумать и сделать так чтобы он самостоятельно разруливал любое количество источников света.

Давайте рассматривать только forward rendering. Есть в сцене набор объектов и набор источников света. Источников в сцене, допустим, 50 штук, но видно действие всегда только малой части из них. Много чего приходит в голову, но не знаю, что из этого эффективнее. Проверять это всё самому слишком долго, да и всё равно везде протестируешь.

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

Второй вариант - сделать большое максимальное число источников света и цикл с переменным числом итераций, определяемым uniform'ом. На Radeon HD 6310M фиксированное число было заметно быстрее, чем передавать то же число источников через uniform. Видимо, это из-за того, что с uniform'ом компилятор не может развернуть цикл. Но может на других видеокартах нет разницы? Но меня интересуют также мобильные платформы уровня GLES 3.0, там наверное разница будет только больше.

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


Второй вопрос, как лучше, один универсальный массив и цикл по нему для всех типов источников света? Или отдельные массивы и циклы для точечных, направленных и spot light? Первый вариант гораздо удобнее и гибче, но в нём придётся делать проверку лишних условий в цикле. Насколько страшны эти проверки?

Третий вопрос, не просядет ли производительность, если все источники света в сцене запихнуть в один UBO, а объектам передавать только индексы источников, влияющих на них? Насколько быстро работает доступ по индексу в UBO, если:
1) этот индекс передаётся через uniform
2) вычисляется на основе выборки из текстуры, но результат при этом совпадает для большой группы соседних фрагментов (порядка 100-1000)


#1
17:04, 25 июля 2015

По аналогу многих движков у меня есть без форменная иерархия объектов матриц, которые можно заставить функционировать как угодно.
Отдельно я приделал систему менеджера световых источников - этих менеджеров может быть условно сколько угодно и они могут обслуживать любой комбинационный набор источников света.
Физический объект можно подключить к одному из таких менеджеров независимо от материала и его реализации или шейдера.
Но во время отрисовки одного объекта материал и шейдер и все остальное взаимодействуют только с одним его менеджером световых источников - это взаимодействие полностью зависит от основного контроллера объекта или шейдера, который реализуется в самом проекте.

Таким образом я могу воспользоваться стандартной системой освещения glLigth реализуя для определенного класса объектов, или любую другую схему отрисовки обьеденяя все источники света в один менеджер и имея таким образом единый массив источников света.
Или разделять источники освещения распределяя нагрузку по досягаемости света до объекта, или упираясь в технические ограничения делить их на небольшое количество.

#2
17:43, 25 июля 2015

foxes
> без форменная иерархия объектов матриц
Не получилось распарсить, что это? При чём тут матрицы?

foxes
> Физический объект можно подключить к одному из таких менеджеров независимо от
> материала и его реализации или шейдера.
Не понял, а что вообще делает менеджер? Он знает о способе отрисовки объекта, сколько и каких источников умеет рисовать шейдер? Другими словами, туда можно пихать любые объекты, или только с одной реализацией шейдера освещения?

#3
18:15, 25 июля 2015

gammaker
> числом итераций, определяемым uniform'ом
gammaker
> уровня GLES 3.0
если не ошибаюсь, динамическая индексация в пиксельных шейдерах там не держится.
как вариант - находить 2-3 ближайших лайта в VS, дальше шейдить их в PS константным кодом (ну или вообще всё в VS делать, но это не айс).

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

#4
18:45, 25 июля 2015

Mr F
> если не ошибаюсь, динамическая индексация в пиксельных шейдерах там не
> держится.
С GLES 2.0 не путаешь? А то 3.0 - это уже почти DX10-железо. К тому же там вроде унифицированная архитектура и по идее всё это должно быть.

Mr F
> как вариант - находить 2-3 ближайших лайта в VS, дальше шейдить их в PS
> константным кодом (ну или вообще всё в VS делать, но это не айс).
Идея интересная, подумаю на эту тему. Но если в сцене источников много, например штук 100, то перебирать их наверное будет затратно даже для VS. Хотя можно на CPU отсечь заведомо не влияющие. Но всё-таки надо сделать, чтобы и с низкополигональными моделями работало. А то пользователь загрузит какую-нибудь стороннюю модель уровня с очень большими полигонами, а там лайты будут дёргаться.

Видел у хумуса пример clustered lighting. Там вводят трёхмерную сетку и хранят список источников света, которые действуют в каждой ячейке. Пиксельный шейдер читает индексы источников в кластере из 3D текстуры. Получается, что если источники движутся, надо будет каждый кадр обновлять 3D текстуру, хотя бы частями. Но несмотря на это, на GTX 755M это совсем не тормозит: 22 источника света выдают 650 FPS. Недостатков, как у Deferred Shading'а нет, производительность хорошая, и других недостатков не видно. Неужели это панацея от всех проблем с освещением и deferred уже можно отправлять на свалку?

#5
19:38, 25 июля 2015

gammaker
Как вариант записать источники света в volume map (скажем RGB 64x64x64) наложенную на всю видимую сцену.
Но есть пара моментов:
1. Не совсем тривиальная задача - вычислить интерполированные цвета вокселей этой текстуры,
видимо каждый источник должен знать положение ближайших к нему (например спереди, сзади, слева, справа, сверху, снизу).
2. Будет проблема с динамическими источниками.

#6
19:39, 25 июля 2015

упс, опоздал )

#7
19:51, 25 июля 2015

nes
> 1. Не совсем тривиальная задача - вычислить интерполированные цвета вокселей
> этой текстуры
А что там интерполировать? Просто закодировать индекс источника света в массиве в воксель целочисленной текстуры. В соседних вокселях может конечно получиться скачок, но если сделать побольше источников на воксель (штуки 4 наверное хватит), отсортированных по своему вкладу с ограниченным радиусом, то наверное будет незаметно.

nes
> видимо каждый источник должен знать положение ближайших к нему (например
> спереди, сзади, слева, справа, сверху, снизу).
Не понял, зачем это?

#8
20:04, 25 июля 2015

gammaker
>Просто закодировать индекс источника света в массиве в воксель целочисленной текстуры.
Тогда какой профит от такой текстуры?
Зачем индекс, если нам нужно получить интерполированный цвет от нескольких источников?

>Не понял, зачем это?
Чтоб вычислить конечный цвет воксела, учитывая интенсивности ближайших источников света.

#9
20:15, 25 июля 2015

nes
> Тогда какой профит от такой текстуры?
Чтобы освещать не всеми источниками света в сцене, а только теми, которые действуют на воксель, независимо от геометрии освещаемого объекта.

nes
> Зачем индекс, если нам нужно получить интерполированный цвет от нескольких
> источников?
И что это будет за свет? Ambient что ли? Как таким образом сделать ламберта и спекуляр?

#10
21:09, 25 июля 2015

gammaker
>И что это будет за свет? Ambient что ли? Как таким образом сделать ламберта и спекуляр?
Это наверное будет specular color.

#11
21:52, 25 июля 2015

gammaker
> Не получилось распарсить, что это? При чём тут матрицы?
Как основа позиционирования любых объектов в пространстве, источник света или освещаемая поверхность.
gammaker
> Не понял, а что вообще делает менеджер?
следит за существованием объекта, создает удаляет источник света или выдает полный список управлемых источников света данным менеджером, избавляет от всей виртуальной части слежения и работы с объектом. Говоря человеческим языком некий массив (ассоциативный список или вектор).
gammaker
> Он знает о способе отрисовки объекта,
есть способы которые определяются заранее и есть в движке, а есть алгоритмы которые ты сам определяет уже в контроллере объекта который вешается на ту самую "матрицу" на которую также вешается меш.
gammaker
> сколько и каких источников умеет рисовать шейдер?
Сколько реализуешь в подключаемом шейдере и сколько сможешь передать через контроллер освещаемого объекта столько и будет.
gammaker
> Другими словами, туда можно пихать любые объекты, или только с одной
> реализацией шейдера освещения?
определяется контроллером объекта. для каждого объекта можно создавать свой контроллер или как класс объектов.
objects_ligth_system | Как вы управляете источниками света в своём движке?

стандартный контроллер света
менеджер источников света
стандартный контроллер объекта

#12
21:05, 8 авг. 2015

Решил посмотреть как там сделано в Unity и офигел: зачем делать по одному проходу на каждый пиксельный источник света? Сделали бы хотя бы несколько вариантов шейдеров на 1, 2 и 4 источника и выбирали бы подходящий. Или шейдер, поддерживающий любое количество источников. Зачем выбирают самый тормозной вариант?

#13
22:16, 8 авг. 2015

У меня источники света присваиваются материалу, а не мешу :)
С одной стороны не логично, с другой, больше возможностей для комбинирования материалов.

#14
22:34, 8 авг. 2015

bodja
> У меня источники света присваиваются материалу, а не мешу :)
> С одной стороны не логично, с другой, больше возможностей для комбинирования
> материалов.
Ужас. А в чём заключаются возможности комбинирования материалов?

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

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

Сейчас смотрю, как сделано в Unity. Оказывается, в старых версиях примерно так и было, а в пятую версию добавили убершейдер, где наоборот под каждый материал подбирается свой наиболее подходящий шейдер.

Страницы: 1 2 Следующая »
ПрограммированиеФорумГрафика

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