lunes, 30 de enero de 2017

Configuración de la iluminación global.

Dentro del apartado gráfico una de las partes más importantes y más influyentes en el resultado final del juego es la iluminación. Distintas configuraciones de la iluminación puede darle, a una misma escena, un aspecto más o menos emocional dependiendo de la luz que se le aplique, su intensidad, su color, etc.

Unity, desde la versión 5, incorpora una característica muy interesante en este aspecto y es la iluminación global. Aunque no vamos a explicar en qué consiste exactamente la iluminación global explicaremos cuatro cosas sobre el tema y siempre podéis ver el artículo en el manual de unity donde se comenta más detalladamente.

A grandes rasgos se puede decir que es la iluminación que afecta, directa e indirectamente, sobre un objeto.

La iluminación directa sobre un objeto es la iluminación de las fuentes de luz que tiene la propia escena y que inciden directamente en el objeto, como la luz del sol.

La iluminación indirecta seria la luz rebotada de otros objetos que tiene alrededor y que, dependiendo del material de estos objetos, también influye sobre la luz que se le aplica a nuestro objeto. Así por ejemplo, si tenemos una pared roja y justo al lado un cubo blanco, si la luz da directamente sobre la pared, el cubo se teñirá un poco de rojo, porque la luz que rebota sobre la pared roja influye sobre la superficie del cubo blanco.

Como una imagen vale más que mil palabras, a continuación se muestra un ejemplo visual de la iluminación global.

Ejemplo de iluminación global en Unity
Ejemplo de iluminación global en Unity.


Como se puede ver, la imagen de la izquierda es sin iluminación (sólo con el color de cada objeto). La imagen del medio es sólo con iluminación directa. Y finalmente la imagen de la derecha es con la iluminación global, donde influye tanto la iluminación directa como la que se genera indirectamente.

Se puede apreciar como la iluminación incidente sobre la bola blanca hace iluminar el interior de la habitación. También se puede apreciar como la superficie de las bolas que están más cerca de las paredes se tiñen del color de esa pared.

Hay que decir también que hay varios niveles de iluminación global y que se aplican varias técnicas en una escena a parte de la luz directa e indirecta. Una misma escena con iluminación global, no se verá igual de bien en un juego en tiempo real que como imagen renderizada con un programa de edición como blender. Renderizar una escena con una muy buena iluminación tiene un coste de procesamiento muy elevado y no es factible llegar a ese nivel de detalle en un juego que se ejecuta todo en tiempo real. Lo más parecido a eso, sería usar una iluminación baked o pre-renderizada, que aunque no es a tiempo real, se puede acercar bastante al resultado final.

Bueno, hecha esta introducción sobre la iluminación global para los que no estaban muy familiarizados con ella, vamos a comentar como hemos configurado la iluminación de nuestro juego. Cabe decir que es una configuración que seguro se irá modificando y mejorando durante el desarrollo del juego, pero por el momento nos servirá para tener una base por donde empezar.

Primero vamos a mostrar una imagen de como quedaría un bloque de edificios con la iluminación por defecto de unity.

Escena con la iluminación por defecto de unity.
Escena con la iluminación por defecto de unity.





Por defecto es una iluminación decente, pero para nuestro caso, que queremos darle un toque más cartoon al juego, le falta algunos ajustes en la configuración.

Para quienes quieran aplicar una iluminación global a su escena, vamos a resumir los pasos para aplicar correctamente las luces. Decir que puede tener muchas configuraciones, la de a continuación es sólo una más, pero os puede servir para tener una base.

Dentro de unity, en la pestaña Lighting y subpestaña Scene, modificamos los siguientes valores:
  • Ambient source: Color
  • Ambient color: #544689 (aquí aplicarle el color que más os guste para vuestra escena)
  • Activar la opción: Precomputed Realtime GI
  • Realtime resolution: 0.5 (para nuestra escena en lowpoly y vista de lejos, es suficiente)
  • Desactivar la opción: Baked GI (de momento no tendremos iluminación pre-renderizada)
  • Desactivar la opción: Auto-build (la aplicaremos manualmente luego de hacer los cambios)
Crear un objeto Directional Light y arrastrarlo a nuestra escena. Esta fuente de luz simulará la luz del sol. Configuraremos los siguientes parámetros:
  • Color: #F4E2ACFF
  • Shadow Type: Shoft shadows
  • Strength: 0.85 (si queréis le podéis bajar la intensidad para que no sean tan oscuras)
Después de configurar la iluminación global y crear nuestra fuente de luz es muy importante activar la opción Static de los objetos que queremos que se le aplique la iluminación global. Esta opción la encontraréis en la pestaña Inspector de cada objeto, a la derecha de su nombre. Esta opción indica que el objeto no se moverá y sobre el cuál la luz puede rebotar. Por lo tanto, a los objetos móviles, como nuestro coche, no se le podrá aplicar iluminación global y que esta rebote en el material de nuestro coche. Para estos casos, existe otro método, como las light probes pero que en este artículo no trataremos porque aún no nos hemos puesto con ellas.

También comentar que para nuestro caso en concreto, como queremos una estética cartoon de nuestro juego, hemos modificado el shader de los objetos, el cual también influye mucho en como se ve cuando se le aplica luz. Por defecto unity aplica el shader Standard a los objetos. En nuestro caso, hemos seleccionado el Legacy shaders/Diffuse, el cual aviva los colores del objeto y le da a la escena un toque más colorido.

A continuación mostramos la escena con una primera prueba de iluminación y la cuál nos servirá como base para ir mejorándola poco a poco durante el desarrollo del juego.

Escena del juego después de configurar la iluminación global.







Finalmente, para los que quieran profundizar más sobre la configuración de la iluminación global en unity, os dejamos este enlace a un tutorial oficial muy interesante y completo.

Esperamos que os haya sido útil y nos vemos en la siguiente entrada :).

jueves, 26 de enero de 2017

TIP#3. Append, link e instancias en Blender.

Hoy vamos con un tip muy rápido y sencillo, pero si no lo conoces puedes dar rodeos fácilmente evitables.

Cuando estás trabajando para encontrar un pipeline cómodo y lo más eficaz posible, hay que mirar diferentes maneras de hacer las cosas. Con nuestro proyecto actual estamos intentando construir una ciudad bastante grande, donde los objetos no pueden ser únicos, los vamos a aprovechar por toda la urbe, intentando que se note lo menos posible.

Imaginemos que tenemos una escena donde montar toda la ciudad y luego tenemos otra escena con los distintos tipos de edificios que hemos hecho. El motivo de tener las cosas en archivos distintos es para que no ocupe demasiado, a parte de para mantener un orden.

El caso es que necesitamos pasar los edificios al archivo de la ciudad e ir copiándolos. Para ello es necesario estudiar la mejor manera de importar los objetos y en blender existen dos formas de hacerlo:
  • Append: seleccionaremos los objetos que queremos traer a la escena de la ciudad y los importará automáticamente. Podemos traer cuantos objetos queramos y los podremos modificar a nuestro antojo. Eso sí, si queremos hacer una corrección a uno de los objetos, tendremos que retocarlos todos.
  • Link: funciona exactamente igual que el anterior. La diferencia con el método anterior es que no podremos modificarlos desde la escena donde lo hemos importado (esto lo detallamos mejor enseguida). Para ello, deberemos ir al archivo donde se encontraba el objeto original y cambiar lo que queramos. Lo bueno es que cuando volvamos a entrar a la escena de la ciudad, se habrán hecho las modificaciones también.
Por tanto, la que nos deja más libres es el primer método. Simplemente importas y ya puedes duplicar, modificar, etc. Pero si te has dejado algo y quieres modificar el objeto, deberás modificarlo y volver a importarlo. Y en caso de haber copiado muchas veces ese objeto por la escena, deberás volverlos a copiar y ponerlos en su sitio.

El segundo método es ideal si quieres traer objetos que pesen mucho y que pueden sufrir cambios con el tiempo. Lo malo es que está más restringido si quieres duplicarlos. Al final funciona como un proxy. Una vez importado, solo tendrás ese elemento enlazado, con lo cuál, el objeto importado no se podrá mover, así que tendrás que crearlos en la posición donde te interese. Pero, hay una solución.

Para poder mover o modificar un objeto que hemos enlazado, seleccionaremos el objeto (veremos como el objeto se ilumina de color azul y no el naranja habitual) y le daremos a la L. Saldrá un desplegable y seleccionaremos "Selected objects". De inmediato, el azul cambiará a naranja, aunque seguiremos viendo el puntito azul, pero ya podremos alterar el objeto.

Podremos moverlo, rotarlo y escalarlo, pero no podremos poner el "Edit Mode". Si modificamos el objeto original, se verán los cambios aplicados en la escena donde lo hemos importado. También podremos duplicar el objeto, pero esas copias nunca estarán enlazadas con el objeto original, así que si hacemos cambios, las copias no cambiarán. Eso si, las copias sí las podremos modificar en "Edit Mode".

Instancias

Una instancia es una copia de un objeto, y como tal, solo cuenta una vez. Podremos crear tantas instancias como queramos de un objeto y repartirlo por todo el escenario. Así, siguiendo el ejemplo de los edificios, traeremos el que queramos a nuestra escena (ya sea con un append o con un link) y crearemos copias de tipo instancia (ALT + D) tantas veces como queramos, que blender solo lo contará una sola vez y si además se modifica, se modificará en todas las copias.

Como veis, todo tiene sus pros y contras, y deberemos trabajar con distintos métodos según su finalidad y lo que nos pueda venir mejor.

Esperamos que os pueda resultar útil esta información.

lunes, 23 de enero de 2017

El montaje de la ciudad. Unity, Blender y viceversa.

En el proyecto del Torii no tuvimos que pensar mucho en el método a utilizar. Todo el 3D se hizo en blender y el montaje de la escena en unity.

El escenario era relativamente pequeño, así que cualquier modificación del 3D se hacía sobre blender y se volvía a importar a unity. Al final nos dimos cuenta que unity refrescaba automáticamente los archivos siempre y cuando exportásemos de blender a la carpeta donde estaban los .FBX. En ese momento no se importaban los .blend directamente.

En el caso de ahora, nos entran muchas más dudas, ya que el escenario será enorme y se compondrá a partir de piezas pequeñas repetidas por toda la escena. En este punto tenemos que contar con dos cosas. Una, el método en si de que va primero, ¿el huevo o la gallina?. Y dos, el rendimiento del propio programa.

Empezando por el segundo punto, en blender se pueden usar instancias para repetir todas las piezas para que al trabajar en la escena vaya más fino, sino es imposible por muy lowpoly que sean los elementos. De hecho, nos cuesta un poco mover de forma fluida la escena de los edificios que pusimos anteriormente. En unity se trabaja mejor porqué lo que no se ve en pantalla, no parece cargarlo. Esto último no tenemos mucha idea más que de cosas que hemos ido leyendo, así que no os lo toméis al pie de la letra. Investigaremos sobre ello, y lo comprobaremos cuando montemos la ciudad, así que ya actualizaremos con nuestras experiencias.

Continuando por el primer punto, o montamos la ciudad completa en blender y en unity abrimos el .blend. O abrimos todas las piezas y elementos en unity directamente y montamos ahí la ciudad. Vemos varios pros y contras en cada uno de los métodos.

La verdad es que no tenemos ni idea, pero viendo que ahora se importan los .blend seguramente no sea tan pesado como cuando tenías que andar exportando el archivo.

Tanto si montamos la escena completa en blender y luego importamos el .blend a unity, como si montamos la ciudad en unity a partir de los .blend de los distintos modelos, el resultado es el mismo. Y es que a cada modificación para arreglar o añadir cosas de los archivos 3D, al guardar el .blend se refrescarà automáticamente en unity.

lunes, 16 de enero de 2017

Mapa III. Módulos de edificios.

Hasta ahora hemos estado pensando la manera de crear la cuadrícula de la ciudad poniendo carreteras y decidiendo qué partes podrían ser de zonas verdes, servicios, etc.

Lo que queremos hacer a continuación son las piezas del puzzle que hicimos (y os podéis descargar en el artículo) en 3D. Esto va a traer trabajo porqué a parte de hacer los modelos de las piezas en 3D, hay que texturizarlos uno por uno. Las pruebas y error que tendremos que hacer para que todo cuadre nos traerán bastante trabajo, así que vamos a cambiar un poco de tema para seguir avanzando.

Al hacer el esquema de la ciudad, estamos creando a la vez la disposición de las aceras. Cuando hagamos las carreteras en 3D, daremos volumen a las aceras. Encima de ellas es donde iremos poniendo los distintos edificios o zonas verdes.

Dentro de los edificios, distinguimos entre:
  • Construcciones genéricas como bloques de oficinas y de pisos.
  • Y las más específicas como pabellones, iglesias, campos callejeros de baloncesto, gasolineras, aparcamientos, etc.
Empezaremos con el primer tipo y para ello haremos variaciones de cada uno. El plan es rellenar la ciudad con estos edificios, cuando estén las carreteras hechas en 3D, y dejar las zonas que hemos especificado de servicios para las construcciones especiales.

Aún así, no lo tenemos claro, y creemos que al final tendremos que añadir más cantidad de este tipo especial de construcciones, pero quizás lo hagamos entre las aceras de los edificios. Creemos que pueden verse demasiado rellenas de bloques, y probablemente demos aire si entre edificios de oficinas o de pisos ponemos un aparcamiento o un campo de baloncesto.

Son cosas que, a falta de experiencia, iremos viendo mientras vayamos montando la ciudad.

Para montar un edificio en 3D haremos distintos modelos de "cajas". Algunas más altas y otras más anchas. Una vez hecho el modelo haremos la UV y le daremos color.

Una vez hechos distintos tipos de edificios haremos una lista de objetos a modelar que será lo que compongan esos edificios. Todos estos objetos tendrán su UV hecha para colorearlos. Dependiendo del objeto parecerá más un edificio de oficinas o de apartamentos.
  • Para las oficinas: ventanas sencillas, puertas dobles, respiraderos, aires acondicionados grandes o letreros para publicidad.
  • Para los apartamentos: ventanas más ornamentadas, balcones, maceteros, parabólicas, tuberías, acceso a las azoteas o tendederos.
Una vez hechos muchos objetos así, podemos empezar a montar edificios y hacer las primeras pruebas. Este sería el resultado de una posible manzana de edificios de nuestra ciudad:
Prueba de módulo de edificios



Aunque es difícil de ver, si os fijáis, observaréis que también hemos puesto otro tipo de objetos, como sombrillas, bancos, basuras, etc. Estos ítems son otra lista de modelos que estamos haciendo para añadir a la ciudad. Si vemos que puede ser interesante, ya haremos otro artículo para hablar sobre ellos, aunque solo sea mostrarlos.

De momento nos va a costar avanzar en el 3D en este tipo de módulos (de carreteras y edificios) porqué ahora es momento de hacer muchas pruebas con unity para ver como importamos todos estos objetos.

Esperamos que os haya gustado :).

jueves, 12 de enero de 2017

TIP#2. Solución al problema de los ejes entre Blender y Unity.

Seguimos con nuestra nueva sección de tips con un problema bastante molesto que nos hemos encontrado al trabajar con el software que usamos.

Para los más despistados, blender es un programa de código libre que sirve para modelar objetos 3D y animarlos (eso a grandes rasgos, porqué hace mucho más :D).

Una de las ventajas realmente buenas que tiene unity es que puedes importar archivos creados en blender de manera fácil, simplemente arrastrando el archivo .blend dentro de la carpeta del proyecto de unity.

Pero uno de los primeros problemas que uno se encuentra cuando hace esto, es que los ejes de coordenadas XYZ que vienen por defecto de blender no coinciden con los ejes de unity. Para concretar, el eje vertical en blender es el Z mientras que en unity es el Y; y el eje Y en blender es el -Z en unity. Un lío vamos. Esto conlleva que una vez importado el objeto dentro de unity, los ejes locales del objeto no coinciden con los ejes globales de la escena.

En la siguiente imagen se muestra el problema. Es un objeto que se ha importado tal cual a unity. Este objeto tiene varios subobjetos (el bloque de casas, la acera, etc.). Si seleccionamos todo el objeto en si (el objeto padre) los ejes coinciden con los de unity, pero si en cambio seleccionamos uno de los subobjetos, vemos que no, tal y como se muestra en la imagen.
Imagen de los ejes del objeto sin aplicar ninguna corrección.

Aunque pueda parecer un problema insignificante para un objeto de este tipo, realmente puede traer muchos dolores de cabeza para otro tipo de objetos. Pongamos que en lugar de unas casas queremos importar un coche, el cual luego moveremos por programación a partir de un script. Si los ejes no coinciden con los de unity, intentar mover el coche aplicando los vectores de físicas será un auténtico calvario.

Unity por defecto no tiene una solución a este problema, así que cada uno se tiene que buscar la vida para encontrar la manera de solventarlo. En nuestro caso, después de buscar bastante y probar varias cosas, dimos con un script para unity que corrige este error automáticamente.

El autor del código tiene como apodo Edy y ésta es la página en cuestión dónde comenta este problema.

Además enlaza a la página dónde se puede descargar el script y dónde también hay las instrucciones de uso, aunque es bastante sencillo de utilizar.

En nuestro caso, para facilitaros un poco el trabajo, os comentaremos por pasos como debéis aplicar el script y cómo tenéis que configurar unity para que funcione automáticamente. Así que vamos a ello.
  1. Ir a este enlace y hacer clic al botón verde de arriba a la derecha para descargar en formato ZIP el archivo.
  2. Dentro del archivo descargado veremos que hay una carpeta llamada Editor. Debemos copiar esta carpeta a la raíz de nuestro proyecto de unity.
  3. Finalmente, debemos editar el nombre de la carpeta de nuestro proyecto donde importaremos los archivos .blend y añadir al nombre la palabra [importer]. De este modo, todos los objetos que arrastremos dentro de esta carpeta serán tratados y corregidos automáticamente por el script.
Para que veáis como queda la carpeta del proyecto después de estas modificaciones os mostramos una captura de pantalla del resultado.
Árbol de carpetas de nuestro proyecto en Unity.
Aunque esto ya va a gustos de cada uno, normalmente dentro de la carpeta Assets se crea una nueva carpeta Prefabs dónde se incluye todos los prefabs del proyecto, los cuáles son los objetos 3D importados de blender. En este caso hemos renombrado esta carpeta a Prefabs [importer] para que cada vez que arrastramos un archivo .blend dentro de esta carpeta, aplique la corrección de ejes automáticamente.

Ahora sí, una vez importado nuestro objeto de ejemplo, si comprobamos los ejes del mismo subobjeto de la primera captura vemos que estos coinciden con los de unity, tal y como se muestra en la siguiente imagen.
Imagen de los ejes del objeto luego de aplicar la corrección del script.
Eso es todo! Solo cabe darle las gracias a Edy por su gran trabajo haciendo este código y sobretodo, por compartirlo con la comunidad de unity. Cosas como estas se valoran mucho.

Esperamos que os haya sido útil :).

lunes, 9 de enero de 2017

Mapa II. Croquis del mapa.

En el anterior artículo escribimos sobre nuestro puzzle casero que hicimos para intentar abarcar todas las posibilidades que podían haber para montar las carreteras. Por cierto, no dejéis de pasar a leerlo si no lo habéis hecho, ya que os podréis descargar nuestras piezas :).

Una vez teníamos las piezas, pensamos en como podía ser el mapa. Qué cosas podían haber y las distintas zonas que nos gustaría que apareciesen. Zonas verdes, zonas más industriales, edificios especiales (como escuelas, gasolineras, zonas de aparcamiento, etc), zonas abandonadas, zonas desérticas y otras más boscosas. En fin, un poco de todo.

Pero antes de ponernos a montar piezas, teníamos que montar un croquis rápido para definir esas zonas de forma más genérica. A raíz de eso, obtuvimos el siguiente esquema:
Croquis del mapa entero por zonas.


Después de especificar todas esas zonas que nos gustaría que apareciesen en el mapa entero, nos queríamos poner a hacer el mapa más específico de las carreteras, pero seguíamos teniendo un problema de creatividad. ¿Cómo nos ponemos a hacer un mapa de cero? Una vez más, usamos las referencias para tener algo donde basarnos. Nos miramos algunos mapas de ciudades, y recurrimos al típico, Manhattan. Queríamos tener un sitio icónico en la ciudad, y pensamos en un Central Park. A partir de un mapa cualquiera de la ciudad, lo ponemos de base, y nos ponemos a crear carreteras encima. No es exactamente igual, pero sí es muy parecido, ya que hemos intentado poner elementos que nos gustaban, como Central Park, los muelles o el río pasando por medio de todo nuestro mapa.

A partir de esa idea que teníamos de mapa, y ya sabiendo como van las cosas por experiencia, hay que dividir el trabajo en módulos e ir avanzando conforme vaya progresando. Quién mucho abarca, poco aprieta. Primero haremos la parte de la ciudad. Aún no sabemos si toda, porqué de momento solo hemos hecho algunas pruebas, y no sabemos si será demasiado grande o no. Habrá que hacer pruebas de todo tipo con el mapa que tenemos, para ver si carga bien, si el rendimiento es correcto o si se hace muy largo ir de una punta a otra y que pueda resultar pesada la jugabilidad.

Este es nuestro resultado final:
Croquis del mapa de la parte de la ciudad principal.




Por si tenéis curiosidad, el mapa lo hemos montado con blender. No sabíamos como hacerlo para que fuera fácil y lo más rápido posible, y después de hacer alguna prueba, nos decidimos por éste método. Creamos tantos planos nuevos como piezas del puzzle teníamos. Hicimos las UVs a los planos en un solo clic y usamos las imágenes de las piezas como texturas. A partir de ahí, copiar y pegar polígonos y con la herramienta magnética de snap para cuadrar los vértices entre piezas, fuimos montando. No le dimos un acabado final, ya que tendríamos que haber unido bien los polígonos y realizar una textura bien hecha para toda la pieza resultante, pero nos bastó para el esquema que andábamos buscando.

Entre otras cosas porqué sabíamos que ese mapa no iba a ser el definitivo. Las piezas del puzzle solo son para montar el esquema, ya que no las usaremos luego para las carreteras definitivas.

lunes, 2 de enero de 2017

Mapa I. Módulos de carretera.

Como no sabíamos por donde empezar para hacer el mapa (más allá de un croquis simple) nos pusimos a buscar módulos que se pudieran comprar por internet. No para comprarlos, al menos en primera instancia, sino para ver como habían resuelto otras personas el mismo problema.

Lo que vimos es lo que esperábamos, montar un escenario más o menos complejo y/o grande con las menores piezas posible. Así que nos pusimos a diseñar nuestro pequeño puzzle intentando pensar en solventar todas las diferentes posibilidades que pudieran haber.

En las primeras pruebas nos dimos cuenta de un problemilla que íbamos a tener. Hicimos una pequeña prueba de carreteras, haciendo la pieza de carretera de dos sentidos y las intersecciones. Una vez montado nos dimos cuenta que tendríamos problemas al girar el coche porqué estaba hecho todo en ángulos rectos. Así que tendremos que hacer que los módulos de las aceras donde están los edificios, tendrán que acabar en curva y no en ángulo recto para que los vehículos puedan girar de manera más natural.

Una vez hechas estas pequeñas pruebas, nos pusimos a pensar en todas las piezas que tendría nuestro puzzle. Había que pensar en varias opciones para poder dar variedad al mapa y que no se quedara en la misma tipología de carretera.

Así, nos quedamos con:
  • Pieza vacía que simula la acera donde estarán los distintos edificios y estructuras.
  • Carreteras rectas de distintos sentidos y carriles, según se quiera.
  • Distintas piezas que cruzan distintos tipos de carreteras.
  • Distintas piezas que son terminaciones de distintos tipos de carreteras.
A continuación, una imagen que resume todas las piezas que hemos detallado:
Piezas de puzzle de carreteras
Piezas del puzzle de carreteras que hemos hecho.


También os dejamos con una primera prueba de montaje de las piezas para ver que todo podía cuadrar bien:
Prueba de carretera con piezas de puzzle
Croquis de prueba con las piezas del puzzle.
Después de esto, sólo nos queda pensar en crear un primer croquis de mapa con estas piezas y distinguir las diferentes partes que queremos que aparezcan en el proyecto. Si después podemos o no hacerlo entero, ese será otro tema, pero es necesario proponer todas las partes que nos gustaría que apareciesen en el mapa.

Como aún no hemos terminado este primer croquis con nuestras piezas, vamos a dejarlo aquí y os acabamos de contar el resto en el próximo artículo.

Eso si, os vamos a dejar un enlace para que os descarguéis nuestro pack de carreteras que hemos realizado por si os interesa u os puede resultar útil. Esperamos que os guste!