¿Cómo hacer el trazado de rayos en OpenGL moderno?

Question

Así que estoy en un punto en el que debería comenzar a encender mis modelos de color plano. La aplicación de prueba es un caso de prueba para la implementación de los últimos métodos, así que me di cuenta de que idealmente debería implementar el trazado de rayos (ya que teóricamente, podría ser ideal para gráficos en tiempo real en unos pocos años).

¿Pero dónde empiezo?

Supongamos que nunca he hecho iluminación en OpenGL antiguo, por lo que iría directamente a métodos no desaprobados.

La aplicación ha configurado correctamente objetos de búfer de vértice, vértice, entrada normal y de color y dibuja y transforma modelos en el espacio correctamente, en un color plano.

¿Existe alguna fuente de información que pueda tomar uno de los vértices de colores planos a todo lo que se necesita para obtener un resultado final adecuado a través de GLSL? Idealmente con cualquier otro método de iluminación adicional que pueda ser necesario para complementarlo.

Answer 1

No aconsejaría probar el trazado real de rayos en OpenGL porque se necesitan muchos trucos y trucados para eso y, si me preguntan, ya no tiene sentido seguir haciéndolo. Si desea hacer un trazado de rayos en una GPU, debe usar cualquier lenguaje GPGPU, como CUDA o OpenCL, ya que facilita mucho las cosas (pero aún más, no es trivial).

Para ilustrar el problema un poco más lejos: Para el trazado de rayos, es necesario trazar los rayos secundarios y probar la intersección con la geometría. Por lo tanto, necesita acceder a la geometría de alguna manera inteligente dentro de su sombreador, sin embargo, dentro de un sombreador de fragmentos, no puede acceder a la geometría, si no la almacena "codificada" en alguna textura. El sombreador de vértices tampoco proporciona esta información de geometría de forma nativa, y los sombreadores de geometría solo conocen los vecinos, por lo que aquí el problema ya comienza. A continuación, necesita estructuras de datos de aceleración para obtener cualquier frame-rate razonable. Sin embargo, atravesando, por ejemplo, un Kd-Tree dentro de un shader es bastante difícil y si mal no recuerdo, hay varios documentos exclusivamente sobre este problema. Si realmente quieres seguir esta ruta, hay muchos artículos sobre este tema, no debería ser demasiado difícil encontrarlos.

Un ray tracer requiere patrones de acceso y caché extremadamente bien diseñados para alcanzar un buen rendimiento. Sin embargo, usted tiene poco control sobre estos dentro de GLSL y la optimización del rendimiento puede ser realmente difícil.

Otro punto a tener en cuenta es que, al menos que yo sepa, el trazado de rayos en tiempo real en las GPU se limita principalmente a escenas estáticas porque, p. los kd solo funcionan (bien) para escenas estáticas. Si desea tener escenas dinámicas, necesita otras estructuras de datos (por ejemplo, BVH, iirc?) Pero necesita mantenerlas constantemente. Si no me he perdido nada, todavía hay mucha investigación sobre este tema.

Answer 2

Puede confundir algunas cosas.

OpenGL es un rasterizador. Obligarlo a hacer raytracing es posible, pero difícil. Esta es la razón por la que raytracing no es "ideal para gráficos en tiempo real en unos pocos años". En unos pocos años, solo los sistemas híbridos serán viables.

Entonces, tiene tres posibilidades.

• Raytracing puro. Represente solo un cuadrángulo de pantalla completa y en su sombreador de fragmentos, lea la descripción de su escena empaquetada en un búfer (como una textura), recorra la jerarquía y calcule intersecciones de rayos y triángulos.
• Rayado híbrido. Rasterize su escena de la manera normal, y use raytracing en su sombreador en algunas partes de la escena que realmente lo requiera (refracción, ... pero se puede simular en rasterización)
• Rastrillado puro. El sombreador de fragmentos hace su trabajo normal.

¿Qué es exactamente lo que quiere lograr? Puedo mejorar la respuesta dependiendo de tus necesidades.

De todos modos, this SO question es muy relacionado. Incluso si esta implementación en particular tiene un error, definitivamente es el camino a seguir. Otra posibilidad es openCL, pero el concepto es el mismo.