Por fin tenemos ya cosas visibles con los MD5 utilizando animación esquelética (por supuesto). :)
Video (188KB)
En este video se ha desactivado la iluminación para que se vea todo más claro pero hay que decir que al hacer el skinning se realiza la transformación tanto de las coordenadas del vértice como las normales y las tangentes.
El siguiente paso a dar será implementar la interpolación entre sets de animación y el soporte para varios canales de animación. Explico cada cosa porque tal vez a alguien le pueda resultar interesante.
El tema de la interpolación entre animaciones es por ejemplo realizar la transición entre la animación de andar a correr de forma suave, sin cambios bruscos.
El otro punto es uno de los más importantes y el que le ahorrará al animador tener que crear más de un animación. Consiste en tener varios canales de animación. Cada uno de estos canales tendrá asignado una lista de bones y a cada uno de estos canales se les podrá asignar una animación de forma independiente. Así, podríamos tener el canal "cabeza" y "torso" reproduciendo la animación "disparar" mientras que el canal "piernas" reproduce la animación "correr". Como es de imaginar esto nos permite realizar un montón de combinaciones sin necesidad de explotar al animador. :lol:
La otra cuestión que hay pendiende es realizar el skinning a través de un vertex shader. El problema es que los MD5 pueden llegar a soportar más de 4 pesos. Yo he llegado a ver hasta 8 pesos por vértice. La solución podría ser reducir su número a 4 como máximo pero me temo que esto causará una deformación incorrecta en el mesh. Todo dependerá de si por ejemplo los 8 pesos estaban repartidos por igual o la contribución de algunos de ellos era insignificante...
Y nada más, ya iré informando con los avances que vaya realizando sobre estos temas.
Saludos.
Mola, mola (ole)
A ver si para la version 2 del motor ya tengo una grafica decente y puedo hacer algun juegecillo con él. (genial)
Muy interesante y mu potente. (uoh)
Lo de los 4 bones es algo a lo qu emuchos estamos ya acostumbrados.
Así que tpoco es tanto problema. Unreal 2003 sólo permitçía inicializar physique con 3, y además en rigid (lo que no quiere decir qeu no pudieras poner pesos...una movida de terminología que se me escapa)
O sea, si es verdad que en zonas como caderas, entrepierna, hombros, alguna más, hacen inexcusablemente falta 3, y en algún caso 4, pero se puede vivir sin 5, o más.
Tal vez puedas..."redondear". pero claramente con un thresold no muy bestia. Por ejemplo, que redondee los pesos 0,0001 y cosas así, que eso no es el grafo que lo haya querido poner así, sino seguramente, un marrón en el proceso de rigging.
Lo normal que ponga el grafo son pesos como de 0.2, 0,8, 0,05 en ciertos casos...etc..alguna vez uno muy bajo, pero algo de más de 3 ceros empieza a oler a gato encerrado ;)
Lo más efectivo de todo...o sea, lo que menos sorpresitas y quejas del grafo va a provocar es... un maxscript que permita limitar sin exportar esto a 4 bones (y si más adelante surge la necesidad, tal vez puedas inlcuir otra cosa que evite petes en el engine) , o sea, que asesine los pesos fantasma, que se dan mucho sin la voluntad del grafo. Esto hará que si un bone/biped bone estaba puteando, y al redondearlo, el grafo podrá darse cuen de que al eliminar aquél, como resulktado otro tira demasiado, dando un marrón de deformación excesiva: entonces lo corregirá a mano. Así se asegurará de que lo que él saque, será muy muy parecido o igual a lo que se veanm en el engine.
Si eso es muy complicado...bueno, pues simplemente haz lo del redondeo al importar. Es más, no sé si igual ya hay un script para esto en scriptspot.com.
pero que muchos engines no pillan más de 4 bones, en muchos casos tb por ir con no se qué limitaciones de opengl, dx o las tarjetas.
De hecho, yo tiendo a usar el menor número posible, pq hace bastante tiempo se me dijo que lo limitara, pq le suma mucho calculo a la tarjeta.
Tiene genial pinta el tema.
mis 2 trillones de céntimos de euro.
" o sea, que asesine los pesos fantasma"
y tal vez reparta ese 5º peso(o la suma de los demás bones que se hayan ido de madre con un peso mínimo, o simplemente menor que los 4 primeros (para los que no sepan que hay que limitarse a 4)) entre los 4 primero que tengan mayor influencia.
No sé si me explico. Y tpoco sé si lo que te sugiero es una brutalidad de trabajo, o un remedio interesante, pq no soy programador. Yo sólo digo lo que se me ocurre así de golpe ;)
Evidentemente, 8 bones, para el grafo, es mejor, en el sentido de que 0 limites siempre es mejor, pero...si el costo va a ser una sacudida en el rendimiento, y mucha incompatiblidad con tarjetas, equipos etc...no merece la pena, sobre todo pq habitualmente, es cuestión de 3 o 4 bones...cierto es que con alguno más puedes hacer sutilezas muy curiosas. Hmmm...tal vez ..sí, en animación facial quizás sea interesante, pero por ejemplo, recuerdo haber hecho algo de eso con 3 o 4 bones y quedaba bien, pq al hacerlos hijos de la cabeza, no hacía falta que el bone de cabeza tb influyera, lo repartía entre los de las expresiones. Y ya digo, solían ser dos, 3, o como mucho, 4. Ahora, que si se pueden poner 8, de escándalol!
Gracias por los consejos donald.
Lo de reducir los pesos a 4 es precisamente para poder realizar el skinning por hardware (es una limitación que existe). En caso de hacer esa reducción, debería encontrarse los 4 pesos más influyentes y repartir proporcionalmente el resto de los pesos entre esos 4. Pero me temo que no va a ser posible. Por ejemplo aquí pongo la lista de pesos para un vértice:
0.1569510102
0.1897923201
0.1000000015
0.2393546104
0.1569510102
0.1569510102
es decir que todos influyen de una manera más o menos proporcional por lo que reducir en ese caso a 4 pesos casi seguro que afectaría a la deformación de la malla. De todas formas todo sería pedirle al grafista que se limite a 4 pesos, pero de momento lo hacemos por software por lo que no hay limitación pero aún así, lo ideal sería hacerlo por hardware ya que nos evitaría tener que bloquear el vertex buffer del mesh en cada frame para transformar los vértices, con la consiguiente ganancia en rendimiento.
Saludos.
hazlo por hardware, tengo entendido que por software es extremadamente lento.
Y piensa en varios personajes a la vez, y en alta...buf...nada, en serio, por hardware. Lo de los 4 bones, sencillamente es como van muchos engines y queda perfecto, si el grafo sabe.
"De todas formas todo sería pedirle al grafista que se limite a 4 pesos"
Exacto. Yo contaba con eso: el grafista ya de por sí sabe que se tiene que limitar a 4, y creeme que no es complicado, sabes perfectamente que tu hombro está teniendo influencia en determinado vértice de la clavícula, el hueso del hombro, parte de la espina dorsal o el bone que uses en ese área... siendo una de las partes más complicadas, ya ves, 3... cuando te acercas en la zona de la clavícula, al cuello,....vale, influye la clavícula, en algun caso algo el cuello, y algo el último hueso "spine"...
en la enterpierna, igual las dos piernas y pelvis ...algun vértice en las caderas , o en los glúteos pueden necesitar 4...pero que es cuestión de saber hacerlo, y eso, el grafista , sabrá.
Pero es que...te decía lo de "matar" las referencias con pesos muy bajos pq...a menudo, los sistemas de pesado de dtos paquetes, pueden como error,o por un intento automático de normalizar...generar un ínfimo peso en otro bone...o quedarse perdido una influencia del root...pq no se asigne toda la fuerza (hasta 1.0) , o pq estos programas, tras mucho guarrear, a veces se hacen un lío un poco. Por eso siempre viene bien cierto checking, en el exportador, o como un maxscript "de limpiado", de manera que no haya sorpresas, y por ejemplo tu plugin muestre el modelo con un pesado dto, pq elimine uno bueno y deje uno que influenciaba poco , y por error...
este tipo de marrones nunca tienen un peso grande...ya digo, unas milésimas, o cosas así....tb puede haber un despiste del grafista pero...que no se despiste...XD
Vaya, a golpe de pesos normalizados (yo trabajo con lasso a nivel de vértice, como decía no uso envelopes...uso mirro de pesos siempre que puedo, para reducir el tiempo de esta tarea ) , y con la cantidad de "trial y error" que se hace, es dificil que simplemente le asigne 20% de un bone, y 60 del otro....así los pesos que se escapen, serán de eso, de 0,0001, etc...a Blender le pasaba algo parecido en el exporter x, al menos en fase de betatesting-privado.
Exportaba el x, pero...aunque los pesos iban bien en blender, algunos se quedaban sin peso, por un problema de precisión en decimales, o algo. pasaba con el pintado de pesos, tb existente en Max, con el skin modifier. Aunque yo prefiero mi lazo.
Con cierto exporter gratuito de x de Truespace, pasaba mucho.
Vaya, que marrones de estos, son frecuentes, tb en max....y pueden , y vuelven loco a más de uno.
Así que planteate la posibilidad de eliminar un peso si es de algo así como 0,0001(a mano, al grafista se le escaparán muchos,aunque se ponga a limpiarlo...y el que peses sólo con envelopes/pintado, ni te cuen...) o algo así pq eso no se nota, realmente....no afecta , casi. Será un error...cierto es que a veces se persigue un efecto con un valor muy bajo: en las caderas, en los glúteos, para determinadas torsiones en la cintura, yo a veces uso un peso de 0.1....pero a lo menos que creo haber llegado es a 0.01...
lo que sea ya 0.001 , o 0.0001...sobre todo, éste último...suele ser marroncillo...
yo creo que...bueno...una utilidad ideal, sería la que permitiera pasarselo a todos los bones, menos a los que el grafo descartara,(uno suele saber en que zonas hay detalles muy sutiles a conservar, pero ya digo, 0.01...tal vez sea lo mínimo habitual...) y luego a exportar. La verdad, es que si eliminara por error los pesos de 0.1, 0.2, 0.04... sería una putada. Yo los uso muy a menudo
pero esto es una utilidad genérica, que es posible que ya un usuarioya lo haya hecho en modo de maxscript, así que no he dicho nada, que añadiendo trabajo extra soy único...XD
No es por meterme con nadie, pero...
"0.1569510102
0.1897923201
0.1000000015
0.2393546104
0.1569510102
0.1569510102"
creo que ahí hay demasiados pesos...
la mayor parte de las torsiones, y articualciones, suelen requerir 2 , o 3....
por ejemplo: el codo-->2. Rodilla--->2 (alguna vez 3. Sobre todo si no lo he modelado inteligentemente, jeje(pero esto, a la altura del muslo, que diga) ) ...tobillo-->2 ...
El hombro, no. El hombro es una pasada, pero más de cuatro me parecería un disparate, incluso ahí.
Y...por lo que llevo visto, parece que el menor numero de bones por vértice, es menos calculo para la máquina.
No es que no sea más chulo y potente n bones, pero...digo que se puede pesar así, perfectamente, y de hecho, se hace.
Eso lo he sacado de uno de los modelos de Doom3 así que habría que pedirles exlicaciones a ellos :D.
De todas formas para ellos no parece ser un problema porque me da que también realizan el skinning por software. Habrá que hacer pruebas y ver el rendimiento con unas cuantas decenas de modelos en escena y ver qué tal va. Tal vez no sea tanto problema aunque evidentemente siempre iría mejor si se realizara en la GPU.
Saludos.
me creerías si te dijera que me lo temía?
de hecho, lo pensé justo al darle al botón de responder..pq era el Imp que usabais...supongo.
sin duda que estarán bien puestos...tb uno se hace viejo con las viejas limitaciones... igual ya da lo mismo.Si permites más bones, más facil para los grafistas.
La verdad, no sé. Igual hay algoe scrito por gamedev, flipcode o sitios así. No sé lo que estará a la orden del día, en esto.
Bueno, la cosa va avanzando. Ya tengo los resultados de las primeras pruebas de los canales de animación.
Descargar video (630 KB)
A la izquierda podéis ver el imp sólo con la animación "idle", en el centro sólo con la animación "walk" y a la derecha el resultado de aplicar la animación "idle" al canal "torso" y la animación "walk" al canal "piernas".
Ahora tengo que pulir el código y hacerlo más funcional y finalmente implementar la interpolación entre animaciones. ¡A ver si para el final de la semana puedo tenerlo todo hecho!.
Saludos.
Viendo el video, un amigo me ha hecho ver que hay una falta de sincronización entre el mesh y el esqueleto (las líneas amarillas). Sólo aclarar que el problema está al capturar el video porque en lo que es la aplicación en tiempo real no ocurre. Sólo aclarar eso, por si alguien se estaba preguntando si era un error en la animación.
Saludos.
juer...que potencia.
esto es un "poquito" mejor que los quake3 tags... ;) XD
si, eso me ha pasado haciendo screecap con el camstudio, alguna vez que otra, a mi tb...
Bueno pues vuelvo a escribir el mensaje que había escrito esta mañana porque también ha desaparecido por arte de magia. :lol:
Los canales de animación y la mezcla entre sets de animación ya casi están terminados a falta de solucionar unos problemillas. He creado un pequeño video donde podéis ver el resultado.
Descargar videoComo podéis ver, el modelo pasa por las animaciones idle->walk->run->walk->idle. Entre cada uno de esos sets de animación se han especificado 6 frames de interpolación, es decir que teniendo en cuenta que las animaciones van a 24fps, la transición dura 0.25 sg.
Cuando solucione los problemas que mencionaba tendré que implementar los modificadores de transformación que servirán por ejemplo para cosas tan básicas como mover el modelo y otras no tan básicas como implementar IK. De esta forma se podrá hacer que si se le dispara a un modelo en la mano, ésta transmitirá el impulso producido por el disparo a toda la cadena de bones. Esto tardará en llegar porque entre otras cosas aún no hemos desarrollado el motor de física. :)
También se implementará lo que en Doom3 se conoce como frame commands. Son ni más ni menos que eventos que se disparan cuando se alcanza un frame determinado. Por ejemplo imaginad que el frame 23 de una de las animaciones coincide con que el personaje pisa el suelo. En ese caso se aplicará un evento a dicho frame que reproducirá el sonido de un paso. Muy útil. :)
Stay tuned!.
(genial) (genial) (genial)
(ole)
Joer, se ve de fábula (ole)
Lo de mezclar canales de bones para conseguir una acción nueva me ha encantado. Es algo que siempre he querido tener en el NLA de blender, un mezclador por huesos.
En las transiciones a mi me ha dado la sensación de que cuando el personaje iba cogiendo velocidad los 6 frames de interpolación eran suficientes, una interpolación rápida que queda muy bien. Sin embargo al pasar del movimiento a parar del todo me han parecido pocos frames, el personaje para precipitadamente. Igual podríais aumentar el número de frames solo en el caso de pasar de movimiento a parado. Ponerle 8 ó 10 frames (sería cuestión de probar) porque así parecería que el personaje empieza a parar hasta que se queda quieto.
Seguid así que da gusto "veros"
Saludos.
Cita de: "8tintin"Sin embargo al pasar del movimiento a parar del todo me han parecido pocos frames, el personaje para precipitadamente. Igual podríais aumentar el número de frames solo en el caso de pasar de movimiento a parado. Ponerle 8 ó 10 frames (sería cuestión de probar) porque así parecería que el personaje empieza a parar hasta que se queda quieto.
Sí, donde más se nota es en el paso de walk a idle pero bueno, como es totalmente configurable, se puede especificar el número de frames que dure la transición en cualquier momento. Además, el que la transición quede mejor o peor también depende del frame donde comience la mezcla. Si por ejemplo en la animación actual el modelo tiene la pierna atrás y la nueva animacón la tiene adelantada, el transición será más brusca pero evidentemente aumentando el número de frames de transición se arreglaría.
Cita de: "8tintin"Seguid así que da gusto "veros"
¡Intentaremos mantener el ritmo!. :D
Gracias.
English text below...
--------------------------
Hola.
Resulta que estoy revisando la animación esquelética que tenía implementada hace ya tiempo (utilizando el formato MD5 de Doom3) y que quiero acabar de aquí a no mucho tiempo para poder añadirla al motor. El caso es que una de las cosas que me tenían mosca es el pobre rendimiento que obtenía. Por ejemplo, el modelo Imp, me daba unos 30 fps. ¡Lo cual, como es de suponer, es inaceptable!.
Así que esta noche he estado haciendo pruebas para ver cómo mejorar el rendimiento sin tener que hacer el skinning con la GPU. Al final he obtenido un incremento del frame rate de un 800%. ¿Qué es lo que ocurría?.
Pues como es lógico, las llamadas a funciones ocasionan una cierta penalización. Pero ciertamente, ¡¡jamás pensé que las llamadas que hace MDX a las funciones nativas de D3DX llegara a esos extremos!!. Mirad los resultados:
Utilizando las funciones de D3DX Matrix.Multiply, Vector3.TransformCoordinate y Matrix.TransformNormal: ~30fps
Utilizando funciones equivalentes a las anteriores pero programadas por mí: ~190fps
Metiendo el código directamente (no se hacen llamadas a funciones): ~240fps
En fin, jamás pensé que la penalización pudiera ser tan brutal. Lo cierto es que viendo lo visto, habría que repasar el motor en busca de fragmentos de código que pudieran estar causando un descenso del rendimiento tan bestia.
Saludos.
-------------------------
Hello.
I am reviewing the skeletal animation that I implemented a long time ago (using format MD5 of Doom3) and that I want to finish to be able to add it to the engine.
The case is that one of the things that I was dissapointed with was the poor performance obtained. For example, the D3s Imp model, gave about 30 fps. Which it was totally unacceptable!.
So tonight I've been testing to see how improve the performance without having to do skinning with the GPU. In the end I have obtained an increase of 800% in the frame rate. So what was happening?.
As it is logical, calls to functions cause a certain penalty. But certainly, I never thought that the calls that MDX does to the native functions of D3DX could cause such performance hit!!. The results:
Using the functions of D3DX Matrix.Multiply, Vector3.TransformCoordinate and Matrix.TransformNormal: ~30fps
Using functions equivalent to the previous ones but programmed by me: ~190fps
Putting the code directly (without function calls): ~240fps
In short, I never thought that the penalty could be that high. The truth is that we should take a look to the source code looking for fragments of code that could be causing a similar performance hit.
Greetings.
Nada, olvidé que estaba probando en modo debug. En modo release el frame rate ronda los 340 en los tres casos.
Sin skinning el frame rate es de aproximadamente 530 fps.
-----------------------
Nevermind, I was testing on debug mode. In release mode the frame rate is around 340 in three cases mentioned in the message above.
Without skinning the frame rate is around 530 fps.
-----------------------
PD: ¿el foro va lento o es cosa mía?. :)
Ber si necesitas ayuda con los md5 ya sabes que yo los tengo implementados hace tiempo, lo unico que lo hago con quaterniones y no con matrices, a mi ya sabes que un ciberdemon animado me daba ~1000fps y con unos 50 me queda en 60fps.
CitarPD: ¿el foro va lento o es cosa mía?.
Llevo intentando postear esto todo el dia asi que ya ves (grrr)
Cita de: "zupervaca"Ber si necesitas ayuda con los md5 ya sabes que yo los tengo implementados hace tiempo, lo unico que lo hago con quaterniones y no con matrices, a mi ya sabes que un ciberdemon animado me daba ~1000fps y con unos 50 me queda en 60fps.
CitarPD: ¿el foro va lento o es cosa mía?.
Llevo intentando postear esto todo el dia asi que ya ves (grrr)
No si los md5 los tenía implementados (en C++) desde que salieron los primeros tests de Doom3. Y la verdad es que el sistema que desarrollé soporta muchas de las características de Doom3. Por ejemplo soporta blending entre sets de animación (pasar de una animación a otra haciendo una mezcla de x frames) y canales de animación (reproducción de diferentes animaciones al mismo tiempo para diferentes grupos de bones). Lo que pasa es que no me gustó como me quedó y por eso quiero reescribirlo.
Lo que sí estaría bien es saber cómo haces la conversión de los datos del md5 (rotaciones, por ejemplo) a Direct3D. Yo por ejemplo multiplico el bone raiz por una matriz de conversión pero lo ideal es hacerlo en tiempo de carga. Aunque es posible que al final me decante por crear un formato propio con soporte de escalado de bones.
Saludos.
EDITSi desactivo la transformación de las normales y la tangente me da unos 440fps. Está claro que todavía hay que optimizar más y tal vez hacer el skinning en la GPU.
Me imagino que te refieres a esto: x,y,z = x,z,-y.
Este es el codigo que uso en tiempo de carga para pasar de doom3 a mi sistema de quaterniones ya que no uso los de direct3d, no obstante me parece que uso el mismo.
// Obtener flag y puntero al inicio de los floats de este joint
int sourceFlags = source->flags;
float *frameStartIndex = startFrame + source->startIndex;
// NOTA: x,y,z = x,z,-y
// Posicion X (Tx)
if( sourceFlags & 1 )
{
destJoint->pos.x = *frameStartIndex;
frameStartIndex++;
}
else
{
destJoint->pos.x = source->pos.x;
}
// Posicion Y (Ty)
if( sourceFlags & 2 )
{
destJoint->pos.z = -*frameStartIndex;
frameStartIndex++;
}
else
{
destJoint->pos.z = -source->pos.y;
}
// Posicion Z (Tz)
if( sourceFlags & 4 )
{
destJoint->pos.y = *frameStartIndex;
frameStartIndex++;
}
else
{
destJoint->pos.y = source->pos.z;
}
// Rotacion X (Qx)
if( sourceFlags & 8 )
{
destJoint->rot.x = *frameStartIndex;
frameStartIndex++;
}
else
{
destJoint->rot.x = source->rot.x;
}
// Rotacion Y (Qy)
if( sourceFlags & 16 )
{
destJoint->rot.z = -*frameStartIndex;
frameStartIndex++;
}
else
{
destJoint->rot.z = -source->rot.y;
}
// Rotacion Z (Qz)
if( sourceFlags & 32 )
{
destJoint->rot.y = *frameStartIndex;
frameStartIndex++;
}
else
{
destJoint->rot.y = source->rot.z;
}
// Calcular el componente W
destJoint->rot.ComputeW();
PD: Antes de postear copiar el mensaje por que hoy el foro esta remolon :)
repetido
Pero... al final publicareis un tuto explicando las caracteristicas del formato md5 , el codigo etc
La verdad, lo que hubiesemos podido aprender con vosotros... es una pena que decidais dejar el motor y no continuar con las enseñanzas ....
De todas formas, mi reconocimiento y admiracion por vuestro trabajo !!!
Cita de: "Guest"Pero... al final publicareis un tuto explicando las caracteristicas del formato md5 , el codigo etc
Mi intención es añadir la animación esquelética al motor y en todo caso sacar un tutorial tipo manejo de un personaje con el teclado y el ratón (o algo similar).
Pero vamos que no sé cuándo estará terminado. :)
Saludos.
Cita de: "zupervaca"Me imagino que te refieres a esto: x,y,z = x,z,-y.
Bueno, esa era la conversión más evidente y la primera que probé en su día, pero si no recuerdo mal, las rotaciones no funcionaban bien. ¿Tú no tienes que hacer ninguna conversión?. O tal vez metía la gamba en alguna parte, que también es posible... jeje
Y pasando al tema del skinning, he seguido haciendo pruebas y la verdad es que sí hay diferencia entre llamar a las funciones de D3DX o utilizar las mias o directamente meter el código de transformación en la función de skinning. Aquí tenéis los resultados:
Haciendo uso de
D3DX:
350 fpsHaciendo uso de
mis funciones:
370 fps (pasando
por referencia las matrices y vectores) /
335 fps (pasando
por valor las matrices y vectores)
Sin llamadas a funciones:
480 fpsO sea que sí que hay bastante diferencia entre los tres casos mencionados. Parece que el hecho de que las funciones de D3DX estén (en teoría) muy optimizadas es contrarestado con creces por la penalización producida por la llamada a sus funciones. Si no, no se entiende que mi código de transformación sea más óptimo que el de D3DX.
Saludos.
Ber yo uso unas mias por que las llamadas a objetos com comen mucho, se gana mucho teniendo unas propias en c++ ya que pueden compilarse como inline, me imagino que en csharp pasara lo mismo, no obstante usando la libreria como dll puede que no se note la diferencia.
Todas las conversiones que hago estan en el codigo que te paso, no obstante debes tambien realizarla en la lectura de la malla para que salga correctamente.
Este es el codigo que tengo para crear el indexbuffer y el vertexbuffer de un mesh:
void Mesh_Close( dib::Graphics::View *view, dib::Graphics::SkinInfo **skinInfo, dib::Collection::DinArray<dib::Graphics::Mesh> *meshes )
{
// Crear el indexbuffer
dib::Graphics::IndexBuffer *indexBuffer = view->CreateIndexBuffer( this->tris, this->numTris * 3, 16 );
if( indexBuffer != NULL )
{
// Crear el vertexbuffer
VertexMD5 *verticesVB = new VertexMD5[this->numVerts];
if( verticesVB != NULL )
{
// Obtener los dos vertices
Vertex *source = &this->vertices[0];
Vertex *sourceEnd = source + this->numVerts;
VertexMD5 *dest = &verticesVB[0];
while( source != sourceEnd )
{
// Actualizar el vertice destino
dest->u = source->u;
dest->v = source->v;
dest->pos.Zero();
Weight *curWeight = &this->weights[source->weight];
Weight *lastWeight = curWeight + source->countWeight;
while( curWeight != lastWeight )
{
// Obtener su joint
Joint *curJoint = &this->joints[curWeight->joint];
dib::Math::Vector3 wv;
dib::Math::Quat q( curJoint->rot.x, curJoint->rot.y, curJoint->rot.z );
q.RotationVector( curWeight->pos, wv );
// NOTA: x,y,z = x,z,-y
dest->pos.x += (curJoint->pos.x + wv.x) * curWeight->weight;
dest->pos.y += (curJoint->pos.z + wv.z) * curWeight->weight;
dest->pos.z -= (curJoint->pos.y + wv.y) * curWeight->weight;
// Siguiente
curWeight++;
}
// Siguiente
source++;
dest++;
}
dib::Graphics::VertexBuffer *vertexBuffer = view->CreateVertexBuffer( verticesVB, this->numVerts, sizeof(VertexMD5) );
delete verticesVB;
if( vertexBuffer != NULL )
{
// Crear la informacion de la malla (Skin)
dib::Graphics::Skin *skin = new dib::Graphics::Skin( this->numVerts );
if( skin != NULL )
{
Vertex *source = &this->vertices[0];
Vertex *sourceEnd = source + this->numVerts;
dib::Graphics::Skin::VertexInfo *vertexInfo = &skin->vertexInfo[0];
while( source != sourceEnd )
{
int startWeight = source->weight;
int endWeight = source->countWeight + startWeight;
vertexInfo->weights.Create( source->countWeight );
Weight *weight = &this->weights[startWeight];
Weight *weightEnd = &this->weights[endWeight];
dib::Graphics::Skin::Weight *dest = &vertexInfo->weights[0];
while( weight != weightEnd )
{
// NOTA: x,y,z = x,z,-y
dest->Set( weight->joint, weight->weight, dib::Math::Vector3(weight->pos.x, weight->pos.z, -weight->pos.y) );
weight++;
dest++;
}
// Siguiente
source++;
vertexInfo++;
}
// Crear la malla para almacenar todos los valores
dib::Graphics::Mesh *mesh = new dib::Graphics::Mesh( view );
if( mesh != NULL )
{
// Agregar al array de mallas
if( meshes->Add(mesh) )
{
// Actualizar la malla
mesh->indexBuffer = indexBuffer;
mesh->material = NULL;
mesh->skinInfo = skinInfo != NULL ? *skinInfo : NULL;
mesh->skin = skin;
mesh->vertexBuffer = vertexBuffer;
mesh->vertexDeclaration = NULL;
// Continuar procesando las siguientes mallas
return;
}
delete mesh;
}
delete skin;
}
delete vertexBuffer;
}
}
delete indexBuffer;
}
this->reader.Abort();
}
Lo primero es meter todos los vertices en un array de vertices para crear el vertexbuffer, ya en el aprovecho para realizar la conversion, despues memorizo en estructuras propias los frames, es decir, la informacion de la animacion tambien convertida y por ultimo lo meto todo en una clase mesh.
La verdad es que leer esto en el foro es imposible ya que se come colores y tabulaciones por todas partes.
Se me olvidaba, esta funcion es llamada por cada mesh del objeto, si un md5 tiene dentro 5 mallas se crean las 5 y las mete en el array, de este tipo de archivo no saco la informacion de los huesos.
Otra cosa muy importante, yo no tengo los joints globales, los tengo jerarquicamente, es decir, un joint hijo depende de su joint padre para colocarse correctamente en el espacio, por eso en la demo de hace tiempo cuando se presiona la tecla "V" (me parece que era esa) el modelo camina ya que dejo de posicionar el joint padre de todos al valor 0,0,0
PD: Y pensar que esto ya no me compila con la nueva version de la libreria :(
PD2: Si quieres para que te sea mas facil leer todo me das un correo y te paso los cuatro archivos que tengo del md5 o si quieres ethernet se lo paso a el y lo ponga como el codigo del mes, hacia tiempo habia dicho que iba a dar el codigo, pero como se quedo obsoleto para la libreria pase de este codigo.
Hola, al tratar de bajar los videos la pagina donde estan alojados me daba error, es posible? como puedo hacer para verlos? los puedes publicar nuevamente?
Saludos Matias
PD: por el revuelo que arme con mis sugerencias en el otro thread del foro pido disculpas si el tema se fue de las manos, mi intencion solo era aportar sugerencias para beneficio del desarrollo de la engine. Estoy completamente de acuerdo que el destino de los fuentes y los tiempos los deciden exclusivamente ustedes... (los desarrolladore de la engine..) Saludos nuevamente Matias
PD: no se que pasa con el foro, soy Matute.. me loguee correctamente .. pero en el foro salgo como invitado..
Saludos
Gracias zupervaca, le echaré un ojo. Por cierto, ¿tú qué haces con los frames de animación, los construyes al cargar el modelo (consume más memoria) o en cada frame (en tiempo de ejecución) reconstruyes todo en base al frame base?.
Cita de: "Guest"Hola, al tratar de bajar los videos la pagina donde estan alojados me daba error, es posible? como puedo hacer para verlos? los puedes publicar nuevamente?
Sí, los quité hace tiempo porque los tenía alojados en mi FTP y me faltaba espacio para meter otras cosas. Veré lo que puedo hacer (si es que los conservo).
Cita de: "Guest"PD: por el revuelo que arme con mis sugerencias en el otro thread del foro pido disculpas si el tema se fue de las manos, mi intencion solo era aportar sugerencias para beneficio del desarrollo de la engine. Estoy completamente de acuerdo que el destino de los fuentes y los tiempos los deciden exclusivamente ustedes... (los desarrolladore de la engine..) Saludos nuevamente Matias
Fastidia un poco, pero nada que no se pueda olvidar. :)
Gracias.
Bueno, he encontrado los videos. Los podéis descargar de
aquí.
El
md5_mixer.avi muestra la mezcla de sets de animación. Se puede ver cómo el modelo pasa de la animación "idle" a "walk" y a "run" de forma suave, interpolando un determinado número de frames.
Luego, el
md5_channels.avi muestra la capacidad de poder asignar diferentes animaciones a diferentes grupos de bones. Así, se puede ver que de cintura para arriba se reproduce la animación "idle" y de cintura para abajo, la animación "walk".
Tened en cuenta que estos videos se crearon hace un año y medio, por lo que la calidad de la iluminación dejaba bastante que desear. :)
Saludos.
----------------------------
Ok, I've found the old md5 videos. You can download them
here.
The
md5_mixer.avi shows the blending between animation sets. You can see how the model goes from animation "idle" to "walk" and "run" smoothly, interpolating between a specific number of frames.
Then, the
md5_channels.avi shows the ability to assign multiple animations to different groups of bones. So you can see that the upper body is playing the animation "idle" and the lower part, the animation "walk".
Keep in mind that this videos were created a year and a half ago, so the lighting quality was very poor at that time. :)
Citar¿tú qué haces con los frames de animación, los construyes al cargar el modelo (consume más memoria) o en cada frame (en tiempo de ejecución) reconstruyes todo en base al frame base?.
Los creo todos en tiempo de carga, pense hacerlo en tiempo de ejecucion, pero despues de probarlo y ver el numero de comprobaciones preferi cambiarlo, no obstante aunque se haga asi se puede especificar un mismo esqueleto a diferentes mallas siempre y cuando tengan bien asignados los huesos.
Antes de cambiar de sistema pense hacerlo mediante un memcpy y luego modificar los que hicieran falta, pero se perdian muchos fps igualmente, asi que preferi sacrificar memoria.