Scene Graph Y Animationes

Haddd · 03 de Febrero de 2006, 12:40:05 PM

¿Podeis darme urls para saber las diferentes formas de implementar un scene graph con soporte para crear animaciones ?

Y también que comenteis un poco el tema, claro ;)

CoLSoN2 · 03 de Febrero de 2006, 12:49:25 PM

¿Te refieres a que un objeto animado sea un nodo del grafo y cada bone de su esqueleto un subnodo? Ogre creo que hace algo así, héchale un vistazo.

zupervaca · 03 de Febrero de 2006, 03:29:18 PM

No he mirado mucho en link, pero pone como organizar la escena y habla sobre objetos animados dentro de ella.

http://www.gamedev.net/reference/articles/...article2028.asp

Haddd · 03 de Febrero de 2006, 03:42:14 PM

Yo me refiero más a como gestionar todo el tema de la animación por keys, asociado al nodo de una escena. Vamos, una especie del editor de timeline del Max, pero claro, asociado a un nodo, donde puedes cambiar su rotación, escala, posición....

zupervaca · 03 de Febrero de 2006, 04:16:44 PM

Las lineas de tiempo tipo max en juegos no se que resultados daran, ya que al tener llaves que solo cambian los valores necesarios se hace muy pesado, por ejemplo, si queremos ir directamente al tiempo 60 deberemos de calcular toda la animacion desde el tiempo 0, este es el motivo de por que los de idsoftware siempre crean animaciones de 0 a X siendo el tiempo siempre un frame con todos los vertices.
Actualmente estoy mirando el sistema de huesos del md5 y hacen el mismo sistema que han hecho siempre, ademas los listos de ellos han hecho que se vean animaciones muy fluidas sin interporlar posicion ni hacer necesario el slerp para el cuaternion.

BeRSeRKeR · 03 de Febrero de 2006, 06:21:05 PM

Cita de: zupervacaActualmente estoy mirando el sistema de huesos del md5 y hacen el mismo sistema que han hecho siempre, ademas los listos de ellos han hecho que se vean animaciones muy fluidas sin interporlar posicion ni hacer necesario el slerp para el cuaternion.

No sé muy bien a qué te refieres.

Si quieres decir que sólo utilizan los bones para, en tiempo de carga, crear un mesh por cada frame, entonces me temo que no. La transformación de los bones y los vértices se lleva a cabo en cada frame. Adicionalmente se realiza interpolación lineal entre claves de posición y slerp para las claves de rotación. También se realiza interpolación entre sets de animación para que las transiciones entre una animación y otra sean fluídas.

Piensa por ejemplo de que de lo contrario no podrían asignar diferentes sets de animación de diferentes sets de bones al mismo tiempo (a no ser que hagan todas las combinaciones posibles a la hora de generar todos los meshes, lo cual sería un consumo de memoria demasiado grande, me temo). Además, también aplican ragdolls a los bones, y eso no hay más remedio que calcularlo en tiempo real.

Saludos.

Ithaqua · 03 de Febrero de 2006, 06:33:20 PM

Cita de: zupervacaLas lineas de tiempo tipo max en juegos no se que resultados daran, ya que al tener llaves que solo cambian los valores necesarios se hace muy pesado, por ejemplo, si queremos ir directamente al tiempo 60 deberemos de calcular toda la animacion desde el tiempo 0

¿Y por que va a estar la curva en valores relativos en vez de en valores absolutos?
Otra cosa es que el parámetro en sí sea del tipo velocidad por ejemplo, en vez de posición, donde hay que integrar por pasos para obtener la posición final.
Pero las animaciones siempre las tendrás en valores absolutos de posición/escalado/rotación, con lo que no entiendo por qué ibas a tener que calcular todos los pasos intermedios.

zupervaca · 03 de Febrero de 2006, 07:10:42 PM

CitarSi quieres decir que sólo utilizan los bones para, en tiempo de carga, crear un mesh por cada frame, entonces me temo que no

No me refiero a eso (eso es una cochinada :lol:), digo que la animacion de los huesos va muy fluida y sin ningun tipo de interpolacion ves el esqueleto moverse muy bien, es decir, pones en una secuencia de animacion frame0, luego el frame1 y asi hasta el ultimo y veras como el esqueleto sin interpolarlo va suave.

Citar¿Y por que va a estar la curva en valores relativos en vez de en valores absolutos?

No tiene nada que ver con valores relativos o absolutos, el problema viene cuando en una pista de tiempo se le indica una llave de posicion en el tiempo 0 y luego una de rotacion en el tiempo 60, si vas al tiempo 60 y no has mirado la llave de posicion en el tiempo 0 fallara. La solucion para esto es memorizar el tiempo en que se actualizo por ultima vez la pista de tiempo y cuando se vuelva a actualizar procesar todas las llaves desde el tiempo que se habia memorizado hasta el actual.

senior wapo · 03 de Febrero de 2006, 08:37:11 PM

Cita de: zupervaca
Citar¿Y por que va a estar la curva en valores relativos en vez de en valores absolutos?
No tiene nada que ver con valores relativos o absolutos, el problema viene cuando en una pista de tiempo se le indica una llave de posicion en el tiempo 0 y luego una de rotacion en el tiempo 60, si vas al tiempo 60 y no has mirado la llave de posicion en el tiempo 0 fallara. La solucion para esto es memorizar el tiempo en que se actualizo por ultima vez la pista de tiempo y cuando se vuelva a actualizar procesar todas las llaves desde el tiempo que se habia memorizado hasta el actual.

¿ ein ?

Claro que tiene que ver, lo que tu describes son transformaciones "relativas", deltas, si lo prefieres, respecto al frame anterior. En cambio, términos absolutos, seria que el frame 60 no guarda solamente la orden "rotar x grados" sino la combinación de todos los pasos anteriores + la rotación. Lo que se viene haciendo con matrices 4x4 toda la vida, concatenar transformación, rotación etc... y guardar el resultado final.

Una cosa es que al editar, sea más cómodo hacerlo por separado (o no), y otra que el motor que uses para moverlo tenga que operar internamente de la misma forma.

Pero por favor, no nos pongamos a discutir lo que es "relativo" y lo que no :(

@Haddd: ¿ Que tal un interpolador de escena ? Para cada frame de escena guardado, almacenas las matrices de transformación de todos los nodos cuya matriz haya cambiado respecto al frame anterior. Almacenas también la creación y destrucción de nodos, y los cambios de material, claro. Cuando reproduces la animación de la escena, recorres los datos del frame actual y aplicas las modficaciones a los nodos correspondientes.

Es decir, un sistema externo. Que el grafo de escena simplemente provea mecanismos para consultar y aplicar cambios (o transmitir la orden a los nodos).

No se si buscabas algo asi o vas por otro lado...

zupervaca · 03 de Febrero de 2006, 10:47:37 PM

CitarUna cosa es que al editar, sea más cómodo hacerlo por separado (o no), y otra que el motor que uses para moverlo tenga que operar internamente de la misma forma.

El problema que veo es que solo ves una matriz de transformacion, pero es que en una pista de tiempo se pueden llegar a almacenar muchas mas cosas, luz de ambiente, texturado, etc. (y por lo que comenta haddd creo que quieren algo de esto).
Si almacenas todo en una superestructura y en cada paso de la pista de tiempo actualizas todos los datos de esa estructura puede llegar a pegar un bajon de fps bestiales, no creo que fuera recomendable, la potencia de una pista de tiempo es modificar solo los datos que sean necesarios.

Ithaqua · 04 de Febrero de 2006, 04:31:36 AM

Cita de: zupervacaNo tiene nada que ver con valores relativos o absolutos, el problema viene cuando en una pista de tiempo se le indica una llave de posicion en el tiempo 0 y luego una de rotacion en el tiempo 60, si vas al tiempo 60 y no has mirado la llave de posicion en el tiempo 0 fallara. La solucion para esto es memorizar el tiempo en que se actualizo por ultima vez la pista de tiempo y cuando se vuelva a actualizar procesar todas las llaves desde el tiempo que se habia memorizado hasta el actual.

Si las keys contienen valores absolutos no hay problema. Al evaluar un tiempo dado buscas las keys correspondientes (la inmediatamente inferior, e inmediatamente superior) para posición, rotación y escalado. Con eso interpolas y obtienes los resultados finales, pero para nada necesitas saber valores anteriores.

Ithaqua · 04 de Febrero de 2006, 04:33:17 AM

Cita de: senior wapo¿ ein ?

Claro que tiene que ver, lo que tu describes son transformaciones "relativas", deltas, si lo prefieres, respecto al frame anterior.

Pero para que vas a guardar transformaciones relativas si lo que puedes guardar son valores absolutos de toda la vida? la posición, el quaternion de rotación y los valores de escalado. Guardar valores relativos te complica muchísimo la vida cuando no es necesario.

senior wapo · 04 de Febrero de 2006, 02:23:16 PM

Precisamente eso digo yo, para que guardarlos (te estaba dando la razón :P). La réplica era para él, pero a estas alturas yo ya desisto de según que cosas y con quién, porque si discutir diferentes ideas es sano, retorcer la semántica para decir la última palabra acaba siendo cansino.

Haddd · 04 de Febrero de 2006, 02:54:03 PM

Tomo nota de lo que decís. Ya os iré contando lo que voy implementado...

Muchas gracias. (ole)

Ithaqua · 04 de Febrero de 2006, 03:33:50 PM

Cita de: senior wapoPrecisamente eso digo yo, para que guardarlos (te estaba dando la razón :P). La réplica era para él, pero a estas alturas yo ya desisto de según que cosas y con quién, porque si discutir diferentes ideas es sano, retorcer la semántica para decir la última palabra acaba siendo cansino.

Ah oki, no había entendido bien :)
Y de lo otro también me he dado cuenta ;)

Foros

Scene Graph Y Animationes