На пути к эффективному алгоритму Global Illumination, часть 1 (комментарии)

На пути к эффективному алгоритму Global Illumination, часть 1 (комментарии)

Очень хотелось бы узнать соображения пользователей. Показалось ли кому-то что-то интересным, нужно ли что-то пояснить или исправить.

Повезло программистам графики которые будут через 20-25 лет. Я думаю там будет Real-Time Path Tracing и им не придется париться

IBets
Размечтался. Экспоненциальную сложность не побороть приростом производительности. Тем более сейчас все смещается в сторону мобилок, так трассировку еще очень долго придется ждать.

/A\
Ну при губине рекурсии 2 уже не плохо смотрится. Я уверен что за 20 лет появятся способы быстрого нахождение пересечения луча с геометрией

Suslik
> unbiased screenspace GI
неплохо бы расшифровать, что это такое.
и обычно пишут кратное описание техник, если они упоминаются, ну там ключевые особенности и главные недостатки.

> чтобы рассчитать фотореалистично выглядящий cornell box даже с самым наивным monte-carlo path tracer'ом и её
> вычислительной мощности будет достаточно, чтобы рендерить такую сцену в реалтайме почти без шума.
что-то я не видел монте карло метод и почти без шума, с денойзером - да

IBets
Есть множество случаев при которых честная трассировка просто не справляется.
Вот например:
Есть город с кучей стекляшек и тд. И мы пускаем лазерные лучи, они рассеиваются в тумане/дыме, это рассеивание должно отразиться на зданиях и переотражаться в стекляшках (окнах и тд). Сам луч тоже попадает на зеркальные и не очень поверхности и отражается и рассеивается.
При трассировке в экранных координатах каким-нибудь монте-карло шанс, что случайный луч попадет в источник лазера достаточно низкий.
Для такого случая надо делать трассировку прямого освещения, сохранять все результаты и потом делать трассировку рассеяного, это уже в трассировкой из экрана можно сделать.

/A\
Да при рендеринге диэлектриков возникают проблемы. Именно поэтому есть bidirectional path tracing(Дополнительно из источников света испускаются лучи).

Круто! Идея насчёт line sweep весьма интересная.
Но скринспейс ограничения, увы, даже при просмотре с мобилы невооружённым глазом видны - то летаешь, и сильно меняется яркость на всём экране (свет ушёл за кадр), то эмиссив объект начинает светить на занавеску за собой, а потом прекращает. Имхо ворлдспейса не избежать. Может если бы даже какой-то очень грубый ворлдспейс был + твой крутой скринспейс, это позволило бы избежать самых заметных багов.

IBets
> Повезло программистам графики которые будут через 20-25 лет. Я думаю там будет
> Real-Time Path Tracing и им не придется париться
советую всё-таки почитать статью. я конкретно об этом писал под видео star wars.

IBets
> Ну при губине рекурсии 2 уже не плохо смотрится. Я уверен что за 20 лет появятся способы быстрого нахождение пересечения луча с геометрией
дело вообще не в глубине рекурсии, а в том, как время расчёта скейлится с минимальным угловым размером источника, который может разрешить GI. возможно, об этом стоило явно сказать.

/A\
> неплохо бы расшифровать, что это такое.
разумно. добавил.

> и обычно пишут кратное описание техник, если они упоминаются, ну там ключевые особенности и главные недостатки.
на самом деле я сперва хотел это всё расписать, но потом просто пошёл по более общему пути противопоставления всех принципиально трёхмерных техник против принципиально двумерных. мой обзор многих техник с их преимуществами и недостатками можно найти тут: https://gamedev.ru/code/forum/?id=226749

> Есть множество случаев при которых честная трассировка просто не справляется.
> Вот например:
> Есть город с кучей стекляшек и тд. И мы пускаем лазерные лучи, они рассеиваются
> в тумане/дыме, это рассеивание должно отразиться на зданиях и переотражаться в
> стекляшках (окнах и тд). Сам луч тоже попадает на зеркальные и не очень
> поверхности и отражается и рассеивается.
есть куча гораздо более простых случаев, с которыми вообще никакие алгоритмы без специальных фейков не справляются. далеко ходить не надо, обычную сцену из диффузных материалов ни один существующий алгоритм рендерить не умеет нормально, какие уж там туманы с лазерами.

Mr F
> Круто! Идея насчёт line sweep весьма интересная.
ну рад, что хоть до туда кто-то дочитал

> Но скринспейс ограничения, увы, даже при просмотре с мобилы невооружённым
> глазом видны - то летаешь, и сильно меняется яркость на всём экране (свет ушёл
> за кадр), то эмиссив объект начинает светить на занавеску за собой, а потом
> прекращает.
я как бы даже не пытался никакие из этих эффектов скрывать. да и вся статья — про то, что вообще не в этих проблемах суть. там миллион интересных вопросов и без этих очевидных проблем, я бы хотел разобраться в первую очередь с ними. к тому же во многих случаях вроде top-down игр все эти типичные для screenspace ограничения вообще роли не играют, так как камера фиксированная сверху.

Mr F
Будем значит сидеть на precomputed radiance transfer

Suslik
Интересно.
Я был уверен, что в твоей реализации так или иначе используется LSAO и именно за счет этого получается такая сходимость, а оно вон как. Наконец стало ясно причем тут голография. Нужен H-buffer )
Я бы еще упомянул HBIL рядом с Unigine.

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

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

> Алгоритмы, которые я буду рассматривать далее, используют в среднем около 128 плоскостей на фрагмент в реалтайме на существующем железе. Каждую плоскость можно более-менее аппроксимировать через как минимум 8 (на самом деле — больше) лучей.
Вот тут не совсем понятно о каких плоскостях идет речь. Если это плоскость сечения полусферы фрагмента, то она же и является плоскостью луча, т.е. число плоскостей == числу лучей. Или же имеется в виду, что на каждое направление (плоскость) приходится по 8 лучей (сэмплов)?

Ждем вторую часть.

San
> предоставлял возможности для аппаратного ускорения реймарчинга
И за счет чего он будет аппаратно ускорен?
В RTX аппаратно ускорено только пересечение луча и треугольника.

/A\
> И за счет чего он будет аппаратно ускорен?
А вот хз, потому и говорю, что наивно.
Может как-то по-умному префетчить рендертаргеты (глубину и прочее, если обобщить), с кешем для луча. Уточнение результатов какое-то сделать - типа binary search. Понятное дело, что это слишком специфическая штука, чтобы ее реализовывать в железе. С другой стороны, очень много современных техник использует реймарчинг в скринспейсе. Ну и всегда интересно поразмышлять "а что если бы...".

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