Técnicas de Keyframe animation

[JL10]

¿Qué nos puede aportar el "Keyframe animation" a los que queremos crear aplicaciones 3D en tiempo real?.

(Quizá no sepa muy bien en qué consiste esta técnica pero hay constantes referencias a ella en bibliografía afin, que me dá la impresión de que hay que invertir un tiempo en ella)

[senior wapo]

Pues vendría bien que contaras a qué te refieres porque "Keyframe Animation" tiene múltiples sentidos según el contexto.

-En el campo de los motores en tiempo real se suele denominar así a tener cada frame del modelo precalculado en una nueva malla, ahorrándote el tener que interpolar pero disparando el consumo de memoria. Se usaba en motores pensados para ordenadores antiguos, menos potentes. No es un mal método si tienes que mover muchos modelos 3D con pocos poligonos cada uno (en fixed pipeline).

-En el campo de la animación más en general, es un término que se utiliza para marcar el estado del mundo en un momento dado. Para un motor en tiempo real, esto sería util para cutscenes y animaciones complejas del entorno que requieran una cualidad cinemática (no visualmente sino de comportamiento). En los juegos, durante la partida se suelen usar scripts mas que este procedimiento. En las intros de nivel si se pueden usar más, para cutscenes.

[JL10]

(...me estaba temiendo que me iba a meter en un muevo mundo donde ignoro casi todo.... :shock: )

Me refiero a la manera de gestionar la información de estado de cada objeto 3D de nuestro escenario. Parece que recomiendan una estructura de datos, o clase, de los parámetros que identifican la posición y actitud de nuestro elementos geométricos, ya sean estáticos o dinámicos, incluso de nuestra cámara, similar a la que usan los sistema de Keyframe, para una eficiente generación del escenario 3D.

Quería saber si es correcta esta recomendación o hay otra manera más usual o conveniente para este fin. Y si es así, ¿cómo es esa estructura o clase para cada objeto gráfico?.

[senior wapo]

Te refieres a lo que describía en la segunda descripción entonces.

Te cuento. Técnicamente siempre que animas de una forma no procedural usas una forma de keyframing, puesto que estás describiendo estados (keyframe = captura del estado en un instante determinado). Lo que cambia es como se guarda dicho estado (posición de todos los vértices, o posición+rotación de bones, o posición+rotación del objeto).

Su uso se basa en interpolar estados. Esa palabreja quiere decir calcular el estado intermedio a partir de 2 o más estados conocidos. El más típico lo calcula basándose en el tiempo y en el estado anterior y el estado destino.

Se usa continuamente para diferentes aplicaciones:

1. Animación de escenarios. Aquí se suele guardar en los keyframes de escena datos globales de cada objeto activo como la orientación, posición, velocidad, frame de animación interno (ej: 5º paso de la secuencia de correr) etc... Incluye además comandos para activar efectos de postproducción y de cambios de cámara y luces. Eventos. Técnicamente también podrías modificar aquí la geometría y materiales de los objetos, pero es un poco guarro. Ejerce básicamente la tarea de director de cine, indicando quien hace que y cuando.

2. Animación de mallas. Aquí se guarda en los keyframes datos que afectan a la forma y apariencia del modelo, independientemente de su orientación, posición, etc.. Ejemplo más típico secuencias de nadar, correr, levantar un brazo. Tienes varias opciones: guardar directamente las versiones modificadas de las mallas en cada estado o guardar los datos que describen las operaciones que modifican la malla de un estado al siguiente (bones, IK, etc...) Son secuencias predefinidas que se disparan a petición externa, por ejemplo, con lo descrito en el caso 1.

Como preguntas particularmente por el escenario en sí, pues te digo que en juegos se suelen usar scripts más que keyframes, salvo el caso particular de las secuencias cinemáticas (la minipeli de principio de nivel si está hecha con el motor de juego). Pero claro, cada maestrillo tiene su librillo, habrá de todo.

Una estructura simple sería algo así:

Código [Seleccionar] Expand


 struct keyframe_parcial_objeto {
   int ID_objeto;    // A que objeto afecta esta porción del keyframe de escena
   float x,y,z;     // Posición
  float cabeceo, deriva, balanceo;   // Si almacenas como angulos euler
 }

struct keyframe {
float tiempo;   // instante descrito por este keyframes
int ID_primer_keyframe_parcial;
int cuantos;
int ID_objeto_camara;  // Que objeto hace de cámara en este frame
}

Y un array enorme con todos los elementos de la primera estructura.

Después de este ladrillazo dejo que otros te comenten los peros (lo de los ángulos euler levantará ampollas lo veo venir) y tienes google para buscar los palabros que te he sembrado por el post.

[JL10]

Creo que estamos llegando a donde realmente quería ir; llegar a la opinión de expertos sobre la expresión el estado de un objeto (posición, orientación, ¿velocidad?, otros atributos...).

Y ya que lo introduces....

(lo de los ángulos euler levantará ampollas lo veo venir)

para expresar la orientación en simulación; ¿Que es mejor, ángulos euler, cuaterniones, orientaciones sobre ejes locales, etc?.

Creo que por las referencia en las que me está introduciendo este foro, lo mejor es usar ejes locales con angulos euler. (No adolecen de efectos gimbal-lock y la secuencia de las ordenes de giro no hay que invertirlas como con ejes de referencia mundo, y además con un poco de matemáticas se resuelve las interpolaciones o transiciones de orientaciones sin usar slerp)

[AbelNightroad]

quaternions 4ever!  :P

[neophox]

para expresar la orientación en simulación; ¿Que es mejor, ángulos euler, cuaterniones, orientaciones sobre ejes locales, etc?.

He visto usar de todo. A mi me gustan los cuaterniones pq me parecen mas comodos, pero a nuestra matematica creo que no le convencen mucho :D.

[JL10]

¡Mojaros un poquito... AbelNightroad y neophox!.

Sed algo más concretos..., por qué los cuaterniones?.

Los ejes relativos con euler son más intuitivos y requieren menos operaciones que el resto!. :o .   No tiene efectos raros y su secuencia de rotaciones es más natural que usar ejes absolutos de referencia.


De todos modos, podéis decir algo más sobre la estructura del estado de un "Actor" en ese escenario 3D?