MakeHuman pour MorphOS
-
Comme je l’annonce sur la ML MorphOS, j’ai fait un rapide port
de MakeHuman sur MorphOS.
Ca marche, mais vaut mieux un G4-1 GHz!!
D’ailleur le demarrage prend plusieurs minutes… (2-3).
* Le binaire c’est la [617 Ko]
*Les donnees [45 Mo](toutes les poses pre-etablies, necessaire avec le binaire, decompresser l’archive au meme endroit que le binaire).
* Les sources [230 Ko], pour les compiler j’ai fait un tres imple script python, allez dans makehuman-0.9.0/ et tapez « python make.py », vous devez avoir installer: Python, TinyGL sdk, un sdk pour la libpng et un sdk pour la libz
* Correction pour blender: .blender/scripts/obj_import.py
Amusez-vous bien,
– Guillaume
[EDIT, 2006/11/09]
Tous les pb de demarrage sont resolus ainsi que les ope I/O (on peut chreger/sauver maintenant).
J’ai mis a jours les liens au-dessus, il n’y a que les data qui n’ont pas changees.
Pour l’import de l’objet au format wavefront (.obj) dans Blender il vous faudra mettre a jour le fichier obj_import.py qui se trouve dans votre install de Blender, rep .blender/scripts/
j’ai ajoute le lien sur cette mise-a-jour aussi.
Pour info, sachez que le binaire a change de nom (mh), car MakeHuman cree un repertoire ‘makehuman’ dans PROGDIR: pour stocker toutes vos creations.
Super ^_^ !
Comme d’habitude, je suis sûr que tu as fait du très bon boulot !
Je teste ça ce soir…
Abonnez-vous à ma nouvelle chronique "En Route vers le Futur" sur Youtube !
Gasp!
Je ne peux pas brancher mon Peg en ce moment pour ause de « déplacement »! Ca me fait souffrir grave! ((
Heureusement des nouvelles et un travail comme ça font vraiement très plaisir! )))
Bravo! Olà! Bravo!
Merci Yomgui!
L’Humanité Amigaiste te dois,
Encore une fois Amigaiste vois,
Un grand MERCI!
Screetch a écrit :
(…)
Comme d’habitude, je suis sûr que tu as fait du très bon boulot !
(…)
Non… j’ai juste resolus 3-4 pb de compile C++ et fait un petit script Python pour compiler vite fait!
Ensuite j’ai tente de savoir pourquoi c’est si long au demarrage et la j’ai vu que c’est entierement dus au chargement de fichiers par l’utilisation de la classe ifstream et sscanf()…
Mais la meilleur blague de la journee c’est cette phrase venant du site oueb de MakeHuman:
The program has been entirely rewritten in C++, by using in the best way possible the Object Oriented design, to increase stability and reliability.
Traduction:
Le programme a ete entierement re-ecrit en C++, en utilisant de la meilleure facon possible le design « Oriente Objet », pour augmenter la stabilite et la fiabilite.
Y a comme un non-sens dans cette phrase.
Ensuite j’ai tente de savoir pourquoi c’est si long au demarrage et la j’ai vu que c’est entierement dus au chargement de fichiers par l’utilisation de la classe ifstream et sscanf()…
Là, désolé, Yomgui mais je peux pas te laisser dire ça : bien employés les iostream sont très puissants et pas si lents qu’on veut bien le laisser entendre…
Maintenant c’est certain que s’ils utilisent les iostream pour lire des chaînes de caractères, puis des sscanf (qui dit en passant risque de compromettre leur « augmenter la stabilite et la fiabilité ») pour convertir en int bhien c’est certain que ça doit ramer sa mère !
… les méthodes istream::read() et ostream::write() ne sont pas pour les chiens quand on désire lire du binaire….
Alex:
C’est pas du binaire. les fichiers de data sont des fichiers textes ou ils ecrivent souvent des float.
Je te laisse regarder le code source, par exemple animorph/src/VertexVector.cpp.
Si tu t’y connais mieux que moi en C++ (c’est pas tres dur…) tu peux toujours ameliorer le code pour qu’il fonctionne plus vite
Au passage, la version de reference que j’utilise (WinXP sur un bi-pent 3GHz/2GB) demarre en qq secondes, il doit donc y avoir un pb dans la libstdc++ pour une telle difference.
Ah pour info, ce n’est pas le code original. Je l’ai modifie.
Ils utilisent un buffer statique « char *buff[MAX_blabla_LINE]; »
qu’ils remplissent dans une boucle while() avec iostream.getline(). Ensuite ils font le sscanf() dessus.
Je me suis permis d’utiliser iostream.gets() histoire de ne pas bouffer 1024 octets (taille du buffer) betement dans cette boucle.
… pou run buffer qu’ils ne modifient pas.
C’est pas du binaire. les fichiers de data sont des fichiers textes ou ils ecrivent souvent des float.
Ah Ok, mais faudra que je vérifie, il me semble que normalement un petit
float monfloat;
ostream << monfloat; puis un istream >> monfloat;
devrait normalement fonctionner direct, après il est possible d’utiliser des manipulateurs pour fixer les formats de ces float.
Ca évite de passer par une chaine temporaire puis de passer par un sscanf (en plus dans les iostreams il y a déjà une vérification des erreurs qui est toute faite et qui peut même lever une exception si on lui demande gentiment (c.f. la méthode exceptions( ) )…
Si tu t’y connais mieux que moi en C++ (c’est pas tres dur…) tu peux toujours ameliorer le code pour qu’il fonctionne plus vite
Attention je n’ai rien dis de tel, je pense que question portage/dev tu te poses là y a pas à discuter tes compétences, c’est clair 😮 ! Je voulais juste faire une remarque sur la vitesse de iostreams c’est tout.
Après je voudrais bien regarder le code mais vu que je n’ai pas MOS, faudrait que je puisse le compiler sous OS4 pour voir, y a vraiment que cxe que tu disais au début comme dépendances ?
Au passage, la version de reference que j’utilise (WinXP sur un bi-pent 3GHz/2GB) demarre en qq secondes,
Ah oui mais aussi si tu compare un bi-pentium 3Ghz/2GO de ram avec nos pauv’G4 1Ghz/512MO voir 1GO de ram aussi c’est normal qu’il est une différence
il doit donc y avoir un pb dans la libstdc++ pour une telle difference.
Ca c’est tout à fait possible malheureusement je ne pourrais pas te dire en faisant la comparaison sur mon XE G4/800Mhz/512Mo à moins que je ne tente de faire le portage vite fait… Faudrait que je regarde les dépendances et croiser les doigts pour que ça n’utilise pas des trucs qu’on n’a pas dans notre implémentation d’OGL
Alex:
Oui il n’y a que ca comme dependances.
Faudrait juste changer les tests sur le define __MORPHOS__ en __AMIGA__. Ah y a aussi une petite magouille avec la fonction for_each() je ne sais plus ou.
Tiens moi au courant.
PS: j’ai porter et compiler ce truc sur le PC/Win de ref avec AmiDevCPP… pour dire que c’est simple
Les iostreams sont nécessairement plus lents du fait des x couches par lesquelles on doit passer.
Par exemple, pour le « stream >> blah », on passe par un operator>> choisi en runtime en fonction du type passé. Mais ça c’est un détail, après niveau implémentation (je me base sur ce que je vois de la 3.4.6), c’est template à gogo, allocations dynamiques sans arrêt dans la partie gestion de buffers, passage par 36 méthodes différentes, exceptions, templates, pour au final passer par les fonctions ansi.
En pratique, ça se traduit par des résultats 4 fois plus lents environ sur certains tests.
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Développement › MakeHuman pour MorphOS