Qué podemos esperar del Raytracing en Unreal Engine 4.22

5 minutos de lectura
Editado: esta entrada llega un día tarde. Ya ha sido publicada la versión 4.22
Hablo de lo que podemos saber de la prerelease.
Cada nueva versión oficial de Unreal Engine viene precedida por 2, 3 y hasta 4 ‘previews’. Y cuando digo oficial me refiero a la lanzada por Epic Games desde el ‘laucher’, porque al ser un editor y motor de render de código abierto y residir sus cientos de miles, o millones, de líneas de código en Github cualquiera que se atreva puede personalizarlo a su gusto como sabemos de muchas versiones ‘alternativas’.
Las ‘previews’ de las que hablo permiten depurar errores de última hora, poniéndolas en manos de decenas de miles de entusiastas que reportan incidencias que serán corregidas en los cuarteles de Epic. Por supuesto estas versiones nunca deben utilizarse en producción, por mucha ilusión que nos haga probar las decenas de novedades que trae cada nueva edición.
Ofertón del año pasado, se las quitaban de las manos
Pero la 4.22 va a ser un caso especial. Cuando en el GDC2018 Nvidia presentó la primera gráfica con ‘raytracing’ en tiempo real, fue como si se encontrara el Santo Grial perdido hace 2000 años. Y se presentó sobre cinemáticas calculadas en tiempo real en UE4, lo que hacía presagiar aquello que en una o dos semanas tendremos de forma oficial. Entonces las demos se realizaron sobre carísimas estaciones equipadas con 4 gráficas Tesla GV100. Hoy el RT (raytracing, no retweet) que tenemos a nuestra disposición funciona sobre una sola RTX2080Ti, algo que buscaban en Epic Games para hacerlo mucho más accesible.

Hace volar a Enscape, a ver a UnrealEngine
Ya vamos (íbamos) por la ‘preview’ 7, algo que al menos a mi me lleva a pensar que la final va a ser lanzada evitando en lo posible cualquier ‘bug’, especialmente en lo que a ‘raytracing’ se refiere.
El RT, aunque ya válido para cualquier producción, aún es un WIP, un ‘early access’. Está habilitado para iluminación global (preferentemente primer rebote), sombras difusas de cualquier emisor, ‘ambient oclussion’, reflexiones, translucencias e IBL basado en imágenes HDR, entre otras, dejando a un lado ‘lightmaps’, ‘sphere and cube reflection captures’, ‘planar reflections’ y ‘ambient oclussion’ entre otros efectos en ‘screen space’.
Lo mejor de todo es que es híbrido, por lo que podemos elegir el camino tradicional para unos efectos y raytracing para otros.
En la 4.22 tenemos en realidad dos motores de RT:
1.- RT hibridado con los efectos raster: el que hay que usar.
2.- Path tracer, un RT puro, ‘unbiased’ usado como referencia para aprobar internamente los desarrollos del primero. Es una herramienta de uso interno.
La principal ventaja de raytracing frente técnicas consolidadas es que para el usuario es mucho más sencillo de implementar: no ha de preocuparse de añadir ‘reflection probes’ para las reflexiones, y estas, al no ser en ‘screen space’ serán de calidad excelente, tampoco habría de preocuparse del tedioso ‘unwrapping’, ni de afinar con decenas de valores en el cálculo de iluminación, las sombras serán físicamente perfectas, y los resultados no se verán afectados por imperfecciones en el modelado. Todo esto, claro, en función del balance entre pases rasterizados y calculados por RT. Lo mejor de todo es la naturaleza híbrida de la propuesta.
Para hacer uso de RT en la 4.22 hay dos premisas ineludibles: Windows 10 1809 y una gráfica RTX, sea Quadro o GeForce.
Este último punto, que es obvio, conlleva a una reflexión a la hora de determinar el objeto de nuestro desarrollo, es decir, si el cliente dispone o está dispuesto a disponer de una máquina con RTX o no. Decisión que por otro lado, y con el paso del tiempo, perderá importancia en la medida que la computación en tiempo real en ‘server side’ sea cada vez más común: Pixel Streaming, GForce Now, RTX Server Line, 5G, Stadia, bla, bla, bla.
Por otro lado también pienso si el cliente notará o no la diferencia de una escena en RT o no, pero eso es otra historia. Mi visión se basa más en un B2B que en B2C. Son públicos distintos.
Actualmente la mayoría de las funcionalidades de RT se controlan desde la consola de comandos por medio de un nutrido grupo de variables, algo que se habilitará con una interfaz de usuario en la 4.23. Hay otras funciones que se controlan desde los propios actores, como algunas de ellas desde el PostProcess Volume.
Mientras el cálculo se haga sobre RTX local, hemos de tener en cuenta que algunos procesos RT son muy rápidos, incluso más que los tradicionales (sombras, AO), y otros no (reflexiones de más de un rebote, GI de muchas luces, interiores, reflejos muy difusos, pese al Denoiser). De ahí que la posibilidad de hibridarlos o repartirlos entre RT y procesos tradicionales es una opción excelente pero que habrá que distribuir mediante un ‘profiling’ bien segmentado.

Las zonas que delimitan reflexiones nítidas de reflexiones totalmente difusas tienen un coste significativo. Hay variables para mitigar esta pérdida de FPS

Ojo con la autoría de materiales complejos. Sobre todo mejor tirar de un Ubershader o padre súper paramétrico y materiales instanciados para reducir drawcalls. A ver Substance Designer… A ver las importaciones de Datasmith y sus réplicas de Vray.
Conviene mencionar que pese a haber sido habilitadas en versiones precedentes las luces rectangulares no han tenido una funcionalidad plena hasta esta 4.22, momento en el que al disponer de RT, su semejanza con la realidad es ya total. Además se ha añadido la función ‘barn door’, que determina la apertura del cono de iluminación, como en los focos de iluminación de estudio.
En fin, que a falta de la publicación final, que es de esperar que sea esta semana (ya ha sido, 16:00 del 2 de Abril), esto es todo lo que puedo decir de una versión que supondrá un antes y un después.