Варианты хранения запечённого света

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

1. Лайтмапы.
Мне неизвестен ни один автоматический разворачивальщик, который бы давал кач-во ручной работы. Все знакомые артисты, имеющие опыт с лмапами, парились как над улучшением развёрток, так и над самой геометрией (чтобы все стены ровно стыковались, свет нигде не "протекал"). Также на форуме есть человек (Ruslan), занимавшийся своим лайтмаппером довольно долго - он тоже делал много ручной работы и на одном автомате не мог выехать. Особенно часто авто анврапперы лажают с гладкой неквадратной геометрией типа статуй и деревьев. Если в старых играх геометрия был простая, то сегодня весь этот гемор умножается на 10.
Далее, у лайтмапов есть мерзкие швы, когда на одном объекте стыкуются 2 разных куска текстуры. Самые страшные исправляются простым расширением этих кусков на несколько пикселей, но остаются другие из-за отсутствия билинейной фильтрации между двумя кусками. Сблендить этот шов дело непростое, ибо с разных сторон может быть разная плотность текселей, как минимум просто неровный стык.
В Ласт Оф Ас как-то решали эти швы: http://miciwan.com/SIGGRAPH2013/Lighting%20Technology%20of%20The%… 20Of%20Us.pdf
Но что-то у меня не удалось это повторить - маловато инфы об имплементации, или я лох.
Итого:
+ Легко хранить/стримить.
+ Легко семплировать.
+ Можно довольно эффективно хранить данные, если постараться.
- Если не постараться, можно получить много дыр и ниже плотность текселей где надо = плохое использование памяти.
- Если не постараться, можно получить много швов.
- Моделлер должен иметь хороший опыт работы с лайтмапами (либо отдельный человек сидеть и фиксить модели под лайтмаппинг).

2. Повертексные лайтмапы.
Сойдёт, когда вертексов дофига. Также можно адаптивно разбивать сетку в зависимости от детальности света.
+ Не нужна развёртка.
- Без адаптивного разбиения кач-во сильно зависит от геометрии вплоть до того в какую сторону квады триангулированы в каком месте.
- С адаптивным разбиением теряем инстансинг, получаем дохрена вертексов, микроскопических треугольников и прочей жути.

3. Грид.
Печём всё в 3д текстуру.
+ Не зависит от геометрии и юв.
- Много неюзанного пространства. Гигантские объёмы данных.
- Низкая точность.
- Семплирование дороже способов выше.
- Протекание света, особенно очевидно с тонкими стенками.

4. Лайтпробы.
Нерегулярно расставленные точки, в которых записан свет, образуют тетраэдры, внутри которых мы их интерполируем. Где-то интерполируют на центр каждого объекта на цпу (юнити), где-то аж повертексно на гпу, например в Infamous: Second Son: https://www.copy.com/s/9OmMJE9ngVPj/GDC14_infamous_second_son_eng… pdf%3Boid%3A2
Попиксельно, говорят, слишком медленно.
+ Не нужна развёртка.
+ Памяти жрёт мало.
- Те же требования к геометрии, что при бейке в вертексы.
- Эффективно имплементировать повертексно нетривиально.
- Семплирование дороже способов выше.
- Низкая точность.

5. Ptex?
http://ptex.us/
Текстуры хранятся без юв, на треугольниках.
+ Не зависит от геометрии и юв.
+ Вроде как не хранит ничего лишнего и не имеет дыр.
- Никто не юзает в играх - неспроста?
- Слышал слухи, что на гпу их алгоритм вообще плохо ложится - семплирование может быть довольно дорогим.
патентнованый и медленный

Что юзаете вы?
Знаете ли какие-то ещё варианты?
-----
Вариант полностью реалтайм света не рассматриваем

Ох, интересная тема. О, Ptex что-то не встречал раньше.

ASD
> 5. Ptex?
> http://ptex.us/
> Текстуры хранятся без юв, на треугольниках.
ptex работает только с квадами.

А есть объекты, для которых нужно подобие динамического освещения?

bazhenovc
вроде слышал о каких-то вариантах с трианглами. ну и моделить квадами не так проблематично.

Che@ter
да, но это отдельная история. их значительно меньше, и зона их перемещения ограничена.

Mr F
> 5. Ptex?

- патентован. https://patentscope.wipo.int/search/en/detail.jsf?docId=WO2009012464

Нам в принципе пока по фиг, но если продукт окажется в steam/*store/etc могут быть проблемы.

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

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

Там будет храниться что-то типа токго:

Che@ter
> которые генерируются автоматически
Mr F
> Мне неизвестен ни один автоматический разворачивальщик, который бы давал кач-во
> ручной работы.

Che@ter
> Это решит проблему стыковок текстур, швов и прочего.
как?

Mr F
Просто тут мы уже вроде не привязаны к текстурным координатам альбедо текстур и можем делать впринципе что угодно не изменяя при этом старые текстурные координаты.

Можно попдеобней про 3 технику? Может какие модификации есть для устранения основных недостатков? Её официальное название хотя бы для поиска соответствующих статей? Ничего про нее не слышал ранее, но в голове недавно закрутился похожий алгоритм, хотел свелосипедить его, а тут оказывается все за меня придумали)))

Che@ter
тут привязаны к новым ЮВ, которые эффективно задать - проблема (автоматы плошают)

AMM1AK
имеется в виду любая вариация на тему 3д текстуры со светом вокруг сцены.
в фаркрае3 на лету вокруг камеры подобную обновляют, в крайенжине LPV тоже в какой-то мере таковым является, но опять же обновляемый реалтаймно.
ах да, ещё называют такое irradiance volumes

Mr F
Я так понимаю, это преимущественно для динамически перемещающихся объектов по сцене пригодный способ, так как для статики те же лайтмапы дадут в разы качественный результат? Что сам можешь сказать про эту технику? Стоит она траты времени на нее? Спрашиваю, потому что хотел встраивать её в свой велосипед в ближайшее время для освещения динамических объектов. Для не цветного света 1 байта на узел за глаза хватит, по-моему.

AMM1AK
> это преимущественно для динамически перемещающихся объектов
юзают и для статики, для всего разом
только что подкинули ещё вот: http://advances.realtimerendering.com/s2015/SIGGRAPH_2015_Remedy.pdf
там хитро, не равномерный грид, а адаптивно делится, но воксели все равно хранят здоровенного размера.

AMM1AK
> те же лайтмапы дадут в разы качественный результат?
да

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

AMM1AK
> для освещения динамических объектов.
для динамических пойдёт определённо

Mr F
Спасибо за развернутый ответ. Пдф посмотрю обязательно дома с компа))