Reprise du message précédent :
oki, je vais regarder

Salut !
   Bon, alors j'ai mesuré mes FPS, verdict :
   780 fps pour mon petit modèle de 900 triangles    pourquoi tant de haine... j'aurrais voulu au moins 1500 pour un truc assi moche...
   Par contre là où celà deviens bizare c'est quand je mesure mes fps pour un modèle qui comprend plus de triangles : j'ai aussi 780 pour un modèle de 3000 triangles et encore 780 pour un modèle de 175k triangles...   Ce qui me parait plutôt étrange... y'a un couille dans le potage ou c'est justement ça que tu voulais que j'observe ?
 
Merci

900 triangles c'est un peu peu, ça peut faire un batch trop court pour masquer le coût moteur+api.
 
780fps pour 900 et 3000 triangles ça me parait réaliste: le point d'inflexion sur les cartes modernes est de l'ordre de 1500 triangles je crois, mais c'est un ordre de grandeur à la louche et c'est dépendant de l'api ; le D3D 9 a un poil plus de coût API que l'OpenGl à ce que j'ai cru comprendre.
 
par contre 780 fps pour 175k et 3k triangles, là c'est bizarre
 
regarde si tu est sûr de ta mesure de temps par frame ou si y'a pas une autre blague

Salut !
   Bon, effectivement oui il y avait une autre blague... toujours est - il j'ai corrigé et voici les résultats :
   - 1130fps pour un modèle de 1300 triangles texturé & éclairé (l'éclairage de base)
   - 750 fps pour un modèle de 7900 triangles
   - 750 fps aussi pour un modèle de 58k triangles
   - 380 fps pour un modèle de 175k triangles (la c'est tout de suite plus réaliste )
 
Sachant que les trois dernier sont juste éclairés : pas de textures...
 
au passage je balance une capture de mon modèle de 1300 triangles    

 
bon comme tu peut le constater je suis en train de l'animer... pour ce qui est de la gestion des animations je suis au début : recherche de doc. j'ai pas mal trouvé d'info sur les types d'interpolation entre deux keyframes. Bon mon problème actuellement c'est de trouver comment savoir quels sont les vertices attachés aux bones... enfin je vais aller voir du côté du directX SDK : si je peut compredre comment ça marche sur le format ".x" je devrais comprendre comment ça marche pour les autres formats.
Pour ce qui est de la gestion des animations, j'ai pas envis de toucher a mes buffers donc je pense que je vais passer via CG ou GLSL pour le faire faire en interne par la carte graphique. j'ai déjà un livre que je m'était acheté sur CG qui en parlait...
Donc en gros il n'y a plus qu'a...

y'a deux grands type d'animations:
 
- soit tu stoques tous les vertexs skinnés à x fps, et tu interpoles avec un lerp la position des vertexs entre deux frame (Quake 1/2)
 
- soit tu stoques par vertex les bones utilisés et leur poids, et tu blend tout ce petit monde dans un vertex shader, en gros ça te donne un vertex comme ça:
 
struct BonedVertex
{
   float x,y,z,
         nx,ny,nz;
   ....
   ....  /* u,v, tangente, binormale... */
   
   unsigned char Bones[4];
   float Weights[4];
};
 
et dans le VertexShader, ça donne un truc dans ce goût (synthaxe n'importe quoi à l'arrache):
 
matrix BoneMatrix[256];  
 
VertexShader( invertex In, outvertex Out)
{
    Out.Pos = (In.Pos *BoneMatrix[In.Bones[0]])*In.Weights[0];
    Out.Pos += (In.Pos *BoneMatrix[In.Bones[1]])*In.Weights[1];
    Out.Pos += (In.Pos *BoneMatrix[In.Bones[2]])*In.Weights[2];
    Out.Pos += (In.Pos *BoneMatrix[In.Bones[3]])*In.Weights[3];
 
    ....
    etc pareil pour tous les autres grandeurs a skinner
}
 
l'avantage de l'approche skinnée, c'est qu'elle flexible: tu peux faire ce que tu veux avec les bones, passer d'un état keyframé à un état simulé par moteur physique quand Sonic passe sous une voiture

Ok, ce serai plutôt la deuxième technique qui me plairai. comme ça je pourrais écraser le sonic ...
 
Bon je vais chercher dans cette voie...
 
Merci