lunes, 26 de diciembre de 2016

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

jueves, 22 de diciembre de 2016

TIP#1. Atlas de color.

Inauguramos sección de nuestros tips  para hablar un poquito de blender. Así, nuestro primer tip de la sección será para comentar maneras de texturizar.

Hasta ahora lo que hemos ido haciendo para texturizar (para Torii, por ejemplo) era crear el modelo en 3D, sacar su UV y "pintarla" desde el propio blender o desde cualquier programa editor de imágenes.

Otra manera de conseguir lo mismo, "colorear" un modelo, es con un atlas de color. Que básicamente se trata de poner en una sola imagen todos los colores que necesitemos y aplicar esa textura al modelo. La única diferencia será que cuando creemos la UV, posicionaremos cada parte del modelo en el color que nos interese.

Como veréis, es el mismo proceso pero al revés. Con el primer método, hacemos la UV, posicionamos las partes como mejor creamos para texturizar correctamente y "coloreamos". Con el atlas de color, hacemos primero la textura que creamos y al hacer la UV posicionamos las partes del modelo en el color que necesitemos.

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

Este método es especialmente útil cuando creemos que podemos aprovechar una misma textura para varios modelos.

Además, se puede crear un atlas de color con texturas, de manera que podemos tener una única textura con imágenes y no colores planos. A continuación os mostramos una imagen para todos conocida de Minecraft que explica lo que comentamos:
Textura de minecraft.
Textura de Minecraft.
Con este proceso conseguimos evitarnos hacer una textura por modelo, ahorrando espacio y tiempo. Además, podemos crear nuevas texturas mucho más fácilmente y aplicarlas solo arrastrando la nueva imagen al modelo.

lunes, 19 de diciembre de 2016

Algunos detalles del nuevo proyecto.

Aunque aún nos faltan por cerrar muchos detalles, queríamos comentar un poco más lo que tenemos en mente del nuevo reto para que no suenen a chino los artículos que vayamos subiendo. Si en algún momento cambiamos alguna decisión, lo iremos explicando durante el proceso.

Ya hemos avanzado que queremos hacer algo con coches y después de una lluvia de ideas y meditar un poco los pros y contras de cada una, nos hemos decidido por hacer que el coche sea el protagonista y los objetos que transporte una parte muy importante de la jugabilidad. Habrá una historia de fondo con su hilo argumental, pero, a falta de desarrollarla, de momento decidimos que sea un juego de misiones que el jugador realizará en todo momento con el vehículo que lleve en ese instante.

La historia está aún por pensar en detalle. Seguramente tiraremos por algún argumento cliché, como el del chico/a que trabaja para alguna organización criminal (mafia, quizás) y tenga que ir subiendo su rango a través de las misiones que le darán puntos según lo bien que lo haga. Eso si, intentaremos darle algún toque creativo a falta de una idea innovadora.

Dadas esas premisas el escenario será urbanita, aunque podría ampliarse a zonas rurales (pueblecitos), zonas desérticas, montañosas, etc.

Aunque no hemos detallado mucho, lo importante ahora es saber que:
  • El jugador llevará un vehículo.
  • El escenario será una ciudad con posibilidad de ampliar zonas como desiertos, zonas rurales, montañosas, etc.
  • Los objetos que el jugador transporte en su vehículo serán una parte importante de la jugabilidad y el argumento.
  • El jugador tendrá que realizar misiones para mejorar su rango y avanzar en la historia final.

Estilo

Aunque esta vez no tenemos ningún modelo ya hecho que nos "obligue" a seguir un estilo concreto, decidimos seguir con nuestro amado estilo cartoon.

Dada la idea que teníamos con lo que queríamos hacer, hemos pensado que estaría bien añadirle un toque lowpoly. Porqué al querer hacer una ciudad, tenemos pensado que se vea el juego desde cierta altura. Quizás una vista isométrica. Todas estas premisas hace que para nosotros cuadre el estilo.

Además, a parte de que nos gusta mucho ese toque, no hay que olvidar que también nos irá bien por un par de cosas. No tenemos que detallar tanto los modelos y no habrán tantos polígonos en pantalla, que siempre viene bien para tener un buen rendimiento.

lunes, 12 de diciembre de 2016

Nuevas ideas y nuevo funcionamiento del blog.

Hola a todos!

Bien, como habréis podido ver todos los artículos que hemos ido subiendo son de hace relativamente poco. Este blog lo hemos empezado una vez pasado un tiempo de haber acabado el proyecto del Torii.

Pero aunque no hicimos el blog mientras desarrollábamos el proyecto, toda esta información la íbamos guardando en un documento, así que plasmarla aquí no ha sido demasiado costoso.

Por cierto, no olvidéis pasar por el artículo de la demo y probarla :).

Pero, ¿y ahora?. Pues estamos empezando un nuevo desafío. Ya veremos en que acaba, y ya veremos si acaba, pero nuestra intención es la de ir publicando (ahora sí) artículos explicando como va el nuevo reto, más o menos, a la vez de su desarrollo.

Estamos barajando diferentes posibilidades sobre el nuevo proyecto, pero algo que de momento sabemos es que pensaremos en "algo" que tenga que ver con coches. No nos podemos extender demasiado en la historia que tendrá, puesto que de momento no tenemos una idea concreta, pero si que nos hacía gracia tirar por algo totalmente distinto.

En un principio incluso pensamos en hacer algo en 2D, para dar un giro radical a lo que habíamos hecho hasta ahora, pero después de varias pruebas lo dejamos en stand by para seguir por la línea tresdesera como hasta ahora.

De momento no podemos decir mucho más, porqué aún estamos concretando temática y reorganizando el blog, así que intentaremos avanzar más información la semana que viene :).

El blog

También os queríamos comentar como funcionará el blog a partir de ahora. Aunque no cambiaremos demasiado el funcionamiento, si que nos gustaría avisar de lo que puede pasar.

Como no tenemos el proyecto terminado, a diferencia de con el anterior, iremos actualizando cuando podamos. Hasta ahora publicábamos un artículo cada lunes y jueves prácticamente.

A partir de ahora, intentaremos seguir publicando un nuevo artículo los lunes (o martes a muy tardar). Ese será nuestro mínimo que intentaremos respetar. Lo de los jueves ya no lo tenemos tan claro.

Pero si que nos gustaría inaugurar una nueva sección de tips (mayormente sobre unity o blender) donde os comentaremos cosas que nos hemos ido encontrando, ya sean problemas y soluciones, pequeños tutoriales o explicaciones genéricas. Siempre, evidentemente, orientado a todo lo que vayamos necesitando para el nuevo proyecto.

Si todo va bien, y podemos ir generando cada semana un artículo sobre el nuevo desafío, intentaremos que los tips se publiquen en un segundo día durante la semana (podríamos retomar los jueves como rutina), pero no lo sabremos hasta que veamos si podemos generar un mínimo de contenido semanal.

Lo que sí sabemos es que no siempre habrán artículos de este tipo, sólo cuando nos vayamos encontrando con algo suficientemente interesante como para pararnos un minuto y pensar sobre el asunto. Si tenéis alguna recomendación o queréis que miremos algo concreto, no dudéis en decírnoslo en los comentarios o a nuestro mail :D.

Dicho esto, sólo queda empezar de nuevo. No sabemos como irá, pero seguro valdrá la pena!

lunes, 5 de diciembre de 2016

El juego.

A continuación, os incrustamos a Torii en esta entrada. Para poder ver el resultado final os daremos dos maneras de hacerlo.  Una, desde este mismo blog. Eso si, para que no se cargara el juego solo por entrar a la página, lo hemos puesto dentro del mismo artículo. Tendréis que darle al botón de "Continúa leyendo" que aparece abajo para ver el contenido entero del artículo. Dentro veréis que tras esperar uno o dos minutos (dependiendo de vuestra conexión) se cargará el juego.

La segunda manera, y la que os recomendamos, es vía un enlace que hemos puesto dentro del artículo. Podréis verlo mucho más grande e incluso podréis verlo a pantalla completa si apretáis el botón azul de la parte inferior derecha. No sabemos porqué, pero desde el propio blog, este botón no funciona :(.

Esperemos que os haya gustado el proceso :).

jueves, 1 de diciembre de 2016

El final de Torii.

Se acabó. Hasta aquí habíamos llegado. Ya teníamos una primera versión del juego terminada y sólo nos quedaba decidir si la continuábamos mejorando añadiendo todas esas cosas que se habían quedado en el tintero y añadir nuevas, o bien dejarlo por terminado.

Optamos por la segunda. Cansados de tantos meses dedicando gran parte de nuestro tiempo libre al proyecto tuvo su desgaste. Pero no fue una decisión amarga, al contrario. Quedamos muy contentos con el resultado a pesar de los inconvenientes y que acabó siendo un "walking simulator", sabiendo, claro está, que había cosas que podrían haber quedado mucho mejor.

Resultado final del Torii.


Estos son algunos números:

Tiempo invertido. Empezamos a planificar en el mes de agosto de 2014 y sacamos la primera versión del juego en abril de 2015. Aunque hace prácticamente una semana actualizamos ciertas partes del código programado con la nueva versión de unity (versión 5.4.2)* y poder subirlo con a las nuevas versiones de los navegadores. Podríamos decir que invertimos parte de nuestro tiempo libre durante 8 meses.

Dinero invertido. Estos números son fáciles. Compramos un pack de la asset store por unos 25 euros.

Espacio total. La carpeta que contiene el juego ocupa 3,65 GB.

Pero vamos a hablar de las cosas buenas con las que nos quedamos y de las malas que nos hubiera gustado mejorar.

Si ahora tuviéramos que empezar seguramente intentaríamos mejorar el modelo. Hacerle la retopología de la malla de nuevo para crearla acorde a los requerimientos de un videojuego como limitar los polígonos necesarios.

Volver a hacer el rig y su pesado da mucha pereza, pero viendo lo poco que necesitamos para las animaciones, seguramente se podría haber hecho un sistema de huesos más sencillo que el que tiene ahora.

También nos hubiera gustado intentar mejorar el rendimiento, ya que apenas hemos invertido tiempo para mejorar la caída de FPS cuando hay demasiados polígonos en pantalla. Al final no hicimos nada al respecto porqué la única solución que se nos ocurría era o limitar los objetos en pantalla (algo que ya redujimos bastante cuando empezamos a darnos cuenta del problema) o programar las distancias y que solo cargase los objetos a cierta distancia. El problema de la segunda opción es que el mapa es muy pequeño y decidimos que para esta vez, mejor dejarlo así.

Cabe decir que no sabemos que ha pasado con la versión que teníamos anteriormente, pero al modificar el código para esta nueva versión de unity (la 5.4.2)* y poder volver a sacar una versión actualizada del juego, hemos notado que va bastante peor que antes. Y ya no decimos con respecto a verlo ejecutado desde el propio unity donde va infinitamente mejor que en el navegador.

Aquí llegamos a un punto que nos gustaría mejorar. El recurrente "lo dejamos así porqué no tenemos tiempo". Aunque no sabemos muy bien como podríamos cambiar eso cuando "sólo" le estamos dedicando tiempo libre. Y en realidad, este tipo de decisiones las vivimos en el día a día de nuestras profesiones donde nunca hemos estado en un proyecto donde existiera el tiempo infinito para poder hacer el producto perfecto.

Solo nos queda destacar las partes buenas con las que nos quedamos del proyecto y en nuestro caso, es el proyecto en si. Estuvo chulo hacerlo y ha quedado resultón. Es una versión light de lo que pretendíamos, pero tampoco nos quedamos muy lejos de la meta.

Al final podemos decir que hemos aprendido un montón de cosas nuevas. Muchas de ellas han sido por las malas. Y aunque algunas no las hemos podido mejorar, nos hemos quedado con la lección aprendida para la próxima.

En definitiva, acabamos cuando teníamos que acabar y pasado un tiempo, pensaremos en el siguiente proyecto para empezar.

Esperamos que toda esta información que hemos puesto en el blog os haya resultado útil. En el próximo artículo pondremos el juego disponible para que lo probéis si queréis.

¡Hasta la próxima!

*unity 5.4.2 ya no es la versión más nueva, justo estos días se ha actualizado unity a la 5.5.