Experimento Blender: Como diseñar personajes "rápidamente"

Hoy quiero actualizar con un "tutorial/experimento" que espero editar y completar con imágenes más adelante a medida que lo pruebe. Se trata de la creación de personajes 3D (humanos)  en blender para un videojuego.

El proceso de creación de un personaje es bastante largo y tedioso y se compone de varios pasos desde modelar o hacer la malla o forma básica del personaje hasta pintarlo, añadirle esqueleto y animarlo. Todo este proceso puede llevarte bastante tiempo, sobre todo si no eres un profesional y lo haces como hobby.

WARNING: Este proceso, en principio no está descrito en detalle ni esta orientado como un tutorial si no te sabes manejar con blender. En cualquier caso si ya tienes alguna noción sobre blender, puede que te sea de ayuda.

Empezemos, la idea es obtener una malla de relativamente pocos polígonos con la mayor definición posible. 

Paso 1: Malla high-poly

Necesitaremos una malla high-poly con mucho detalle para extraer el mapa de normales (luego explicaré qué es esto) y otra malla low-poly con menos detalle que será la que usaremos ingame.

En este caso empezaremos usando el programa MakeHuman. Este programa es un software para diseñar personajes 3D a partir de ciertos datos tales como la edad sexo facciones etc. Es un programa muy simple de usar y con el que crearemos un personaje con mucho detalle jugando con los parámetros que nos dan.

Una vez obtenido el diseño básico que queremos exportamos desde MakeHuman a blender nuestro modelo.

Paso 2: Modificando el diseño

Debido a que MakeHuman no dispone de un sistema para poner ningún tipo de ropa a los personajes, estos estarán completamente desnudos, y a menos que quieras que corran por el juego como vinieron a este mundo... habrá que modelar las partes de ropa que queramos hacer. De nuevo 2 opciones:
a) Modelar la ropa que queramos por encima de la malla o en la propia malla.
b) Usar el modo para esculpir que ofrece blender para diseñar con ello la ropa.

Paso 3: Malla low-poly

Ahora que tenemos nuestro diseño exportado a blender y con ropa, vamos a necesitar una malla básica low-poly para nuestro personaje, la cual podemos conseguir:
a) Modelando una malla por encima del personaje high-poly (no hace falta entrar en detalles, algo que no lleve  mas de 5~10 min.
b) Obteniendo un modelo de malla básica desde Internet y hacerle algunas modificaciones simples para se adapte por fuera de la malla high-poly, como si de un "traje de aire" se tratase.

Y aquí es donde está la magia, usamos el modificador shrink wrap para hacer que la malla low-poly se adapte al modelo creado en MakeHuman, con lo que conseguiremos una malla de bajo detalle, pero con la forma que queremos.

Nota: Es probable que tengamos que hacer varios retoques para que esta malla quede bien.

Paso 4: Añadiendo detalle

En vista de que la malla a usar en ingame es low-poly, no tendrá demasiados detalles definidos, así que tendremos que pintarla si no queremos que parezca una estatua.
1) Creamos un desplegado UV de nuestra malla low-poly, necesario para poder aplicarle las texturas que necesitemos.
2) Después debemos crear una textura para el color, podemos elegir o bien utilizando el modo de pintor en blender normal y corriente, o utilizando la pintura por proyección.

Una vez el diseño tiene una textura básica, necesitamos añadirle detalle. Esto se consigue mediante los mapas de normales, mediante los cuales podemos dar la sensación de que una cara plana tiene relieve. Para conseguir esto, necesitamos de nuevo nuestro modelo high-poly.
1) Creamos una imagen nueva desde blender para "imprimir" en ella este map.
2) Seleccionamos el modelo high-poly, shift + right click, modelo low-poly. Vamos a opciones de renderizado y en lugar de renderizar un frame normal, vamos a la opción Bake
3) En este menú elegimos Normals y el espacio Tangent.

Al darle botón bake veremos como el mapa de normales se despliega en la imagen que hemos creado. Ahora solo tememos que aplicar este mapa de normales en el menú de materiales a nuestro modelo low-poly.

Inspiración - Concepto personajes

Lo cierto que el tipo de personajes que quiero incluir en project caelum son personajes con mucha habilidad de movimiento, y con la capacidad de volar en algunos casos.

He encontrado en la página de deviantart algunos dibujos que recogen la idea de lo que quiero.

Project Caelum: problemas con la arquitectura de red

 Hasta ahora la arquitectura de red que me he planteado es muy simple, una arquitectura cliente-servidor utilizando la librería de red ENet (parte del motor libre "Cube" y "Cube 2") pudiendo verse en marcha en el videojuego Sauerbraten.


Mi decisión principal ha sido separar el motor de físicas al lado del servidor lo cual me evita el engorro de sincronizar el motor de física de todos los clientes, para pasar a sincronizar unicamente las posiciones/orientaciones calculadas por el servidor.

Pero hagamos unos calculos para comprobar la viabilidad del sistema. Vamos a centrarnos en la subida del servidor que es donde se centra el cuello de botella del tráfico del juego.


Supongamos una conexión normal/baja de hoy día que soporte 512Kbps de subida. A este servidor se conectarán hasta digamos 16 personas.
512 Kbps * 1024 / 8 = 65.536 Bytes por segundo.
65.536 Bps / 16 clientes = 4096 Bps / persona


Tenemos 4KB de información para enviar a cada cliente por segundo, en esos 4KB debemos incluir toda la información de los demás clientes y la suya incluida, y deberemos mandar un número constante de reportes cada segundo, digamos 30.
4096 Bps / 16 clientes / 30 reportes = 8,5 Bps en cada paquete de datos.


Una posición x,y,z son 3 float y una orientación puede medirse como mínimo con 3 variables (la direccion de la normal), con lo cual minimo en esos reportes necesitamos enviar 6 float, que como minimo pueden ocupar 2 bytes cada uno. 6 float * 2 Bytes = 12 Bytes necesarios como mínimo.


Mi conclusión es o que en algo me estoy equivocando en los cálculos o sincronizar los clientes a tiempo real cada frame no es la solución.

De momento solo se me ocurre que en vez de sincronizar continuamente la posición/orientación etc, solo se sincronicen eventos entre los clientes, pero eso implica que las físicas esten en todos los clientes y sean deterministas, para que no se ejecuten diferente en ningún cliente.

Project Caelum: GUI y NET

GUI

Bueno, hace mucho que no cuento nada por aquí. La verdad es que no hay mucho que decir, he añadido el interfaz de usuario del menú principal. Ahí dejo un screenshot.


NET

También he tocado un poco el tema de red y los tipos de conexión necesarios, que se ejecutará en el servidor y el cliente etc. pero aún estoy en pruebas.
De momento estoy con la parte "fácil": hacer el chat. La interfaz ya está hecha y la parte de red casi terminada también, hice un test con un chat de consola y funcionaba perfecto, ahora solo añadirlo al proyecto.

La parte importante la que lleva el juego, sigo en dudas ya que las físicas del juego en red me plantean muchos interrogantes.

Problema: si las físicas deben ejecutarse en cada cliente y sincronizarse por el servidor o solo ejecutarse en el servidor. En el primer caso las físicas deben ser deterministas, es decir, los factores aleatorios no pueden alterar la ejecución. 


Solución ideal: Creo que la opción ideal consiste en ejecutar principalmente las físicas en el servidor y las físicas de cada personaje en el cliente de modo que la conexión no impida a un cliente su movimiento fluido. Sin embargo intentar ejecutar las físicas "por cachos" me parece un locura ahora mismo.


Solución escogida: Las físicas se ejecutarán en el servidor y los clientes se sincronizaran con el servidor central.

Inspiración - Malicious PS3

Simplemente he visto este video y me ha parecido increible el gameplay y el acabado que le dan, pero sobre todo el movimiento del personaje principal es alucinante.

Personalmente no lo he probado aunque no será por falta de ganas, aún así supongo que lo unico que no será muy innovador es el sistema de combos, que parece bastante similar a los actuales (resumiendo, estilo DMC)

Eso sí, los diseños me parece una absoluta pasada, y lo dicho, la libertad de movimiento también.
^^

Dominio Cerrado!! ¿¿Por Copyright??

Este es el mail que me ha llegado esta noche alegando que la web tiene contenido con Copyright, sin explicar cual es dicho contenido y procediendo a deshabilitarme el dominio.


Cabe destacar que la web está alojada en un servidor de blogspot, y no tk, asi que en primer lugar no entiendo que contenido ilegal puede haber en el dominio .tk y en segundo lugar aunque revisasen mi blog, trata solo de mis proyectos personales y no hay ningun tipo de copyright infringido... asi que, puesto que no me han dado mayor explicación, no entiendo el motivo.


PD: Adjunto el mail que me ha notificado el aviso.
PD2: He reactivado el dominio a la espera de una segunda y última revisión, tal como avisan en el mail.
_______________________________________________________


Dear Dot TK domain registrant,

The Dot TK Abuse and Copyright Infringement department has
visited your website today.

Unfortunately we have to say that today we cancelled your domain NOXWINGS.TK.
No-one can re-register this domain again at this stage. This may change
in the future.

The reason for the cancellation is that the website address
you used for your Dot TK domain name was not accessible or
did not follow the guidelines set in our terms and conditions.



If you want to have us re-verify the content you can press this link.

------------------------------------------------------------

If you are in doubt, please review our terms and conditions, which can be found at: http://www.dot.tk/en/doc_tcfree_v350.pdf

We thank you for using Dot TK.

Dot TK Abuse / Copyright Infringement team

Sistema de terreno (viejo vs nuevo)

Empiezo a pensar si de verdad merece la pena utilizar el sistema de terreno actual para crear los mapas ya que usa un metodo "antiguo" que no provee de capacidad para generar las sombras del terreno sobre si mismo (solo a traves de shaders).

En resumen:
  • Con el sistema antiguo...
    • Tendría un terreno paginado (es decir de unas dimensiones enormes, sin mayor coste)  y vegetación animada etc.
    • El mapa no genera sombras sobre sí mismo (p.e. las montañas no generarán sombras) pero si puedo conseguir fácilmente que el terreno en general se oscurezca/aclare a la luz de dia/noche y que reciba las sombras de otros objetos.
    • El rendimiento es mas rápido aún con shaders.
  • Adoptando el nuevo sistema...
    • Tendria un terreno con paginación (mediante otro sistema) y reacción a sus propias sombras  aunque tardan unos segundos en generarse
    • Me evitaria tener que programar yo los shaders pero con un sistema de terreno mucho mas complicado de implementar.
    • No tendría vegetación y para obtenerla tendría que cambiar el código al nuevo sistema.
    • El rendimiento es bastante lento.
De momento estoy usando el antiguo sistema de terreno utilizando un shader para utilizar un nuevo sistema de texturas (alpha splatting) y para proveer al terreno de iluminación básica.

Trasteando con Ogre: sistema de sombras

Hace tiempo estube haciendo pruebas con este sistema previamente, ya que la técnica utilizada para dibujar las sombras era demasiado costosa para el procesador cuando tenia que dibujar muchas formas o formas más complejas, ahora he encontado una buena configuración bastante optimizada y con buenos resultados visuales.

Con esta primera toma de contacto decidí comenzar a usar una técnica de sombreado que utiliza una textura como buffer para las sombras, con la cual comenzó el primer problema ya que solo generaba sombras a distancias cercanas a la cámara, con lo cual descubrí también que variando el tipo de iluminación de modulativa a aditiva podía conseguir que las sombras no desapareciesen a alejarte demasiado (excepto usando luz direccional o usando luz que abarca zonas muy amplias, aquí el buffer actuará dibujando las sombras mas cercanas unicamente)

Hasta aquí es donde había llegado, pero realmente la solución no me convencía, ya que la calidad de las sombras no era muy buena. Al final trasteando ayer con las demos de Ogre se puede observar que con la tecnica de sombreado por textura podemos elegir los parámetros tipo de proyección y material.

Modificando el tipo de proyección por defecto (uniforme) a "LiSPSM" o "plane optimal" la proyección de la sombra deja de verse pixelada y adquiere una calidad mucho mayor. En cuanto al tipo de material usado, utilizando un "Depth shadowmap" se consigue que los materiales de los objetos reciban sombras creadas por otros (aunque aún no estoy seguro de que esto sea necesario para que los objetos reciban sombras, puede que haya otras formas)



El DepthShadowMap de la estatua de la demo, la verdad que queda un poco mal, pero bien hecho le da mucho realismo al modelo 3D, básicamente lo que aqui cambia es la definición de la sombra. A la izquierda la sombra esta muy pixelada, y a la derecha la sombra es mucho mas definida, con apenas diferencia de fps.

Ps move para pc!! Ánimo

Todos conocemos el famoso mando de Nintendo Wii Remote que dió un sopló de aire fresco al mundo de los videojuegos con este nuevo controlador. Lo que no todo el mundo sabe es que las aplicaciones de este mando se ampliaban también al PC pudiendo usarse para diversos propósitos tales como para crear una pantalla multitáctil [1] o para utilizarse con algún juego del ordenador como podía ser el crysis (en un parche no oficial) [2].


Al igual que ocurrió con este mando, era de esperar que con la salida al mercado del nuevo mando presentado por sony, apareciera algún proyecto con la intención de dar soporte al mando en el PC, ese proyecto es MoveOnPC [3]. Iré siguiendo el proyecto para ver los progresos que consiguen ya que sería realmente planteable añadirlo a mi proyecto (de hecho es lo que desde un principio me hubiera gustado) así que espero les salga bien ^^.

Fuentes:
[1]
http://www.youtube.com/watch?v=5s5EvhHy7eQ
[2]
http://news.softpedia.com/news/Play-Crysis-Using-the-Wii-Remote-and-Nunchuk-80709.shtml
[3]
http://code.google.com/p/moveonpc/