DX8 - MILKSHAPE MS3D ASCII ANIMATED MODEL VIEWER BETA 2

Signaler
Messages postés
589
Date d'inscription
lundi 25 août 2003
Statut
Membre
Dernière intervention
18 juillet 2010
-
Messages postés
17286
Date d'inscription
mercredi 2 janvier 2002
Statut
Modérateur
Dernière intervention
23 décembre 2019
-
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/42498-dx8-milkshape-ms3d-ascii-animated-model-viewer-beta-2

Messages postés
17286
Date d'inscription
mercredi 2 janvier 2002
Statut
Modérateur
Dernière intervention
23 décembre 2019
69
question de stockage, je suppose...
si tu gagne en rapidité (sous tableaux) faut faire des compromis (taille)

au pire, tu peux transformer le format en ce que tu veux... on est bien d'accord que ce format n'est qu'un format de stockage des modèles, pas un format de "travail", pas a exploiter en temps reel, je veux dire...

enfin, ce n'est que mon avis, c'est pas mon rayon, hein ^^
Messages postés
340
Date d'inscription
jeudi 25 juillet 2002
Statut
Membre
Dernière intervention
25 août 2007

euh 10 plombes plus tard :op
pour renfield> tout est a la suite
en gros je voulait dire que toutes les animations sont en fait un tableau de nframes de translations et rotations donc un perso aura par exemple 100 frames (a recalculer bien sur) mais si tu veut par exemple lire l'animation "marche" ou "court" eh bien tu doit connaitre les indexes de debut et de fin de chaque "animation" car la tu dispose d'un tableau contenant toutes les frames et tu doit te de****er avec c'est plutot pas terrible si tu doit ajouter une frame a un animation vu qu'il faut alors reindexer toutes les frames pour pas decaler le tout
il aurait donc été plus interessant de regrouper les animations sous formes de sous tableaux de maniere a ne charger que le tableau des n frames necessaire pour telle ou telle anim ainsi tu ne parcours plus les 1500 frames si tu en utilise que 10, au niveau chargement ce n'en serait que plus rapide aussi , j'ai pu tester ma theorie sur des dump 3ds regroupés par blocs dans des fichier et le resultat et plus que meilleur
l'autre solution serait d'avoir 1 fichier ms3d par animation (comme pour les mdl de half life) mais ca veut dire plus d'access disques ou plus de temps pour interpreter les fichiers.
d'ou l'interet (vu la ram des pc actuels) de charger 1 seul fichier sous forme binaire (genre les md2 de quake2) avec des blocs d'anim utilisant des noms.
je sais pas si c'est suffisament bien expliqué mais bon :/
voila..
Messages postés
589
Date d'inscription
lundi 25 août 2003
Statut
Membre
Dernière intervention
18 juillet 2010
1
Je pense que ce que veux dire Shadowmoy c'est que actuellement qu'il y ai 10 animation differente (marche,course,mort,coup...) rien n'est classé. Dans un fichier ms3d on à tel transformation pour tel frame(s), donc quand on lit les animations au départ on à une suite de transformation avec un index qui represente le numero de(s) la frame(s).

Dans le cas d'un jeu il est plus simple de traiter les different type d'animation séparément, avec leur propre transformation à chacune, certe cela fait que le fichier est plus lourd, mais au final on est gagnant dans les calculs de rendu.

J'ai deja développé un type perso avec une fonction qui permet de récuperer les models d'un fichier, actuellement je ne travaille pas avec les animations donc je ne les ai pas inclu de mon type, le format des vertices et de type d3dxvertex, et c'est prévu pour un affichage direct en forme de liste de triangles. Sans les animations on arrive à des fichiers légérement plus lourd que les fichiers ms3d avec animation. Par contre en vitesse de traitement c'est incomparable.
Messages postés
17286
Date d'inscription
mercredi 2 janvier 2002
Statut
Modérateur
Dernière intervention
23 décembre 2019
69
"tout est a la suite"

tu pourrais développer ?
Afficher les 13 commentaires