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

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

Страницы: 13 4 5 612 Следующая »
SuslikМодераторwww3 июня 201716:45#45
Che@ter
> Это какая-то общая техника "прохода по всем пикселям" или она работает чисто
> из-за специфики просчета этих пикселей (обычная сумма например)?
> Я с подобным никогда не сталкивался и хотелось бы узнать за счет чего это
> достигается.
> Выборка по всему экрану? Если так, то сколько получается выборок на пиксель и
> сколько нужно кадров, чтобы захватить все? Выборки равнораспределены по радиусу
> или полный рандом?
ну про "все пиксели действуют на все пиксели" я немного фигурально выразился, имея в виду, что радиус действия ssgi — весь экран и в принципе пиксель в одном углу может подействовать на пиксель в другом. хотя, так как алгоритм стохастический, то это не гарантируется. освещение для каждого пикселя рассчитывается на основе данных о горизонтах вдоль случайной прямой(или нескольких), проходящей через этот пиксель. такой большой радиус удаётся достичь, используя мипмапы для дальних выборок(чтобы увеличить кэшфрендлинесс) и экспоненциально отдаляющиеся выборки, так как чем дальше, тем точность нас меньше интересует. далее освещённость каждого пикселя усредняется с соседними и потом ещё усредняется между несколькими последними кадрами за счёт репроекции.

в принципе, если far field GI не нужен, то можно радиус ограничить не целым экраном, а, например, 30% -- это сильно повысит производительность.

Правка: 3 июня 2017 16:47

destractПользовательwww3 июня 201716:49#46
А уже прозвучал ответ на главный вопрос этого треда?

Почему Suslik против Global Illumination?

MAMOHT-92Постоялецwww3 июня 201723:15#47
Поддерживаю выбор скринспейс техники для Path of exile. Ибо камера смотрит сверху и под одним и тем же углом( мне кажется или в игре вообще ортогональная проекция?) Причем все источники освещения довольно небольшие( если какой-то чудак не будет делать взрывы на весь экран). 

Суслик, только учти что в игре экран может крайне резко меняться, как и с большой частотой, так и с большими рывками. Flicker strike, warp, leap slam, shield sharge  поэтому что-то накапливать с предыдущих кадров- будет очень устаревшим и дерганным. Или же у меня вся карта в красной дискотеке и радости эпилептика когда я explosive arrow об стены хреначу, все с большой скоростью взрывается и мигает.

Что предлагаю я - использовать что-то  подобие воксельной сетки или даже плоской сетки сверху вокруг перса, не более чем пол экрана в каждую сторону от края экрана. В ее рамках уже просчитывать освещение. Ибо в игре нет далеко взаимодействующих источников света, все локально. Либо же реально использовать любую скрин спейс технику, ибо на сценах из игры оно будет нормально выглядеть.

Правка: 3 июня 2017 23:36

MAMOHT-92Постоялецwww3 июня 201723:32#48
Ну вот, ччто мы видим. Что каждый фаерболл - это источник красного света. И вся сцена должна быть подсвечена красным цветом. В этой игре и так куча взрывов, молний, льда и прочего, весь экран во всяких эффектах. И делать какой-то честный алгоритм - нет смысла, его тупо не увидят в этой канители. ИМХО, твоя задача лишь добавлять освещение в те участки, карты(даже в рамках экрана) где есть какой-то световой эффект от скила, либо просто источник освещения от карты(типо костра, лавы или чего-то еще). Нет смысла направлять переотраженный свет на какую-то стенку, а затем этот свет направить на перса и чтоб было с честным затенением. Опять же это все мое грубое ИМХО.

И да, забей на универсальность! Ты делаешь для конкретной игры, со своими особенностями и частными случаями.

Изображение

g-contПостоялецwww4 июня 201712:39#49
>>Ты делаешь для конкретной игры, со своими особенностями и частными случаями.
Так техник, сделанных для конкретной игры за прошедшие 10-15 лет, просто валом. Я вон читал пейпер по Last Of Us, там уже в самом начале написано, ну у нас пост-апокалиптический мир, ага, значит источников электрического освещения нет, только солнце - обойдемся лайтмапами. В том-то и заключается главная цель, чтобы создать фундаментальную технику непрямого освещения. А частных случаев уже сколько угодно - выбирай не хочу.
-=MASTER=-Постоялецwww5 июня 201718:32#50
Suslik, а почему ты против GI? :-)

По поводу статьи...Наверное всё таки лично мне, ровно как и всем практикам здесь, интересней было бы посмотреть на сорцы в первую очередь, а не на статью...
Ты кстати не пробовал Voxel Cone Tracing на Tiled/Sparse Textures из DX12/Vulkan? Реально же должно меньше памяти жрать...

Che@terПостоялецwww17 июня 201720:01#51
Приобщаюсь к SSGI:
Изображение
Изображение
Изображение
Изображение
Изображение
SuslikМодераторwww17 июня 201720:19#52
Che@ter
какой алгоритм? с path tracing'ом решение сравнивал? какая производительность?

Правка: 17 июня 2017 20:19

Che@terПостоялецwww17 июня 201720:50#53
Suslik
Алгоритм называется "Со слов Suslik'a" :)

Я вот потратил всего несколько часов на этот результат. Пока я только опробываю эту технику, разбираюсь в каком порядке кидать лучи для выборки, как производить расчеты, где сэкономить и тд.
У меня дико падает яркость вторичного освещения, не могу этот момент пока нормально настроить, постоянно меняю коэффициенты в зависимости от сцены, поэтому сравнивать с path tracing'ом вообще нет смысла...
А по производительности - сейчас у меня грубо говоря "брут-форс". 128 выборок без использования mip-уровней. На GTX 1080 от 20 до 120 фпс в разрешении этих скринов в зависимости от настроек, это пока неприемлимо.

С другой стороны я это делаю под микс с VCT. Для меня это чисто развлекаловка, не ставлю себе задачу сделать "идеальный" GI чисто на SSGI. Радиус выборки и их количество можно будет кардинально уменьшить и сам по себе результат SSGI получится очень плохим.

BernsПостоялецwww17 июня 201721:07#54
присоединяюсь к теме. крайне не советую использовать предыдущий кадр - инерция будет в качестве артефакта, это больше для блюмов годится. и выглядит оно не как чистый GI - те места, которые по задумке должны затенять, оно перекрашивает, что больше похоже на рассеивание, могла бы получиться хорошая техника для отрисовки растений.
SuslikМодераторwww17 июня 201721:54#55
Che@ter
> У меня дико падает яркость вторичного освещения, не могу этот момент пока
> нормально настроить
у меня одной из основных целей была математическая чистота, то есть чтобы алгоритм сходился к точному решению. советую для начала отладить все выборки, расчёты горизонтов и прочее на SSAO, потому что его очень легко проверять — плоские поверхности должны иметь освещённость == 1.0f. потом уже расширить формулу до GI.
-=MASTER=-Постоялецwww18 июня 201717:47#56
Che@ter
> Приобщаюсь к SSGI:
а что, в вокселями совсем всё плохо?
-=MASTER=-Постоялецwww28 июня 201714:15#57
Suslik, ну так что, тебе удалось улучшить свой SSGI в те моменты, когда источники света не в кадре?
Вообще, за сколько проходов рендеришь? Судя по всему, у тебя картинка "накопительная", типа как в path trcing-е ?
У тебя кол-во вычислений NxN что ли? То есть всех на всех?

Правка: 28 июня 2017 14:18

SuslikМодераторwww28 июня 201714:51#58
-=MASTER=-
> Suslik, ну так что, тебе удалось улучшить свой SSGI в те моменты, когда
> источники света не в кадре?
не было такой цели. для глобального освещения не в скринспейсе я уже давно реализовал imperfect shadow maps, ссылка на видео в нульпосте.

> Вообще, за сколько проходов рендеришь?
один проход. вообще вторичное освещение считается постпроцессом поверх основного рендера.

> Судя по всему, у тебя картинка "накопительная", типа как в path trcing-е ?
почитай тему. я уже кучу раз рассказывал про temporal coherence.

> У тебя кол-во вычислений NxN что ли? То есть всех на всех?
что значит "все на всех"? очевидно, в лоб влияние каждого фрагмента на каждый посчитать невозможно. но метод стохастический и сходится именно к точному решению.

-=MASTER=-Постоялецwww28 июня 201715:15#59
Suslik, как на счёт сорцов? :-)
Страницы: 13 4 5 612 Следующая »

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

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