Как сделать трассировку лучей в современном OpenGL?
Итак, я нахожусь в точке, что я должен начать освещать мои плоские цветные модели. Тестовое приложение является тестовым случаем для реализации только последних методов, поэтому я понял, что в идеале он должен реализовывать трассировку лучей (так как теоретически он может быть идеальным для графики в реальном времени через несколько лет).
но с чего начать?
предположим, что я никогда не делал освещение в старом OpenGL, поэтому я буду переходить непосредственно к не устаревшим методам.
в приложение в настоящее время правильно настроило объекты буфера вершин, вершинный, нормальный и цветной вход и правильно рисует и преобразует модели в пространстве, в плоский цвет.
есть ли источник информации, который взял бы один из плоских цветных вершин ко всему, что необходимо для правильного конечного результата через GLSL? В идеале с любыми другими дополнительными методами освещения, которые могут потребоваться для его дополнения.
2 ответов
Я бы не советовал пробовать фактическую трассировку лучей в OpenGL, потому что для этого вам нужно много хаков и трюков, и, если вы спросите меня, нет смысла делать это вообще. Если вы хотите сделать трассировку лучей на GPU, вы должны пойти с любым языком GPGPU, таким как CUDA или OpenCL, потому что это делает вещи намного проще (но все же, далеко не тривиально).
чтобы проиллюстрировать проблему немного дальше: Для raytracing, вам нужно проследить вторичные лучи и испытать для пересечения с геометрия. Поэтому вам нужен доступ к геометрии каким-то умным способом внутри вашего шейдера, однако внутри шейдера фрагментов вы не можете получить доступ к геометрии, если вы не сохраняете ее "закодированной" в некоторую текстуру. Вершинный шейдер также не предоставляет вам эту информацию геометрии изначально, а геометрические шейдеры знают только соседей, поэтому здесь проблема уже начинается. Затем вам нужны структуры данных ускорения, чтобы получить любые разумные частоты кадров. Однако, пересекая, например, KD-дерево внутри a шейдер довольно сложный, и если я правильно помню, есть несколько работ исключительно по этой проблеме. Если вы действительно хотите пройти этот маршрут, хотя, есть много работ на эту тему, это не должно быть слишком трудно найти их.
трассировщик лучей требует чрезвычайно хорошо разработанных шаблонов доступа и кэширования для достижения хорошей производительности. Однако у вас есть только небольшой контроль над ними внутри GLSL, и оптимизация производительности может стать очень жесткой.
еще один момент отметить это, по крайней мере, насколько мне известно, трассировка лучей в реальном времени на графических процессорах в основном ограничена статическими сценами, потому что, например, KD-деревья работают только (хорошо) для статических сцен. Если вы хотите иметь динамические сцены, вам нужны другие структуры данных (например, BVHs, iirc?) но вы постоянно должны поддерживать их. Если я ничего не пропустил, в настоящее время все еще много исследований по этому вопросу.
вы можете запутать некоторые вещи.
OpenGL-растеризатор. Заставить его делать рэйтрейсинг возможно, но трудно. Вот почему raytracing не является "идеальным для графики в реальном времени через несколько лет". Через несколько лет жизнеспособными будут только гибридные системы.
Итак, у вас есть три послебатыевское.
- чистый raytracing. Визуализация только полноэкранного квадрата, а в шейдере фрагментов прочитайте описание сцены, упакованное в буфер( например, текстуру), траверс иерархия и вычисление пересечений лучей-треугольников.
- гибридный raytracing. Растеризуйте свою сцену обычным способом и используйте raytracing в шейдере на некоторых частях сцены, которые действительно этого требуют (рефракция,... но он может быть simultated в rasterisation)
- чисто растеризации. Шейдер фрагментов выполняет свою обычную работу.
Что именно вы хотите достичь ? Я могу улучшить ответ в зависимости от ваших потребностей.
в любом случае, это так вопрос тесно связана. Даже если эта конкретная реализация имеет ошибку, это определенно путь. Другая возможность-openCL, но концепция та же.