¿Por qué los reflejos funcionan en el editor, pero no en el compilado?.

Este es un problema que es un quebradero de cabeza, supongo que a mas de uno le habrá pasado que su proyecto funciona perfectamente en el editor, pero a la hora de compilarlo todo, aparece algún problema.

Esta vez ofrezco la solución a uno de los tantos problemas comunes, este problema se viene lastrando desde unity 5, se trata de los reflejos en generados con el componente Reflection probes.

Para quien no esté familiarizado con este componente en unity, reflection probe crea un cubo con 6 tomas, una por cada cara y luego plasma el resultado sobre algún material, dando la ilusión de que dicho objeto con su material, tienen reflejos de aquello que lo rodea.

El problema radica que unity cada vez que actualiza su motor, cada vez le agrega nuevas ventanas o cambia opciones de lugar, esto hace que cuando compilas a veces no sabes que opción está inactiva y que no sabes donde está para activarla.

A veces siento que Unity es un motor que no está completamente integrado, que tiene tantas opciones que se contradice unos con otros, que uno termina por no saber cuál opción prevalece sobre otra.

Configuración en los ajustes de iluminación.

En la configuración de iluminación, en la generación de luces, hay 2 opciones, Hornear sondas de reflejos y borrar datos de horneado.

Si tu escena no tiene reflejos en tiempo real y tienes bastantes reflection probes distribuidos en la escena, pendientes de ser horneados, esta opción de hornear todas las sondas es la indicada.

Pero en mi caso que necesito reflejos en tiempo real, es conveniente borrar todos los datos de horneado, para evitar interferencias.

Configuración en la cámara.

Hay un problema general con las cámaras y es que tienen algunas opciones que contradicen, la configuración gráfica y la configuración de calidad, yo si fuera el programador senior, eliminaría estas opciones que se contradicen y por claridad mental dejaría la menor cantidad de opciones.

Me refiero al Rendering Path, al HDR y al anti aliasing. Estas 3 opciones es mejor dejarlas por defecto para que sean controlados directamente desde las opciones de calidad y las opciones gráficas, así evitamos las contradicciones en la compilación.

Configuración en los ajustes gráficos.

En los ajustes gráficos, unity tiene por defecto activos algunas opciones, pero obligatoriamente toca ajustarlos, porque no todos usamos las mismas opciones de configuración, por ejemplo es mejor usar Rendering path Forward por razones de rendimiento o el uso de iluminación HDR, que aunque entiendo para qué sirve, realmente no veo que sea útil o que haga una gran diferencia el dejar de usarlo.

Es mejor desactivar la iluminación HDR, no tanto por cuestiones estéticas, sino porque generalmente presenta problemas con algunas texturas y skyboxes, generando artefactos en los reflejos. Solo recomiendo esta opción si tanto el skybox como las texturas soportan HDR y el juego fue pensado para ese propósito.

Configuración en la calidad.

Resulta que por defecto el motor a la hora de hacer la compilación de nuestro ejecutable, escoge las calidades gráficas más bajas posibles, se puede observar los checkboxes en verde en la calidad Fastest, es necesario al menos poder pasar a una calidad intermedia, para hacerlo, hay una flecha vertical poco intuitiva en el texto Default, en ese texto puedes cambiar la calidad por defecto por cada plataforma.

En cada una de las calidades y en cada plataforma es necesario que selecciones la opción Realtime Reflection Probes si tienes la necesidad que tengo yo de generar reflejos en tiempo real.

Por último desactiva la opción de Anti aliasing en todas las plataformas y en todas las calidades, pues esta opción crea conflictos con la mayoría de efectos de imagen de 2 pases, porque se ejecuta en el medio y puede voltear la imagen generada por la cámara y generar artefactos en los reflejos. En lugar de usar el anti aliasing por defecto, cámbialo por un anti aliasing como efecto de imagen.

Conclusiones.

El motor de unity entró en la bolsa de los estados unidos hace poco, lo bueno de esto es que van a tener todo el dinero que necesiten para generar nuevas tecnologías, lo malo de esto es que la compañía se va a centrar en generar más ingresos para los inversionistas, dejando de lado a los desarrolladores que somos sus clientes.

Esto significa que se decantaran a introducirles al motor las tecnologías más populares, en lugar de pulir las herramientas que ya tienen.

Esto puede parar en un motor mas completo, pero peor optimizado y peor planeado, queriendo acaparar otros gremios como el cine, la arquitectura o las simulaciones científicas, dejando como uno del montón al desarrollo de videojuegos.

Unity se ha hecho muy grande y creo que deberían separar su motor en piezas modulares que encajen bien y que cada persona se descargue las partes que necesite, también creo que debieran trabajar mejor la raíz de sus gráficos, pues el querer mezclar las APIs DirectX y openGL, crea un salpicón que en algunos sistemas funciona bien y en otros no tan bien.

No siendo mas, nos vemos en un próximo Blog.