Войти
ПрограммированиеФорумГрафика

Развитие рендера в Path of Exile (комментарии) (2 стр)

Страницы: 1 2 3 4 5 Следующая »
#15
22:27, 8 апр. 2020

Ничего себе, это же Суслик!
Ты нереально крут, с огромным удовольствием посмотрел доклад, побольше бы таких!

#16
22:43, 8 апр. 2020

Посмотрел, возникли вопросы.
Вы GI считаете в пиксельном шейдере или на компьютах? Если в пиксельном, то как организован доступ к семплам? Просто у тебя нам 25:34 выглядит так, как будто ты рисуешь частицы, а в пиксельном по условию делаешь аля dithering. Но как эта оптимизация работает, если GPU все равно рендерит блоками (как правило по 4*8 пикселей), и группа тредов попадает в разные ветки условий, и как следствие оно считает абсолютно все пиксели.

Второй вопрос - про кристаллы. Я не совсем понял как именно используется константная глубина, на которую совершается прыжок. Типа предполагаешь, что сзади объект плоский?

#17
(Правка: 23:24) 23:24, 8 апр. 2020

Посмотрел про GI и динамические тени, хочу теперь такую штуку для своей игры. Выглядит относительно несложно, в 2д изометрии тоже должно работать по идее.

А так в целом респект бицухе круто, мач респект.

#18
23:27, 8 апр. 2020

jaguard
> в 2д изометрии тоже должно работать по идее.
В случаях когда камера с видом сверху, аля изометрия - скринспейс тени просто мастхев. К сожалению в полноценной 3д камере такие тени выглядят очень и очень печально.

#19
23:28, 8 апр. 2020

Suslik, круто, очень круто.

#20
23:38, 8 апр. 2020

такой то just in case =)
8 лет прошло, до сих пор вспоминаю

#21
1:16, 9 апр. 2020

Обычно когда такое постят- работу ищут. Чел молодец- выступает, качается, бодрится, миллионам на зависть, говорит про дельные вещи которые нынче уже не актуальны.

#22
2:00, 9 апр. 2020

Суслик молодцом, но видимо ты так хотел обо всём рассказать что уж очень сильно спешил :) Особенно по первым десяти минутам, потом вроде как расслабился и стал чуть более размеренно рассказывать.

#23
6:38, 9 апр. 2020

MrShoor
> Вы GI считаете в пиксельном шейдере или на компьютах? Если в пиксельном, то как
> организован доступ к семплам? Просто у тебя нам 25:34 выглядит так, как будто
> ты рисуешь частицы, а в пиксельном по условию делаешь аля dithering. Но как эта
> оптимизация работает, если GPU все равно рендерит блоками (как правило по 4*8
> пикселей), и группа тредов попадает в разные ветки условий, и как следствие оно
> считает абсолютно все пиксели.
пиксельный fullscreen шейдер. выглядит как частицы, потому что это gather-scatter (как большинство AO техник считается). чтобы треды внутри группы считали одно и то же, можно сделать deinterleaved rendering, но по моим экспериментам на практике оно получается не быстрее, так как я использую мипы и у дальних семплов доступ всё равно оказывается когерентным даже для разных направлений.

jaguard
> Посмотрел про GI и динамические тени, хочу теперь такую штуку для своей игры.
да, в 2д алгоритм с тенями точно так же будет работать, вполне можно попробовать.

Aroch
> Суслик молодцом, но видимо ты так хотел обо всём рассказать что уж очень сильно
> спешил :) Особенно по первым десяти минутам, потом вроде как расслабился и стал
> чуть более размеренно рассказывать.
да, это так. первые 10 минут были труднее всего, потому что свет в глаза лупит, ни черта не видно, себя слышишь снаружи, а не изнутри, всё это очень сбивает с толку.

#24
7:13, 9 апр. 2020

Suslik
> так как я использую мипы и у дальних семплов доступ всё равно оказывается
> когерентным даже для разных направлений.
Так я не про когерентный доступ к текстуре, а про загрузку воркгрупп. Знаешь как работает dynamic branching?

#25
7:16, 9 апр. 2020

Suslik
> да, в 2д алгоритм с тенями точно так же будет работать, вполне можно
> попробовать.
В чистейшем 2д проще растеризовать отрезки в шедоумапу. Т.е. грубо говоря 1D шедоумапа на каждый источник, но т.к. мы можем эффективно растеризовать в 2д текстуру инстансингом - можно за 1 проход сделать все шедоумапы для видимых источников.

#26
7:44, 9 апр. 2020

MrShoor
> В чистейшем 2д проще растеризовать отрезки в шедоумапу
во-первых, это подходит только для непрозрачных объектов. во-вторых, это не даст пенумбры.

> Так я не про когерентный доступ к текстуре, а про загрузку воркгрупп. Знаешь как работает dynamic branching?
а ты знаешь, как работает deinterleaved rendering?

#27
8:00, 9 апр. 2020

Suslik
> во-первых, это подходит только для непрозрачных объектов.
Ну так то есть техники с шедоумапами для прозрачных объектов, они и тут работают так же.

> во-вторых, это не даст пенумбры.
Пенумбра делается классически семплингом, как PCSS или просто PCF.

> а ты знаешь, как работает deinterleaved rendering?
Да, конечно. Рендеришь картинку в 2 раза меньше по ширине/высоте, потом собственно черезстрочно вставляешь. Но у тебя то разный паттерн на семплы. Вот мне и интересно как ты собственно выходишь из положения.

#28
8:00, 9 апр. 2020

Респект! Столько всего в один доклад уместил, такие массивные презентации нечасто и у Активижена бывают)

#29
(Правка: 8:44) 8:34, 9 апр. 2020

MrShoor
> Ну так то есть техники с шедоумапами для прозрачных объектов, они и тут
> работают так же.
в шэдоумепах ты платишь за прозрачность. а в алгоритмах вроде моего, построенных на реймарчинге, ты просто интегрируешь плотность по лучу. поэтому можно тени от какого угодно дыма считать.

> Пенумбра делается классически семплингом, как PCSS или просто PCF.
опять же, чтобы считать pcss для пенумбры, ты должен сначала посчитать occluder distance, что само по себе — гемор ещё тот, а потом ещё платить за блюр. в моём алгоритме пенумбры получаются by design, просто потому что дальние тени рендерятся в низком разрешении и поэтому они менее чёткие.

> Да, конечно. Рендеришь картинку в 2 раза меньше по ширине/высоте, потом собственно черезстрочно вставляешь. Но у тебя то разный паттерн на семплы. Вот мне и интересно как ты собственно выходишь из положения.
нет, я делаю не так. например, для случая рендеринга изображения с паттерном 2x2, я сначала одним fullscreen пиксельным шейдером перемешиваю пиксели буфера глубин из такого паттерна:

0 1 0 1 0 1 0 1
2 3 2 3 2 3 2 3
0 1 0 1 0 1 0 1
2 3 2 3 2 3 2 3
в такой:
0 0 0 0 1 1 1 1
0 0 0 0 1 1 1 1
2 2 2 2 3 3 3 3
2 2 2 2 3 3 3 3
получаем deinterleaved текстуру, у которой вся левая верхняя (например) четверть использует один и тот же seed (то есть одно и то же направление) и поэтому все треды во всей четверти делают одно и то же с нулевым divergence'ом в branching'е и с предельно локальным доступом по памяти.

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

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

если в двух словах, то решаю так. пусть мы для каждого пикселя выпускаем 10 лучей во все стороны в скринспейсе:

for(int ray_index = 0; ray_index < rays_count; ray_index++)
{
  float ray_angle = float(ray_index) / float(rays_count) * 2.0 / pi;
}
чтобы рандомизировать лучи между пикселями, наивное решение — это сделать так:
for(int ray_index = 0; ray_index < rays_count; ray_index++)
{
  float ray_angle = (float(ray_index) / float(rays_count) + pixel_seed)  * 2.0 / pi; //pixel_seed — случайная величина 0..1
}
тогда паттерн для каждого пикселя оказывается повёрнутым на случайный угол 0..2*pi. однако, из-за этого пути исполнения между соседними пикселями очень сильно расходятся, так как лучи идут в разные стороны. однако, можно сделать так:
for(int ray_index = 0; ray_index < rays_count; ray_index++)
{
  float ray_angle = (float(ray_index + pixel_seed) / float(rays_count))  * 2.0 / pi; //pixel_seed — случайная величина 0..1
}
— идея в том, что так как лучи распределены равномерно, то поворачивать паттерн можно не на угол 0..2*pi, а на угол 0..2*pi/rays_count, тогда результат получается точно такой же, а лучи расходятся гораздо меньше.

Страницы: 1 2 3 4 5 Следующая »
ПрограммированиеФорумГрафика