Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Suslik против Global Illumination (3 стр)

Suslik против Global Illumination (3 стр)

Страницы: 1 2 3 4 513 Следующая »
Panzerschrek[CN]Участникwww2 июня 201718:36#30
Suslik

А не пробовал ли ты такую технику:
переотражённое освещение запекается в низкодеталилированные светокарты и лайтпробы. Прямое освещение считается как обычно.

Пример работы:

+ Показать

Правка: 2 июня 2017 19:00

SuslikМодераторwww2 июня 201718:49#31
Panzerschrek[CN]
это самый банальный вариант, я его даже не рассматриваю, потому что если есть возможность запекать, то тут и обсуждать нечего — надо запекать.
Panzerschrek[CN]Участникwww2 июня 201719:03#32
Suslik
> это самый банальный вариант, я его даже не рассматриваю, потому что если есть
> возможность запекать, то тут и обсуждать нечего — надо запекать.

Тогда не понятно, для чего ты ищёшь способ глобального освещения.

Как я понял, тебе нужны техники, работающие в реальном времени. Значит, нужны они для какой-то игры. А что может быть за игра, где не хватит предрассчитанного света, я не очень понимаю. Разве только что-нибудь очень суровое со 100% изменяющимся окружением и с динамической сменой времени суток, типа Майнкрафта.

SuslikМодераторwww2 июня 201719:15#33
Panzerschrek[CN]
я уже писал кучу раз, что у нас одни и те же текстуры используются на разных объектах, а лайтмапы должны быть для каждого объекта уникальные. плюс текстуры тайлятся, а развёртки должны быть специальные, в которых каждый текстурный тексель используется всего один раз. плюс это в любом случае подходит только для статики, а я хочу для всех объектов, включая анимированные. наконец, источники освещения бывают динамические — фаерболлы всякие и тому подобное.
Battle Angel AlitaПостоялецwww2 июня 201719:26#34
Panzerschrek[CN]
Динамическое GI это просто круто. Технический челлендж.
Ну и недостатков у запечёных теней куча - занимают кучу места, а если лайтмапы продвинутые - то кучу * 5, постоянные проблемы с развёрткой и паддингом, долго ждать пока запечётся. Ну и самый страшный тест для лайтмап - разбить лампочку. Если в твоём лайтмаппере невозможно корректно разбить лампочку - он не нужен.
Panzerschrek[CN]Участникwww2 июня 201719:26#35
Suslik
> я уже писал кучу раз, что у нас одни и те же текстуры используются на разных
> объектах, а лайтмапы должны быть для каждого объекта уникальные. плюс текстуры
> тайлятся, а развёртки должны быть специальные, в которых каждый текстурный
> тексель используется всего один раз

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

> наконец, источники освещения бывают динамические — фаерболлы всякие и тому
> подобное

Фаерболы и без вторичного освещения нормально будут смотреться. Никто там особо не будет вглядываться.
Для "динамических" источников света типа включающихся/выключающихся лампочек можно добавлять ещё один слой светокарты для близких к таким источникам объектов. Так делали ещё в Quake.

PS:
Кстати, в "The Last of Us" используются светокарты. Описанные тобой проблемы они с развёртками смогли побороть: http://miciwan.com/SIGGRAPH2013/Lighting%20Technology%20of%20The%… 20Of%20Us.pdf

Правка: 2 июня 2017 19:36

Panzerschrek[CN]Участникwww2 июня 201719:27#36
Battle Angel Alita

> Динамическое GI это просто круто. Технический челлендж.

Ну если только крутость нужна ради самой крутости, а не для практического применения.


> и самый страшный тест для лайтмап - разбить лампочку.

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

SuslikМодераторwww2 июня 201720:09#37
Panzerschrek[CN]
> Да, это дополнительная работа, но это не сверхсложно.
"дополнительная работа" в моём случае — это сделать дополнительную развёртку для 60Гб визуальных ассетов. причём вся статика by design — тайлы, то есть если на каждый тайл заводить уникальную текстуру, то весь смысл тайловой геометрии теряется.

Правка: 2 июня 2017 20:10

Dmitry_MilkПостоялецwww2 июня 201723:43#38
Насчет статики: если вести речь только про статические окклюжны и не меняющие положения (но могущие менять яркость/цвет) источники, то нельзя ли просто для каждого источника описать некоторую "область достижимости" как некий многогранник из клип-плоскостей вокруг источника? то есть эдакий "векторный лайтмап"? Можно также рассматривать это как path tracing, но проверка пересечения уже будет делаться не с полигонами сцены, а с наборами клип-плоскостей, которых для неподвижного источника и статических окклюжнов будет скорей всего не так уж и много...

Правка: 2 июня 2017 23:43

BelfegnarПостоялецwww3 июня 201712:47#39
Suslik
> + сцена должна быть полностью динамической, никакого precompute bullshit'а
Даешь процедурную геометрию и сфер-трейсинг! Нет предзапеченым каркасам и богомерзким треугольникам!
Ну серьезно, где заканчивается работа прекомпьютобогов и начинается прекомпьют булщит? Например, хранение bvh это булщит? А если bvh per mesh? Ну и можно же его еще параллельно для физики использовать и какого-нибудь куллинга.
После ISM были еще ManyLoDs:

Правда, нужон bvh. А для динамиков его еще и апдейтить нужно, но в "lazy-режиме" вроде не смертельно. В пайпере они сравнение с ism приводят:
ManyLoDs | Suslik против Global Illumination
Но тема как-то затухла

Правка: 3 июня 2017 12:48

Panzerschrek[CN]Участникwww3 июня 201713:56#40
Suslik
> так что следующим шагом уже просто попытаюсь впилить в наш проект

А вот это уже будет интересно.
Как впилишь - закинь в эту тему скриншотов. Ну и заодно скриншотов без всебощего освещения, для сравнения.

bodjaПостоялецwww3 июня 201714:59#41
Suslik
> а лайтмапы должны быть для каждого объекта уникальные. плюс текстуры тайлятся,
> а развёртки должны быть специальные, в которых каждый текстурный тексель
> используется всего один раз
Ента штука называется лайтмапа с ЮВ2.
Кстати сделать дополнительную сетку и запечь лайтмапу не так уж и сложно, по крайней мере намного проще чем с текстурами работать.
Ну и светят фаерболы на лайтмапу тоже норм :)
Это я о чем :)
Как там дела с освещением персов? :)
У меня ничего умнее, чем делать карты на каждый "этаж" в голову не пришло.
Che@terПостоялецwww3 июня 201715:45#42
Suslik
Слушай, а вот твой SSGI может дополнительно выдать значение полноты для каждого пикселя? Или даже какую-либо функцию заполненности пространства? Чтобы в будущем сблендить результат с wolrd space техниками.

И очень инетерсует этот момент:
> Алгоритм по факту считает вторичное освещение всех пикслеей framebuffer'а на
> все пиксели
Это какая-то общая техника "прохода по всем пикселям" или она работает чисто из-за специфики просчета этих пикселей (обычная сумма например)?
Я с подобным никогда не сталкивался и хотелось бы узнать за счет чего это достигается.
Выборка по всему экрану? Если так, то сколько получается выборок на пиксель и сколько нужно кадров, чтобы захватить все? Выборки равнораспределены по радиусу или полный рандом?

g-contПостоялецwww3 июня 201716:07#43
С глобальным освещением за все эти годы помоему перепробовали абсолютно все возможные варианты и методы подхода. И с предрасчётами и фуллдинамик и с сетками и с дерьевями, я когда пытался хоть что-то такое придумать, каждый раз оказывалось, что всё уже давно придумано, результаты либо не очень. либо производительность страдает. Пока видеокарты не доросли до полноценного рейтрейсинга, помоему самое разумное это экранные техники. Они хотя бы применимы в реальных приложениях уже давно и вполне успешно.
g-contПостоялецwww3 июня 201716:20#44
Я вообще вот склоняюсь к идее рейтрейсинга с кэшированием результатов в лайтмапу. Но надо как-то эффективно перестраивать те участки, где освещение изменилось в силу перемещения окклюдеров\источников. Наверное для параллельного света есть смысл заморачиваться, но для индора я вообще себе не представляю.
Страницы: 1 2 3 4 513 Следующая »

/ Форум / Программирование игр / Графика

2001—2018 © GameDev.ru — Разработка игр