Coordenadas uv para lightmaps

Un problema bastante tonto, pero que me hizo perder casi dos días de trabajo. Cuando comencé a poner en Unity los escenarios que había modelado en 3Ds Max encontré que tenía unos artefactos extraños en las sombras.

Tal y como se ve en la imagen había zonas mal iluminadas, cuadrados negros extraños. Bueno, Unity 5 trae iluminación indirecta, el motor de iluminación offline (beast) va trabajando creando lightmaps con cada cambio, así que debía ser alguna mala configuración. Así que empiezas a mirar todas las opciones, repartidas entre la ventana de iluminación, las luces, el modelo... Lo único que veo claro es que con luces en tiempo real se ve bien y con luces pre-calculadas es donde surge el problema. Eso descarta que el problema sea en el modelo, que haya hecho algo mal en los mapas uv al crearlo.

Memoria de Temet Nosce

Hacía mucho tiempo que no escribía aquí. El final del desarrollo fue un poco locura y no tenía tiempo para ir escribiendo sobre todo lo que hacía, y después he necesitado un tiempo para desconectar de Temet Nosce. Como proyecto final de máster fue un éxito, la presentación gustó y he obtenido una nota inmejorable. Y ahora vuelvo a coger el proyecto, primero explicando todo lo que hice esos meses finales, y también quiero mejorar alguna cosa y dejaros probar el juego. He decidido no meter más cosas, todas las ideas que tenía y no entraron quedarán en el aire, a lo mejor para futuros proyectos, pero este juego ya está acabado hasta aquí llega. Lo único que voy a hacer es corregir algunos errores, pequeñas cosas que os iré contando.

En este post os dejo colgada la memoria del proyecto que presenté como trabajo final de máster. Una pena que al pasar a pdf unas imágenes quedaron sin pie de foto, cosa que me recriminaron en la presentación. En el odt original estaba todo bien, pero bueno, he corregido esos errores en el pdf y la versión que os dejo debería estar perfecta.

Temet Nosce – Memoria (PDF)

Ragdoll con mecanim en Unity 5

Ya están casi todas las piezas hechas, cada vez queda menos para ponerme a construir de forma efectiva el primer nivel y que así podamos probar el juego, pero según voy haciendo cosas me voy dando cuenta de pequeños detalles que todavía me quedan.

En este caso ha sido que no tenía nada para cuando la vida llegaba a 0. Me faltaba que el personaje se muriera, y para eso tenía que hacer funcionar un ragdoll en Unity 5 con mecanim. Ya he hablado de como hacer un ragdoll, pero era en Unity 4 y sin usar mecanim.

Ya tuve en su momento problemas con mecanim, porque no me mostraba todos los huesos del personaje, y descubrí que podía hacer que se mostrasen los que yo quisiera exponiéndolos. Así pude hacer que se vieran las palmas de la mano, para colocar la espada en una mano y poner un collider en la otra, para que el brazo no atraviese paredes. Siguiendo el mismo procedimiento expuse todas las partes que necesitaba, pelvis, fémures, pantorrillas, tobillos, brazos, antebrazos, cabeza... y monté una ragdoll como había hecho siempre, y... no funciona.

Efectos de imagen y cara

De las cosas más chulas del juego que entregué en Julio y me faltaba de recuperar en esta versión eran los efectos visuales según nos vamos sintiendo peor. He usado menos y creo que con la nueva forma de hacerlos queda mejor.

Cuando estuve probando los efectos de imagen en Unity 5, descubrí que había un par que no me funcionaban desde código, no podía crear variables de ese tipo de efecto para controlarlos. Pensé que era algún problema con las referencias a librerías, pero no, ahora he visto que el problema es que esos scripts no tienen la clase declarada como pública, añadiendo un public a esas clases se arregla el problema. Aunque tener que meter mano en los assets por defecto porque no funcionan, aunque sea por esta chorrada, es un punto en contra de Unity.

Mecánica de caída II: Animación y efectos

Una vez que está resuelta la colisión, como vimos en el primer artículo, hay que ver qué se hace cuando se detecta la colisión. He puesto unos puntos, a mano, de respawn, uno por cada dirección de gravedad, y según qué cubo detecte la caída se coloca al personaje en ese punto y que siga cayendo. Y se tenía que ver esa caída, así que la cámara tenía que retroceder hasta el punto de respawn más rápido de lo normal y siguiendo la trayectoria de caída del personaje en lugar de seguir fija, así que necesitaba tener dos modos de cámara y poder cambiar entre ellos. Ajustado y funcionando, ahora se ve cómo cae.

Quedaba un poco soso, así que le puse un nuevo efecto de partículas, no me he matado, he puesto uno de la asset store, con el único cambio de que las partículas caigan en lugar de flotar hacia arriba. Lo tengo que colocar en el punto de respawn y orientarlo según la gravedad actual antes de activarlo para que el efecto se vea bien. Y como no quiero que las partículas me vayan siguiendo no pueden estar colgados del protagonista.

Mecánica de caída I: Detección de colisiones

Una de las cosas que me faltaban de implementar en la nueva versión del juego es que cuando caigas al vacío vuelvas a aparecer en tierra, pegándote una hostia que te quite algo de vida.

La primera parte que me plantee es cómo detectar que te has caído. Es algo que parece trivial, pero no es tan sencillo. En la versión vieja iba almacenando la altura del suelo que iba pisando, y cuando detectaba que estaba muy por debajo del último suelo pisado es que me había caído. Este sistema tiene algunos problemas. Tienes que ir almacenando la altura del suelo por el que pasas, si hay alguna caída que es alta pero debe ser así para avanzar tendrás falsos positivos. Y solo funciona hacia abajo, si cambias la gravedad ya no vale y tendría que hacer un sistema bastante más complejo para que funcionase.

Entonces pensé hacerlo con colliders, poner unos objetos rodeando el escenario y si tocas alguno de ellos es que te has caído. Comencé metiendo la pieza de escenario dentro de una caja gigante. Aquí tenía dos opciones y no me gustaba ninguna. Una es poner una cada por cada trozo de escenario, pero entonces me detectaría caídas al pasar de una caja a otra (de un trozo de escenario a otro) y necesitaría comprobaciones extra. Otra sería meter el escenario completo dentro de una caja gigante, pero entonces la distancia entre algunas partes del escenario y la caja de caída sería muy grande, estaríamos demasiado tiempo cayendo, como si eso no tuviera solución. Así que descarte la caja.

Adaptando la cámara al cambio de gravedad

Después de tener la cámara funcionando andando por el suelo, faltaba ponerla apunto para que funcione al cambiar la gravedad, cuando andemos por las paredes o el techo.

Ahora en lugar de tener un trazado la cámara, tiene 4, uno por cada posible cambio de gravedad, y según la gravedad en ese momento la cámara irá por un raíl u otro. Además como tenemos el suavizado de cámara, a la hora de pasar de uno a otro se hará automáticamente de forma progresiva.

Suavizado de cámara

El siguiente paso en la carrera de la integración de todos los elementos en el juego en Unity 5 era la cámara. He hablado ya mucho de la cámara y le he dado muchas vueltas, ahora toca la integración y alguna mejora.

Una vez integrado el sistema de la cámara con todo lo que había hecho hasta ahora solo falta poner una ruta y probar si la cámara se mueve correctamente por el rail siguiendo al personaje. Y tengo un primer problema. En este nuevo proyecto la escala es bastante pequeña, así que el hueco que dejo entre la posición del personaje y la de la cámara era tan grande que se me acababa el trozo de escenario que tengo antes de que la cámara comenzase a moverse. Así que tendría que bajar esa distancia. Puedo caer en un problema de precisión por usar una escala más pequeña, pero por ahora funciona. La otra opción era reescalar todo lo que tenía, modelos, escenarios, potencias, efectos de partículas, es mucho trabajo.

Menú de pausa

En los últimos artículos sobre sonido conté como iba a usar un filtro de paso bajo para el menú de pausa, pero como no tenía hecha la lógica para pausar no pude enseñar como sonaba.

Lo primero es crear un pequeño Hud para el menú de pausa, aunque sea sin opciones ni botones ni nada, solo un panel que nos diga que hemos pausado, ya iremos añadiendo opciones. Así que dentro del canvas de UI creo un panel que será el menú de pausa y dentro una imagen (temporal).

Configuración de sonido

Sigo con el sonido, después de ver la teoría, vamos a ver cómo lo uso en el juego. Intenté hacerlo todo con snapshots y transiciones entre ellas. No es mala idea pero no funciona por usar este sistema para intentar crear animaciones de sonido.

Voy a comenzar por explicar los efectos que quiero conseguir y después voy a explicar los intentos de conseguirlo. Lo que quiero es:

• Poder controlar (incluso dar la opción al usuario en la configuración) el volumen de música y efectos de juego (espada, curación, quejidos...) por separado.
• Poder cortar el volumen de todo el sonido del juego cuando suene una interrupción, que se note también que se interrumpe el sonido normal del juego con esa interferencia.
• Un efecto de corte de frecuencias altas en el menú de pausa.
• Poder poner un efecto de reberveración y eco ajustable a todos los sonidos y bajar el pitch de la música según el estado de salud del personaje.
• Que la transición entre estados del personaje sea suave.

Primeras impresiones de Unity 5 (III): Editor de sonido

Unity 5 ha traido también nuevos controles de sonido, y la verdad es que hacía falta, una vez más pasamos de algo bastante básico a un control completamente profesional. Visto por encima puede parecer que han metido una mesa de mezclas y ya, pero tiene bastante más profundidad.

Las mesas de mezclas son Mixers, nuevos elementos que creamos, y serían el equivalente en sonido al Animator que usamos con Mecanim. Son elementos con su propia ventana de edición. En un Mixer podemos crear lo que serían canales de la mesa de mezclas, que se llaman Groups. En principio es parecido a un canal en una mesa de mezclas, pero con añadidos. Los Groups del Mixer son una jerarquía donde el sonido de los hijos pasa por el canal padre. Es decir si tenemos una jerarquía típica familiar en un Mixer (abuelo, padre, nieto), el group nieto tiene su sonido, que pasará al padre, si el padre tiene reducción del 50%, llegará un 50% del volumen del nieto al abuelo, y si el abuelo tiene otro 50% de reducción el sonido final que escucharemos será un 25% de lo que sonase en el nieto.

Power up

Ya puedo matar al enemigo, quiero que cuando acabas con un grupo de venenos caiga un power up para recuperar algo de vida. Así recompensamos al jugador que se para a matar enemigos y no pasa de ellos, y como la vida del personaje va cayendo sola, tienes que pensar si quieres jugar a avanzar rápido sin que te dañen, o a ir matando todo para recoger los power ups.

Tenía que hacer el power up. Tenía en mente esas pildoritas de vida que dejaban caer algunos enemigos en Megaman, al ser en 3D lo más lógico era pensar en algún tipo de esfera más o menos decorada, pero una esfera son muchos polígonos y aún así vista pequeña se nota que no es perfecta. Así que preferí ir a otro tipo de figura más sencilla y al final me quedé con una pirámide cuadrangular. Son 8 polígonos, 4 triángulos que salen de la cúspide y otros 4 que hacen la base. Muy sencilla.

Explosión de veneno

Un vez que detecto bien las colisiones con el personaje o su espada, y tengo una barra de vida, cuando el enemigo golpea al personaje, me falta la parte en que el veneno encaja su golpe cuando el personaje le acierta con la espada.

En el caso del veneno ciego, con 1 solo toque morirá, así que la única reacción que tengo que realizar es la de que muera. Y va a morir en una explosión de líquido verde. Esta explosión es una conjunción de efectos de partículas: he ido cogiendo una nube de humo del efecto de explosión, unas gotas que salpican del de chorro de agua, una textura por allá de una explosión sangrienta y conjuntado todo, y ajustado tamaños, velocidades. Algunos efectos de partículas eran bastante grandes para el tamaño que yo trabajo en el juego y aún reduciendo muchos parámetros el resultado quedaba bastante grande, parecía muy gore (en verde, pero gore), he tenido que reducir todavía más, y aún así es bastante exagerado.

Barra de vida con el nuevo UI

Me estaba dando unos problemas de variables no asociadas el hud antiguo, y como el sistema de UI ha sido actualizado y es bastante mejor ahora, no iba a arreglar el hud viejo para Unity 5, así que ya me puse a aprender sobre el UI nuevo y actualizar el sistema. Por ahora he hecho la barra de vida con el UI nuevo.

El UI viejo era una serie eventos donde podías dibujar cosas en código, no era complicado, pero si no te querías matar a hacer mucho código y apaños solía quedar feote. El nuevo UI son componentes de escena, que puedes toquetear en el editor. Funciona un poco como CSS, tenemos un canvas, que es un espacio sobre el que poner componentes de interfaz y tienen características de responsive web. Podemos decidir como se comporta un elemento al redimensionar la pantalla, si debe estar a una distancia fija de un borde, debe hacerse más estrecho proporcionalmente, mantener tamaño, en un eje, en varios... Además podemos decidir de qué forma se interpreta una imagen. Por ejemplo si tenemos una imagen de fondo para un botón podemos elegir cortes sobre la imagen de tal manera que se redimensione la parte central, dejando los bordes como en el original. Tiene también varios modos de renderizado, 2d en plan hud en pantalla, o con cierta perspectiva, o 3D en el mundo del escenario, para poner, por ejemplo, un bocadillo justo sobre la cabeza de un personaje.

Detección de colisiones de personaje y espada

Estoy en un momento de conectar piezas, ir poniendo todo sobre la mesa y entonces es cuando veo que quedan cosas por hacer aquí, allá, cosas que no están bien migradas o que prefiero hacer de otra manera. Por eso seguramente vengan unos artículos que den bandazos de un lado para otro, lo que me voy encontrando al unir piezas.

En este caso vuelvo a tocar el tema de las colisiones. Todo surge porque una vez que tenía el personaje moviéndose y dando espadazos y al veneno ciego patrullando, era bastante lógico querer probar si se manejaba bien, si podíamos herir al enemigo de forma fácil, o él a nosotros... Y para eso necesito saber cuándo el enemigo choca con nosotros o con la espada.

Problemas al importar el Ciego en Unity

En su momento hice el diseño y animaciones del nuevo tipo de enemigo: el veneno ciego. Y ahí quedó la cosa. No llegué a incluirlo en Unity porque me puse con otras cosas, y ahora ha llegado el momento, y me he encontrado con varios problemas, no ha sido tan sencillo como yo creía.

El primer problema fueron los huesos. Como solo quería animar los brazos, puse unos huesos sueltos en cada brazo, y si en Unity eliges la animación como Legacy se mueve, pero en Generic no. Y si estoy usando animaciones del tipo actual no quería volver a Legacy. Llegué a la conclusión de que no funcionaba con Generic, por ser dos esqueletos, uno en cada brazo, y no uno solo. Y creo que tenía razón, añadí un hueso más al cuerpo que unía los dos brazos y la animación empezó a funcionar con un rig de tipo Generic en Unity.

Interrupciones con Screen Overlay

Al probar las características de Unity 5, miré todos los efectos de imagen que traía, realmente no hay ninguno nuevo, que no estuviera en Unity 4 pro, pero al jugar con ellos me di cuenta que había una cosa que podía hacer más fácil que como lo estaba haciendo: las interrupciones.

Hasta ahora las interrupciones las hacía de la siguiente forma: tenía en la misma escena un plano con una textura que cambiaba al azar entre las posibles imágenes de interrupción, con su propia cámara y luz. Lo tenía alejado del resto del escenario para que no se viera, y con la luz trabajando solo en la capa del plano de esa imagen para que esa luz no afectase a la iluminación del resto de la escena. La cámara tenía puesto el efecto de ruido tipo televisión analógica que se ve. Y cada vez que salía al azar que tenía que hacer una interrupción apagaba la cámara principal del juego y ponía en marcha la de este sitio secundario.

Problemas en el movimiento del personaje

Este artículo va a ser un poco un cajón de sastre sobre todos los aspectos del movimiento del personaje que no he tratado ya. 

En la parte de ataque finalmente he dado 3 movimientos de ataque, lo cual lleva 7 animaciones, las cosas se complican. Si damos al botón de ataque el personaje dará una estocada, y si no hacemos nada más volverá a posición neutral. Eso ya son 2 animaciones. Pero si mientras da la primera estocada, volvemos a dar al botón de ataque hará un segundo ataque, un combo. Así que hace falta la animación del segundo ataque y la de volver a posición neutral desde el segundo ataque. Ya van 4 animaciones, y también he dado opción a atacar mientras estamos en el aire. Esto es un poco más complicado, tiene la animación de coger impulso en el aire para dar el golpe, después una pequeña animación de 2 frames que es la de caer dando el espadazo, que al no saber cuánto vamos a caer necesitamos una pequeña en bucle, y por último la de acabar de caer y recoger hacia atrás. En total 7.

Efecto de estela

Ya tengo el personaje con todas sus acciones básicas del juego cubiertas, anda, corre, salta, cambia la gravedad y ataca con la espada. Esto último es nuevo, en el próximo artículo explicaré varios problemas que he tenido juntando todos los movimientos, los tipos de ataque de espada, etc, en este quiero explicar como he hecho el efecto de estela al atacar con la espada.

Una vez que tienes las animaciones de los espadazos y lo programas para que los de al dar a un botón, te encuentras que es algo soso. Así que empecé a buscar cómo hacer que la espada tuviera un efecto de estela, estuve viendo videos de Medievil y tiene ese efecto, una estela blanca, y me di cuenta que era útil por varias razones, te da tiempo a ver qué dirección toma un movimiento de espada, queda visualmente curioso, y también disimula un poco si la animación no es excepcionalmente buena.

Colocar un arma en Mecanim

Hoy estoy contento, he conseguido solventar un problema que llevaba arrastrando meses, con buen resultado, me abre unas cuantas posibilidades y además lo he hecho trasteando, no encontré la solución en don google. El problema de unir la espada a la mano del personaje.

No es la primera vez que escribo sobre este problema, hice un artículo sobre cómo poner la espada en la mano al personaje en 3Ds max. El problema era que el formato FBX no soportaba las restricciones con las que se hacía, así que no funcionaba en Unity. Eso, y cómo lo solucioné metiendo la espada como parte del mismo modelo lo comenté en otro artículo sobre los problemas de exportar de 3Ds max a Unity. Eso hacía que funcionasen bien las animaciones de Mecanim sobre un modelo con espada, pero la espada era parte del cuerpo. Eso me preocupaba ya que no podría poner un collider solo a la espada para ver si golpeaba a un enemigo. Pero ahora me encontré otro problema, los sistemas que hay para hacer estelas (trails), para dar ese efecto cuando se moviese la espada, no funcionan bien si no tenemos la espada como una parte independiente.

Salto incremental con el controlador de Unity 5

Con el movimiento del personaje ya conseguido me faltaba mejorar algunas cosas, por ejemplo hacer el salto incremental, que cuanto más tiempo dejemos pulsado el botón de salto más alto salte. Algo sencillo en principio, además que ya lo tenía hecho en el controlador viejo, pero las cosas a veces se complican.

La idea básica es dar un impulso inicial al salto cuando se presiona el botón y en cada frame ir aumentando un poco ese impulso si el botón sigue pulsado hasta un tiempo máximo de pulsación del salto. En peras y manzanas: Si pulsas el botón una décima de segundo saltará 1 metro, si pulsas 3 décimas saltará 2 metros, si pulsas medio segundo saltará 3 metros y si dejas el botón pulsado 35 años saltará 3 metros igual que es el máximo.

Migración a Unity 5: cambio de gravedad

En el último artículo dejamos al personaje moviéndose por la escena. Quería como siguiente paso ver si era capaz de hacer una de las partes que tenía hechas en el SuperCharacterController pero no integradas en mi proyecto, las referentes al cambio de gravedad.

Al ser un ejercicio académico lo más importante aquí es aprender. Por eso aunque el trabajo realizado en los cambios del controlador de personaje anterior no se va a usar en el juego final, todo lo que me tuve que pegar con los giros, cuaternios y direcciones de la gravedad me sirvió para aprender y poder realizarlo en el nuevo controlador en menos tiempo. Incluso algunas de las funciones, como la que calcula los ejes más cercanos a un vector las he podido reutilizar.

Migración a Unity 5: El personaje en movimiento

Al final me he puesto en marcha en la tarea de migrar el juego a Unity 5. He tenido que comenzar un proyecto desde 0 e ir añadiendo las piezas que tengo poco a poco. Hay cosas que tendré que sacrificar, otras hacerlas de otras maneras, pero va a aumentar la calidad, y puedo hacerlo todo con la versión gratuita sin recurrir a la pro de formas poco limpias.

Lo primero ha sido colocar el Skybox (al que por cierto he dado una capa de niebla azulina para que parezca más lejos), el personaje, e internar que se mueva correctamente. El sistema de controlador para personaje que tiene incluido Unity 5 es bastante mejor que la mierda que tenía hecho el obrero en la versión anterior. Así que he probado si podía usar su sistema, mortificándolo a mi gusto para que funcione como el que tenía, y fiarme también de su sistema físico y de colisiones. Esto significaría tirar el trabajo que hice adaptando el SuperCharacterController, pero creo que merece la pena. Lo tenía funcionando en un proyecto aislado, de prueba, y estaba teniendo problemas para integrarlo con el proyecto del juego. Y tampoco se llevaba bien con las animaciones de Mecanim.

Primeras impresiones de Unity 5 (II)

En el último artículo ya comencé a contar mis primeras impresiones sobre Unity 5. En este voy a seguir con algunos elementos más, y no creo que sea el último.

Elementos Pro a Personal

Casi todos los elementos que estaban en la versión Pro de Unity 4 han pasado a la Personal en Unity 5. Entre ellos: Efectos de post-proceso, video texturas y light probes (además mejorados).

Cambia un poco la forma de usarlos, pero muy poco. Los efectos de imagen, vistos por encima parecen los mismos y con los mismos parámetros que en la 4pro, lo único es que ahora están en un namespace distinto, por lo que tendremos que añadir un using o más calificadores cuando lo usemos en código. Las demos los usan mucho, a veces se pasan con el Depth of Field, que tiene poco tamaño focal, y se ve todo borroso por todos lados. Son muy interesantes, muchas veces son cosas que no piden mucho rendimiento de comer, al hacerse sobre la imagen final, y mejoran mucho la calidad gráfica.

Primeras impresiones de Unity 5 (I)

La semana pasada en la GDC se anunció la liberación inmediata de la versión definitiva de Unity 5. Que básicamente mete mejor iluminación, y casi todo lo de pago en Unity 4 es gratis en Unity 5. Así que me he puesto a curiosear con la nueva versión, para ver sus posibilidades y si puedo migrar mi proyecto de 4 Pro a 5 Personal y así poder usar algunas nuevas características. Voy a exponer mis primeras impresiones.

Mecanim

Mejora la interfaz para usarlo y añaden más complejidad, que hacen más sencillas algunas cosas. Ahora hay una columna en el editor de Animator para ver los parámetros y las capas, para que estorben menos en el diagrama de la máquina de estados.

También mejora las formas de hacer el blending de animaciones. Aunque mucho de este trabajo se ha ido metiendo en la versión 4 en sus diferentes actualizaciones, lo que había hablado en el artículo de introducción a Mecanim era lo que se podía hacer desde la 4.0. Ahora hay más opciones para hacer el blending.

Skybox de la primera pantalla

Una de las cosas con las que quería trabajar es el Skybox. Ese fondo del juego inalcanzable que ponemos. Normalmente se trabaja con cielos, horizonte, eligiendo entre nublado, día, noche y poco más. Y quise hacer algo distinto. Si estamos en un mundo onírico y fantasioso no es muy inmersivo que el fondo sea de lo más normalucho.

Una de las primeras ideas fue poner el cubemap al revés. Es decir que el cielo fuera suelo y el suelo fuera el cielo, montañas por encima de la cabeza y nubes bajo tus pies. Así además me serviría como primer referente de que la dirección de la gravedad en un mundo imaginario no tiene por que ser la normal. Pero no funcionaba, el fondo llamaba demasiado la atención, y parecía completamente desconectado del escenario que vamos pisando. Daba la sensación de que el escenario estaba flotando dentro del skybox, algo que es cierto pero que no debería notarse tanto.

Introducción a Mecanim

Estoy empezando a usar Mecanim como sistema de animación de movimiento. Y hoy voy a contar alguna de sus bondades principales. Aunque habrá que empezar por explicar un poco ¿qué es mecanim?

Hay algo de confusión sobre esto, y muchos hemos pensado que era lo que no era. Mecanim es la respuesta de Unity ante la baja calidad de las animaciones de los juegos hecho con Unity 3. Entonces, ¿se tienen mejores animaciones con Mecanim? No, las animaciones serán las mismas pero se usarán mejor y será más sencillo hacer cosas más complejas. Mecanim no es un sistema para crear animaciones, sino para usarlas. Tendrás que darle las animaciones hechas de forma externa exactamente igual que hasta ahora. La novedad es que para usarlas en lugar de hacer todo por código harás mucho con un editor visual y con muchas más opciones y potencia.

Crítica a mi nivel de Portal 2

Hace unas semanas me pegué con el editor de cámaras de Portal 2 y publiqué una. No pude realizar todas las ideas que tenía por limitaciones del editor, conseguí transformar algunas en algo parecido y otras se cayeron, al final publiqué y quedé medio satisfecho con el resultado. Ahora un compañero de máster la ha jugado y colgado su gameplay comentado en youtube. Eso me ha servido, además de como divertimento, para ver ciertas cosas de la cámara desde otro punto de vista, cosas que hice mal y otras que si están funcionando bien. En este artículo voy a analizar lo bueno y lo malo desde el punto de vista del diseño de niveles. Me interesa mucho esa materia, y una de las mejores formas de aprender es ser crítico con lo que vas haciendo.

Si antes de ver mis comentarios lo quieres comprobar por ti mismo, esta es la cámara: http://steamcommunity.com/sharedfiles/filedetails/?id=386619576

Problemas al exportar de 3DS max a Unity3D

En entradas recientes he hablado sobre cómo poner la espada al héroe mediante una restricción, y en cómo hice cambios tardíos en el modelo con bastante suerte. Una vez más el demonio está en los detalles y he tenido problemas con todo esto cuando he tenido que pasar a las siguiente etapas.

No había conseguido que me funcionase mi modelo con animaciones ya hechas de las que hay en el Asset Store de Unity, así que comencé a hacer mi propia animación de correr en el 3DS max, poniendo al lado otro modelo corriendo del Asset Store y copíandole un poco las poses, adaptado a mi personaje.

Al tener al personaje corriendo, giré la cámara alrededor buscando que todo fuera bien, y algunas veces veía alguna cosa rara. Pero era muy sutil, si lo miraba frame a frame durante solo un frame salía un triángulo raro por algún lado, que se veía solo desde cierto ángulo. Y todo venía por esas partes interiores duplicadas que puse para evitar que el faldón y las mangas fueran transparentes por dentro. Y claro, si un trozo de estos se sale de donde debe, como está mirando hacia el lado inverso, se va a ver transparente, salvo en algún ángulo extraño, y justo eso es lo que estaba viendo. La solución es pegar (weld) los vértices internos y externos en el borde. Algo que de todas maneras debería haber hecho en su momento al crear esos nuevos telares.

Escenario del Parque Güell

Llevaba desde verano queriendo hacer escenarios con inspirados en Gaudí. Al tener los exteriores como terreno, me tenía que esperar a hacer interiores. Pero tras la decisión de hacer los exteriores modelados, he podido comenzar ya. Y para muestra un botón.

Quería usar una parte del Parque Güell. Tiene una galería donde la pared está inclinada, enfrentada a una columnas con el mismo ángulo. Visto a lo largo de la galería tiene un poco forma de oreja. Así que aprovechando la práctica creando formas con NURBS (realmente comencé a usar esas formas para poder hacer cosas así) usé la misma técnica que expliqué en el anterior artículo.

Multimaterial con mapeados UVW separados

Me interesa poder crear los escenarios como una o varias piezas que pueda escalar y colocar en Unity. Y cada una de esas piezas puede estar formada por varios objetos. En el caso que vimos de la primera parte de la primera pantalla, el suelo, los obstáculos y las paredes. Y poder elegir libremente el material de cada uno de estos elementos por separado. Incluso el mapeado de texturas. Y de eso va este artículo.

Lo primero es dividir el objeto dando identificadores de material a cada zona que queramos. Para ello tenemos que tener todo como un solo objeto y en editable poly. Una vez que elegimos un polígono (o varios) o un subelemento podemos darle un id de material. Yo he dividido el objeto en 6. El primero la parte no visible del cubo que hace de suelo (lados y parte de abajo) para ponerla en negro. Después el plano que hace de suelo. Estos con selección por polígonos. Ya mediante selección por elementos doy identificadores al NURBS de las paredes y a los 3 obstáculos. Podría haber dado el mismo id a los 3 obstáculos, ya que seguramente lleven el mismo material, pero he preferido separarlos para poder elegir la proyección de la textura de cada uno por separado.

Uso de NURBS para el modelado 3D

Finalmente me he lanzado a crear los escenarios modelados, en lugar de usar terrenos. Una de las ventajas de esto es que puedo hacer formas más complejas, doble nivel de suelo, paredes verticales, zonas con techo, y curvas, muchas curvas que en terrenos es complicado de conseguir.

Necesito esas curvas porque quiero usar formas inspiradas en Gaudí. Lo primero que he intentado es tener unas paredes curvas en la primera parte de la primera pantalla, y eso me ha permitido aprender a usar NURBS para el modelado 3D.

En la primera parte las paredes tienen una doble curvatura, una en su borde superior, que se hará más bajo o más algo dependiendo de la zona y con curva suave. Y la segunda sobre el plano, ya que esta habitación tiene silueta de balón de rugby o de barca, más ancha el medio y acabando en punta. Al tener dos curvaturas es algo más complicado que solo crear un plano NURBS a medida.

Música de Temet Nosce I

Un parte muy importante en un juego, para que transmita emociones y de una mayor sensación de inmersión es el sonido, en particular la música.

Los que estamos empezando en esto, haciendo pruebas más que otra cosa, aprendiendo, solemos cometer la torpeza de dar poca importancia al sonido y la música. Al final nos encargamos de la jugabilidad, los gráficos, etc y algunas veces llegan cosas sin sonido, o con sonidos tirados a última hora de mala manera. Desde luego no podemos permitirnos contratar un músico y dar una banda sonora hecha a medida. Así que solemos recurrir a bancos de música libre, sacar sonidos de donde podemos o cosas peores.

Caigo en ese mal en cuanto a los sonidos. Pero sí he dedicado algo de tiempo y técnica a crear buena ambientación con la música. No recuerdo como fue el orden de ideas, si primero tuve la canción y luego la técnica a usar, o al revés. El caso es que tenía esa idea de que la música se adaptase al estado de vida del protagonista. Igual que las distorsiones en la pantalla se hacen mayores cuanto más jodido de vida estás, que la música también se hiciera más profunda, distorsionada, como de sueño.

Cambios tardíos en el modelo

He sufrido pequeñas pesadillas con final feliz. En varias ocasiones me ha pasado que me he dado cuenta de un fallo de modelado con el modelo en una fase muy posterior, el rigging hecho, incluso con animaciones funcionando. Según lo aprendido tradicionalmente esto es muerte y destrucción, seguramente te toque volver a repetir todos los procesos posteriores al modelado, incluyendo los mapas uv, texturizado, rigging y animación. He conseguido alterar varias cosas sin tener que volver a pasar por todo eso, voy a mostrar dos ejemplos.

El primero ha ocurrido cuando he empezado a probar el personaje en Unity, y entonces me doy cuenta de que el faldón visto desde dentro no se dibuja, o si miras dentro de la manga, es transparente. En 3DS max no me ocurría, y es que tenía activado que dibujase los polígonos por los dos lados. Existe la posibilidad de activar esto en Unity, pero si lo haces es para toda la escena. El impacto en rendimiento es brutal. No solo eso sino que la iluminación comienza a fallar, y se ven efectos raros. No parece buena solución.

Poner la espada al personaje

Esta entrada va a ser más concisa que la media del blog. Trata sobre cómo poner una espada a un personaje y se podría aplicar a cualquier objeto que se agarre o su movimiento dependa de otro.

En su momento me planteé poner huesos a la espada, es un concepto un poco raro, pero he visto poner huesos a la capa de un héroe para animar su movimiento al caer, por ejemplo. Pero en este caso no funcionaría. Los huesos son más para deformar algo, darle movimiento interno, y la espada no se va a deformar, no tiene movimiento externo, siempre se mueve como una pieza completa.

Y realmente lo que quiero es no tener que animar el movimiento de la espada, en mi juego el protagonista va a tener siempre la espada cogida de la mano, así que con que la espada se mueva con la mano me sirve. Y eso es lo que quiero, animar el brazo del protagonista y que la espada se mueva como si de verdad estuviera agarrada. Para ello solo hay que poner una restricción de tipo enlace (Link constraint). Así enlazamos el movimiento de la espada al del hueso de la palma de la mano. ¡Y ya está! En el vídeo muestro como ahora al mover un hueso del brazo la espada se mueve junto a la mano y siempre queda bien agarrada.

¿os habéis fijado que mi personaje es zurdo?

Simulación de telas

En las últimas semanas parecía que todo me salía bien, que todo eran alegrías. Pues hoy toca aceptar una derrota, algo que no he conseguido hacer funcionar y que tendré que hacer de otra manera.

Un compañero de máster me comentó de pasada que podía simular el abrigo del personaje en 3ds max y así no tendría que animarlo a mano. Pero estaba ya casi decidido a quitar el abrigo. El problema vino cuando ya le puse los huesos al modelo, y probé una animación de andar. Muchas cosas no funcionaban bien, como me esperaba, porque hay que ajustar el weighting de los huesos. Pero me llamó mucho la atención el movimiento de la ¿camisa larga?, ¿faldón?, ¿vestido? (la cosa morada) del protagonista. Las piernas lo atravesaban a veces al andar, eso tenía pinta de que no se arreglaba con el pesado de huesos, sino que iba a necesitar retocar las animaciones de esa parte de ropa casi frame a frame.

Y ahí se me encendió la bombilla de intentar usar simulación. Llegué a tutoriales por youtube y parecía sencillo, vi alguno donde se creaba un modelo con 4 cilindros, creaba cierta ropa con un plano y ponía a simular y el resultado era muy bueno, cómo mola, resultado muy bueno con poco trabajo, la parte del tutorial de la simulación física de telas apenas duraba 2 minutos.

Cambio de gravedad con SuperCharacterController

En la entrada anterior presentaba el SuperCharacterController, y los cambios que había hecho, y en esta me reservo el cambio principal, el control de gravedad, vuelvo a poner el vídeo para que se vea de qué hablo.

Siempre tenía la duda de en el caso de tener una cámara libre se aplicase el cambio de gravedad hacia donde cambiaría. Es decir, si damos al botón de cambiar la gravedad hacia la izquierda, hacia donde debería cambiar la gravedad, ¿según el vector left del personaje?, ¿el vector left de la cámara?. Si se hiciera con el del personaje sería un lío, por ejemplo si el personaje está mirando hacia la pantalla (le vemos la cara) y cambiamos la gravedad a su izquierda, en realidad la cambiamos a nuestra derecha. ¿queríamos hacer eso? Seguramente no. Así que para facilidad del usuario, me parece lógico que se cambie siempre según su punto de vista. Ahora bien, al tener una cámara libre, podríamos estar mirando en cualquier dirección, eso significaría poder poner la gravedad en cualquier dirección, completa libertad, y cosas un poco raras. ¿Gravedad mirando hacia una esquina?

Encontré una solución haciendo que la gravedad se ajuste al eje más próximo. Es decir, imaginemos que el personaje está moviéndose en diagonal, pero lo más cercano es el eje +z, entonces al girar la gravedad a la izquierda, la gravedad pasará de -y a -x. Es un sistema que funciona bastante bien en un escenario como el de la demo, donde las paredes son rectas y alineadas con los ejes. Al tener una cámara sobre raíles siempre puedo hacerlo respecto a la cámara, pero si sigo haciéndolo ajustado a los ejes y hago que los escenarios también sean ajustados a los ejes intentando que no se note mucho que todo es muy cuadradote. La ventaja es que así puedo realizar puzles y retos de forma sencilla y fácil de probar y evito muchos posibles bugs y tampoco vuelvo loco al jugador.

Nuevo sistema de control usando SuperCharacterController

El control del juego no me gustaba, sobre todo porque hacía muy frustrantes las secciones de salto, los saltos con un salto de altura única (aunque a veces salta más o menos de forma extraña), y en 4 direcciones, no en direcciones libres. Por eso comencé a buscar tutoriales para ver cómo se las apañaban para hacer un control de este tipo para rehacer el mío.

Así, a través de diversas búsquedas, paseos por los foros y páginas de google llegué al blog de Erik Ross. Me pareció muy interesante pues dedica 4 o 5 entradas a describir problemas con la detección de colisiones y movimiento en Unity y en su controlador de personaje por defecto. Y resulta que tenía muchos más problemas por el lado de las colisiones de lo que creía. El blog requiere un cierto conocimiento de matemáticas (e inglés), pero está muy bien. Se ve que está haciendo un remake HD del Mario 64, y aprovecha para ir explicando las cosas que está haciendo, a día de hoy casi todo referido al controlador del personaje.

Por ejemplo uno de los temas que explica, acompañado de gráficos muy útiles, es por qué con el controlador de personaje de Unity, al bajar cuestas, el personaje baja a trompicones, como si andase en plano y cada cierto tiempo se diera cuenta que está en el aire y cayera un poquito. Y desde luego en la solución de controlador que ofrece las bajadas se hacen de forma suave.

Efecto agujero en la cara

Antes de explicar qué hace Kayne West aquí, voy a entrar en un pequeño detalle del nuevo personaje que presenté en la última entrada: los ojos del protagonista.

Los ojos que puse al modelo, los de Kenshi Himura, me parecían muy grandes y femeninos, y justo viendo Rurouni Kenshin me di cuenta que cuando Kenshi lucha, sus ojos son más pequeños y con forma de romboide, más agresivos. Y así he dibujado un segundo par de ojos y adaptado las cejas a esta nueva expresión. No me gusta el resultado, no me acostumbro, de repente parece el malo de la historia (el malo y mal operado). Dejo una comparativa de ambos tipos de ojos, no se si seguiré trabajando en el segundo tipo de ojos, por ahora he vuelto al primero.

Nuevo personaje: diseño e inspiración.

Una de las cosas que más trabajo me llevaron y que menos me gustaron de la primera versión del juego era el protagonista. Me maté haciendo el modelo, y quedo muy feo y eso que tenía polígonos para dar y regalar.

Quería cambiar ese modelo, pero para poder hacer un personaje de una calidad decente para mi gusto necesitaría meses de práctica, lo cual seguramente sería muy bueno para mejorar mi faceta artística, pero que no hago por dos razones. No tengo tanto tiempo para dedicar solo a eso, necesito un juego completo para entregar y además tampoco quiero ser modelador, por lo que invertir meses de tiempo en mejorar en ese campo no sería la mejor decisión.

Así que decidí partir de algo ya hecho, un modelo base y moldearlo a mi gusto. Primero intenté trabajar con z-brush, partiendo de algunos modelos de ejemplo que trae, aprovechando que el programa deja moldear como si fuera arcilla y marcar detalles que te acaba metiendo en un mapa de normales. Me sigo sintiendo perdido en ese programa, necesitaría una buena batería de tutoriales. Así que empecé a buscar si encontraba algún modelo libre que usar como base que se pareciese más a lo que quería usar, incluso si pudiera tener el rigging ya hecho. Me miré todos los modelos de blendswap, más de 2000, incluso me bajé y probé varios. Alguno parecía candidato. Entonces probé otra cosa, intentar conseguir alguno de los modelos de referencia para mi personaje.

Veneno ciego: animación

Después de tener el modelo, ya con texturas y todo del nuevo personaje. El siguiente paso es hacer una pequeña animación, que esos tentáculos se muevan un poco mientras el personaje avanza. Porque esos tentáculos todos tiesos mientras el personaje se desplaza por la pantalla quedaría muy raro.

Y aquí he tenido que hacer algo por primera vez: crear huesos. Hasta ahora siempre había animado cosas con esqueletos estándar, sobre todo humanoides, así que usaba huesos prefabricados. Es la primera vez que he tenido que coger y crear un hueso, colocarlo en su sitio, poner el siguiente unido... Aunque este caso es fácil, cada brazo lleva solo 3 huesos, y no he tenido que poner límites de movimiento ni nada así, porque solo iba a hacer una animación y más o menos sencilla. Hubo un momento que me paré a pensar que era extraño crear huesos por primera vez para una especie de moco gigante.

Veneno ciego: Inspiración y diseño

Ya había dado pistas de que tenía la intención de hacer un segundo tipo de enemigo. Y tenía la idea bastante clara y el resultado se parece bastante a lo que quería hacer.

La inspiración inicial fue un monstruo del Ni No Kuni. En el juego español se llama Moko, en inglés Pom Pom. Es un bicho verde, una bola con un par de tentáculos colgando. Pensé que eso era fácil de hacer y la idea me gustaba, pegaba con mi diseño actual de veneno, pero se ve la diferencia entre uno y otro. Cuando lo he buscado por Internet, además de encontrar muy pocas imágenes (y por es tan pequeña, lo siento) he visto que el bicho era diferente a como yo lo recordaba, con más tentáculo y más cortitos. Y he preferido seguir lo que estaba en mi cabeza, solo 2 brazos y más largos.

Implementación de la cámara: tercera versión

Decía en el último artículo que ya tengo la cámara funcionando como quiero, y que los problemas de rendimiento no eran culpa del sistema de cámara. En este artículo voy a cubrir cómo funciona la cámara al final y pequeños problemas y sus soluciones.

El sistema básico tiene las ideas que expliqué en el artículo sobre la segunda versión de la cámara. Tener trozos de spline de 5 nodos, con nodos equidistantes, y donde el último tramo de un spline y el primero del siguiente se suponerponen haciendo una transición suave entre un spline y el siguiente en esa parte en común. Lo que al final se queda fuera es la aproximación de la posición del personaje al spline por trozos de spline. Ahora mismo sigo aproximando el spline como una recta para saber a qué altura del spline está el personaje. En mis pruebas no se nota diferencia entre las dos aproximaciones y es más barata.

Uno de los problemas que tenía desde el principio de los tiempos y que pensaba que el usar la transición suave entre 2 splines se iba a arreglar era el de los puntos muertos en los empalmes de splines. Se entiende mucho mejor con una imagen de estas cutres que dibujo tipo paint (pero que uso programas de los buenos para hacerlos, el manco soy yo, no el sw):