Unreal Engine 4. Impresiones posteriores.

Ahora que ya llevamos unas semanas con el nuevo (para nosotros) Unreal Engine, aprovecharemos para hacer otra entrada explicando nuestra experiencia con nuevos argumentos, más allá de las primeras impresiones que publicamos hace unos meses.

Cabe decir que durante este tiempo, Unity ha sacado la versión 4.6 de su motor e imaginamos que seguramente tenga mejoras interesantes. Como a nosotros no nos sobra tiempo, no podremos comparar ya que a partir de ahora nos queremos centrar en el Unreal Engine.

Así que es posible que alguna cosa que se comente aquí ya la tenga Unity en alguna última versión, o bien que las tenga a partir de complementos externos, pero como siempre decimos, si ya vienen por defecto con el motor, mucho mejor.

Primero vamos a nombrar algunas de las cosas buenas que hemos ido encontrando en este motor. Y como no todo es perfecto, luego pasaremos a comentar las cosas no tan buenas :-).

• Auto generación del LOD. A groso modo, el LOD (Level of Detail) serian los distintos niveles de geometría que un objeto puede tener dependiendo de la distancia desde la cuál se mire este objeto. A ciertas distancias, la cantidad de polígonos que tiene un objeto se reduce, porque a simple vista no hay diferencia visual entre un objeto cercano con N polígonos y un objeto lejano con la mitad o una tercera parte de los polígonos. Esto ayuda a optimizar el juego y que vaya más fluido. Para crear estos niveles de LOD normalmente el propio diseñador 3D del objeto, cuando lo crea, también tiene que crear réplicas con menos nivel de polígonos, lo que aumenta muchísimo el tiempo dedicado en la creación de cada objeto. En el Unreal Engine nos hemos encontrado la grata sorpresa de que tiene un auto-generador de LOD a partir de un objeto que tengas creado. A partir de unos parámetros como la cantidad de niveles de LOD a generar, la reducción de polígonos por nivel o la distancia de visión entre otros, automáticamente crea las réplicas de los objetos. En nuestro caso, los resultados de las réplicas generadas son muy satisfactorios y es muy útil para generar los niveles de LOD de todos los objetos. El único problema es que tienes que ir objeto por objeto para crear el nivel de LOD, pero bueno, tampoco se le puede pedir tanto :-).

• Miniaturas de los modelos. Esto quizá para algunos puede ser una parida o algo sin importancia, pero ayuda mucho que al importar un objeto te genere automáticamente la miniatura y visualmente puedas ver la lista de objetos en imágenes. En el momento de buscar un objeto para añadirlo al escenario es mucho más fácil buscarlo si visualmente puedes ver el objeto. Esto por ejemplo Unity no lo tenía y una vez probado, seguro que se hecha en falta.

Miniaturas de los objetos importados.

• Creación automática del modelo convexo de colisión. Cuándo a un objeto complejo en cuánto a geometría se le tiene que aplicar simulación de físicas, estas físicas no se aplican sobre la geometría completa del objeto ya que supondría una gran cantidad de recursos para procesar cada petición. Cuando utilizamos Unity, este tenía la opción de convertir la geometría de la colisión a una forma convexa (básicamente es una versión simplificada de la geometría de colisión) para que así al procesar las físicas de este objeto sea más fácil. Esto es bueno, pero a la vez limita un poco la geometría de colisión de este objeto, como por ejemplo, que haya una parte de colisión donde realmente no hay polígonos del objeto. En Unreal Engine, también existe esta herramienta para generar la versión convexa de la geometría de colisión del objeto, pero en este caso va un poco más allá, y permite definir a través de un parámetro la fidelidad de esta geometría convexa. Lo que permite crear una geometría más o menos fiel a la original del objeto si así se desea (a coste de empeorar el rendimiento, claro). En el siguiente ejemplo se puede ver lo que comentamos. A la izquierda se genera el modelo de colisión con el valor 0.1 (poca fidelidad) y a la derecha con el valor por defecto (0.5), lo que permite un modelo de colisión más detallado.

Diferencia de la geometría de colisión al crear el modelo convexo.

• Blueprints. En el artículo anterior ya comentamos un poco por encima las características de los Blueprints. Ahora que los hemos podido probar mejor, podemos reafirmar que son una buena herramienta para la programación de muchas partes del juego que no requieren complejidad. En nuestro caso, por ejemplo, hemos podido programar la funcionalidad del vehículo y otras pequeñas funcionalidades sólo con Blueprints. Aunque cabe decir que Unreal Engine trae una clase específica para crear vehículos, la cuál ayuda mucho. Por el nivel de complejidad del juego, creemos que todo se podrá hacer mediante Blueprints, ya que no necesitamos nada especialmente complejo como para tener que utilizar directamente el C++. Los Blueprints son divertidos de programar y muy visuales, a la vez que permiten igualmente depurar de manera fácil mediante los breakpoints de toda la vida.

• Launcher de Unreal Engine. Este punto sí es una mejora muy grande que hemos encontrado respecto Unity, ya que éste último no tiene un gestor de versiones del motor, lo que dificulta poder gestionar las nuevas versiones que van saliendo y la compatibilidad de los proyectos con estas versiones. En cambio Unreal Engine, el propio launcher tiene una sección para gestionar todas las versiones que tienes instaladas en tu ordenador, sus actualizaciones y todos los proyectos que haces con el motor.

Ejemplo de nuestro launcher con dos versiones de Unreal Engine instaladas.

• El propio Editor. Esto quizá es un poco más difícil de explicar sin probarlo por uno mismo, pero comparándolo con el motor de Unity, el editor de Unreal Engine está creado con más cuidado y más mimo en las pequeñas cosas. Tiene muchos pequeños detalles que individualmente no són algo como para destacar, pero que en conjunto hacen que te sientas más cómodo trabajando. Por ejemplo, la posibilidad de crear distintos niveles de quadrícula para forzar la colocación de los objetos en el escenario, un modo visual de reemplazo de objetos a partir de un filtro de selección, la posibilidad de importar un modelo de colisión desde otro objeto, el icono que se activa cuando editas cualquier valor para poder volver al valor que tenia por defecto, etc. Muchas pequeñas cosas que en conjunto hacen algo mejor.

Y ahora algunas cosas no tan buenas que hemos encontrado. Algunas parecen bugs y otras son más del comportamiento del propio Editor.

• Bug de la señal de ceda el paso. Pues sí, tenemos un bug algo curioso. Cuándo copiamos una parcela de edificios con su atrezzo las señales de ceda el paso de los objetos copiados las sustituye por el objeto de un semáforo que también tenemos en nuestro atrezzo. No sabemos si internamente hay alguna referencia que se nos escapó cuando hacíamos pruebas o es que al editor se le va la pinza y le tiene manía a las señales de ceda el paso... ¡si tan malas no son! [Actualización: este bug ha sido solucionado en la versión 4.16.2 del Unreal Engine].

• La auto expansión de las carpetas del World outliner. Este quizá es el comportamiento del editor que nos trae más de quicio. El World outliner es el panel dónde se muestran todos los objetos que tienes en tu escena. Allí los puedes agrupar por carpetas para tenerlo bien organizado. Hasta aquí bien. El problema es que cuando seleccionas un objeto en tu escenario, este también se selecciona en dicho panel y se expanden todas las carpetas que contiene ese objeto, lo cual a veces molesta bastante porque, aunque selecciones el objeto, no quieres que se expanda todo en el panel. Incluso cuando abres el mapa por defecto se expande todo y no recuerda el estado en que estaban la última vez que cerraste el editor, con lo que tienes que colapsar de nuevo todas las carpetas para tenerlo organizado, y si tienes muchos objetos y carpetas como podemos tener nosotros, molesta bastante. Señores de Unreal, primer aviso, ¡solucionad esto ya! si no nos volvemos a Unity!... que no, que es broma... [Actualización: en la versión 4.16.2 del Unreal Engine parece que ha sido solucionado parcialmente, algunas carpetas no se auto expanden y otras sí].

• Alguna inestabilidad del Editor. En general el editor es muy estable (eso si, sus recursos consume) pero cabe decir que algun crasheo nos ha hecho, aunque los podemos contar con los dedos de una mano. Normalmente són debido a falta de memoria (teniendo 16 GB de RAM) cuando se editan muchos objetos, como por ejemplo cuando se tuvieron que crear todos los niveles de LOD de todos los objetos. Llega un punto que es mejor cerrar el editor y volverlo a abrir para que haga limpieza de memoria.

Y hasta aquí la segunda parte de la migración a Unreal Engine. Si alguien se quedó con dudas en la anterior entrada dónde explicamos la migración a este motor, esperamos que con esta nueva entrada detallando algo más las cosas buenas y malas le sean útiles para tomar una decisión. Aunque lo mejor, como siempre, es probar las dos opciones por uno mismo y quedarse con la que más le guste :-).

ACTUALITZACIÓN: Posteriormente hemos realizado una nueva entrada hablando solo de la programación con blueprints, os aconsejamos la lectura si os interesa el tema :-)