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

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

Страницы: 1 2 3 4 5 Следующая »
#30
10:00, 9 апр. 2020

Suslik
Да, самое главное забыл - есть ссылка на презентацию? Ты иногда прощёлкивал самые важные слайды в угоду публике.

#31
10:04, 9 апр. 2020

Skyblade
не, мы их не выкладывали. но там, вроде, всегда можно запаузить на слайдах, которые я прощёлкал.

#32
10:55, 9 апр. 2020

Suslik
Да, я понимаю, но это не слишком удобно.

#33
(Правка: 11:46) 11:45, 9 апр. 2020

Suslik
> ты должен сначала посчитать occluder distance, что само по себе — гемор ещё тот
Никакого гемора там нет. В 2д это вообще элементарно делается, в отличие от 3д случая.

> а потом ещё платить за блюр
Там нет никакого блюра потом, есть просто N тестов в глубину шедоумапы, из них прошло тест M семплов, вот тебе пенумбра M/N.

Suslik
> идея в том, что так как лучи распределены равномерно, то поворачивать паттерн
> можно не на угол 0..2*pi, а на угол 0..2*pi/rays_count
Тут я чёт окончательно запутался что происходит. Завтра прочту внимательнее, сформирую мысли и спрошу то что будет непонятно.

Ты молодцом, что выступил с докладом, но еще большим молодцом ты будешь, если детальнее объяснишь техники и подходы. Мне нравится твой GI в скринспейсе, и очень любопытно как ты срезаешь углы в своих оптимизациях. :)

#34
(Правка: 12:07) 12:06, 9 апр. 2020

MrShoor
> Там нет никакого блюра потом, есть просто N тестов в глубину шедоумапы, из них
> прошло тест M семплов, вот тебе пенумбра M/N.
под "блюром" я здесь имею в виду блюр результата z-теста. это и есть то, что ты описал. отстой в том, что чем шире ты хочешь пенумбру, тем больше радиус выборок нужно делать. чем больше радиус, тем больше выборок нужно для нормального качества. чем больше выборок, тем дороже. получается так, что чем шире участок пенумбры ты хочешь рендерить, тем дороже это выходит. у меня же цена на один пиксель наоборот падает, потому что там где пенумбра широкая, на самом деле меньше точность нужна.

> Тут я чёт окончательно запутался что происходит. Завтра прочту внимательнее, сформирую мысли и спрошу то что будет непонятно.
это я описал специфическую технику для расчёта алгоритмов по типу scatter-as-gather, которые работают с паттерном, где несколько лучей в скринспейсе от каждой точки расходится. её, может, надо более нормально изложить, потому что идея-то очень полезная, но я сомневаюсь, что я её изобрёл, поэтому лучше сначала поискать, может, оно уже опубликовано где-то. но я пока не встречал.

чтобы понять, что именно делает моя оптимизация, надо сначала 100% понять, что именно я оптимизирую:
Изображение

псевдокод этого алгоритма (scatter-as-gather) примерно такой:

vec2 center_point = gl_FragCoord.xy;
for(int ray_index = 0; ray_index < rays_count; ray_index++) //номер луча
{
  float ray_ang = float(ray_index) / float(rays_count) * 2.0f * pi;
  vec2 ray_dir = vec2(cos(ray_ang), sin(ray_ang));
  for(int step_index = 0; step_index < steps_count; step_index++) //номер шага вдоль луча
  {
    float ray_offset = pow(step_mult, step_index) * start_step;
    vec2 test_point = center_point + ray_dir * ray_offset;
    gi += CalculateLight(center_point, test_point);
  }
}
то есть это не изображение дракона размножило как частицу много раз (scatter), а из многих точек прочитался дракон (gather). это типичная схема, которая используется при расчёте алгоритмов вроде HBAO, это не моё изобретение. так вот целью стоит сделать так, чтобы эту самую повторяемость как можно сильнее скрыть, не увеличивая количество выборок. вот отсюда можно ещё раз попробовать разобраться с постом #29.

#35
16:02, 9 апр. 2020

Отличная презентация, поздравляю!
Приезжай в гости в Сидней когда локдаун закончится =)

#36
18:31, 9 апр. 2020

Спасибо за интересный доклад :)

#37
22:53, 9 апр. 2020

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

> то есть это не изображение дракона размножило как частицу много раз (scatter),
> а из многих точек прочитался дракон (gather)
Во! Теперь понял что именно там происходит. Я почему-то думал, что ты именно так хитро свет наносишь этими драконами в первом проходе. А там посути нет первого прохода, там просто есть рассчет освещения реймаршингом. Драконы получаются просто потому что фиксированные шаги реймаршинга попадают на этого самого дракона спустя X итераций. А паттерн получается из-за разного угла по seed. Классный подход в общем, спс, возьму на вооружение.

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

Интересная презентация, думал не досмотрю до конца, а досмотрел с удовольствием ) Фейк рефракта выглядит хорошо. Помню лет 7 назад для быстрого рендера делал воду с похожим эффектом, правда наоборот. Рендерилось только дно, но выглядело как вода, конечно с рефрактом (фейковым, т.к. границы объектов под водой не рефрактились, но если вода достаточно мутная, то не заметно. Для текстур считал производные и перепроецировал UV). Шейдер крайне компактный. Эх были времена графики...

#39
23:10, 9 апр. 2020

L
> Эх были времена графики...
Да они и сейчас есть, вон рендер Суслика тому подтверждение. И вообще считаю что сейчас еще больше всяких трюкачеств в коде становится, ибо есть бюджеты на это. Это раньше отдуваться приходилось только артистам, а сейчас если хочешь перфоманса и качественной картинки - приходится впрягаться граф программистам.

#40
23:36, 9 апр. 2020

MrShoor
Да я не об этом. У меня были времена, когда мог этим заниматься )  Давно железо программирую, времени мало на графику.

#41
18:41, 10 апр. 2020

Суслик красава
респект!

#42
18:42, 10 апр. 2020

Doctor_Bro.

Ты битухи зацени )
#43
2:14, 11 апр. 2020

+1 за отказ от репроекции

#44
5:09, 11 апр. 2020

Suslik
Можно совместить симуляцию воды и травы и будет вообще класс, как у Тарковского в Солярисе
Изображение

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