Versión para imprimir
Aquí les comparto este video que me ha iluminado mucho respecto del concepto de pathtracing, y como es su implementación en código.
Es video está en inglés pero puede usarse el subtitulador para entenderlo.
No tiene desperdicio, una verdadera joya!
https://youtu.be/NIpC53vesHo?si=AOfJn5cidL7iAP45
En el siguiente video de la serie, nos muestra como el proceso de pathtracing puede ser paralelizable en multicores, sean estos de CPU o de GPU.
https://youtu.be/46ddlUImiQA?si=kR_s3wTtRpvbZHTx
Gracias por compartirlo Carolina, a ver si esta noche puedo echar un vistazo.:ok:
Cita:
Iniciado por Carolina
Hola.
Existen dos tipos de path tracing, unidireccional y bidireccional, el primero solo rastrea rayos hacia atrás, es decir desde la cámara hasta la escena, el segundo además rastrea rayos desde las fuentes de luz hasta la escena.
Seguimiento de ruta hacia atrás, donde se generan rutas comenzando desde la cámara y rebotando por la escena hasta que encuentran una fuente de luz. Esto se conoce como "hacia atrás" porque los caminos que comienzan desde la cámara y avanzan hacia la fuente de luz son opuestos a la dirección en la que realmente viaja la luz. Todavía produce el mismo resultado porque todos los sistemas ópticos son reversibles.
Seguimiento de luz (o seguimiento de ruta hacia adelante), donde se generan rutas a partir de las fuentes de luz y rebotan por la escena hasta que se encuentran con la cámara.
Las CPU son dispositivos en serie, por lo que pueden ser lentas, pero pueden realizar cálculos más precisos (bidireccional path tracing, hacia adelante y hacia atrás), por lo que generalmente producen mejores resultados. Las GPU son dispositivos paralelos, sin embargo, no pueden realizar cálculos matemáticos tan precisos porque no es necesario detener demasiado el proceso (unidireccional path tracing, solo hacia atrás).
La gran mayoría por no decir todos los motores de render actuales son unidireccionales, las gpu mandan, la velocidad manda, la calidad en imagen estática baja. Como cosa buena permiten animaciones mucho más rápidas.
https://en.wikipedia.org/wiki/Path_t...l_path_tracing
Por esto necesitan las gpu el eliminador de ruido.
https://forums.autodesk.com/t5/maya-...t/td-p/9810939
Se aplica a todos los motores gpu actuales.
Las Gpus son muy rápidas desde luego pero tienen sus problemas y no son de fácil solución, independientemente de monopolios contra ley pero permitidos, ya sabemos.
Un saludo.
Archivo adjunto 246753
En esta imagen se observa una doble dispersión, los motores unidireccionales no pueden renderizarla, no pueden ni con una simple dispersión, el porque es fácil, trazan rayos desde la cámara y captan el color de esos rayos cuando rebotan o se reflejan en algo material, pero la luz no es algo material, los rebotes o como prefiráis llamarlo de la luz con la luz son ecuaciones mucho más complejas que se deben calcular, a día de hoy, trazando rayos desde las fuentes de luz además de desde la cámara, individualmente, sin montecarlos ni trucos varios para muestrear, eso implica una cantidad de cálculos en serie enormes porque un rayo depende del anterior y es por lo que estos efectos que aportan realismo son tan costosos de calcular, existen trucos que muestrean estos efectos pero siguen siendo trucos.
No debemos confundir el espacio de color con el algoritmo de render, existen diferentes motores de render en los que sus algoritmos tratan el color de diferentes formas, el algoritmo es una cosa y el entendimiento del color por parte del mismo, otra. Los motores espectrales se diferencian de los Rgb por ejemplo, en que los primeros entienden el color como una onda espectral, los segundos como números enteros, una onda tiene más información por lo que en principio el resultado final se podría entender que es más real, pero si el algoritmo no capta todas las interacciones de la luz, la realidad no es tal.
Hoy en día existe todo un ejército comercial de motores de render que mezclan algoritmos y espacios de color, pero no hay nada nuevo desde hace bastantes años.
Tecnológicamente sí existe un avance computacional tanto en procesos en serie (Cpu, multihilo no es paralelo es una aproximación de tiempos de espera del procesador que utiliza para otras cosas), como en paralelo (Gpu, autentica computación en paralelo), son dos programaciones completamente diferentes, las CPU son mejores para bidireccional pathtracing porque las ecuaciones de esos algoritmos no se pueden calcular en paralelo sin recurrir a trucos, mientras que las gpu son mejores, más rápidas en unidireccional, porque esos algoritmos se pueden paralelizar, el problema en estos es que no captan toda la información por lo que se generan puntos sin ella que deben compensar ópticamente con trucos como limpiar el ruido y demás.
El futuro son las gpu, no por su calidad de render sino por su velocidad. Es mejor cálculos menos precisos pero mucho más rápidos que cálculos más precisos pero muy lentos.
https://youtu.be/7l6QOcgWXfI
Lo malo son los monopolios, desde mi punto de vista anulan la innovación.
Un saludo.
-- IMÁGENES ADJUNTAS --
https://foro3d.com/attachment.php?attachmentid=246753
Unidireccional: Cálculos en paralelo los rayos no dependen del anterior. GPU. Más rápidos pero menos reales.
Bidireccional: Cálculos en serie los rayos dependen del anterior. CPU. Más lentos pero más reales.
Un saludo.
Los cazadores de mitos los explican mejor.
https://youtu.be/-P28LKWTzrI
Un saludo.
Hola
Esto esta copiado del manual de Fryrender que evolucionó hacia Arion y depués ya no tuvo continuidad, dando paso a Maverick totalmente acelerado por GPU
Cita:
Como trabaja fryrender3.1. ?
Desde un punto de vista técnico, Fryrender no es
un motor de render clásico, sino un simulador físi-
co que reproduce las Leyes de radiación lumínica y
precisión óptica.
Dicha simulación lumínica es alcanzada gracias al
uso de técnicas de integración unbiased que ase-
guran que el render alcanzará el balance de luz
real y exacto, facilitando el suficiente tiempo para
el cálculo. La palabra “unbiased” significa que esta
convergencia es susceptible de ser progresiva, y li-
bre de artefactos
La física de la luz es simulada de manera precisa
por fryrender. por lo tanto todos los fenómenos
que tus ojos sean capaces de ver son tomados en
cuenta de manera automática, justo como ocurre
en el mundo real. Mezcla de colores, caústicas,
profundidad de campo… No necesitarás preocu-
pate por estos efectos de manera explícita: apare-
cerán automáticamente como resultado de la
simulación
Fryrender en un motor de
render basado en la física,
unbiased y espectral.
Qué es la luz3.2. ?
La luz visible es la radiación electromagnética de
una longitud de onda que es visible por el ojo hu-
mano. en fryrender, los espectros de luz con longi-
tudes de onda de ~350nm (cercano al ultra-violeta)
hasta ~800nm (cercano al infra-rojo) son simula-
dos
en fryrender, siempre que especifiques un color
rgb o un mapa rgb, internamente se realiza una
conversión a los espectros equivalentes todo el
cálculo sucede en el espacio espectral hasta que
sucede la conversión final (llamada tonemappping)
justo antes de que la imagen sea creada.3.3.
en el núcleo de la simulación de iluminación de
fryrender, cada ruta de luz emitida por una fuente
de luz es trazada individualmente, rebotando en
la escena hasta que golpea a la cámara, produc-
iendo un sample. A medida que el tiempo pasa,
los samples se van acumulando en el framebuffer,
formando el render
este proceso se repite constantemente, continu-
adamente, enviando un sample en cada momento
Los samples acumulados en el framebuffer forman
el ruido visual (también llamado grano) que algu-
nos asemejan al grano en fotografía real. A medida
que el tiempo pasa y aumenta el número de sam-
ples calculados, el ruido en la imagen se hará más
denso y fino.
El hecho que Fryrender sea unbiased hace que el
proceso descrito nuncan finalice (literalmente).
el motor se mantendrá generando más y más
samples.trazando la mayor cantidad de rutas de
luz posibles Nótese que desde un punto de vista
teórico, el número de rutas posibles es infinita. Al-
gunos componenetes de luz tardan más tiempo en
ser encontrados y calculados.
Un cálculo unbiased garantiza
que, con suficiente tiempo
de render, todos los com-
ponentes serán mostrados
sin que el usuario se tenga
que preocupar de manera
explícita.
En general, el usuario deja al render calcularse has-
ta que el nivel de ruido sea satisfactorio (o hasta
que el grano efectivo desaparezca), y determine
cuando parar el proceso es posible determinar el
tiempo límite, o un número máximo de passes, de
este modo el render parará de manera automática
cuando una de las dos condiciones se alcance
interacción lumínica3.4.
Las rutas de luz son generadas al azar, cubriendo
todas las posibilidades de manera eventual por
otro lado, desde la fuente de luz original hata la
cámara, los rayos de luz rebotan (cambian de direc-
ción) cada vez que golpean con una superficie.
La manera en la que los rayos de luz golpean cuan-
do una superficie es golpeada está determinada
por la dirección de incidencia, las propiedades geo-
métricas de la superficie y las propiedades físicas
configuradas por el material. estas propiedades
físicas son modeladas internamente usando lo que
se llama BRDF (Bi-directional Reflectance Distribu-
tion Function) o BTDF (para Transmisión) o BSDF
(para Dispersión).
Hola.
Muy bueno muchas gracias.
Añado:
A nivel técnico 3d las gpu no son capaces de calcular bidireccional pathtracing ni ningún proceso que implique bidireccionalidad, hacen un unidireccional pathtracing con “trucos” para simular el bidireccional pathtracing. Los motores de render unidireccional pathtracing, la mayoría por no decir todos los actuales acelerados por gpu, en escenas con iluminación indirecta compleja como pueden ser las causticas tienen una probabilidad muy baja de que un camino iniciado en la cámara finalmente llegue a una fuente de luz. Esto da como resultado una imagen ruidosa (necesitan denoiser) y una imposibilidad práctica de manejar casos complejos.
Maxwell, FryRender, Indigo y LuxRender por ejemplo usan Path tracing bidireccional, el resto son todos unidireccionales. Unbiased y biased es otra cosa, espectrales y rgb otra, direccional bidireccional otra, esta ultima la más importante para simular la realidad pero muy lentos y son procesos no paralelizables porque son secuenciales un rayo depende del anterior.
Archivo adjunto 246826Archivo adjunto 246827Archivo adjunto 246829
Un saludo.
-- IMÁGENES ADJUNTAS --
https://foro3d.com/attachment.php?attachmentid=246826
https://foro3d.com/attachment.php?attachmentid=246827
https://foro3d.com/attachment.php?attachmentid=246829