ПроектыФорумУтилиты

UNIGINE - универсальный 3D-движок (9 стр)

Страницы: 18 9 10 1126 Следующая »
#120
21:26, 18 дек 2017

-=MASTER=-
> Там пейперов в прямом понимание этого слова вообще нет, это больше похоже на
> рекламу, а не на описание техники.
Там как раз описание техники, если ты не заметил в этой статье описания техники, то учи английский, что я могу тебе еще сказать.
Ну и я лично понял принцип этой техники. Когда буду посвободнее - попробую реализовать, но даже не надейся на исходники.

-=MASTER=-
> По сути, Суслик делал примерно тоже самое в своей ветке "Суслик против GI"
И нет, у суслика совершенно другая техника. Общее между этим и сусликовым только то, что они оба используют color буфер для вторичного освещения.

#121
22:34, 18 дек 2017

MrShoor
> Ну и я лично понял принцип этой техники.
тогда поясни, как они с помощью blue noise-а трейсят лучи, я чё то не въехал )

#122
0:21, 19 дек 2017

-=MASTER=-
> тогда поясни, как они с помощью blue noise-а трейсят лучи, я чё то не въехал )
blue noise используется для распределения семплов, так же и как и обычный noise. Например берешь N точек из hammersley point set и добавляешь к ним значение из RG каналов noise текстуры для конкретного пикселя в screen space. Потом по этим смещенным точкам строишь лучи на полусфере.
Так как семплов сильно ограниченное число, то в результате noise паттерн становится виден на финальном изображении. Чтобы этот паттерн был меньше заметен - они и используют blue noise вместо uniform noise.

#123
4:18, 19 дек 2017

binstream
> https://80.lv/articles/ssrtgi-toughest-challenge-in-real-time-3d/

Ordinary screen-space effects, such as SSAO and SSGI, that are used to simulate global illumination, do not treat objects as obstacles for light rays. Roughly speaking, the light passes through objects, that’s why all popular approaches are unable to provide realistic lighting, offering just a rough imitation of interaction between photons and objects. Our approach is a real screen space ray tracing that takes obstacles into account.

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

я так и не нашёл ответов на вопросы:
- как, используя bent normals, строится финальная аппроксимация GI?
- правильно ли я понимаю, что свет считается по-прежнему из лайтпроб, просто выборка делается не из нормали поверхности, а из bent normal'а? если это так, то каким образом строятся лайтпробы?
- как именно строятся bent normals в скринспейсе? впрочем, этот этап — технический и его логично умолчать. но в объяснении того, как по сути работает остальная часть алгоритма, маркетингового булщита существенно больше, чем информации по теме.

#124
5:25, 19 дек 2017

Suslik
> - как, используя bent normals, строится финальная аппроксимация GI?
Я тоже не нашел ответы на эти вопросы, но мне кажется принцип там примерно такой:
Для пикселя строим полусферу с учетом распределение от roughness.
Ориентируем эту полусферу по bent нормали
Трейсим по буферу глубины (как в SSAO), при попадании вытаскиваем из дифузки нужного LOD-а цвет и добавляем к освещению.

А поинт бент нормалей в том, что importance sampling по полусфере ориентированной на бент нормаль даст фейковый эффект баунса в углах. Возможно там даже не importance sampling а просто 1 семпл по бент нормали.

Вот:
bents | UNIGINE - универсальный 3D-движок
За счет бент нормали угол окрасится в красный цвет (будет типа баунс от нижней стенки).

#125
5:28, 19 дек 2017

Suslik
> - как именно строятся bent normals в скринспейсе?
Насколько я понял почти так же как и в SSAO. Трейсимся по полусфере, но если для SSAO мы складываем количество лучей, которые не уперлись в обстакл, то для бент нормалей мы складываем сами лучи, и потом эту сумму нормализуем.

#126
6:05, 19 дек 2017

MrShoor
если судить по пейперам, в которых, собственно, конкретика по бент-нормалям:
http://people.mpi-inf.mpg.de/~ritschel/Papers/ScreenSpaceBentCones.pdf
http://www.spherevfx.com/downloads/ProductionReadyGI.pdf
то их используют в первую очередь для использования диффузных environment map'ов для освещения. это, грубо говоря, даёт цвет ambient освещению в зависимости от того, откуда свет преимущественно приходит. то есть волшебства в самих bent normals нет вообще никакого. даже если представить, что они у нас уже есть посчитанные с бесконечной точностью, максимум что можно получить из них — это офигенно точная выборка из diffuse environment map'а. либо они используют light probes и тогда везут за собой всю тележку проблем, с ними связанные: только супер low-frequency гармоники, магия с их расстановкой и генерением, проблемы с динамическими объектами, недостаточное разрешение для рендеринга честных indirect shadows итд.

#127
7:34, 19 дек 2017

Suslik
> это офигенно точная выборка из diffuse environment map'а. либо они используют
> light probes и тогда везут за собой всю тележку проблем, с ними связанные:
> только супер low-frequency гармоники, магия с их расстановкой и генерением,
> проблемы с динамическими объектами, недостаточное разрешение для рендеринга
> честных indirect shadows итд.
А в чем проблема сделать скринспейс рейкаст по бент нормалям? Почему ты считаешь, что обязательно нужны лайт пробы?

#128
7:37, 19 дек 2017

MrShoor
> А в чем проблема сделать скринспейс рейкаст по бент нормалям? Почему ты
> считаешь, что обязательно нужны лайт пробы?
в том, что если делать 1 семпл, то получится чёрт знает что(будут резкие переходы цвета вторичного освещения, например). если делать много семплов, то ничем не отличается от ssgi вроде того, что я делал. только лишнее действие ещё bent normal рассчитывать, потому что в этом случае от неё толку всё равно нет.

#129
7:52, 19 дек 2017

Suslik
> в том, что если делать 1 семпл, то получится чёрт знает что(будут резкие
> переходы цвета вторичного освещения, например)
Если правильно нагенерить MIP-ов на дифузку, и делать cone tracing по MIP уровням, то не будет черт знает чего.

> только лишнее действие ещё bent normal рассчитывать, потому что в этом случае
> от неё толку всё равно нет.
Даже для нескольких семплов толк от bent нормали есть. Вокруг bent нормали можно строить importance выборки.

#130
9:55, 19 дек 2017
+ Показать

У меня тут один вопрос к двум техниками, вот этой, SSRTGI и технике Суслика.
[внимание на экран]
Изображение
Есть сцена с полом и стенами, в которых есть какие-то дыры, ну там окна и тд. Сцена (камера) повёрнута так, что эти окна не видны в скрин спейсе, то есть, допустим (чисто ради примера) есть ортогональная видовая матрица, стена - перпендикулярно к экрану, свет от источника "ударяется" об какой-то относительно зеркальный пол и indirect light отчасти по идее доложен пролететь через невидимое в скрин спейсе окно и упасть на вторую сплошную стену за окном. Так вот, в технике Суслика или в SSRTGI этот отражённый свет через окно учтётся?
P.S.: ну понятно, что если стена перпендикулярна, то и боковую стену не видно, это чисто для примера. В реальности стена в скрин спейсе будет конечно же наклонена как бы из-за перспективы.

#131
10:11, 19 дек 2017

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

#132
10:42, 19 дек 2017

Suslik
> это сильное допущение, но которое позволяет использовать сильные оптимизации.
Согласен. Ну значит, я тогда тоже придумал свой SSRTGI, сегодня демку залеплю :)

#133
13:16, 19 дек 2017

-=MASTER=-
> Согласен. Ну значит, я тогда тоже придумал свой SSRTGI, сегодня демку залеплю :)
так ты сначала демку показывай, а потом рассказывай, что ты там придумал.

#134
10:37, 23 дек 2017

Suslik
> так ты сначала демку показывай, а потом рассказывай, что ты там придумал.
в общем признаю фейл, мой алгоритм работает только в случае хранения каждого пикселя как лайт сорца в отдельном буфере, то есть памяти нужно (width*hight)^2, да и сам алгоритм N*N, то есть всех со всеми, это конечно круто, но это фейл )
Суслик, Шур, так что, вы поняли, как работает этот SSRTGI у юниенжина?  )  Если да - то объясните дураку в двух словах, в чём тут фокус )
Когда я слышу фразу Screen Space Ray Tracing, я представлю себе это как пускание конуса от каждого пикселя (ну или вообще во все стороны) и имея буфер глубины и нормалей, не сложно определить, должен этот пискель светится или нет. Разумеется при таком подходе ни о каком real time и речи быть не может ) 
binstream, давай колись уже, в чём там у вас фокус? )))

Страницы: 18 9 10 1126 Следующая »
ПроектыФорумУтилиты