Что означает ssr в играх
Обман игроков, или как устроены отражения в играх.
ПРЕДИСЛОВИЕ
Довольно часто разработчики игр пытаются сделать отражения в своих играх как можно более правдоподобными, но знаете ли вы, что с отражениями в реальной жизни они не имеют ничего общего. Практически всегда это обман. Создать эффект отблеска зеркал, переотражения на воде, преломление света от осколков стекла помогают многочисленные ухищрения и упрощения создателей игр. Сегодня нескольких таких методах мы и поговорим.
МЕТОДЫ
1. Рендер сцены с нескольких ракурсов. (planar reflections)
Это пожалуй самый распространённый метод создания зеркальных поверхностей в играх. Сцена (видимая игроком часть локации) рендерится (рендер — отрисовка кадра, либо сцены) с нескольких точек, далее уже накладывается на слой, которому нужно создать эффект отражения. Этот процесс добавляет много «гемороя», так как рендер сцены «съедает» очень много ресурсов компьютера, соответственно разработчикам игр требуется дополнительное время на оптимизацию. Довольно часто о таком методе вспоминают только под конец создания проекта, поскольку приоритет стоит у более важных аспектах игры (Например проработка персонажей, создание ландшафта и проработка мира). Пример на скриншотах внизу.
2.Полностью созданная зеркальная комната.
Это был очень популярный способ до начала 2000-х годов. Использовался метод в 99% случаев только для создания зеркал. Он ещё более ресурсозатратен, чем первый способ, зато очень простой в создании. Для начала создаются две абсолютно одинаковых комнаты, выставляется всё те же объекты, те же источники света, вообщем обе комнаты просто дублируются. Самое главное то, что вместо зеркала было просто отверстие в другую комнату, а другая комната просто отражалась по горизонтали. Естественно и сам персонаж в комнате-зеркале spawnился(создавался) и отрисовывался заново. По причинам всё большего нарастания количества объектов в локациях данный метод на сегодняшний день мало кем используется. Пример на скриншотах внизу.
3. Screen-space reflections (упрощённая трассировка лучей).
SSR (Screen-space reflections) появилась задолго технологии RTX от Nvidia, но в целом использует похожий принцип. Однако, в отличие от технологии Nvidia, такой метод задействует трассировку только для тех объектов, которые находятся в поле зрения игрока, остальные же объекты не просчитиваются для экономии ресурсов ПК. Это логично, так как технология впервые появилась в 2011 году, и представила её компания Crytek в своей Crysis 2, а после и в Crysis 3, в то время мощность видеокарты просто не позволяла разработчикам рендерить лишнее. Сейчас же такая технология присутствует во всех современных «движках» («движок» — ПО для создания игры) таких как Unreal Engine 4, Unity, CryEngine и других. Пример на скриншотах внизу.
4. Qube maps (кубическая карта).
Способ очень популярный, хотя не без своих изъянов, таких например как отсутствие игрока в отражении, поскольку кубическая карта «prerender» объект («prerender» объект — объект, отрисованый до присутствия персонажа в локации) а также большая степень размытия, из за чего qube maps нельзя использовать для зеркал. Кубическая карта состоит из шести граней куба, у которого на каждую грань «накладывается» своя текстура. Каждую текстуру можно увидеть только по отдельности, смотря в одно из шести направлений. Определяется такая текстура в зависимости от того, куда смотрит центральная точка на экране игрока. Метод используется как в настоящее время, так и в недалёком прошлом, так как не требует большого количества ресурсов ПК. Саму технологию представила Nvidia в 1999 году вместе со своей видеокартой GeForce 256. Примеры на скриншотах.
5. RTX (Ray Tracing). Трассировка лучей от Nvidia.
Многие считают, что RTX просчитывает тени, источники света и отражения также, как и в реальной жизни, но это не так. Ray Tracing это тоже лишь имитация, но основанная на природных и физических явлениях. Вообще в целом RTX — это целый набор различных технологий, таких например как: создание динамических теней; реалистичных отражений; реалистичных источников света, а также степень их преломления от объектов (перечислена лишь малая часть, на деле их гораздо больше). Благодаря тому, что в видеокартах серии RTX имеются RT ядра и достигается высокая производительность и приемлемый FPS, так как нагрузка на просчёт отражений ложится на них, а не на видеоядро. На самом деле, такой метод может работать и на видеокартах линейки GTX (пример: GTX 1080, 1070), но производительность будет очень низкой. Немного о том, как работает сама технология: это метод комбинированной отрисовки кадра, где отлеживается траектория лучей света во всех точках пространства. Он даёт возможность определить степень освещённости, степень отражения и преломления объектов. Даже сейчас, в 2020 году использовать «на полную» RTX не получается, так как мощности нынешних видеокарт всё ещё не хватает, но будем надеяться на лучшее. Примеры RTX на скриншотах внизу.
6. iRAY. Трассировка лучей на GTX видеокартах.
iRAY на самом деле редко используется непосредственно в играх, зато очень часто использовалась (пока на замену не пришёл RTX) в создании 3D моделей для этих самых игр. О том как работает «Nvidia iRAY» достаточно мало информации, но принцип схож с трассировкой лучей на видеокартах 2000 серии, хотя и с большим количеством упрощений и послаблений (так как до недавнего времени работала только на GTX видеокартах, поддержку RTX добавили в прошлом году). Примеры на скриншотах ниже (с помощью него созданы источники света, отражения на полу на первом скриншоте и в окнах на втором скриншоте).
7.Global illumination и shadow map (глобальное освещение и карты теней).
8. Дополнительная камера.
Этот способ довольно редко используется в играх, так как требует очень много ресурсов и в целом он очень похож на способ #1, однако он очень прост в реализации, поэтому его используют в основном неопытные разработчики. Суть в том, что помимо камеры игрока (через неё вы видите всё, что происходит на экране) создаётся ещё одна с таким ракурсом, чтобы кадр для последующего отражения получился естественным. Далее на полученный кадр накладываются эффекты (самый частый из них это размытие) и для экономии ресурсов понижается разрешение (но даже с пониженным разрешением ресурсов требуется слишком много). Кроме высокого потребления ресурсов ПК, ещё одним недостатком является статичность кадра, то есть где бы ваш персонаж не встал, отражение не перестроится (хотя через «множество костылей» это можно реализовать, но это очень глупо, поскольку есть способы лучше, тот же SSR). Примеры на скриншотах внизу.
КОНЦОВКА
Сегодня вы узнали для себя чуть больше об отражениях в играх, надеюсь вы не жалеете о потраченном времени на прочтение, я же в свою очередь за уделённое мне время вас благодарю. (Можете также посмотреть новый блог о самых популярных игровых условностях у меня в профиле, мне будет приятно если именно вы его прочитаете)
ССЫЛКИ НА ВСЕ ИСТОЧНИКИ
SSLR: Screen Space Local Reflections в AAA-играх
Привет, друг! В этот раз я опять подниму вопрос о графике в ААА-играх. Я уже разобрал методику HDRR (не путать с HDRI) тут и чуть-чуть поговорил о коррекции цвета. Сегодня я расскажу, что такое SSLR (так же известная как SSPR, SSR): Screen Space Local Reflections. Кому интересно — под кат.
Введение в Deferred Rendering
Для начала введу такое понятие как Deferred Rendering (не путать с Deferred Shading, т.к. последнее относится к освещению). В чем суть Deferred Rendering? Дело в том, что все эффекты (такие как освещение, глобальное затенение, отражения, DOF) можно отделить от геометрии и реализовать эти эффекты как особый вид постпроцессинга. К примеру, что нужно, чтобы применить DOF (Depth Of Field, размытие на дальних расстояниях) к нашей сцене? Иметь саму сцену (Color Map) и иметь информацию о позиции текселя (другими словами на сколько пиксель далеко от камеры). Далее — все просто. Применяем Blur к Color Map, где радиус размытия будет зависеть от глубины пикселя (из Depth Map). И если взглянуть на результат — чем дальше объект, тем сильнее он будет размыт. Так что же делает методика Deferred Rendering? Она строит так называемый GBuffer, который, обычно, в себя включает три текстуры (RenderTarget):
В случае с Color map, Normal map вроде все понятно, это обычные Surface.Color текстуры: пожалуй, за исключением того, что вектор нормали может лежать в пределах [-1, 1] (используется простая упаковка вектора в формат [0, 1]).
А вот ситуация с Depth map становится непонятной. Как же Depth map хранит в себе информацию о позиции пикселя, да еще и одним числом? Если говорить сильно упрощенно, трансформация примитива:
Дает нам экранные координаты:
И некоторую информацию о том, насколько “далеко” от камеры пиксель:
Исходя из этого UV нам не нужен, т.к. при рисовании обычного квада на весь экран он и так известен. Поэтому стоит хранить в карте глубины не позицию пикселя, а только глубину.
В дальнейшем мы сможем реконструировать позицию пикселя очень простым способом:
Напомню, что для построения GBuffer необходима такая методика как MRT (Multiple Render Targets), которая рисует модель сразу в несколько Render Target (причем в каждом RT содержится разная информация). Одно из правил MRT — размерность всех Render Target должна быть одинаковой. В случае Color Map, Normal Map — Surface.Color: 32-ух битная RT, где на каждый канал ARGB приходится по 8 бит, т.е. 256 градаций от 0 до 1.
Благодаря такому подходу мы можем применять сложные эффекты к любой геометрии, например самый популярный Screen Space эффект: SSAO (Screen Space Ambient Occlusion). Этот алгоритм анализирует буферы глубины и нормали, считая уровень затенения. Весь алгоритм я описывать не буду, он уже описывался на хабре, скажу лишь то, что задача алгоритма сводится к трассировки карты глубины: у нас есть набор случайных векторов, направленных из считаемого “пикселя” и нам нужно найти кол-во пересечений с геометрией.
Пример эффекта (слева без SSAO, справа с SSAO):
Так же Deferred Shading является Screen Space эффектом. Т.е. для каждого источника света на экране (без всяких оптимизаций) мы рисуем квад в режиме Additive в так называемый RenderTarget: Light Map. И зная мировую позицию “пикселя”, его нормаль, позицию источника света — мы можем посчитать освещенность этого пикселя.
Пример Deferred Shading (освещение выполнено отложено, после отрисовки геометрии):
Достоинства и проблемы Screen Space эффектов
Самый главный плюс Screen Space эффектов — независимость сложности эффекта от геометрии.
Самый главный минус — локальность всех эффектов. Дело в том, что мы постоянно будем сталкиваться с Information Lost, во многих случаях это сильно зависит обзора, поскольку SSE зависит от смежных глубин текселей, которые могут быть сгенерированы любой геометрией.
Ну и стоит отменить, что Screen Space эффекты выполняются полностью на GPU и являются пост-процессингом.
Наконец SSLR
После всей теории мы подошли к такому эффекту, как Screen Space Local Reflections: локальные отражения в экранном пространстве.
Для начала разберемся с перспективной проекцией:
Горизонтальный и вертикальный угол зрения задается FOV (обычно 45 градусов, я предпочитаю 60 градусов), в виртуальной камере они разные т.к. учитывается еще и Aspect Ratio (соотношение сторон).
Окно проекции (там, где мы оперируем UV-space данными) — это, что мы видим, на то мы проецируем нашу сцену.
Передняя и задняя плоскости отсечения это соответственно Near Plane, Far Plane, задаются так же в проекцию как параметры. Делать в случае Deferred Rendering слишком большим значением Far Plane стоит, т.к. точность Depth Buffer сильно упадет: все зависит от сцены.
Теперь, зная матрицу проекции и позицию на окне проекции (а так же глубину) для каждого пикселя мы вычисляем его позицию следующим образом:
После нам нужно найти вектор взгляда на этот пиксель:
В качестве CameraPosition выступает позиция камеры.
И найти отражение этого вектора от нормали в текущем пикселе:
Далее задача сводится к трассировке карты глубины. Т.е. нам нужно найти пересечение отраженного вектора с какой-либо геометрией. Понятное дело, что любая трассировка производится через итерации. И мы в них сильно ограниченны. Т.к. каждая выборка из Depth Map стоит времени. В моем варианте мы берем некоторое начальное приближение L и динамически меняем его исходя из расстояния между нашим текселем и позицией, которую мы “восстановили”:
Вспомогательные функции, перевод мировой точки на экранное пространство:
После завершения итераций мы имеет позицию “пересечения с отраженной геометрией”. А наше значение nuv будет проекцией этого пересечения на экран, т.е. nuv.xy – это UV координаты в экранном нашем пространстве, а nuv.z это восстановленная глубина (т.е. abs(GetDepth(nuv.xy)-nuv.z) должен быть очень маленьким).
В конце итераций L будет показывать расстояние отраженного пикселя. Последний этап — собственно добавление отражения к Color Map:
Разбавим теорию иллюстрациями, исходное изображение (содержание Color Map из GBuffer):
После компиляции шейдера (отражения) мы получим следующую картину (Color Map из GBuffer + результат шейдера SSLR):
Не густо. И тут стоит еще раз напомнить, что Space-Screen эффекты это сплошной Information Lost (примеры выделены в красные рамки).
Дело в том, что если вектор отражения выходит за пределы Space-Screen – информация о Color-карте становится недоступной и мы видим Clamping нашего UV.
Чтобы частично исправить эту проблему, можно ввести дополнительный коэффициент, который будет отражать “дальность” отражения. И далее по этому коэффициенту мы будем затенять отражение, проблема частично решается:
Результат, отражение умноженное на error (попытка убрать артефакт SSLR — information lost):
Уже лучше, но мы замечаем еще одну проблему, что будет, если вектор отразится в направлении камеры? Clamping’а UV происходить не будет, однако, несмотря на актуальность UV (x > 0, y > 0, x
Как работают отражения в играх. Краткая история от рейкастинг-игр до RTX
Привет. Сегодня хотелось бы написать о такой вещи, как отражение света от поверхностей и рассеивании света в видеоиграх. Всё началось с замечательной конторы 3D Realms, которве выпустили свой ответ DOOM- Duke Nukem 3D. В игре было много весёлых и интересных механик, но самой крутой, как я считаю, стали зеркала. Тащемта, зеркалами они и не являются. Это всего лишь отражённая зеркально такая же комната, внутри которой находится такой же зеркальный спрайт ГГ, который повторяет за игроком все движения. Тогда это было круто, но немногие понимали работу этих псевдозеркал.
Но рендерить сразу две комнаты было очень сложно и потому сообразительные ребятки из Nvidia в 1999 году выпустили свой очередной опус: nvidia geforce 256. Одной из её самых крутых особенностей была поддержка cube maps — кубических карт отражений. Для создания кубической карты из центра локации захватываются шесть плоских изображений, которые ужимаются и наносится на плоскости невидимого для игрока куба, после чего его грани сглаживаются — получается панорамный шар, затекстуренный изнутри.
Так создавались отражения в Half-Life 2, Crysis и многих других играх, которые выходили в начале нулевых.
Но и этого разрабам показалось мало.
В 2011 году гении из Crytek добавила в Crysis 2 шейдер, который получал отражения при помощи трассировки лучей только к видимым на экране объектам, используя информацию с предыдущих стадий рендеринга. Эта технология получила название screen space reflections (или просто SSR), и сейчас используется повсеместно.
SSR — ресурсозатратный процесс, но нагрузка на движок получается ниже, чем от дополнительного рендера, который использовался в том же Duke Nukem.
Для отражения SSR использует только те ресурсы, которые видит сам игрок. Если какой-то объект хотя бы частично остаётся за кадром, то и его отражение в воде или в витрине не будет прорисовываться до конца. И это было одним из камнем предкновения: представьте, что вы стоите на берегу озера. Кристальная гладь воды отражает лес на том берегу. И вот вы увидели красивый камушек у себя под ногой. Вы наклоняетесь чтобы поднять его, лес пропадает из вашего поля зрения и вы видите, что вместе с ним пропало отражение и теперь вы видите только синюю воду. Страшно, да? А ведь это до сих пор используется в играх и в движках.
SSR часто применяют в комбинации с другими методами отражения. Например, в том же Spider-Man от Insomniac Games стеклянные фасады небоскрёбов чередуют SSR с кубическими отражениями. Первые используются в важных для сюжета местах и улицах с плотным трафиком — в отличие от cube maps, SSR может убедительно показать отражения пешеходов и автомобилей, хотя и искажает перспективу.
На первом скриншоте видно, как исчезает отражение модели игрока (unreal engine 4). Это были самые наичестнейшие отражения на тот момент
Но честный просчёт физики света и отражений был для обычных геймеров чем-то, что находится за гранью реальности и доступно только таким серьёзным корпорациям, которые делают фильмы и 3D мультфильмы, таким как Disney или Warner Brothers.
Но не так давно такой гигант, как ранее упомянутая Nvidia, выпускает линейку видеокарт RTX, которые меняют в корне представления о реалистичном свете. Это был прорыв! Теперь каждый, кто отдаст более 1к мёртвых американских президентов, может получить это чудо техники себе. Честные отражения, рассеивание света и его преломления в зависимости от типа поверхности: всё это стало реальностью. Игры стали ещё более реалистичными. На сводах пещер появились честные каустики, свет, проходя в окно комнаты не просто освещал её, но рассеивался от пола на стены, создавая максимально реалистичную модель освещения. Теперь игры стали более похожи на реальный мир.
Различия между ванильным Quake 2 и модом Quake 2 RTX. Обратите внимание на шахту системы вентиляции и на то, как приломляется свет.
Игры становятся всё более и более реалистичными и, возможно, скоро они будут передавать всю физику реального мира.
Если есть какие-то замечания/предложения- буду рад прочитать!
Русские Блоги
[OpenGL] Эффект отражения экранного пространства
Введение в концепцию
Отражение экранного пространства, также известное как SSR, является одним из алгоритмов серии SS. Алгоритм основан на отложенном рендеринге, то есть перед внедрением SSR вам необходимо знать об отложенном рендеринге, включая: запись информации, относящейся к G-буферу, и восстановление положения, вектора линии визирования, нормали и т. Д. В соответствии с G-буфером. Серия информации и т. Д.
Принцип самого алгоритма очень прост, то есть для каждого пикселя объекта в пространстве экрана решается вектор отражения в соответствии с информацией о нормали и линии визирования, соответствующей пикселю. Затем начните с текущей точки и шагайте по направлению вектора отражения, чтобы определить, равна ли глубина координат после пошагового перехода глубине объекта, хранящегося в G-буфере. Если они равны, это означает, что есть пересечение, и цвет объекта на пересечении принимается в качестве окончательного Цвет отражения.
Сам по себе этот алгоритм не является реальным отражением, а представляет собой грубое моделирование отражения, поэтому его эффект намного хуже, чем у оптического отслеживания в реальном времени. Согласно экспериментам, если SSR реализован чисто без какой-либо оптимизации или маскировки, эффект действительно Очень плохой.
Во-первых, есть существенное ограничение: поскольку это алгоритм экранного пространства, он может получать только те цвета пикселей, которые можно увидеть на текущем экране. Если часть столкновения отражения является частью объекта, который перекрывается, часть за пределами камеры В такие места потом попасть невозможно. Для пикселей, не прошедших проверку попадания, можно использовать выборку только кубического отображения (из кубической карты фона или предварительно обработанной кубической карты окружающей сцены), чтобы восполнить недостаток, или, если возможно, данные могут быть получены из предыдущего кадра в движущемся изображении.
Другая очень серьезная проблема заключается в том, что, поскольку наше обнаружение пересечения представляет собой алгоритм легкого пошагового выполнения, а пошаговое выполнение имеет определенную длину шага, оно не может быть очень точным. Поскольку при пошаговом режиме существует определенный интервал, будут появляться артефакты в форме полос или некоторые места, где отражения не должны появляться, поскольку существует ошибка в определении равных чисел с плавающей запятой, это может быть ошибочно оценено как отражение попадания, поэтому появляются странные цвета. В первом случае, если мы внесем случайное возмущение в начальную позицию светового шага, эффект будет немного лучше (но на самом деле он только превратит искаженное изображение в форме полосы в искаженное изображение с зернистым шумом, что эквивалентно изменению искажения. «Равномерно разложить» в сторону Ray-match).
Это ограничение также ограничивает сценарии применения SSR. Например, если мы хотим добиться очень гладкого и четкого зеркального эффекта, то лучшим выбором должна быть плоская проекция, которая заключается в использовании дополнительной камеры для рендеринга сцены в зеркале отдельно (трассировка лучей также возможна, но она плавно применяется в играх. По оценкам, некоторые трудности все еще существуют). Что касается SSR, мы обычно используем его там, где качество отражения не такое высокое, например, вода на земле после дождя или высокие здания со светозагрязненным стеклом. В первом случае цвет и очертания отраженного объекта можно смутно различить из стоячей воды. Поскольку сама стоячая вода имеет некоторые нормальные возмущения и помехи в освещении, она в определенной степени исказит изображение. В это время отражение Точность изображения не так уж и важна.
Мы вводим в игру SSR, который представляет собой относительно недорогой метод отражения в реальном времени, который в определенной степени улучшит качество изображения, а также изменит содержание отражения по мере движения объекта. В это время в сочетании с традиционным методом отражения, то есть кубическая карта объединяется, и система отражения может быть изначально построена.
Демонстрация эффекта
Я сделал эту демонстрацию, потому что случайно увидел описание алгоритма отражения экранного пространства, когда читал книгу. В нем всего несколько строк, но я могу понять смысл после прочтения. Поэтому я подумал о повторной реализации этого алгоритма, чтобы увидеть, есть ли какие-нибудь проблемы с моим пониманием. Конечно, я очень сожалею об этом после того, как сделал это, потому что эффект от простого внедрения SSR будет очень разочаровывающим.В основном, картина, которую можно увидеть, выглядит так:
Эффект 1：
Если порог сравнения слишком велик, будут возникать повторяющиеся отражения, такие как отражения, появляющиеся под сферой, где отражения не должны появляться.
Эффект 2：
Если шаг выборки слишком велик, появятся артефакты полосатости.
Эффект 3：
Добавьте случайный шум возмущения в начальную позицию трассировки лучей для эффекта 2,
Но на самом деле он меняется с артефактов полос на артефакты зернистости.
Эффект 4 ：
На основе эффекта 3 размер шага уменьшается (исходный размер шага 2/5), а искажения лучше
Эффект 5 ：
Добавлена оптимизация бинарного поиска на основе эффекта 4, но кажется, что отражения появятся там, где отражения не должны появляться
также может быть связано с выбором порога. Бинарный поиск более точен и требует меньшего порога.
Эффект 6 ：
На основе эффекта 5 порог сравнения глубины во время двоичного поиска немного снижен, чтобы уменьшить количество ложных отражений.
В любом случае, это не похоже на эффект, который можно хорошо применить к игровому контенту. Я не слишком оптимизировал результаты и едва смог добиться эффекта исходного изображения, но все же не могу избежать некоторых неверно идентифицированных отражений (например, некоторых белых шумов слева и справа от нижней части сферы), а также возможности неправильного получения изображения под определенными углами. Цвет отражения.
Эффект 7：
Отражение полностью открыто, а цвет отражения размыт
Эффект 8：
Один из недостатков алгоритма, например, если верхняя часть мяча вынесена за пределы экрана, полученный результат отражения будет неполным.
Реализация
В настоящее время все вычисления выполняются в пространстве просмотра. Возможно, будет более точным использовать постоянный размер шага в пространстве экрана.
Сначала вычислите вектор отражения и преобразуйте вектор отражения в пространство обзора. Mat3 добавлен, чтобы исключить эффект смещения.
После этого я получил случайный размер начального шага.Я получил этот джиттер из проекта объемного света и не подтвердил, как Crytex сделал это в начале.
Получите основной цвет объекта из g-буфера, а затем смешайте основной цвет и цвет отражения, выбранный кубической картой, для пикселей, которые должны быть отражены как цвет значения отражения по умолчанию.
Установите длину шага и общее количество шагов. Здесь количество шагов также может быть записано как фиксированное значение в соответствии с потребностями. Это эквивалентно тому, что объекты, находящиеся слишком далеко, относятся к вторичной информации, поэтому отражение не рассчитывается.
Начните входить в цикл Ray-Match, сначала рассчитайте длину шага в направлении вектора отражения, а затем получите окончательное положение шага pos:
Запишите текущую глубину. Для объекта перед камерой глубина отрицательная, поэтому мы принимаем обратное:
Затем положение пространства просмотра преобразуется в пространство экрана. В это время диапазон значений x, y равен [-1,1]. Переназначить его на [0,1], что соответствует координатам текстуры G-буфера. :
Когда обнаруживается, что глубина луча больше, чем глубина объекта в сцене, дополнительно оценивается, меньше ли разница между ними, чем определенный порог.По результатам оценки положение считается положением отражения. Мы выбираем цвет размытия по Гауссу, а затем выходим из цикла.
Рассчитайте ленивую версию размытого цвета (потому что лучше использовать mipmap для понижающей дискретизации или размытия горизонтального и вертикального направлений 🙂
Оптимизация двоичного поиска также выполняется локально. Основная идея состоит в том, чтобы использовать текущую позицию выборки и предыдущую позицию выборки в качестве двух конечных точек пополам, когда глубина луча больше глубины объекта сцены, а затем определять глубину и сцену в средней позиции выборки. Если разница в глубине объекта меньше определенного порога, в противном случае установите начальную точку как текущую среднюю точку или конечную точку как текущую среднюю точку в соответствии с соотношением между двумя глубинами.
Лучше всего установить ограничение на количество циклов (оно будет зависать, если не было установлено ранее). Я думаю, это потому, что глубина сцены не монотонна, ее глубина монотонна лишь частично. В противном случае мы будем выполнять двоичный поиск в начале вместо того, чтобы находить диапазон значений пересечения, а затем проводить дихотомию в этом небольшом диапазоне. Мы можем провести дихотомию в этом небольшом диапазоне, потому что мы согласны с тем, что этот раздел может быть удовлетворен. Локальная монотонность. Но это не абсолютное значение, поэтому мы все еще можем не найти конечную позицию попадания, поэтому необходимо установить максимальное количество циклов.
После добавления двоичного поиска, хотя отражающих попаданий действительно намного больше, но есть цвета отражения во многих местах, где не должно быть отражающих попаданий. Предполагается, что существует определенная взаимосвязь с выбором порога:
некоторые проблемы
Кроме того, эта реализация оставила некоторые проблемы:
Кроме того, текстура глубины объекта сцены, которую мы выбрали, является глубиной передней части объекта, а объект имеет толщину. При вычислении точки пересечения вектора отражения и объекта она должна пересекаться с задней стороной объекта. Поскольку глубина задней части неизвестна, она может быть Просчитано как пересечение объекта спереди. Если объект сплошного цвета, ошибка не выглядит столь очевидной, но если разница в цвете между передней и задней текстурами велика, выбранный цвет отражения будет иметь очень очевидную мутацию.