The Deliver, retrospetiva. Parte II.

Como os prometimos la semana pasada, hoy toca esta segunda parte de nuestra recopilación de lo que llevamos con The Deliver. Tal como dijimos, nos centraremos en esta segunda y última entrada en todo lo que hace referencia a Unreal.

Inicialmente pensábamos seguir con Unity en este segundo proyecto pero a diferencia de lo que nos pasó con el primer proyecto, Torii, teníamos la oportunidad de poder usar Unreal Engine gratuitamente si nos gustaba. Así que nos picó la curiosidad, lo catamos durante un tiempo y vimos que habían algunas diferencias entre los dos motores lo suficientemente interesantes como para no hacer el cambio. Aunque no todo fue tan bien como cabía esperar, ya que tuvimos bastantes problemas con lo más importante que podíamos tener, los vehículos y su funcionamiento. Cuando conseguimos hacer funcionar nuestro vehículo inicial, publicamos un tutorial de los wheeled vehicles y un enlace para poder descargaros el rig del coche de forma gratuita.

Imágenes de almacenes.

Después de los testeos y resolución de problemas críticos, nos pusimos a crear la ciudad desde cero. Íbamos creando pequeñas parcelas temáticas y distribuyéndolas por toda nuestra urbe virtual.

• Zonas en obras.
• Zonas industriales.
• Almacenes.
• Hospitales, estaciones de policía y bomberos.
• Más edificios de oficinas y apartamentos.
• Iglesias, pistas de tenis y gasolineras.
• Nuevos almacenes.
• Supermercados, hoteles y zonas peatonales.

Toda esta parte se estuvo trabajando desde blender haciendo los modelos e importándolos a Unreal para su posterior posicionamiento en el mapa. Mientras estuvimos añadiendo estos modelos, fuimos perfilando nuestro plan de ataque para acabar esta primera zona. El caso es que no queríamos añadir todos los edificios en toda la ciudad sin probar otras cosas antes. Así os explicamos como nos íbamos a organizar.

Museo de la ciudad.

Poco a poco la ciudad ha ido creciendo y hemos estado dando forma a todo el mapa. Mientras creábamos edificios nuevos y los poníamos en Unreal, empezábamos a programar algunas funcionalidades de la jugabilidad del proyecto y grabando distintos gameplays para poder mostrar como se iba viendo todo el conjunto.

• De ruta por la ciudad.
• El menú y la pantalla de carga.
• El sistema de daños.
• El sistema de misiones.
• Mejoras en el sistema de daños.

Y por fin llegó el día en que acabamos nuestra fase 2 del mini mapa, es decir, acabamos de añadir parcelas de edificios a nuestra porción del mapa diseñado.

Vista desde Unreal de la zona de la ciudad completada.

Como ya avanzamos en anteriores ocasiones, ahora estamos acabando de perfilar toda esta zona de la ciudad añadiendo pequeños detalles y avanzando en la programación de las funcionalidades habladas anteriormente (misiones, pantallas de carga, daños, etc.).

La semana que viene, volveremos a la normalidad con nuevo contenido :). Esperamos que os haya gustado.

The Deliver, retrospetiva. Parte I.

Aquí viene la primera parte de la retrospectiva que nos hemos decidido a hacer durante el mes de agosto. Recordad que a partir de septiembre, volveremos con ganas y subiremos contenido nuevo con cositas muy interesantes :D.

Estamos muy cerca de cumplir un año con el proyecto. Empezamos con The Deliver propiamente (antes hicimos algunas pruebas) en octubre de 2016 más o menos, aunque no desvelamos los primeros detalles hasta diciembre del año pasado.

En esas fechas ya publicamos que el juego seria el típico de misiones de conducción, aunque la idea seria tener una historia detrás que las apoyara. La idea inicial de llevar de un punto A a un punto B un objeto, mercancía o incluso algún personaje, continua siendo una realidad. También hablamos del estilo que queríamos que tuviera y que, al igual que el leitmotiv del juego, nos hemos mantenido en ese toque lowpoly cartoon.

Aunque no fue hasta abril de este mismo 2017 cuando publicamos como se llamaría y una posible portada.

Poster The Deliver.

Durante estos meses nos propusimos ir explicando el proceso paso a paso con la idea de, no solo obligarnos a documentar todo lo que estábamos haciendo, sino también como una autoayuda, por si en algún momento nos podía servir el blog para dar a conocer nuestras inquietudes, problemas y dudas. Además, nos parecía que teníamos que devolver de alguna manera toda la ayuda que hemos ido encontrando durante este tiempo buceando por Internet. Si lo documentábamos podíamos estar ayudando a desarrolladores como nosotros que se podían encontrar cualquier dificultad que habíamos podido resolver nosotros con anterioridad.

De esta motivación salieron los primeros artículos como nuestro pipeline de texturización, los módulos de las carreteras en 2D que os podéis descargar gratuitamente y los módulos finales en 3D, cómo hicimos el mapa de la ciudad o cómo teníamos intención de hacer los módulos que contendrían los edificios.

Módulos de las carreteras en 3D.

Si nos seguís, a estas alturas ya sabréis que estamos trabajando en Unreal Engine 4 pero inicialmente seguíamos trabajando con Unity como con nuestro anterior proyecto, Torii. Así que inicialmente, os contamos como íbamos haciendo el montaje de la ciudad, cómo hicimos la configuración de la iluminación global, y como empezamos a desarrollar las físicas del coche y las físicas del atrezzo.

Mientras os hemos ido explicando con detalle como desarrollábamos las distintas funcionalidades que explicaremos en la segunda parte de esta retrospectiva, íbamos intercalando esta información con otras entradas dónde mostrábamos los modelos en 3D hechos en blender. Así pues os mostramos los distintos elementos que íbamos a repartir por la ciudad, las basuras, los distintos árboles y parques naturales, los distintos servicios de la ciudad, algunos lugares de ocio e incluso nos atrevimos con una escena de prueba intentando bocetear como queríamos que fuera el estilo visual final del juego.

Escena de prueba de The Deliver.

Hasta aquí esta primera parte que esperamos que os haya resultado útil :). El próximo lunes, la segunda y última parte donde nos centraremos en todo el trabajo hecho en Unreal y los gameplays.

Lo que tenemos y lo que viene.

En esta entrada vamos a intentar resumir el estado actual del proyecto. Lo que hemos podido hacer hasta ahora y nuestras intenciones de los próximos movimientos. Y para que no se haga pesado, mostraremos alguna imagen más de la ciudad :-).

Hasta ahora nos hemos centrado mucho en modelar edificios y atrezzo para ir llenando la primera parte de la ciudad. Como veréis en la imagen de debajo, nos quedan aún algunas parcelas, pero ya estamos cerca.

Vista general de la ciudad.

Internamente planteamos las fases de creación de la zonas del mapa (ciudades, pueblos, bosques, lo que sea) en 3 fases:

• Primera fase: crear la estructura base de la zona. En el caso de la ciudad diseñamos el mapa de calles y luego en Unreal Engine pasamos ese diseño de calles a 3D, colocando cada pieza de calle en su lugar. En el caso de un pueblo sería algo parecido, pero seguramente con menos calles. Y en el caso de un bosque, la primera fase sería diseñar un mapa topográfico de como podría ser más o menos la zona y luego en Unreal Engine utilizar la herramienta para crear los desniveles del terreno.
• Segunda fase: una vez ya tenemos la estructura base, esa zona se tiene que llenar "a lo bruto", por decirlo de alguna manera. Eso no quiere decir llenar la zona de cualquier manera, sino encontrar una forma para que se pueda llenar rápidamente sin perder la calidad. En el caso de la ciudad es donde entra el diseño 3D de edificios y atrezzo, y empezar a crear y duplicar parcelas. En nuestro caso, muchas de las parcelas las duplicamos dos veces para poder llenar más fácilmente la ciudad y a la vez intentar no dar la sensación de copia. A cada parcela le damos prácticamente el detalle de atrezzo final, pero a las calles no, eso ya lo haremos en la fase siguiente. En el caso de un bosque, en esta fase sería "pintar" el terreno de árboles e indicar algunas zonas con casas o atrezzo variado, pero sin entrar mucho en detalle.
• Tercera fase: esta última fase es donde, a partir de las pruebas de juego realizadas, terminamos de llenar la zona con más atrezzo para acabar de dar el detalle que nos gustaría que tuviera la versión final. En el caso de la ciudad, por ejemplo, sería poner los pasos de cebra, más señales de tráfico, más atrezzo en las aceras de la ciudad para darle más vidilla, calles en obras, etc. En el caso del bosque, se terminaría de llenar la zona con rocas, árboles caídos y atrezzo más detallado en las zonas de casas.

Actualmente, nos encontramos acabando la segunda fase de la parte de la ciudad que estamos haciendo. Una vez terminadas las parcelas nos pondremos a detallar un poco más el atrezzo de las calles.

Paralelamente, también estamos intentando optimizar el juego para que vaya lo más fluido posible, creando los niveles de LOD (Level of Detail) para cada objeto y las geometrías de colisión adecuadas para que no afecten en exceso al rendimiento.

En cuanto a programación, lo que tenemos hecho hasta ahora es el control de físicas del atrezzo de la ciudad, para que cada objeto reaccione correctamente cuando el vehículo del jugador colisione con este y balancear los parámetros de peso para que cada objeto reaccione como se espera.

Además, tenemos bastante encarriladas las físicas de la pickup, para que reaccione como se espera.

Ahora que prácticamente tenemos terminada esta zona del mapa, lo que haremos será hacer una pausa en cuanto a creación de más mapa, y centrarnos en la jugabilidad en sí que tendrá el juego. Es decir, por una parte crear un menú simple del juego, que se irá ampliando más adelante. Y por otra parte, centrarnos en el tema de las misiones.

En cuanto a las misiones, la idea es crear un sistema de misión básica y luego ya ir ampliándolo. El sistema de misión básica deberá tener un punto de partida inicial dónde recoger el paquete y un punto final dónde entregar el paquete. Habrá un contador de tiempo para poder puntuar la velocidad de la entrega. Además, el paquete tendrá un indicador de los daños que recibe durante el trayecto. Para poder hacer una buena puntuación, se deberá de llegar en el menor tiempo posible y sin que el paquete sufra daños o los mínimos posibles. Si la entrega no se hace en un tiempo decente o el paquete ha sufrido muchos daños, la misión se dará por fallida.

De momento esto es lo que tenemos en mente. En las próximas semanas os mostraremos los avances de lo comentado en esta entrada.

Para finalizar, os mostraremos alguna imagen más de nuestra ciudad en segunda fase :-).

Vista de unos parques de la ciudad.

Vista de la cafetería del club de tennis.

Vista interior de una parcela de edificios.

Vista de una zona en obras en un callejón.

Esperamos que os haya gustado y nos vemos en la siguiente entrada :-).

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.

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.

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.

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 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:

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!

Texturización. Nuestro pipeline.

En esta entrada explicaremos nuestro pipeline cuando hacemos un modelo 3D en blender. No os vamos a descubrir ningún misterio si sabéis algo del tema, pero ya que no os podemos contar más detalles del nuevo proyecto porqué, como ya sabéis, trabajamos en nuestros ratos libres, nos parece buena idea comentar cualquier tema que pueda interesarle a alguien.

Lo primero de todo, necesitamos el modelo en 3D. Un modelo en 3D nunca está finalizado hasta que no esté posicionado en las coordenadas (0, 0, 0) y con su UV hecha.

Lo de las coordenadas es para poder mover el modelo de un programa a otro sin tener sustos de posicionamiento. Por ejemplo, cuando importamos un objeto a unity y queremos aplicarle alguna funcionalidad, puede ser de vital importancia que sus coordenadas no vengan con algún desfase heredado, ya que programar algún comportamiento se puede convertir en una auténtica tortura. Este punto lo desarrollaremos un poco más en un artículo futuro, ya lo veréis :).

La UV es necesaria, a parte de para "pintar" el modelo, para cuando exportemos e importemos el modelo. Ya que se llevará consigo esa información y así podremos aplicarle la textura que queramos en cualquier software.

Pero, ¿qué es una UV? Pues es el modelo en 3D "abierto en canal" para poder texturizarlo en un editor de imágenes (como photoshop, gimp, etc) o incluso desde el propio blender, si tenéis cierta maña para pintar encima.

Lo más importante es saber donde hacer los cortes para que en la malla desplegada resultante se vean lo menos posible esas juntas. Para un modelo sencillo como una caja, no hay mucho misterio, pero para un modelo más o menos complejo, es relevante encontrar la mejor manera de hacer esos cortes y a la vez enfatizar esas partes donde es más importante tener más resolución. Por ejemplo, para un personaje, dependiendo de su finalidad, podría ser muy interesante que la parte de la cabeza ocupe más espacio en la UV que el resto del cuerpo, ya que va a tener más detalle.

No nos extenderemos en como se hace una UV porqué hay miles de tutoriales por internet y tampoco somos unos gurús del tema, pero solo con hacer una simple búsqueda en google, podremos ver ejemplos de distintos modelos. También podréis encontrar información en la página de unity sobre UV que puede ser interesante.

Ahora sí, lo que os queríamos comentar era nuestro itinerario una vez hecho el modelo en 3D.

A diferencia de con el Torii, "colorearemos" los modelos de distinta forma. Ya avanzamos en el primer tip del blog por donde irían los tiros hablando de los atlas de color. Para nuestro nuevo proyecto hemos decidido simplificar el proceso. En vez de crear una imagen para cada modelo, crearemos una imagen base y la usaremos en todos los modelos.

Podríamos ir a lo bruto y no molestarnos en hacer las UV, coloreando directamente los polígonos, pero si más adelante cambiamos la manera de hacerlo, tendríamos que hacer todas las UV de golpe y sería demasiado tedioso. Realmente no se notaría la diferencia de si hacemos correctamente la UV o no, pero es más por un tema de orden y limpieza.

Así que una vez terminamos de modelar, hacemos la UV y distribuimos los trozos de esa UV que nos interesen en los colores que creamos de nuestro atlas de color.

Por ejemplo, si tenemos como modelo un coche, crearemos su UV haciendo los cortes en la malla correspondientes y pondremos el chasis en el rojo, las ventanillas en el azul claro, las gomas de las ruedas en el negro, etc.

Pero como una imagen vale más que mil palabras, os mostramos como quedaría la UV de un macetero con el atlas de color que hemos realizado para tener todos los colores básicos en un solo archivo:

UV y atlas de color de un modelo sencillo.

De momento hemos decidido que crearemos varios atlas de color. Usaremos uno base para todo donde estarán todos los colores genéricos (rojos, azules, verdes, amarillos, etc). Pero además creemos que estaría bien tener atlas específicos para zonas concretas de la ciudad o incluso modelos. Por ejemplo, tener un atlas de color de todos los verdes posibles para las zonas de bosque, ya que si usamos el atlas base, nos faltarían tonalidades. Y aprovechando esta situación, donde tendremos las UV's de los árboles posicionadas, podríamos cambiar el atlas de color de tonos verdes por uno de tonos naranjas para los árboles de otra zona y cambiarlo todo de golpe sin necesidad de rehacer las UV's. It's magic!

Aplicando esta manera de trabajar, podemos crearnos un atlas (o los que necesitemos) para añadir texturas más complejas a los modelos. Por ejemplo, podríamos tener un atlas para las señales de tráfico, donde en vez de colores tendríamos las imágenes de los stops, límites de velocidad, etc.

Evidentemente, todo esto es factible hacer si el estilo que se le quiere dar al juego acompaña. En nuestro caso, seguimos con el estilo cartoon, por tanto, podemos permitirnos el lujo de crear una textura con colores planos. Incluso para nuestro atlas de señales de tráfico, el pupurri de imágenes no desmerecerá el resultado final, ya que no es necesario que tenga miles de píxeles de resolución porqué se verá desde lejos.

Para acabar con el artículo, os dejamos nuestro primer atlas de color para que podáis utilizarlo si os gusta :).

Atlas de color de Un juego a ratos.

De momento, eso es todo en cuanto a texturización. Cuando haya más novedades en un futuro, os las contaremos. Y, por favor, si tenéis cualquier pregunta o queréis hacer alguna aportación o corrección, no dudéis en comentar, ya que nosotros también estamos aprendiendo a base de prueba y error :).