company_banner

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

Автор оригинала: Digital Foundry
  • Перевод


По мере приближения запуска нового поколения консолей Insomniac Games начала публиковать больше материалов, раскрывающих подробности о Marvel’s Spider-Man и Marvel's Spider-Man: Miles Morales. Оба проекта задействуют технологию трассировки лучей. На взгляд Алекса Баттальи из Digital Foundry, выглядит она очень достойно, если не сказать, что превосходно. Для старта — весьма недурно.

Тем не менее, читая комментарии в Интернете, он столкнулся с немалым количеством критики по отношению к реализации технологии, а также к частоте и разрешению кадров. Поэтому в новое видео Digital Foundry он решил представить своего рода пособие по трассировке лучей на консолях следующего поколения и объяснить, почему в Marvel's Spider-Man она выглядит именно так.

Итак, обо всем по порядку. Давайте обсудим, для чего именно нужна трассировка лучей в Marvel’s Spider-Man на PS5.

При частоте кадров 30FPS с разрешением 4К трассировка лучей выглядит замечательно. При этом, как заведено в играх Insomniac, динамическое разрешение может использоваться, а может и нет. Здесь трассировка лучей применяется для отражений в игре, подобных тем, которые видны на дверях машин.



Или на этом скриншоте, где герой и город вдалеке отражаются в окне здания.



Согласно пресс-релизу, трассировка лучей также используется для фонового затенения (Ambient Occlusion, AO). Его труднее определить на скриншотах или в видео. Как правило, AO имитирует тени от непрямого освещения в тех областях, куда свету, отражающемуся в окрестностях сцены, труднее добраться.



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



Отражения показываются в разрешении 1080p, тогда как остальная часть изображения — в 4K. Комментаторы жалуются, например, на то, что листья в отражении более редкие либо вовсе отсутствуют по сравнению с теми, которые можно увидеть на «реальном» дереве. Или что некоторые внутриигровые объекты, такие как автомобили или пешеходы, могут не показываться в отражениях. Или на отсутствие теней. Или на пренебрежение мелкими деталями, например, на костюме Человека-паука.



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

Давайте представим, что мы и есть те самые разработчики, которым нужно создать максимально реалистичные отражения, уложившись в заданный бюджет.



Разделим процесс работы с трассировкой лучей на четыре шага. Допустим, нам нужно уложиться в 8 мс для создания отражений для игры на 30 FPS при разрешении 4K.

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

На втором этапе мы запускаем лучи в структуру, созданную на первом.



Чтобы увидеть, попадает ли луч куда-либо, окружим все объекты невидимыми хитбоксами. Таким образом, луч, попавший в сцену, движется сквозь нее до тех пор, пока не зарегистрирует попадание в геометрию. Чем больше лучей мы запускаем, чем дальше они проходят или чем больше хитбоксов заденут, тем больше времени потребуется для этого шага. Эта часть пайплайна трассировки лучей может быть аппаратно ускорена на консолях и ПК.

На следующем этапе происходит затенение попадания или выбор цвета пикселя.



Чем больше попаданий затеняется или чем сложнее затенение, тем больше времени потребуется на этот шаг.



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



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



Одна из первых оптимизаций, к которой мы прибегнем, — уменьшение разрешения для трассировки лучей. Таким образом мы ограничим количество выходящих лучей и сократим время, необходимое для второго и третьего шага.



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



Посмотрим на скриншот из демо The Ghost Runner с включенной трассировкой лучей с разрешением 4K на видеокарте RTX2060 Super. Здесь мы видим некоторые отличия по сравнению с «Человеком-пауком». Unreal Engine 4, на котором создана игра, использует метод трассировки лучей чуть более дорогой по времени, но физически более точный, чем в «Человеке-пауке».



RTX 2060 Super работает аналогично RTX 2070, имеет такую же пропускную способность шины памяти, как и у PS5, и такой же ее объем — 8 ГБ. RTX 2060 Super, скорее всего, станет отличной отправной точкой для сравнения с графическим процессором PlayStation 5.



Когда сцена вместе с отражениями рендерится в 4K, а количество самих отражений на экране столь невелико, как в случае со статичной лужей выше, графический процессор едва укладывается в 30 FPS. Если бы в сцене было больше динамики, частота кадров определенно была бы меньше. Уменьшение осевого разрешения трассировки лучей на 50% и, таким образом, общего разрешения до 1080p увеличивает производительность примерно на 27%, оставляя свободные ресурсы в графическом процессоре для повышения частоты кадров до 30 FPS.



В других сценах можно увидеть более впечатляющие результаты. Как, например, здесь. Отражающая стеклянная поверхность занимает почти весь экран. В этом случае отражения с исходным разрешением 4К приводят к частоте кадров 21 FPS. При этом понижение разрешения отражений до 1080p увеличивает частоту кадров на 58% до 33 FPS при необходимых 30 FPS.

Таким образом, на графическом процессоре с такой же производительностью, что и у PS5, необходимо использовать отражения с трассировкой лучей с более низким разрешением для возможности поддерживать постоянной частоту кадров 30 FPS при общем разрешении 4К. Тогда становится понятным, почему для снижения стоимости трассировки лучей в «Человеке-пауке» будут использоваться отражения только при 1080p.



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

Давайте попробуем сократить время первого шага, уменьшив динамичность либо количество объектов, по отношению к которым будет выполняться трассировка лучей. Так, на показанных ранее скриншотах некоторые динамические объекты могли отсутствовать в отражениях. Или здесь, в геймплейном видео Miles Morales, в массовых сценах порой можно заметить, что некоторые из NPC не отражаются на поверхностях.



По опыту других разработчиков мы знаем, что прорисовка множества персонажей на экране может оказаться очень ресурсоемкой. Например, отрисовка некоторых сцен в Metro Exodus с большим количеством персонажей на RTX 2080 Ti занимает более 4 мс. В нашем случае это окажется половиной отведенного бюджета.

Итак, уменьшение количества динамических объектов на первом этапе трассировки лучей приводит к ускорению процесса, и тогда мы вписываемся в отведенные 8 мс.



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

Например, взглянем на эти скриншоты Battlefield V.





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



Возвращаясь к нашему кадру из «Человека-паука», мы видим, что в отражениях видны объекты, находящиеся очень далеко. Вероятно, было бы очень неприятно, если бы объекты на горизонте отсутствовали в отражениях или постоянно мигали, то появляясь, то исчезая.



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



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

Снова посмотрим на наш скриншот с городом. В отражении на окне можно увидеть более редкие или вовсе отсутствующие листья по сравнению с тем, как они выглядят на изначальной модели дерева. Листья здесь классифицируются как прозрачные, а для прозрачных объектов второй шаг пайплайна занимает больше времени. Мы знаем это из опыта с Battlefield V, где частицы и отражения делают некоторые сцены чрезвычайно дорогими.

image

Что касается «Человека-паука», мы можем уменьшить количество листьев на деревьях в отражениях перед вторым шагом. А еще сделаем так, чтобы эффекты частиц не обрабатывались трассировкой лучей, как здесь, где туман в отражении не отображается.



Теперь мы почти вписываемся в бюджет кадра, но все еще немного его превышаем.



Последняя оптимизация может быть сделана на третьем шаге, где мы используем затенение.

Вернемся снова к нашему скриншоту. Заметили ли вы отсутствие мелких деталей в отражении костюма Человека-паука? Которые видны на его настоящем костюме? Если мы упростим материал в отражении, потребуется меньше времени на его прорисовку.



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



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



Надеемся, на этом примере нам удалось донести представление о том, с какими дилеммами сталкиваются разработчики игр, когда им приходится иметь дело с ограниченным бюджетом производительности и такими дорогостоящими технологиями, как трассировка лучей.
Pixonic
Разрабатываем и издаем игры с 2009 года

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

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

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

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

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

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

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

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

                        Самое читаемое