Как стать автором
Обновить

Проблемы рейтрейсинга в играх нового поколения: анализ трассировки лучей в ремастере Marvel's Spider-Man

Время на прочтение7 мин
Количество просмотров14K
Всего голосов 47: ↑47 и ↓0+47
Комментарии23

Комментарии 23

Почему нельзя просто запечь отражение статических объектов типа города с его домами и деревьями, а динамически отражать только движущиеся объекты, типа Спайдермена, автомобилей, людей?
Так со всех ракурсов чтоб нормально это выглядело потребуется еще больше нагружать систему, наверно поэтому. Представьте себе, что при каждом новом угле обзора это проделать
Отчасти ответ дан в этом абзаце:
Когда сцена вместе с отражениями рендерится в 4K, а количество самих отражений на экране столь невелико, как в случае со статичной лужей выше, графический процессор едва укладывается в 30 FPS. Если бы в сцене было больше динамики, частота кадров определенно была бы меньше.

Технология тяжеловесная даже для статики, не говоря уже о динамически изменяющихся объектах. К тому же, когда объект не меняется во времени, его качественность больше цепляет глаз, чем при быстром перемещении. Здесь почти та же дилемма, что и с крупными объектами и мелкими частицами — что проще заметить, на том и акцент.
Сейчас в общем-то плюс минус так и делают (через кубические карты + ssr), основная проблема это нормально свести запеченые отражения с реалтаймовыми так, чтобы объекты не «парили», чтобы свет совпадал, и т.д.
Конкретно у подхода «трассировать только динамику» есть как минимум одна ключевая проблема: что делать, если динамический объект частично перекрывается статическим? Например, человек стоит за деревом. Если трассировка не будет учитывать статику, то отражение человека будет выглядеть так, словно он стоит перед деревом, а не за ним.
Занимательная статья, только то что сравнение ведётся с 2060с и 2070 вызовет сильное жжение у адептов, ведь они свято верят, в том что у пс5 и сериес х стоят аналоги 2070с и не меньше
По последней информации, Big Navi имеет быстродействие на уровне +- GeForce RTX 2080 Ti, поэтому сравнение в целом релевантное. О том, что новые консоли адекватно будет сравнивать с RTX 30×0, никогда и речи не шло.
BigNavi — их несколько. И некоторые из них могут конкурировать с 3080 и 3090.
Да, но мы говорим о тех, что ожидаются в новых консолях. По прогнозам, до RTX 3080 и RX 6900 они все же не будут дотягивать.
И всё же, в чём фундаментальная причина того, что рейтрейсинг такой медленный?
При обычном рендеринге GPU проходит циклом по всем (видимым) полигонам и для каждого полигона — по его текстуре, заполняя буфер экрана цветами пикселей и z-буфер значениями глубины.
При рейкастинге (мы пока не берём в счёт отражения луча) для каждого пикселя экрана перебираются все полигоны и находится ближайший, из текстуры которого берётся цвет.
Получается, что и здесь, и там — выполняются одни и те же вложенные циклы. Но почему рейкастинг до сих пор не захватил мир?
Одно дело просто пройтись по всем видимым полигонам, другое дело пройтись по всем полигонам для каждого пикселя (посчитайте сколько их в 4к разрешении). Поэтому применяют всевозможные структуры для доступа к данным (octree, kd-tree и пр). Но всё равно перебор полигонов для каждого пикселя даже с учетом деревьев довольно затратное занятие, особенно, если учесть что SIMD архитектура видеокарт для этого не предназначена. Поэтому появились т.н. RTX ядра, которые решают эту задачу аппаратно. И всё равно этого недостаточно
Правильно ли я вас понимаю?
1. И здесь, и там сложность алгоритма кубическая, т.к. общее количество итераций равно произведению кол-ва полигонов на кол-во пикселей (текстуры или экрана).
2. Если внешний цикл перебирает полигоны, а внутренний — текстурные координаты, то это облегчает задачу для GPU, т.к. все вычислительные потоки заняты одной и той же работой с одним куском памяти (текстурой), который может эффективно кешироваться.
3. Если, в случае рейкастинга, внешний цикл перебирает пиксели(лучи), а внутренний — полигоны, то каждое ядро обращается ко всей видеопамяти и выдёргивает данные из всех загруженных текстур, и такая работа с памятью снижает общую производительность.
Не совсем.
В случае обычной растеризации у нас «под пикселем» может быть всего один полигон, а может штук 5-10. Текстурируется (обрабатывается пиксельным шейдером) как правило только один, в этом помогает z-буффер. То есть растрируя полигон, мы проходимся не по пикселям на экране, а по текселям на полигоне и отображаем их на экран. Здесь у нас сложность практически линейная, сколько пикселей на экране — столько и итераций. Конечно, там бывает ещё прозрачная геометрия, всякие слои и пр., но это на суть не влияет.

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

Я рекомендую вам ознакомится с самими понятиями растеризации треугольников и трассировкой или просто почитать эту статью, здесь как раз описана разница между ними и почему в играх в основном используется обычная растеризация habr.com/ru/post/342708
Если бы одного луча на пиксель хватало для получения нормальной картинки — то да, это было бы не сильно медленнее. Но для того, чтобы результат выглядел хоть как-то приемлимо, требуются десятки лучей на пиксель, причем количество этих лучей сильно от поверхности зависит. Всякие денойзеры и разные методы сэмплирования (importance sampling вообще сейчас повсеместно применяется, например) помогают уменьшить количество требуемых для сходимости лучей до приемлимого уровня, но это все равно очень дорого. Плюс еще и любой рейтрейсинг очень недружелюбен к кэшам, т.к. лучи на соседних пикселях (да даже в пределах одного пикселя) могут пойти трейсить вообще разные части сцены. А гпушки крайне не любят плохую работу с кэшом. Растерный пайплайн гораздо больше под внутреннее железо подходит все-таки, его больше 20 лет на это затачивали.
Мне кажется проблема здесь в том, как происходит обращение к данным. Растеризация предельно параллельная задача, которая делает практически только линейные обращения к памяти. Именно поэтому GPU могут обрабатывать такое невероятно количество данных и постоянно увеличиваются в скорости так, как CPU и не снилось. При этом у них еще и сравнительно небольшие кэши, памяти с бОльшими задержаки, но шире шиной. Т.е. все завязано на линейном обращении к памяти и полностью независимых друг от друга вычислениях. Рейтрейсинг же по определению подвержен куче кэш промахов. Для оптимизации, чтобы оно хотя как-то работало, используют всякие иерархические структуры. В нынешних GPU строят BLAS и TLAS структуры. Деревья всегда плохо ложатся на кэши, а уж на SIMD так тем более. Ну и конечно сам объем вычислений на каждый пиксель, когда скорость чрезвычайно зависит от количества геометрии. То, с чем растеризация в общем-то проблем не имеет, ворочая миллионы полигонов в кадре, позволяя делать хитрый кулинг, отрезая все лишнее. С рейтрейсингом то как раз ничего не отрежешь, потому что изначально желание эту самую невидимую геометрию в зеркале или луже увидеть.
Из статьи вынес следующее — никакими обещанными 60/120 fps на новых консолях и не пахнет.
Вам стоить тогда больше почитать. 60 фпс тайтлов полно и будет больше, по крайней мере у бокса. С пс5 сложнее конечно будет. 120 фпс уже есть. Показывали гирзы 5 в таком режиме, dirt 5 так умеет. Все будет и как обычно будет зависеть от конкретной игры.
Уже несколько тайтлов объявили что у них будет ползунок графики между фпс и качеством. Собственно аналогичное было в ps4 pro. Меня вообще удивляет что все хотят производительности топовых гпу от консолей, ценник которых в полностью собранном виде меньше
Нормальным рейтресингом пока вообще не пахнет. И не будет ещё пару десятилетий. Как минимум. Количество вычислений при честном рейтресинге всё ещё на порядки превышает быстродействие нынешних видеокарт. Но направление развития внушает некоторые надежды, что со временем…
А что значит нормальным? GI частично уже пробуют считать в том же метро, а это как по мне главная польза от рейтрейсинг, а не все эти зеркала. На боксе показывали демку майнкрафта, где все освещение path tracing делает.
Если честно, я так и не понял, почему бюджет 8ms, когда под отрисовку кадра у нас есть 33.3ms (30fps)?

Это же только на рейтрейсинг, в бюджет кадра входит не только он, но и другие этапы рендеринга.

Интересно тогда, почему именно столько. И точно ли нельзя пожертвовать временем в других расчётах, компенсировав их (а может и выграв) в просчёте RT.
В расчете сразу оговорено, что это теоретическое допущение. Скажем, в Halo Infinite, где трассировка поддерживается при 4K на 60 FPS, наверняка эта цифра будет меньше. Да и в целом — это скорее на усмотрение каждого отдельного разработчика, чем именно он готов жертвовать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий