Use advanced navigation for a better experience.
You can quickly scroll through posts by pressing the above keyboard keys. Now press the button in right corner to close this window.

Adaptándonos a modelar para Realidad Virtual – Parte 1

 

Este primer artículo mío para Epic Nerd va enfocado a la realización de assets 3D, como encargado de la dirección de arte de The Hum: Abductions y Lead 3D Artist. Voy a estar contando un poco las peripecias de trabajar modelados para usar en VR como principal plataforma, pero sin dejar de lado que el producto final sea perfectamente disfrutable en pantallas clásicas. 

Habiendo trabajado muchos años para la industria de la publicidad, donde el límite de polígonos para piezas de gráfica de revistas no era algo que me preocupaba mucho (los tiempos de render eran manejables), y luego más adelante cuando entré en la industria de los videojuegos, empezar a pensar las topologías de una manera más optimizada para modelados en lowpoly fue un proceso, lo primero que me sorprendió es que modelar para VR, si bien es similar, y no cambia técnicamente a lo mencionado anteriormente, hay que incorporar un workflow de trabajo completamente nuevo.

 

Implementando nuevas formas de trabajar


Las limitaciones y requerimientos actuales de los primeros Kits VR son bastante altos, si bien siguen siendo development kits, por lo que pude ver en la GDC y charlando con gente, en el futuro esos límites y requerimientos van a seguir subiendo.

Hoy en día, para lograr una experiencia placentera en VR, se necesita cumplir el requisito básico y primordial, pasar los 75 fps en el caso de Oculus DK2, que pronto van a ser 90 con el nuevo protototipo. A esa performance hay que sumarle que son 2 camaras renderizando 2 vistas minimamente distintas para cada ojo, lo cual da a que optimizar assets sea un factor extremadamente importante (ademas de muchas otras cosas).

Lo primero que uno piensa cuando trata de optimizar un modelo 3d para usarlo en un engine, es bajar la mayor cantidad de polígonos y agregarle el detalle que debería tener con texturas, la más importante y más usada hoy en día en cualquier motor para esa tarea (aparte del mapa de color) es el mapa de normales o normal map.

 Aca viene el primer palo en la rueda:

La triste realidad es que un mapa de normales es una especie de engaño hacia la cámara, funciona todo muy lindo, hasta que hay 2 camaras en escena (y un ojo nuestro en cada una) y toda la magia se pierde en un segundo, mirar de cerca un objeto en VR que esta muy detallado con normales simplemente se ve mal, te das cuenta que no es detalle en el objeto, es como una imagen pegada, no hay profundidad.

Obviamente no hay que descartarlos pero hay que encontrarle la vuelta.

Siempre hablando de VR, mientras más lejos estén los objetos de nuestra vista, mejor funcionan los normal maps, por ende, para objetos que sabemos que van a estar a cierta distancia, esta todo bien. Otros normales que funcionan bien son los que agregan detalles sutiles, como texturas minimas, rugosidades, etc, siempre y cuando el mapa sea tranquilo, si el ruido es muy significante, genera efectos raros en VR y te das cuenta al segundo que algo raro hay en ese objeto.

Ejemplos de normales que funcionan mal y otros que funcionan medianamente bien

Normales

Uno empieza a hacer malabares con topología, mapas y tiempos, la realidad es que los detalles modelados, se ven mejor que con mapas en VR, ciertos detalles que antes con normales iban de 10, ahora hay que hacerlos con polígonos, pero a la vez no pasarse mucho por que hay que seguir moviendo todo a más de 75fps, asi que es un reto andar decidiendo donde gastar más y dónde ahorrar polígonos. La prueba y error con el oculus también es muy importante, por más que uno le vaya agarrando la mano, el veredicto final esta con la cabeza adentro del Oculus. De todas maneras se puede ir encontrando un punto intermedio en todo este embrollo y uno va agarrando velocidad con la práctica.

Existen otras alternativas como Parallax Mapping, Displacement o Tesselation, que son mas ideales para VR, pero poco viables hoy en día con placas de video normales, la idea es que el juego sea jugable para mucha gente y no complicarnos tanto con workflows mas largos que consumen mayores recursos.


Otro tema a tener en cuenta con los mapas de normales, que no solo afecta el VR es cuando usamos Mipmapping, a grandes rasgos, los mipmaps son “Lods” de texturas, son mapas de la misma textura en menor resolución que se van reemplazando por el mapa anterior mientras mas lejos este la camara de ese objeto, es un recurso muy utilizado hoy en día en motores actuales, y ayudan mucho a la performance, el problema con los mipmaps en normal maps es que al ir perdiendo informacion, la textura se va “empastando” y alisando, se pierden esas diferencias de valores y alturas, cosa que afecta muchisimo a la sensacion que tiene que brindar el material, por que afecta directamente al brillo que pueda tener ese objeto, por ende, surje el efecto que mientras mas lejos estemos de ciertos objetos, mas empiezan a brillar, cuando no deberia ser así.

Hay técnicas para evitar este tipo de problemas, pero la mas simple, es, o desactivar los mipmaps o cambiar el filtrado de ciertas texturas con esos problemas, o evitar normals que contengan mucha informacion cambiante de alturas, como enrejados, texturas que tileen mucha cantidad de elementos, dejo una imagen  de una charla de la gente de Valve sobre el tema:

Ejemplos de normales que funcionan mal haciendo mipmapping

glsssines

Hay muchos otros factores y elementos a tener en cuenta a la hora de realizar assets para un engine en VR, pero lo voy dejando para la próxima.

Como todo, tomen esto con pinzas, son simplemente experiencias propias que me fueron pasando en el transcurso del desarrollo, cualquier comentario, feedback o sugerencia no duden en dejarlo, Salute!

Marito

Mauricio Dal Fabbro.

Dibujos by Santman.

Leave a reply

 

small_keyboard