− Скрыть
Прямой свет:
Вторичный свет:
Вместе:
+альбедо:
Suslik
А не пробовал ли ты такую технику:
переотражённое освещение запекается в низкодеталилированные светокарты и лайтпробы. Прямое освещение считается как обычно.
Пример работы:
Panzerschrek[CN]
это самый банальный вариант, я его даже не рассматриваю, потому что если есть возможность запекать, то тут и обсуждать нечего — надо запекать.
Suslik
> это самый банальный вариант, я его даже не рассматриваю, потому что если есть
> возможность запекать, то тут и обсуждать нечего — надо запекать.
Тогда не понятно, для чего ты ищёшь способ глобального освещения.
Как я понял, тебе нужны техники, работающие в реальном времени. Значит, нужны они для какой-то игры. А что может быть за игра, где не хватит предрассчитанного света, я не очень понимаю. Разве только что-нибудь очень суровое со 100% изменяющимся окружением и с динамической сменой времени суток, типа Майнкрафта.
Panzerschrek[CN]
я уже писал кучу раз, что у нас одни и те же текстуры используются на разных объектах, а лайтмапы должны быть для каждого объекта уникальные. плюс текстуры тайлятся, а развёртки должны быть специальные, в которых каждый текстурный тексель используется всего один раз. плюс это в любом случае подходит только для статики, а я хочу для всех объектов, включая анимированные. наконец, источники освещения бывают динамические — фаерболлы всякие и тому подобное.
Panzerschrek[CN]
Динамическое GI это просто круто. Технический челлендж.
Ну и недостатков у запечёных теней куча - занимают кучу места, а если лайтмапы продвинутые - то кучу * 5, постоянные проблемы с развёрткой и паддингом, долго ждать пока запечётся. Ну и самый страшный тест для лайтмап - разбить лампочку. Если в твоём лайтмаппере невозможно корректно разбить лампочку - он не нужен.
Suslik
> я уже писал кучу раз, что у нас одни и те же текстуры используются на разных
> объектах, а лайтмапы должны быть для каждого объекта уникальные. плюс текстуры
> тайлятся, а развёртки должны быть специальные, в которых каждый текстурный
> тексель используется всего один раз
Для моделек - деталей уровня надо делать дополнительную развёртку для использования её для построения светокарты. Да, это дополнительная работа, но это не сверхсложно.
Для высокополигональных моделек вроде монстров, кустиков, всяческого мусора хватит и лайтпроб.
> наконец, источники освещения бывают динамические — фаерболлы всякие и тому
> подобное
Фаерболы и без вторичного освещения нормально будут смотреться. Никто там особо не будет вглядываться.
Для "динамических" источников света типа включающихся/выключающихся лампочек можно добавлять ещё один слой светокарты для близких к таким источникам объектов. Так делали ещё в Quake.
PS:
Кстати, в "The Last of Us" используются светокарты. Описанные тобой проблемы они с развёртками смогли побороть: http://miciwan.com/SIGGRAPH2013/Lighting%20Technology%20of%20The%… 20Of%20Us.pdf
Battle Angel Alita
> Динамическое GI это просто круто. Технический челлендж.
Ну если только крутость нужна ради самой крутости, а не для практического применения.
> и самый страшный тест для лайтмап - разбить лампочку.
Смотри пост выше, какой методикой можно сделать разбивающуюся лампочку.
Panzerschrek[CN]
> Да, это дополнительная работа, но это не сверхсложно.
"дополнительная работа" в моём случае — это сделать дополнительную развёртку для 60Гб визуальных ассетов. причём вся статика by design — тайлы, то есть если на каждый тайл заводить уникальную текстуру, то весь смысл тайловой геометрии теряется.
Насчет статики: если вести речь только про статические окклюжны и не меняющие положения (но могущие менять яркость/цвет) источники, то нельзя ли просто для каждого источника описать некоторую "область достижимости" как некий многогранник из клип-плоскостей вокруг источника? то есть эдакий "векторный лайтмап"? Можно также рассматривать это как path tracing, но проверка пересечения уже будет делаться не с полигонами сцены, а с наборами клип-плоскостей, которых для неподвижного источника и статических окклюжнов будет скорей всего не так уж и много...
Suslik
> + сцена должна быть полностью динамической, никакого precompute bullshit'а
Даешь процедурную геометрию и сфер-трейсинг! Нет предзапеченым каркасам и богомерзким треугольникам!
Ну серьезно, где заканчивается работа прекомпьютобогов и начинается прекомпьют булщит? Например, хранение bvh это булщит? А если bvh per mesh? Ну и можно же его еще параллельно для физики использовать и какого-нибудь куллинга.
После ISM были еще ManyLoDs:
Правда, нужон bvh. А для динамиков его еще и апдейтить нужно, но в "lazy-режиме" вроде не смертельно. В пайпере они сравнение с ism приводят:
Но тема как-то затухла
Suslik
> так что следующим шагом уже просто попытаюсь впилить в наш проект
А вот это уже будет интересно.
Как впилишь - закинь в эту тему скриншотов. Ну и заодно скриншотов без всебощего освещения, для сравнения.
Suslik
> а лайтмапы должны быть для каждого объекта уникальные. плюс текстуры тайлятся,
> а развёртки должны быть специальные, в которых каждый текстурный тексель
> используется всего один раз
Ента штука называется лайтмапа с ЮВ2.
Кстати сделать дополнительную сетку и запечь лайтмапу не так уж и сложно, по крайней мере намного проще чем с текстурами работать.
Ну и светят фаерболы на лайтмапу тоже норм :)
Это я о чем :)
Как там дела с освещением персов? :)
У меня ничего умнее, чем делать карты на каждый "этаж" в голову не пришло.
Suslik
Слушай, а вот твой SSGI может дополнительно выдать значение полноты для каждого пикселя? Или даже какую-либо функцию заполненности пространства? Чтобы в будущем сблендить результат с wolrd space техниками.
И очень инетерсует этот момент:
> Алгоритм по факту считает вторичное освещение всех пикслеей framebuffer'а на
> все пиксели
Это какая-то общая техника "прохода по всем пикселям" или она работает чисто из-за специфики просчета этих пикселей (обычная сумма например)?
Я с подобным никогда не сталкивался и хотелось бы узнать за счет чего это достигается.
Выборка по всему экрану? Если так, то сколько получается выборок на пиксель и сколько нужно кадров, чтобы захватить все? Выборки равнораспределены по радиусу или полный рандом?
С глобальным освещением за все эти годы помоему перепробовали абсолютно все возможные варианты и методы подхода. И с предрасчётами и фуллдинамик и с сетками и с дерьевями, я когда пытался хоть что-то такое придумать, каждый раз оказывалось, что всё уже давно придумано, результаты либо не очень. либо производительность страдает. Пока видеокарты не доросли до полноценного рейтрейсинга, помоему самое разумное это экранные техники. Они хотя бы применимы в реальных приложениях уже давно и вполне успешно.
Я вообще вот склоняюсь к идее рейтрейсинга с кэшированием результатов в лайтмапу. Но надо как-то эффективно перестраивать те участки, где освещение изменилось в силу перемещения окклюдеров\источников. Наверное для параллельного света есть смысл заморачиваться, но для индора я вообще себе не представляю.