.comment-link {margin-left:.6em;}

PROYECTO UTOPIA

jueves, septiembre 29, 2005

Libreria Cal3d

En nuestro proyecto, decidimos usar la librería Cal3D para la carga y control de animaciones de los personajes de nuestro videojuego. Veamos brevemente que nos ofrece.

Las características mas importantes de esta librería las podemos resumir en dos:

- Permite asociar diferentes animaciones a una malla.

- Tiene diversos exportadores de ficheros para los programas de modelado mas importantes como Maya o 3DMax. El numero de exportadores se va ampliando para incluir otros de uso generalizado como el Blender.

Cal3D ha establecido una serie de ficheros que forman la estructura básica de todo personaje a animar. Así, cada modelo esta compuesto por los ficheros siguientes:

- Skeleton. El esqueleto de la figura. La base jerárquica de la animación.

- Malla del modelo.

- Ficheros de animaciones. Cada uno contiene un ciclo completo de animación.

- Materiales. Se pueden tener diversos ficheros de materiales para la iluminación del modelo y sus texturas.

Estos ficheros se forman a partir de un modelo y animación realizado con nuestro programa de modelado favorito, para después, exportar cada uno de los ficheros necesarios.

Este tipo de formato ahorra bastante tiempo a los modeladores, ya que permite usar la misma malla y su esqueleto para las diferentes animaciones que se vayan a usar en el juego. Y en programación el trabajo ahorrado es descomunal ya que con unas pocas funciones es muy sencillo usar las diferentes animaciones, realizando transiciones suaves entre cada una de ellas.

Hablemos de las animaciones. Cal3D define dos tipos de animación: Ciclos y Acciones.

Los ciclos son animaciones, que como bien indica el nombre, repetimos en un bucle. Un ejemplo de animación de este tipo puede ser la de andar de un personaje.

Las acciones, son animaciones que ejecutamos en un instante dado. Por ejemplo, nuestro personaje va andando y en un momento dado, da un salto.

Hay que resaltar que cualquier animación puede ser tratada como ciclo o como acción, diferenciándose solamente por el tipo de función usada para procesar la animación.

Para tratar una animación como ciclo usaremos dos funciones:

BlendCycle() y clearCycle().

BlendCycle() ajusta el peso de una animación en una cantidad de tiempo determinada. La función tiene tres argumentos:

- Identificador de la animación.

- Peso de la animación.

- Tiempo de transición.

Estos valores se usan para asignar una transición con suavidad entre dos ciclos (animaciones) diferentes.

Para las acciones usaremos la función executeAction(). Tiene tres parámetros:

- identificador de la animación.

- Tiempo de transición inicial.

- Tiempo de transición final.

Las acciones se ejecutan automáticamente.

No debemos olvidar el control del tiempo. Para que la animación se presente con suavidad, el control del tiempo se ha de realizar en un proceso cíclico. Esto envuelve evaluar el tiempo en cada momento y los valores de transición para la animación que esta activa en cada momento. Esto se realiza mediante la función update(). Solo acepta un argumento que son los segundos transcurridos desde la ultima llamada a la función.

Veamos un pequeño ejemplo de código:

void CvisorModelosUtopiaView::actualizar(int idAnimacionUso)

{

float elapsedSeconds;

elapsedSeconds = (float)(GetTickCount() - m_lastTick) / 1000.0f;

if(!ejecutaAccion)

{

m_calModel->getMixer()->blendCycle(idAnimacionUso, 1.0f, 0.0f);

}

else
// Se ejecuta como accion la animación elegida.

{

m_calModel->getMixer()->executeAction(idAnimacionUso, 1.0f, 1.0f);

ejecutaAccion=false;

idAnimacion=idAnimacionCiclo;

}

m_calModel->update(elapsedSeconds);

m_lastTick = GetTickCount();

}

En este ejemplo, la función actualizar() recibe el identificador de la animación a procesar. Si el valor de la variable ejecutaAccion es verdadero se ejecutará la animación como una acción. Si es falso se ejecutará como un ciclo.

En breve seguiremos comentando mas posibilidades de esta librería.

Las dificultades de ver una caja rebotando

Una de las últimas grandes incorporaciones al mundo de los videojuegos en 3d es la física realística. Nadie en su sano juicio comenzaría a día de hoy un motor de físicas desde cero si quiere ver un producto acabado antes de tres o cuatro años, es realmente algo complicado. A día de hoy hay dos grandes pesos pesados Havok y ODE. Havok es un producto comercial de gran calidad, y creo que puedo decir sin caer en la exageración que es el rey, el uso en productos como Half Life 2 o Painkiller así lo demuestra. ODE, en cambio, es lo que se llama la alternativa, un producto OpenSource de calidad consolidada y usado en gran variedad de productos comerciales. Puede que Havok sea de una calidad superior pero no os podéis ni imaginar la gran ayuda que supone el poder disponer del código fuente, desde resolucion de problemas via debugger (puedo saber exactamente en que línia del motor peta el programa y así averiguar en que estoy fallando) a averiguar en que forma trabaja para asegurarme que lo estoy exprimiendo al máximo.

miércoles, septiembre 21, 2005

[BSP/PVS] Capitulo 1. Vectores

Imagino que los que estáis leyendo esto ya conoceréis bastante bien como funcionan los vectores. Lo que realmente me interesa es que tengáis claro al 100% el Dot product y el Cross product que serán una de nuestras herramientas básicas a la hora de construir el árbol BSP. No me pondré a explicar las otras operaciones. Los que estén interesados en una explicación mas detallada de los vectores pueden visitar la página web Vector Math for 3D Computer Graphics.


Dot product

El Dot product entre dos vectores u y v es:

u · v = |u| |v| cos θ

O dicho de otra forma:

cos θ = u.x * v.x + u.y * v.y + u.z * v.z estando u y v normalizados.

Donde |u| y |v| se refiere a los vectores normalizados (su longuitud es 1) y θ a el ángulo entre los vectores u y v. Si tenemos los dos vectores normalizados podemos extraer el ángulo más fácilmente, es por esta razón que normalmente en los motores gráficos siempre trabajan de esta forma.

Nos será enormemente útil sobretodo en los cálculos con planos.

Cross product

El cross product o producto cruzado es un vector w perpendicular a los otros dos vectores u y v (u x v):

w.x = u.y * v.z - u.z * v.y
w.y = u.z * v.x - u.x * v.z
w.z = u.x * v.y - u.y * v.x

El nuevo vector forma un ángulo recto (de 90º) con los vectores u y v. Seguramente habreis oido hablar sobre la regla de los dedos; si formais un angulo recto con el dedo gordo (el vector u) y el indice (el vector v) formando una L y estirais el corazón hacia adelante (el vector w) tendreis una idea de como funciona esta fórmula.

Una de sus utilidades es la de calcular la normal de un polígono. Imaginad que tenéis un triangulo con tres vértices P1, P2 y P3. A partir de los vértices del triangulo podemos obtener dos vectores uno que va desde P2 a P1 y otro desde P3 a P1:

u = P2 - P1
v = P3 - P1

Ahora con los vectores u y v nos es fácil encontrar la normal haciendo:

normal = u x v




Proximamente...

Con estas dos formulas nos será mucho mas fácil comprender como extraer los planos de los polígonos y en otro futuro capítulo como cortar polígonos.

lunes, septiembre 19, 2005

Esas tediosas esperas

Una de las cosas que vamos a intentar evitar son esas esperas aburridas a la hora de cargar los niveles. Considero que los ordenadores de hoy tienen suficientes recursos como para cargar los recursos de forma instantanea o, mejor dicho, hacer creer al usuario que la carga es instantanea.

Nuestro modulo de recursos posee un hilo de ejecucion aparte con el que podremos hacer, por poner un ejemplo, que al acercarse el jugador a un area del mapa se vayan cargando los modelos de nuevos enemigos consiguiendo evitar que aparezca una horrible pantalla con el texto de Loading...

jueves, septiembre 15, 2005

Grupos de desarrolladores de videojuegos

Si siempre habeis querido formar parte de un grupo de gente con clara intencion de desarrollar algun que otro videojuego esta es vuestra pagina. Aun es relativamente nueva y hay poca gente apuntada pero todo es cuestion de tiempo.

miércoles, septiembre 14, 2005

Tutorial sobre arboles BSP/PVS

Voy a comenzar una serie de posts a modo de introduccion sobre el complejo tema de los arboles BSP/PVS. Voy a evitar a toda costa introducir codigo (que no pseudocodigo) para que vosotros tambien tengais que trabajar un poco. Ire leyendo los comentarios que me dejeis para intentar resolveros cualquier duda.

El temario sera mas o menos este (por orden de aparicion y sujeto a cambios):
  1. [BSP/PVS] Introduccion
  2. [Mates] Vectores
  3. [Mates] Planos
  4. [Mates] Poligonos
  5. [BSP/PVS] Fabricacion de un BSP simple
  6. [BSP/PVS] BSP Leafy
  7. [Portales] Creacion de portales a partir de un arbol BSP
  8. [BSP/PVS] Y la traca final... PVS
A pesar de lo que hayais leido por ahi no es ni mucho menos tan complejo como os quieren hacer creer. Con que os concentreis un poco en seguir la mecanica basica lo entendereis enseguida.

Quién espera a quién?

Esa es la pregunta. ¿Gráficos espera a programación? ¿O es al revés?.
Podríamos decir que depende del punto de vista.

Si la opinión nos la da un grafista-modelador-animador, seguro que nos dirá que él prefiere esperar a los programadores. El trabajo de modelar la figura, su animación, las texturas, se deberán realizar según se vaya a usar el modelo. No es lo mismo usar un modelo en una animación que usar un modelo que se incluirá en el motor del juego. A nadie le gusta trabajar sobre un modelo o una animación y que luego le digan que tiene que reducir los polígonos a la mitad o que la animación tiene demasiados frames para el motor del juego.

El programador nos dirá que necesita muchos modelos para trabajar sobre el motor. Muchos ejemplos. Muchas pruebas. Y es verdad. El motor del juego podría ir muy bien moviendo determinado personaje pero con otros, se descubrirá que la animación no se presenta correctamente o que las texturas no se aplican bien.

De todo esto se deduce que es necesario buscar un punto de equilibrio. Y la experiencia nos enseña que en todos los juegos se desechan una gran cantidad de bocetos, modelos, imágenes y texturas.
Como también se busca un limite a la programación del motor y se desechan muchas características.

Puede parecer una tontería pero seguro que muchos grafistas y muchos programadores recordarán horas de trabajo perdido por no tener esto en cuenta.

¿Cómo solucionarlo?

Pues aceptando que parte de nuestro trabajo no se podrá usar en el juego y manteniendo una buena comunicación entre las dos partes para que ese trabajo perdido sea el mínimo

Seguiremos contando...

Indie

Indie es un termino americano muy usado en peliculas independientes. Denota que detras de una produccion no hay un gran empresa si no un grupo de gente motivada con ganas de hacer algo con la maxima calidad posible. Tambien es aplicable a videojuegos y, creedme, hay una gran variedad de juegos indie. Lo podeis comprobar vosotros mismos.

martes, septiembre 13, 2005

Juegos de tablero

Me gusta programar en C pero algunos van demasiado lejos.