opengl graphics raytracing opengl-3

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



graphics raytracing (2)

No aconsejaría probar el trazado real de rayos en OpenGL porque necesitas muchos hacks y trucos para eso y, si me preguntas, ya no tiene sentido hacer esto. Si desea hacer un trazado de rayos en la GPU, debe ir con cualquier lenguaje GPGPU, como CUDA o OpenCL, ya que facilita mucho las cosas (pero no por eso triviales).

Para ilustrar el problema un poco más: Para el trazado de rayos, debe rastrear 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. Luego, necesita estructuras de datos de aceleración para obtener cualquier frame-rate razonable. Sin embargo, atravesar, por ejemplo, un árbol de KD dentro de un sombreador es bastante difícil y si no recuerdo mal, hay varios documentos exclusivamente sobre este problema. Sin embargo, si realmente quieres seguir esta ruta, hay muchos artículos sobre este tema, no debería ser demasiado difícil encontrarlos.

Un rastreador de rayos 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 GPU se limita principalmente a escenas estáticas porque, por ejemplo, los árboles kd solo funcionan (bien) para escenas estáticas. Si desea tener escenas dinámicas, necesita otras estructuras de datos (p. Ej., BVH, iirc?) Pero necesita mantenerlas constantemente. Si no me he perdido nada, todavía hay mucha investigación sobre este tema.

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, ¿por dónde empiezo?

Supongamos que nunca he encendido en OpenGL antiguo, así que iría directamente a métodos no desaprobados.

La aplicación ha configurado correctamente los 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.

¿Hay alguna fuente de información que pueda tomar una 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.


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, tienes 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.
  • Trazado de rayos híbrido. Rasterize su escena de la manera normal, y use Raytracing en su sombreador en algunas partes de la escena que realmente lo requiere (refracción, ... pero se puede simular en rasterización)
  • Rasterización pura El sombreador de fragmentos hace su trabajo normal.

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

De todos modos, esta pregunta SO está muy relacionada. 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.