Как сделать трассировку лучей в современном OpenGL?

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

Но с чего начать?

Предположим, что я никогда не делал освещения в старом OpenGL, поэтому я бы пошел прямо на не устаревшие методы.

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

Есть ли источник информации, который бы взял один из плоских цветных вершин ко всему, что необходимо для правильного конечного результата через GLSL? В идеале с любыми другими дополнительными методами освещения, которые могут потребоваться для его дополнения.

Ответ 1

Я бы не посоветовал попробовать реальную трассировку лучей в OpenGL, потому что для этого вам нужны много хаков и трюков, и, если вы спросите меня, больше нет смысла делать это. Если вы хотите выполнить трассировку лучей на графическом процессоре, вы должны перейти на любой язык GPGPU, такой как CUDA или OpenCL, потому что это делает вещи намного проще (но все же, далеко не тривиально).

Чтобы проиллюстрировать проблему немного дальше: Для трассировки лучей вам нужно проследить вторичные лучи и проверить пересечение с геометрией. Поэтому вам необходим доступ к геометрии каким-то умным способом внутри шейдера, однако внутри шейдера фрагмента вы не можете получить доступ к геометрии, если вы не храните его "закодировано" в некоторую текстуру. Вершинный шейдер также не предоставляет вам эту информацию геометрии изначально, а геометрические шейдеры знают только соседей, поэтому здесь проблема уже началась. Затем вам нужны структуры данных ускорения, чтобы получить разумные частоты кадров. Однако перемещение, например, Kd-Tree внутри шейдера довольно сложно, и, если я правильно помню, есть несколько статей только по этой проблеме. Если вы действительно хотите пройти этот маршрут, тем не менее, есть много статей по этой теме, их не должно быть слишком сложно найти.

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

Еще один момент, который следует отметить, заключается в том, что, по крайней мере, насколько мне известно, трассировка лучей в реальном времени на графических процессорах в основном ограничена статическими сценами, поскольку, например, kd-деревья работают (хорошо) для статических сцен. Если вы хотите иметь динамические сцены, вам нужны другие структуры данных (например, BVH, iirc?), Но вам постоянно нужно их поддерживать. Если я ничего не пропустил, в настоящее время продолжается много исследований по этой проблеме.

Ответ 2

Возможно, вы что-то путаете.

OpenGL - это растеризатор. Заставлять его делать трассировку лучей возможно, но сложно. Вот почему raytracing не "идеально подходит для графики в реальном времени через несколько лет". Через несколько лет только гибридные системы будут жизнеспособными.

Итак, у вас есть три возможности.

Чистая трассировка. Выполните рендеринг только полноэкранного квадроцикла и в своем шейдере фрагмента прочитайте описание сцены, упакованное в буфер (например, текстуру), перейдите по иерархии и вычислите пересечения лучей треугольников.
Гибридная трассировка. Растрируйте свою сцену обычным способом и используйте raytracing в вашем шейдере на некоторых участках сцены, которые действительно требуют этого (преломление,... но это может быть одновременно в растеризации).
Чистая растеризация. Фрагментный шейдер выполняет свою нормальную работу.

Что именно вы хотите достичь? Я могу улучшить ответ в зависимости от ваших потребностей.

В любом случае, этот вопрос SO очень важен. Даже если эта конкретная реализация имеет ошибку, это определенно путь. Другая возможность - openCL, но концепция одинаков.