¿Cómo logran los motores de juegos modernos el renderizado en tiempo real frente al renderizado "lento" de Blender?

Soy nuevo en gamedev y Blender, y hay algo que no puedo evitar:

En Blender, un solo renderizado (incluso usando el renderizador de Ciclos más avanzado) puede tomar hasta 45 segundos en mi máquina. Pero, obviamente, en un juego, puedes tener gráficos asombrosos, por lo que el renderizado obviamente ocurre continuamente, varias veces por segundo en tiempo real.

Así que también me pregunto cuál es la desconexión, con respecto a cuán "lentos" parecen ser los renders de Blender, en comparación con cómo los motores de juego logran el renderizado en tiempo real (o casi en tiempo real).

rendering blender

— smeeb
fuente

La representación en tiempo real es un gran tema en sí mismo, hay muchos libros escritos sobre ella (incluida la "Representación en tiempo real"). Y los renderizadores como Cycles funcionan de manera completamente diferente a los renderizadores 3D en los motores de juego: realmente no puedes compararlos

— UnholySheep

@UnholySheep Por supuesto que puedes compararlos. ¿De qué otra forma alguien explicaría la diferencia para responder la pregunta?

— user985366

@ 10 Respuestas Pero esta pregunta no sería de actualidad en ese sitio.

— GiantCowFilms

@ 10Respuestas: Si bien el OP menciona a Blender, la pregunta se reduce esencialmente a por qué los motores de juegos en tiempo real parecen procesar escenas 3D más rápido que los renderizadores 3D aproximadamente fotorrealistas (como Blender, pero también muchos otros). Tenga en cuenta que esta es también la pregunta respondida por la respuesta aceptada. Con eso en mente, estoy de acuerdo en que la pregunta es más sobre el tema aquí en Desarrollo de juegos , donde se pueden hacer preguntas sobre la tecnología general de desarrollo de juegos, en lugar de en Blender , donde las preguntas son más específicas de Blender en particular.

— O Mapper

Supongo que el secreto aquí es que lo asombroso no tiene que ser preciso. Hay aproximaciones rápidas para las matemáticas utilizadas en la representación 3D, como InvSqrt

— Dmitry Grigoryev

Respuestas:

115

El renderizado en tiempo real, incluso el renderizado moderno en tiempo real, es una bolsa de trucos, atajos, hacks y aproximaciones.

Tomar sombras por ejemplo.

Todavía no tenemos un mecanismo completamente preciso y robusto para representar sombras en tiempo real de un número arbitrario de luces y objetos arbitrariamente complejos. Tenemos múltiples variantes en las técnicas de mapeo de sombras, pero todas sufren los problemas bien conocidos con los mapas de sombras e incluso las "soluciones" para estos son realmente solo una colección de soluciones y compensaciones (como regla general si ves los términos "sesgo de profundidad" o "desplazamiento de polígono" en cualquier cosa, entonces no es una técnica robusta).

Otro ejemplo de una técnica utilizada por los renderizadores en tiempo real es el cálculo previo. Si algo (p. Ej., La iluminación) es demasiado lento para calcular en tiempo real (y esto puede depender del sistema de iluminación que utilice), podemos precalcularlo y almacenarlo, luego podemos usar los datos precalculados en tiempo real -tiempo para un aumento del rendimiento, que a menudo se produce a expensas de los efectos dinámicos. Esta es una compensación directa entre memoria y computación: la memoria es a menudo barata y abundante, la computación a menudo no lo es, por lo que quemamos la memoria extra a cambio de un ahorro en la computación.

Los renderizadores sin conexión y las herramientas de modelado, por otro lado, tienden a centrarse más en la corrección y la calidad. Además, debido a que están trabajando con una geometría que cambia dinámicamente (como un modelo mientras lo estás construyendo), a menudo deben recalcular las cosas, mientras que un renderizador en tiempo real estaría trabajando con una versión final que no tiene este requisito.

— Maximus Minimus
fuente

Otro punto a mencionar es que la cantidad de cómputo utilizada para generar todos los datos que un juego necesitará para visualizar rápidamente un área puede ser de un orden de magnitud mayor que la cantidad de cómputo que se requeriría para representar una vista. Si la representación de las vistas de un área tomara un segundo sin ningún cálculo previo, pero algunos datos precalculados podrían reducirlo a 1/100 de segundo, pasar 20 minutos en los cálculos previos podría ser útil si se necesitaran vistas en un juego en tiempo real, pero si uno solo quiere una película de diez segundos a 24 fps, hubiera sido mucho más rápido pasar cuatro minutos ...

— supercat

... generando las 240 vistas requeridas a una velocidad de una por segundo.

— supercat

@supercat y debido a esto, tus renders están prácticamente libres de problemas y obtienes mucho control sobre el proceso. Podrías usar un motor de juego para renderizar ... si estuvieras listo para sacrificar las características. Pero como dijiste, no vale la pena.

— joojaa

Un ejemplo sorprendente de esto que puedo recordar es el motor Quake original (~ 1996), que fue capaz de lograr gráficos en 3D en tiempo real relativamente alucinantes en máquinas muy limitadas utilizando combinaciones de técnicas de cálculo previo extremadamente largas. Los árboles BSP y los efectos de iluminación prestados se generaron con anticipación; diseñar un nivel para ese motor generalmente implicaba horas (generalmente de la noche a la mañana) de espera para que finalicen las herramientas de compilación de mapas. La compensación fue, esencialmente, la disminución de los tiempos de representación a expensas del tiempo de autoría.

— Jason C

(El motor original de Doom [1993] tenía cálculos previos similares. Marathon puede tenerlo también, pero no recuerdo, recuerdo haber construido niveles de Marathon pero no puedo recordar lo que estaba involucrado)

— Jason C

109

La respuesta actual ha hecho un muy buen trabajo al explicar los problemas generales involucrados, pero creo que pierde un detalle técnico importante: el motor de renderización "Cycles" de Blender es un tipo de motor diferente al que usan la mayoría de los juegos.

Por lo general, los juegos se representan iterando a través de todos los polígonos de una escena y dibujándolos individualmente. Esto se hace 'proyectando' las coordenadas del polígono a través de una cámara virtual para producir una imagen plana. La razón por la que se usa esta técnica para juegos es que el hardware moderno está diseñado en torno a esta técnica y se puede hacer en tiempo real con niveles de detalle relativamente altos. Por interés, esta es también la técnica empleada por el motor de renderizado anterior de Blender antes de que la Fundación Blender dejara caer el viejo motor a favor del motor Cycles.

Ciclos, por otro lado, es lo que se conoce como un motor de trazado de rayos. En lugar de mirar los polígonos y representarlos individualmente, proyecta rayos virtuales de luz en la escena (uno por cada píxel en la imagen final), hace rebotar ese haz de luz en varias superficies y luego usa esos datos para decidir de qué color es el píxel debiera ser. El trazado de rayos es una técnica computacionalmente costosa que lo hace poco práctico para renderizar en tiempo real, pero se usa para renderizar imágenes y videos porque proporciona niveles adicionales de detalle y realismo.

Tenga en cuenta que mis breves descripciones del trazado de rayos y la representación de polígonos están muy reducidas en aras de la brevedad. Si desea saber más sobre las técnicas, le recomiendo que busque un tutorial o libro en profundidad, ya que sospecho que hay muchas personas que han escrito mejores explicaciones de las que yo podría reunir.

También tenga en cuenta que hay una variedad de técnicas involucradas en el renderizado 3D y algunos juegos realmente usan variaciones de trazado de rayos para ciertos fines.

— Pharap
fuente

+1 por un muy buen punto; Deliberadamente no bajé por la madriguera del trazado de rayos frente a la rasterización, por lo que es genial tener esto como un complemento.

— Maximus Minimus

Esta respuesta llega más al corazón de la diferencia. Los motores de juego realizan rasterización (hacia adelante o diferido) mientras que los renderizadores fuera de línea (como Blender, Renderman, etc.) realizan el trazado de rayos. Dos enfoques completamente diferentes para dibujar una imagen.

— venta

@ LeComteduMerde-fou Como gamedev está dirigido a desarrolladores de juegos, sentí que una explicación técnica complementaria sería beneficiosa para el lector con mayor inclinación técnica.

— Pharap

@ssell Es cierto, pero no se trata solo de trazado de rayos, incluso sin trazado de rayos, incluso con renderizado por GPU, el renderizado de Blender suele ser mucho más detallado y más lento. Esto tiene que ver principalmente con el enfoque en la corrección: mejor filtrado y resolución de texturas, suavizado, iluminación, mapeo de sombras, precisión Z, quads, superficies bidireccionales, grandes recuentos de polígonos, salida de alta resolución, mapeo de relieve preciso , falta de mapas precalculados, morphing, cinemática precisa ... es una larga lista de características que los motores de juego carecen o falsifican.

— Luaan

@Chii me acordé mal. Estaba pensando en ART VPS , era solo aceleración, no en tiempo real.

— Jason C