Комментарии 23
Почему нельзя просто запечь отражение статических объектов типа города с его домами и деревьями, а динамически отражать только движущиеся объекты, типа Спайдермена, автомобилей, людей?
0
Так со всех ракурсов чтоб нормально это выглядело потребуется еще больше нагружать систему, наверно поэтому. Представьте себе, что при каждом новом угле обзора это проделать
+2
Отчасти ответ дан в этом абзаце:
Технология тяжеловесная даже для статики, не говоря уже о динамически изменяющихся объектах. К тому же, когда объект не меняется во времени, его качественность больше цепляет глаз, чем при быстром перемещении. Здесь почти та же дилемма, что и с крупными объектами и мелкими частицами — что проще заметить, на том и акцент.
Когда сцена вместе с отражениями рендерится в 4K, а количество самих отражений на экране столь невелико, как в случае со статичной лужей выше, графический процессор едва укладывается в 30 FPS. Если бы в сцене было больше динамики, частота кадров определенно была бы меньше.
Технология тяжеловесная даже для статики, не говоря уже о динамически изменяющихся объектах. К тому же, когда объект не меняется во времени, его качественность больше цепляет глаз, чем при быстром перемещении. Здесь почти та же дилемма, что и с крупными объектами и мелкими частицами — что проще заметить, на том и акцент.
0
Сейчас в общем-то плюс минус так и делают (через кубические карты + ssr), основная проблема это нормально свести запеченые отражения с реалтаймовыми так, чтобы объекты не «парили», чтобы свет совпадал, и т.д.
Конкретно у подхода «трассировать только динамику» есть как минимум одна ключевая проблема: что делать, если динамический объект частично перекрывается статическим? Например, человек стоит за деревом. Если трассировка не будет учитывать статику, то отражение человека будет выглядеть так, словно он стоит перед деревом, а не за ним.
Конкретно у подхода «трассировать только динамику» есть как минимум одна ключевая проблема: что делать, если динамический объект частично перекрывается статическим? Например, человек стоит за деревом. Если трассировка не будет учитывать статику, то отражение человека будет выглядеть так, словно он стоит перед деревом, а не за ним.
+4
Занимательная статья, только то что сравнение ведётся с 2060с и 2070 вызовет сильное жжение у адептов, ведь они свято верят, в том что у пс5 и сериес х стоят аналоги 2070с и не меньше
-2
И всё же, в чём фундаментальная причина того, что рейтрейсинг такой медленный?
При обычном рендеринге GPU проходит циклом по всем (видимым) полигонам и для каждого полигона — по его текстуре, заполняя буфер экрана цветами пикселей и z-буфер значениями глубины.
При рейкастинге (мы пока не берём в счёт отражения луча) для каждого пикселя экрана перебираются все полигоны и находится ближайший, из текстуры которого берётся цвет.
Получается, что и здесь, и там — выполняются одни и те же вложенные циклы. Но почему рейкастинг до сих пор не захватил мир?
При обычном рендеринге GPU проходит циклом по всем (видимым) полигонам и для каждого полигона — по его текстуре, заполняя буфер экрана цветами пикселей и z-буфер значениями глубины.
При рейкастинге (мы пока не берём в счёт отражения луча) для каждого пикселя экрана перебираются все полигоны и находится ближайший, из текстуры которого берётся цвет.
Получается, что и здесь, и там — выполняются одни и те же вложенные циклы. Но почему рейкастинг до сих пор не захватил мир?
0
Одно дело просто пройтись по всем видимым полигонам, другое дело пройтись по всем полигонам для каждого пикселя (посчитайте сколько их в 4к разрешении). Поэтому применяют всевозможные структуры для доступа к данным (octree, kd-tree и пр). Но всё равно перебор полигонов для каждого пикселя даже с учетом деревьев довольно затратное занятие, особенно, если учесть что SIMD архитектура видеокарт для этого не предназначена. Поэтому появились т.н. RTX ядра, которые решают эту задачу аппаратно. И всё равно этого недостаточно
+2
Правильно ли я вас понимаю?
1. И здесь, и там сложность алгоритма кубическая, т.к. общее количество итераций равно произведению кол-ва полигонов на кол-во пикселей (текстуры или экрана).
2. Если внешний цикл перебирает полигоны, а внутренний — текстурные координаты, то это облегчает задачу для GPU, т.к. все вычислительные потоки заняты одной и той же работой с одним куском памяти (текстурой), который может эффективно кешироваться.
3. Если, в случае рейкастинга, внешний цикл перебирает пиксели(лучи), а внутренний — полигоны, то каждое ядро обращается ко всей видеопамяти и выдёргивает данные из всех загруженных текстур, и такая работа с памятью снижает общую производительность.
1. И здесь, и там сложность алгоритма кубическая, т.к. общее количество итераций равно произведению кол-ва полигонов на кол-во пикселей (текстуры или экрана).
2. Если внешний цикл перебирает полигоны, а внутренний — текстурные координаты, то это облегчает задачу для GPU, т.к. все вычислительные потоки заняты одной и той же работой с одним куском памяти (текстурой), который может эффективно кешироваться.
3. Если, в случае рейкастинга, внешний цикл перебирает пиксели(лучи), а внутренний — полигоны, то каждое ядро обращается ко всей видеопамяти и выдёргивает данные из всех загруженных текстур, и такая работа с памятью снижает общую производительность.
0
Не совсем.
В случае обычной растеризации у нас «под пикселем» может быть всего один полигон, а может штук 5-10. Текстурируется (обрабатывается пиксельным шейдером) как правило только один, в этом помогает z-буффер. То есть растрируя полигон, мы проходимся не по пикселям на экране, а по текселям на полигоне и отображаем их на экран. Здесь у нас сложность практически линейная, сколько пикселей на экране — столько и итераций. Конечно, там бывает ещё прозрачная геометрия, всякие слои и пр., но это на суть не влияет.
В случае с трассировкой лучей мы в каждом пикселе экрана перебираем вообще все полигоны, то есть сложность квадратичная, но это в общем случае, на деле, там конечно оптимизации через деревья, в итоге сложность перебора около логарифмическая.
Я рекомендую вам ознакомится с самими понятиями растеризации треугольников и трассировкой или просто почитать эту статью, здесь как раз описана разница между ними и почему в играх в основном используется обычная растеризация habr.com/ru/post/342708
В случае обычной растеризации у нас «под пикселем» может быть всего один полигон, а может штук 5-10. Текстурируется (обрабатывается пиксельным шейдером) как правило только один, в этом помогает z-буффер. То есть растрируя полигон, мы проходимся не по пикселям на экране, а по текселям на полигоне и отображаем их на экран. Здесь у нас сложность практически линейная, сколько пикселей на экране — столько и итераций. Конечно, там бывает ещё прозрачная геометрия, всякие слои и пр., но это на суть не влияет.
В случае с трассировкой лучей мы в каждом пикселе экрана перебираем вообще все полигоны, то есть сложность квадратичная, но это в общем случае, на деле, там конечно оптимизации через деревья, в итоге сложность перебора около логарифмическая.
Я рекомендую вам ознакомится с самими понятиями растеризации треугольников и трассировкой или просто почитать эту статью, здесь как раз описана разница между ними и почему в играх в основном используется обычная растеризация habr.com/ru/post/342708
+4
Если бы одного луча на пиксель хватало для получения нормальной картинки — то да, это было бы не сильно медленнее. Но для того, чтобы результат выглядел хоть как-то приемлимо, требуются десятки лучей на пиксель, причем количество этих лучей сильно от поверхности зависит. Всякие денойзеры и разные методы сэмплирования (importance sampling вообще сейчас повсеместно применяется, например) помогают уменьшить количество требуемых для сходимости лучей до приемлимого уровня, но это все равно очень дорого. Плюс еще и любой рейтрейсинг очень недружелюбен к кэшам, т.к. лучи на соседних пикселях (да даже в пределах одного пикселя) могут пойти трейсить вообще разные части сцены. А гпушки крайне не любят плохую работу с кэшом. Растерный пайплайн гораздо больше под внутреннее железо подходит все-таки, его больше 20 лет на это затачивали.
+4
Мне кажется проблема здесь в том, как происходит обращение к данным. Растеризация предельно параллельная задача, которая делает практически только линейные обращения к памяти. Именно поэтому GPU могут обрабатывать такое невероятно количество данных и постоянно увеличиваются в скорости так, как CPU и не снилось. При этом у них еще и сравнительно небольшие кэши, памяти с бОльшими задержаки, но шире шиной. Т.е. все завязано на линейном обращении к памяти и полностью независимых друг от друга вычислениях. Рейтрейсинг же по определению подвержен куче кэш промахов. Для оптимизации, чтобы оно хотя как-то работало, используют всякие иерархические структуры. В нынешних GPU строят BLAS и TLAS структуры. Деревья всегда плохо ложатся на кэши, а уж на SIMD так тем более. Ну и конечно сам объем вычислений на каждый пиксель, когда скорость чрезвычайно зависит от количества геометрии. То, с чем растеризация в общем-то проблем не имеет, ворочая миллионы полигонов в кадре, позволяя делать хитрый кулинг, отрезая все лишнее. С рейтрейсингом то как раз ничего не отрежешь, потому что изначально желание эту самую невидимую геометрию в зеркале или луже увидеть.
+1
Из статьи вынес следующее — никакими обещанными 60/120 fps на новых консолях и не пахнет.
0
Вам стоить тогда больше почитать. 60 фпс тайтлов полно и будет больше, по крайней мере у бокса. С пс5 сложнее конечно будет. 120 фпс уже есть. Показывали гирзы 5 в таком режиме, dirt 5 так умеет. Все будет и как обычно будет зависеть от конкретной игры.
+3
Уже несколько тайтлов объявили что у них будет ползунок графики между фпс и качеством. Собственно аналогичное было в ps4 pro. Меня вообще удивляет что все хотят производительности топовых гпу от консолей, ценник которых в полностью собранном виде меньше
+1
Нормальным рейтресингом пока вообще не пахнет. И не будет ещё пару десятилетий. Как минимум. Количество вычислений при честном рейтресинге всё ещё на порядки превышает быстродействие нынешних видеокарт. Но направление развития внушает некоторые надежды, что со временем…
-1
Если честно, я так и не понял, почему бюджет 8ms, когда под отрисовку кадра у нас есть 33.3ms (30fps)?
0
Это же только на рейтрейсинг, в бюджет кадра входит не только он, но и другие этапы рендеринга.
0
Интересно тогда, почему именно столько. И точно ли нельзя пожертвовать временем в других расчётах, компенсировав их (а может и выграв) в просчёте RT.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проблемы рейтрейсинга в играх нового поколения: анализ трассировки лучей в ремастере Marvel's Spider-Man