Ce fichier contient des copies d'e-mails annoncant aux membres du LI2/CERV les diverses versions d'ARéVi publiées.
Certains d'eux donnent des informations pouvant faire office de documentation sur quelques points particuliers.
Bien entendu, comme tout e-mail qui se respecte, ceux-ci sont truffés de fautes.
Je ne coordonne plus le développement de la bibliothèque ARéVi.
Elle est désormais hébergée sur
http://www.cerv.fr/AReVi/
et est maintenue par tous les membres du CERV qui le souhaitent.
Christophe Le Gal a modifie les fichiers de AReVi/Contrib/ArMath afin de remplacer les types ``template'' par des ``double''.
Les modifications sont : -correction de l'exporter blender<->md5 -correction de coordonnées de texture du md5 -correction du md5Parser.y pour qu'il passe avec des vieux bisons
Juste une modif de vector3D.h/.Ci par Ronan Billon pour fonctionner avec sa HLib2.
Euh ... desole mais j'ai voulu faire le malin en modifiant la maniere de mesurer le temps reel dans AReVi ( RealTimeScheduler et ArSystem::getTime() ). Seulement je me suis loupe ca fait pas du tout ce que je pensais ... Le temps ralentit, voire s'arrete presque dans certains cas ... Remarquez, j'arrive a un age ou ca commence a m'interesser ce genre de choses ;^) Donc la version d'aujourd'hui corrige ca.
Sur ma page une nouvelle version d'AReVi.
- Eric Cazeaux a mis en place le cube-mapping pour
les textures (cf Tests/Lib3D/testCubeMap). Ca semble
avoir un petit probleme sur certaines cartes graphiques
ou ca ne fonctionne bien qu'en 16bpp (a creuser ...)
- Le travail de stage de master-recherche de Kristen Manac'h a
ete integre dans les classes Index3D/PointIndex3D/VolumeIndex3D.
Ca remplace purement et simplement Grid3D.
- Index3D est une classes abstraite pour l'indexation des Base3D.
- PointIndex3D est specialise dans l'indexation de _points_ et
sert a repondre rapidement a des requetes du genre ``quels sont
les points qui sont approximativement dans tel volume ?''
- VolumeIndex3D est specialise dans l'indexation de _volumes_
(1 point + un rayon) et sert a repondre rapidement a des
requetes du genre ``quels sont les volumes qui recouvrent
approximativement tel point ?''
- Ces structures d'indexation peuvent accueillir des objets de
types quelconques (derives de Base3D) et de granularites
(echelle ?) tres variees. Il suffit juste de choisir
a quel niveau de granularite on insere un element. Pour
un point ca depend essentiellement de son ``pas'' (v*dt).
Pour un volume ca depend de son pas et de son rayon.
Une granularite trop fine provoque des changements de cases
tres frequents qui peuvent etre penalisants ; a l'inverse
une granularite trop grossiere fait qu'on obtient un
voisinage potentiel (mais pas reel !) trop grand lors des
detection donc la detection n'est pas efficace.
- Pour les details j'ai le rapport de stage en pdf.
- L'exemple Tests/Lib3D/testIndex utilise ca (c'est la demo
de la soutenance de Kristen)
- J'ai bricole l'ordonnanceur pour qu'il soit plus efficace
lorsque pas mal d'activites doivent se declencher a la meme
date (c'est tres souvent le cas dans la pratique). Dans le
cas tres particulier ou il n'y a qu'une activite a chaque
date distincte de declenchement on ne gagne rien.
- La ``hLib'' est maintenue par Ronan Billon (normal, il est
a la place de Thomas ;^). On l'a adaptee pour qu'elle
s'integre mieux dans AReVi. Voir le README dans l'archive.
- Il y a aussi la ``derniere'' version du tutoriel sur AReVi
par Ronan Billon encore. Elle date du 23 mai car je ne me
suis pas occupe d'AReVi depuis le 11 mai et j'avais laisse
tout ca en attente... desole ...
- Certainement des tas de trucs que j'ai oublie ...
Oups, dans la version precedente j'avais introduit une modif qui pouvait provoquer un blocage lors du rendu ...
Le compilateur g++ 4.1.0 respecte maintenant une modif qui a ete faite dans la (re)normalisation de c++ concernant les declarations ``amies''. Maintenant le fait de dire que quelque chose est ``amie'' d'une classe ne suffit plus a declarer cette chose ; il faut la declarer en plus a l'exterieur de la classe... Ceci perturbe le systeme de macros d'AReVi qui justement reposait sur l'ancienne interpretation pour fournir les fonctions new_MyClass() et register_MyClass_Class(). Il y avait moyen d'utiliser l'option -ffriend-injection pour forcer le compilateur a utiliser le fonctionnement precedent mais celle-ci sera certainement amenee a disparaitre a moyen terme... J'ai donc prefere modifier la maniere d'utiliser AReVi pour respecter cette nouvelle contrainte. Desormais les fonctions amies new_MyClass() et register_MyClass_Class() sont respectivement remplacees par les methodes statiques MyClass::NEW() et MyClass::REGISTER_CLASS(). (si vous utilisez le script register-class dans vos fichiers configure vous n'avez qu'a vous preoccuper de new_ --> ::NEW ) Pour ceci voici un petit bout de script qui, s'il est invoque depuis le repertoire contenant vos fichiers sources, doit faire l'essentiel des conversions : !!!!! ATTENTION !!!!! SAUVEGARDEZ VOS FICHIERS AVANT CAR EN CAS DE FAUSSE !!!!! MANIP VOUS RISQUEZ D'ALTERER LEUR CONTENU ---------------------------------------------------------------- for i in `find . -name \*.h -o -name \*.Ci -o -name \*.cpp` ; do echo $i cat $i | sed -r -e s/'new_([_a-zA-Z][_a-zA-Z0-9]*)'/'\1::NEW'/g \ -e s/'register_([_a-zA-Z][_a-zA-Z0-9]*)_Class'/'\1::REGISTER_CLASS'/g \ > $i.tmp mv $i.tmp $i done ---------------------------------------------------------------- J'ai fait ca sur tout AReVi et les tests et ca c'est tres bien passe. Pour le code utilisant gtk ou il y a quelques `machin_new_with_bidule()' qui sont transformes en `machin_with_bidule::NEW()' qu'il faudra reprendre a la main (ou bien ameliorer l'expression rationnelle). Ce n'est pas la peine de raler, j'aurais egalement prefere garder l'ancienne notation pour les ``new'' (ca ressemble plus a des choses connues), mais la il n'y a pas le choix ... Sinon j'ai limite le niveau d'optimisation a -O1 avec g++ 4.1.0 car j'ai des plantages inexpliques si je vais au dela (valgrind ne dit rien avant !)
- Correction d'un pb en debug avec g++ 4.X
- Correction d'un pb interne avec les arstub
(pas visible normalement)
- Object3D::onMouseButtonInteraction()
Object3D::onKeyboardInteraction()
Object3D::onMotionInteraction()
recoivent 2 arguments supplementaires
- la ShapePart3D (de la Shape3D de l'Object3D)
- le numero de triangle dans la ShapePart3D (Surface3D)
- Petite optimization sur Grid3D --> +15% FPS sur testGrid !
- Gestion des messages d'erreurs dans le plugin Xml (E. Cazeaux)
- MAJ du plugin Text2Speech (E. Cazeaux)
Nouvelle version du tutoriel par R. Billon.
Encore une petite mise à jour :
-Ajout d'une section "survol" des ArWidget
-Ajout du plugin ArSystem::loadPlugin("MagickImageLoader"); dans les exemples
Nouvelle version du tutoriel par R. Billon. Encore des modifs, en essayant de structurer un peu plus :) La partie message est toujours "under construction"
bonjour, après avoir essayé le compilateur GCC.3.4.4 sur cygwin et constaté des erreurs inexplicables ( pb allocation/désallocation mémoire), je viens de faire la mauvaise expérience de ce compilateur sur linux: même type d'erreurs et même crépage de chignon pour trouver d'où ca vient sans pouvoir au final l'expliquer. Voilà fabrice tu attendais que quelqu'un l'ai testé, je l'ai fait, promis je ne recommencerait pas...
Salut, Voici donc une nouvelle version qui ne change pas grand chose par rapport à la précédente : Ajout de deux scripts pour automatiquement déplacer ArWidget avec AReVi (ça utilise arevi-config donc vérifier qu'AReVi est bien présent et accessible!) Correction AwLabel, OSDText qui persiste lors de la destruction du widget (merci C. Septseault). Attachement Tooltips/ArWidget supprime l'effet de retard lors du déplacement d'un widget avec le tooltip visible. Ajout de delay pour les tooltip, static de AwWidget, paramètre dans le skin, voir skinCustom.xml (F. Devillers) Ajout d'un proto de fileSelector dans les tests ... a noter la boucle simulationStep (run) pour faire la modalité ... beurk, c juste pour le test! Correction AwEntry, signe '-' pour le mode numérique. Il s'agit donc juste d'un flush de qlq modifications sur source forge.
Le meme tutorial mais avec les fichiers ``configure''. Merci m'sieur Billon.
Une premiere version du tutorial AReVi realise par Ronan Billon est disponible sur ma page.
M'sieur Cazeaux a encore fait des folies (ArWidgets ...) Pour ca il a ete necessaire de faire des petites modifs dans AReVi. Les callbacks concernant les interactions (clavier,souris) ont ete remontees de Window3D vers Renderer3D. Les methodes simulateXXX() correspondantes aussi. Les (anciens) WindowInteractor s'appellent donc maintenant AbstractInteractor et peuvent etre associes a des Renderer3D (puis qu'on peut simuler les evenements a ce niveau). Ca permet notamment d'avoir des interactions sur une texture generee par un TextureRenderer. (Du genre interagir avec une scene qui est rendue sur une tele visualisee dans une autre scene ... Bon ok ca sert a rien mais c'est beau ...) La derniere position de la souris recue dans un Renderer3D est accessible par getLastMousePosition(). Les methodes firstPicking()/picking() ont ete ajoutees dans Scene3D. (Ce n'est que la combinaison de computeCursorDirection() et firstRayIntersection()/rayIntersection() )
On n'arrete plus m'sieur Cazeaux !!! - specifications des derivees dans les nurbs de dimension N - transformations XSL dans le plugin XML
Juste un petit oubli dans les ArNurbs ... (E.Cazeaux)
Sur ma page une nouvelle version d'AReVi : - Un test un peu trop severe qui fait echouer l'initialisation de la 3D (en affichage 16 bits) a ete retire. - Quelques modifications mineures de code ici et la (suite aux plaintes de quelques compilateurs) - "arClass.h" est inclu depuis "arObject.h" comme ca on ne l'oubliera plus dans les .cpp (l'erreur a cause de la macro AR_CLASS_DEF pas encore connue n'est facile a comprendre a la premiere lecture) - Des modifications sur l'evaluation des Path par F. Devillers (j'ai rien compris ;^) - Des vecteurs et nurbs de dimension N par E. Cazeaux - Des metaballs par E. Cazeaux (trop fort m'sieur Cazeaux)
Une nouvelle version d'hLib est disponible. Elle corrige quelques bugs mais
surtout ajoute une nouvelle classe : AnimationMixer.
L'AnimationMixer sert à 2 choses :
- enchainer des mouvements cycliques (AnimationCycle)
- supperposer des actions (AnimationAction)
* Enchainer des animations cycliques :
- une animation est jouée en boucle
- on empile une nouvelle animation
- un fondu est calculé pour baculer d'une animation à une autre (le délai
du fondu est spécifié par l'utilisateur)
Cela peut faire office de transition d'animation le temps que je termine
l'algo de calcul automatique des transitions.
* Superposer des actions :
- une animation est jouée en boucle
- on ajouter une AnimationAction en spécifiant les délais d'exécution, de
fondu entrant, fondu sortant
- l'animation sera déclenchée en respectant le délai d'exécution, en se
supperposant sur l'AnimationCycle en cours
Cela implique de faire du motion blending local. La classe AnimationAction
permet de spécifier pour chaque articulation un poids. Ce poids sera utilisé
pour superposer l'action & le mouvement en boucle. Par exemple, j'ai un
mouvement où le gugus fait salut avec son bras droit, le reste du squelette
restant immobile. Toutes les articulations auront un poids nul (pas
d'influence), sauf celles du bras droit qui aurant un poids égal à 1.
Comme c'est laborieux de spécifier les poids manuellement (mais possible),
il vous suffit d'appeler la méthode AnimationAction::computeDefaultWeights().
Bien évidément un programme de test est fournit (testAnimationMixer), et
c'est disponible sur sourceforge & ma page perso enib.
Les PBuffer/FramebufferObject on ete revus, notamment sous Window$ car ils ne fonctionnaient pas bien. Dans Window$/Cygwin ne pas utiliser gcc-3.4.4 mais la version precedente (3.3.3). Pas mal s'en pleignent sur la mailing-list de Cygwin et j'obtiens egalement des warnings injustifies dans la STL et des plantages. PA. Beal a ajoute une methode File3D::mergeShapes() Ajout de XPath dans le plugin XML (E. Cazeaux) Dans l'outil PathEditor on peut charger une scene serialisee plutot qu'une simple forme pour le decor (T. Jourdan)
Une nouvelle version d'hLib est disponible sur sourceforge.
La principale nouveauté est le motion blending : il est possible de
fusionner plusieurs animations entre elles pour en créer une nouvelle.
Exemple : pour obtenir une marche rapide, on utilise un mouvement de
marche a 70% et un de course à 30%. La composition des mouvements se
fait via un arbre binaire.
L'interface des classes pour l'animation a été modifiée. Maintenant il
n'y a plus d'interpolateurs de keyframes (spherique ou cubique). Comme
personne ne se servait de l'interpolation cubique, je l'ai dégagée. Il
ne reste plus que l'interpolation sphérique linéaire, qui est intégrée
dans l'animation directement (plus besoin d'instancier un
KeyframeInterpolator, il n'existe plus).
Les animations sont décomposées en 2 éléments : la class Animation et
la class AnimationData.
La classe Animation est la classe a utiliser. C'est elle qui propose la
méthode evaluate() pour interpoler les images clés. C'est une classe
abstraite, dont dérive 3 types :
-------------
| Animation |
-------------
^ ^
| |
------------------- ------------------
| AnimationAction | | AnimationCycle |
------------------- ------------------
^
|
-----------------------
| AnimationBlendCycle |
-----------------------
Les classes AnimationCycle & AnimationBlendCycle c'est pour les mouvements
en boucle. Le motion blending ne supporte que ce type d'animations. La
classe AnimationAction c'est un mouvement qu'on ne joue qu'une fois.
Une animation possède donc une référence sur une AnimationData, ce qui
permet de partager les données de mouvement entre plusieurs animations.
La classe Animation rajoute une Transform3D qui n'est pas utilisée pour
le moment (mais ca va venir).
Cela implique un changement au niveau des plugins. Quand on charge une
animation, on n'a aucun moyen de savoir si c'est un mouvement cyclique ou
non. Donc le plugin retournera un vecteur d'AnimationData. C'est au
developpeur de l'utiliser avec un AnimationCycle ou un AnimationAction.
Les programmes de tests compilent à nouveau avec la version courante
d'hLib, et il y a maintenant un testMotionBlend. Par contre je ne compile
plus le testMotionPath (bug que je n'ai pas encore résolu).
Une nouvelle version d'AReVi pour les vacances
- Le systemes de particules ont ete remanies pour pouvoir
utiliser une texture. De nouveaux parametres ont ete
introduits, et il est possible de personnaliser
l'initialisation, l'evolution et le rendu des particules
par surdefinition de _initParticle(), _updateParticle,
_render(). Voir notamment Tests/Lib3D/testFire.cpp.
- La classe Grid3D emet un evenement lorsqu'un element
change de case (idee de Gireg Desmeulles, merci)
- David Herviou propose un wrapper avec le langage de
script Lua (merci)
- Les repertoires ont ete un peu reorganises et maintenant
les services de distribution sont dans une bibliotheque
separee afin de ne pas allonger le temps de compilation
quand on n'en a pas besoin. Pour compiler cette
bibliotheque on fait:
./armake ns
pour lier une appli qui l'utilise on fait:
arevi-config --ldflags --ns
pour initialiser la bibliotheque depuis l'appli on fait:
registerAReViNSClasses();
les .h ne sont plus dans AReVi/Contrib mais dans AReViNS
- les methodes simulateXXX() de WindowInteractor ont ete
deplacees dans Window3D (c'est plus simple)
- les methodes setDestroyOnClose() et setLeaveOnClose()
de Window3D ont ete remplacees par une unique methode
setCloseAction()
J'en profite pour publier une nouvelle version d'hLib. Nouveautés : - script hLib-config, qui fonctionne exactement comme arevi-config - juste hLib/hlib.h à inclure - correction du petits bugs dans la plugin half-life - le skinning avec plusieurs bones fonctionne vraiment ! (j'avais pas pu tester avant) Dispo sur sourceforge bien sur
Sur ma page une nouvelle version d'AReVi
Principales nouveautes :
- Un nouveau mode de rendu stereo qui superpose les images
pour chaque oeil (#anaglyphs). Le filtrage de la couleur
pour chaque oeil peut etre ajuste librement (pas tout ou
rien). Ca permet d'obtenir un rendu stereo sans materiel
special, juste une paire de lunettes bicolores (Jaune-Bleu
par exemple) pas chere (en carton, present dans toutes les
bonnes boites de cereales). A noter toutefois que ca passe
par le rendu dans une texture, il faut donc que cette
fonctionnalite soit supportee.
- Le rendu dans une texture utilise maintenant l'extension
framebuffer_object (si disponible, sinon les PBuffers).
Ceci est plus efficace sur les materiel/driver qui
l'implementent bien (ce n'est pas toujours le cas !) car ca
evite une recopie des donnees depuis la zone de rendu vers
la texture.
- Il est possible de fixer l'aspect-ratio du rendu 3D
independamment du vrai rapport largeur/hauteur. C'est
principalement interessant pour le rendu dans les textures
car elles ont necessairement des dimensions qui sont des
puissances de deux. Dans ce cas l'aspect-ratio par defaut
(necessairement une puissance de deux donc) ne correspondait
pas forcement a l'utilisation qu'on voulait en faire
(dimensions d'un televiseur, d'un mirroir ...) et on etait
alors oblige de jouer sur les coordonnees textures pour
corriger. Maintenant c'est beaucoup plus simple, il suffit
d'imposer au rendu dans la texture un aspect-ratio qui
correspond au support de la texture (televiseur, mirroir ...)
Sinon j'ai essaye AReVi sur la FedoraCore4 toute neuve de Thomas.
Ca a l'air de fonctionner mais j'ai du faire des ``bricoles''
pour eviter des erreurs dues, semble-t-il, aux optimisations
du compilateur (GCC 4.0.0) !!! Oui je sais ca parait etonnant
mais je vois apparaitre des comportements etranges en passant de
-O1 a -O2 (et j'utilise -O3). Il semblerait qu'il se loupe quand
du code inline utilise d'autre code inline... Il est a noter que,
justement, l'optimisation a ete entierement remaniee dans GCC 4 !
Une analyse avec `valgrind' ne me reporte aucune erreur avant
celles qui semblent etre dues a l'optimisation !!!
J'ai donc bricole pour eliminer les erreurs que j'ai constatees
sur les exemples mais il se peut tres bien qu'il y en ait
d'autres ailleurs. Donc je ne sais pas trop quoi faire ...
si ce n'est juste vous recommander de diminuer le niveau
d'optimisation si vous constatez un comportement etrange
avec ce compilateur...
Juste la correction d'un petit probleme avec une extension OpenGL qui posait probleme sur les Geforce 6XXX. Un petit bug egalement dans Grid3D
Vite fait la nouvelle version d'AReVi. Quelques modifs pour les systemes x86_64. Il y avait une ambiguite sur les `long' qui font 32 ou 64 bits selon le systeme. En revanche les `int' font toujours 32 bits et les `long long' font toujours 64 bits. J'ai donc supprime l'usage des `long'. Il serait peut etre bien d'utiliser les entiers normalises POSIX (int32_t, uint32_t...), qu'en pensez vous ? En ce qui concerne les performances, la meme machine en x86_64 semble plus rapide qu'en x86 (je ne vois absolument pas pourquoi ?!?!) mais un peu moins en rendu (driver/X11 moins au point ?) Une ShapePart3D peut maintenant avoir un ShapePartRenderer qui court circuite son procede de rendu par defaut. Le ShaderProgram (qui contient un VertexShader et un FragmentShader) en est un cas particulier (le seul pour l'instant en fait ...). Sinon dans le genre ``la science avance'' on peut visualiser en wireframe et bounding-box chaque Object3D individuellement (et pas seulement les scenes completes). Il y a un diagramme de classes a peu pres a jour a la fin de la documentation (si j'ose m'exprimer ainsi).
Sur ma page une nouvelle version d'AReVi Il y a eu pas mal de modifs dont certaines sont visibles. Tout d'abord, d'un commun accord avec les membres de l'equipe AReVi, j'ai remplace partout ou c'etait possible les ``float'' par des ``double''. En effet le melange de ces deux representations impliquaient des conversions frequentes. Les calculs mathematiques ne sont pas plus ni moins long en ``float'' qu'en ``double'', les conversions en revanche coutent du temps. De plus si j'en suis arrive la c'est initialement a cause de problemes de precision numerique (intersection d'un tres petit triangle avec un tres grand par exemple). J'ai constate une legere amelioration des performances de l'ensemble donc personne ne sera fache. Au niveau des ``ShapePart3D'' on peut maintenant controler si on souhaite utiliser une display-list ou non. La plupart du temps la display-list ameliore grandement les performances (c'est donc le reglage par defaut) mais lorsque la geometrie est recalculee tres souvent la compilation de la display-list prend un temps non negligeable ; on peut la desactiver pour voir si on gagne du temps, en particulier si on utilise les vertex-array. A ce propos, j'ai revu le rendu des ``ShapePart3D'' afin d'utiliser des vertex-array (compiles qui plus est) si possible (un seul tableau d'index pour les coordonnees vertex, normal...). Avec tout ca, le programme ``testBumbing'' est passe de 25FPS a 75FPS ; bien entendu il correspond pile poil au cas que je cherchais a traiter (vertex-array regenere a chaque rendu). Pour les gens qui font de l'OpenGl ``a la main'' en definissant leurs propres ``ShapePart3D'' il y a de nouvelles regles a respecter : en plus de _rebuildIfNeeded() il faut fournir les methodes _setAppearance(), _drawGeometry() et_resetAppearance(). L'idee est d'appeler le meme code qu'on utilise ou non les display-list. En gros, _rebuildIfNeeded() doit recalculer les coordonnees/maillages si besoin et eventuellement reconstruire les display-list en appelant les trois methodes indiquees. La methode de rendu appele alors la display-list ou bien ces fonctions selon le reglage. Avec Thomas on a mis en place ce qu'il faut pour utiliser les vertex/fragment shaders de GLSL. Il ne s'agit pas d'un plugin puisque ca fait partie d'OpenGL (si la carte et le driver le supportent) ; a terme le plugin Cg devrait donc disparaitre (a moins qu'ils permette des choses impossibles avec GLSL). Je prefere largement GLSL a Cg car c'est normalise et independant d'un quelconque constructeur. En plus Thomas semble trouver ca plus clair. On branche a un ``ShaderProgram'' des ``VertexShader'' et ``FragmentShader'' qui sont initialises depuis une chaine, un flux ou une URL. On attribue alors le ``ShaderProgram'' a une (ou plusieurs) ``ShapePart3D'' aussi simplement qu'on attribue une texture. Voir l'exemple dans Tests/Lib3D : ./testShaders Ex/toonShader.fp Ex/toonShader.vp Ex/Hand.wrl Les classes ``Transform3D/Transform2D'' (et Util3D::Transform) ont maintenant un booleen qui indique s'il s'agit de l'identite. Ainsi les produits/transformations evitent des calculs inutiles et on evite aussi de transmettre des matrices identite a OpenGL. La methode isIdentity(bool) donne cette indication ; l'argument sert a indiquer s'il faut comparer la matrice a l'identite (les 0/1 au bon endroit) pour mettre a jour son booleen ou si on teste juste le booleen. A part quelques autres petites bricoles ca doit etre tout.
C'est une version de transition mais elle apporte néanmoins quelques corrections de bugs. - Ajout plugin pour sérialiser / désérialiser les humanoides dans un fichier (hLib humanoid : *.hlh) - Ajout plugin pour sérialiser / désérialiser les animations dans un fichier (hLib animation : *.hla) - Ajout d'un plugin Half Life (format de fichier SMD) (idée de Charles) - Ajout d'un outil pour convertir un fichier (ms3d, bvh, smd...) aux formats hlh & hla. Ca permet de parser les fichiers textes offline, et de les convertir dans un format de fichier binaire qui sera plus rapide à charger (idée de Charles aussi). L'outil se trouve dans le répertoire tools. - Possibilité de contraindre les articulations (1, 2 & 3 degrés de liberté), et de spécifier les limites angulaires (pas encore disponible avec les liaisons rotules). Ca sera utile pour la cinématique inverse. - Ajout d'un éditeur (pas fini) de contraintes. Il se trouve dans le répertoire tools. - Distinction entre keyframes absolues (smd) & relatives (ms3d, bvh, hLib) à une pose de référence. - Lors du chargement d'un squelette, le noeud racine est à l'origine (c'etait déjà le cas) mais maintenant, le squelette est orienté correctement. C'est à dire la tête suivant +z, et le regard suivant +x. L'éditeur n'est pas terminé et ne permet pas encore de spécifier les contraintes des liaisons rotules. Par contre il utilise les nouvelles fonctionnalitées des osd, ce qui permet de faire des petits éléments d'interface sympa par dessus la fenêtre de rendu. Pour télécharger c'est ici : http://www.enib.fr/~jourdan/hLib/
Sur ma page une nouvelle version d'AReVi Les OSD ont ete modifies et deplaces dans Lib3D (Thomas estime en effet que c'est maintenant profondement imbrique dans les Renderer3D, WindowInteractor ...) Des petites corrections de-ci de-la ... Une classe Grid3D qui gere une structure dynamique a temps d'acces constant pour reperer les objets du monde. L'interet est d'eviter de passer en revue 1000 objets pour se rendre compte qu'on n'a que deux voisins a traiter. Chaque objet est donc dans une case et les recherches ne se font que dans celle-ci et ses 26 voisines. Il va sans dire que le choix du pas de la grille a un role determinant sur les performances et doit etre ajuste avec soin. On peut bien entendu utiliser plusieurs grilles si on travaille a differentes echelles. L'exemple Lib3D/testGrid illustre son utilisation. Les performances de cet exemple sont limitees par le nombre de triangles des poissons. Si quelqu'un a des poissons avec tres peu de facettes je veux bien les adopter.
Une nouvelle version d'AReVi sur ma page
Le plugin AviRecorder est remplace par AudioVideoEncoder
qui fait la meme chose en video mais aussi de l'audio (B. Muguet).
Des petites bricoles de-ci de-la en particulier sur
l'introspection (ArClass/ArMethod/ArConstant ...)
Le truc nouveau c'est que j'utilise maintenant l'introspection
pour m'interfacer plus franchement avec TCL (La maniere de
faire precedente qui ne necessitait pas l'introspection est
toujours disponible).
Concretement au niveau de TCL je fournis les commandes suivantes
dans le namespace `AReViApp' :
::AReViApp::init appelle la fonction d'initialisation de
l'appli AReVi (comme avant)
::AReViApp::update appelle la fonction de mise a jours de
l'appli AReVi (comme avant)
::AReViApp::destroy appelle la fonction de fin de
l'appli AReVi (comme avant)
::AReViApp::makeConsole cree une console de saisie de commande
(type xterm) avec historique et
completion (nouveau)
::AReViApp::makeBrowser cree un browser pour parcourir les
classes AReVi (nouveau)
::AReViApp::invoke invoke une methode dans AReVi (nouveau)
::AReViApp::constant donne la valeur d'une constante definie
dans AReVi (nouveau)
Pour commencer simplement, si une classe Toto definie une constante
MACHIN (enum ou autre) on peut y acceder comme ca :
tcl> set machin [AReViApp::constant Toto::MACHIN]
Pour invoquer une methode :
tcl> AReViApp::invoke Viewer3D.1 translate -5 0 0
tcl> AReViApp::invoke Viewer3D.1 getPosition x y z
tcl> puts "x=$x y=$y z=$z"
...
Pour invoquer une methode statique :
tcl> set rate [AReViApp::invoke -static Renderer3D::getFrameRate]
nb: -static peut etre abrevie en -s, -st, -sta, -stat, -stati ...
re-nb: si vous avez tape -stati vous pouvez pousser jusqu'a -static ;^)
Pour invoquer un constructeur :
tcl> set viewer [AReViApp::invoke -static Viewer3D]
En gros pour AReViApp::invoke on a :
1er arg : -static ou un objet
2eme arg : methode, methode statique ou classe
arguments suivants : parametres de la methode
Pour le choix de la methode il peut y avoir des ambiguites
en cas de surcharge. J'adopte donc la demarche suivante :
- recherche de toutes les methodes (on constructeur) ayant
le nom indique et le nombre d'arguments passes
- s'il n'y en a qu'un --> aucune ambiguite
- s'il y en a plusieurs --> echec ! il faut indiquer le prototype
(le browser est bien utile ici)
Ca donne par exemple :
tcl> AReViApp::invoke Viewer3D.1 \
"getPosition(double &,double &,double &)" x y z
Forcement ... c'est plus long a taper ...
Concernant le browser, il peut aider ce genre d'operation. En
particulier si on clique sur une methode elle est ``copiee''
il suffit donc de ``coller'' dans la console pour eviter de
taper tout son prototype. De plus si on double-clique sur la
methode une fenetre montre sa declaration C++ avec le nom des
parametres afin d'avoir une idee de leur role.
Concernant la console le gros du travail concerne la completion.
Quand on fait `Tab' ou `Esc-Esc' elle propose des choix qui
dependent de ce qu'on est en train de saisir. On y trouve :
- la liste des commandes TCL
- la liste des variables globales TCL
- la liste des namespace TCL
- la liste des classes AReVi
- la liste des instances AReVi
(qui commencent par ce qu'on a tape bien sur ...)
De plus si on a tape un truc qui commence comme une classe
(Base3D:: par exemple) la completion propose les methodes
statiques et les constantes accessibles dans cette classe.
Encore plus fort maintenant : si le mot qui precede celui
qu'on tape designe une instance AReVi alors la completion
propose les methodes accessibles sur cette instance.
Du coup avec ca plus l'historique ca facilite grandement
les actions ``en ligne'' sur l'appli AReVi.
(Si ca s'appelle pas ``se casser le c..'' ca alors !)
Il y a un exemple dans Tests/Tcl qui fait marcher tout ca.
Bien sur c'est portable et tout et tout ...
Maintenant, si vous avez lu jusqu'au bout, j'ai un truc
a demander.
Certain utilisent des langages comme Perl, Python, Ruby, Lua ...
et seraient certainement interesses pour les interfacer egalement
avec AReVi. Donc j'ai deux proposition : une qui m'arrange,
une autre qui m'arrange moins mais qui m'interre tout de meme.
La premiere proposition serait que les personnes concernees
s'inspirent de ce que j'ai fait avec TCL pour faire la meme
chose avec leur langage (et me fournir le resultat bien sur !!!).
La deuxieme proposition c'est qu'ils m'expliquent comment
s'y prendre pour que je puisse le faire (en clair je n'ai pas envie
de passer mon temps a decouvrir les meandres de l'architecture
interne de tous ces langages).
J'attend les propositions...
Une nouvelle version d'hLib est disponible ici : http://www.enib.fr/~jourdan/hLib.tgz Les nouveautés en vrac : - script pour compiler et configurer hLib (comme arevi). Mais c'est pas fini, il faut que je vire encore des trucs dans les scripts a fabrice. - compatible avec la derniere version d'arevi uniquement - plus d'appel a hLib_Classes_register. Il faut maintenant faire hLibInit() & hLibDeInit() (définis dans include/hLib) - possibilité de sérialiser les humanoides (et donc de les cloner) - optimisations diverses (devrait être globalement plus rapide) - le loader est maintenant un singleton accessible par HLibLoader::access() ou get() - le loader gere un cache des fichiers chargés, comme pour les textures d'arevi - le loader supporte maintenant les liens symboliques vers les plugins - le loader determine l'extension du plugin en fonction de la plateforme - pour les KeyframeInterpolator -> la méthode interpolate(dt) est remplacée par evaluate(t), t étant une valeur entre 0 et la durée du mouvement. On peut donc jouer les mouvements à l'envers. - pour la cinématique inverse, on peut spécifier les buts (classe Goal) en position et orientation globale ou locale dans le repere du squelette - quand vous modifiez les attibuts d'un but, appeler la methode applyChanges du solveur d'IK pour prendre en compte les modifs - la translation du noeud racine des animations est extraite et renvoyée à l'utilisateur pour qu'il l'applique s'il en a besoin. Concrètement, si vous jouez un fichier de motion capture dans lequel le squelette se déplace, dans votre appli il fera du sur place si vous n'appliquez pas la translation manuellement ! - ajout d'une nouvelle classe MotionPath. Dans le cas d'une animation où le squelette se déplace (cf ligne du dessus), on peut remplacer la trajectoire par une nurbs quelconque. Quelques modifications sont apparues dans la dernière version d'AReVi : - Pour la classe Path, le parcours se fait maintenant à vitesse constante. Donc il n'y a plus de méthode pour ajuster la durée du chemin. La méthode Path::evaluate(t) prend un parametre entre 0 & 1 et non entre 0 & durée du chemin comme avant. - Il y a une classe FFD maintenant ! FFD c'est Free Form Deformation pour ceux qui ne se rappellent plus de leurs cours de RV. Y'a même un programme de test. Ca permet via une boite de déformation de transformer un maillage. Il est possible de composer les transformations de manière hiérarchique.
Une nouvelle version d'AReVi sur ma page. Il y a des corrections diverses, pas mal de nettoyage (petites incoherence par-ci par-la) et un nouveau truc. Commencons par les trucs qui fachent ... Pour ceux qui utilisaient mon bazar de callbacks automatiques, desormais il n'y a qu'un macro a utiliser au lieu de deux. Avant on avait BEGIN_CALLBACK_MANAGEMENT et END_CALLBACK_MANAGEMENT maintenant c'est juste AR_CALLBACK (allez voir AReVi/Lib3D/window3D.h vous allez vite comprendre). Ensuite pour fabriquer les plugins, avant on utilisait DYNLIB_TARGET dans le fichier configure, maintenant il y a PLUGIN_TARGET. En fait je viens de comprendre la difference essentielle qu'il y a entre une bibliotheque dynamique et un plugin sous MacOsX (pour les autres plateformes il n'y a pas de difference mais bon autant utiliser la bonne variable tout de suite en cas de portage ulterieur) Voila, j'espere que ca ne vous a pas trop fache ... Maintenant le truc qui fache moins ... Il y a un outil ``arstub'' qui genere ce qui va bien pour l'introspection/reflection des classes AReVi. Du coup dans ArClass il y a des ArMethod et des ArConstant ... Et, cherry on the cake, j'ai complete la doc pour que ca explique un peu tout ca ... Il reste a interfacer ca avec des langages de script et pourquoi pas faire un browser ...
Un nouvelle version d'AReVi sur ma page.
- Une classe Bumping : une ShapePart3D qui fabrique
un maillage a partir d'une carte d'altitude (texture
en niveaux de gris).
C'est une idee de P.A. Beal, merci bien.
- Possibilite d'ignorer certains degres de libertes
dans les attachement des Base3D.
C'est encore une idee de P.A. Beal, merci encore plus bien.
- Modifs au niveau des plugins de son, utilisation de ESD
(mixage en soft des differentes sources car toutes les
cartes/driver ne savent pas le faire en hard).
Il y a aussi la capture du son (micro).
Tout ca c'est fait par E. Cazeaux (qu'on ne remercie
meme plus tellement il fait de choses ;^) et B. Muguet,
merci egalement.
- Un nouveau concept qu'on n'avait jamais essaye mais je
sens que ca va tout revolutionner : on peut
activer/desactiver la repetition des touches dans une
Window3D (toute `r' du SimpleInteractor).
Oui je sais c'est gonfle comme idee mais il n'y a que
comme ca que la science avance.
- Des petites corrections par ci par la ...
Sur ma page une nouvelle version d'AReVi
- des modifs sur la distribution (E. Cazeaux)
- quelques corrections de petits bugs eparpilles ...
n.b. : Pensez a faire suivre aux etudiants/ingenieurs/stagiaires
qui travaillent avec vous.
Sur ma page une nouvelle version d'AReVi :
- corrections de bugs divers et varies (pas mal en fait ;^)
- possibilite de deformer/decaler la pyramide de vision
(pour des effets du genre mirroir ...)
- possibilite de polling en ecriture sur les TcpConnection
...
Il y a des vrais morceaux de David Herviou a l'interieur !
- les services sont decrits dans AReVi/Contrib/CgFilter.h
- voir l'exemple CgViewer/testStang dans Tests/Cg
Sur ma page, une nouvelle version d'AReVi.
Pas beaucoup de nouveautes :
- corrections de bugs, dont un qui pouvait influer
sur la performance,
- ca fonctionne sur les toutes nouvelles machines
(en fait le probleme venait de gcc 3.4 utilise dans
la Fedora installee sur celles-ci ; il est un peu
plus ``severe'' que les versions precedentes),
- Cyril Septseault a mis a jour son File3D,
- le texte 3D a ete completement reecrit. Maintenant
dans Tools/GLFontBuilder il y a un outil qui permet
de generer des fontes 3D a partir des fichiers
true-type. On n'est plus limite aux quelques fontes
3D que j'avais recupere avant. En particulier, il
y a les caracteres accentues, c'est pas mal pour
les demos.
Je pense qu'il n'y a aucune modification de code a faire
pour passer a cette nouvelle version.
Ce serait bien que chacun se mette a jour, en particulier
ceux qui doivent mettre une demo dans la salle noire.
Ainsi il n'y aura pas besoin de 72 versions d'AReVi sur
la machine.
Ce serait bien aussi que ceux qui travaillent avec des PFE,
stagiaires, ingenieurs, esclaves ... fassent suivre ce
message afin qu'ils se mettent a jour egalement.
En effet quand on vient me questionner sur AReVi je raisonne
sur la version la plus recente et j'ai parfois des surprises
en decouvrant que les problemes sont dus a quelque chose
qui a ete corrige depuis un moment.
Je vous rappelle egalement qu'il y a une documentation
(allez voir dans le Stang Alar) qui explique entre autre
le petit fichier ``configure'' qui calcule les dependances
et genere le makefile.
Je dis ca car j'ai vu il n'y a pas longtemps un PFE
qui s'embettait a modifier a la main un makefile genere
par un tel script alors qu'il suffisait d'ajouter un mot
dans le script en question.
J'ai mis a disposition une nouvelle version d'AReVi (20040928) qui a pour principal interet : - des corrections dans les scripts - une clarification autour de Transform3D (voir plus loin) - de la doc ... oui-oui j'ai bien dis de la doc La doc contient des corrections par rapport a la derniere fois et des nouveaux chapitres (annexes) qui expliquent l'installation d'AReVi, et l'utilisation des scripts configure. Donc ... plus d'excuses ! A propos de Transform3D il y avait une ambiguite. On ne savait pas si addTranslation(), addRotation() etc effectuaient des pre ou des post multiplication de la matrice. En fait c'etait des pre ! (oui je sais c'est bizarre) Donc maintenant j'ai renomme tout ca en preTranslate(), preRotate() etc et j'ai ajoute les methodes postTranslate(), postRotate() etc. Donc si vous utilisiez cette classe dans votre code il suffit de remplacer aveuglement les appels a add???() par les pre???() correspondant. C'est tout. Au fait, s'il y a des fautes ou des erreurs dans la doc, merci de m'en faire part.
Voici une nouvelle version d'AReVi.
Il y a un changement dans la denomination qui sert par la meme
occasion de numero de version:
- Le nom de repertoire doit comporter AReVi_????m??d??
indiquant dans l'ordre l'annee le mois et le jour
(les ? sont donc des caracteres numeriques)
- Les lettres 'm' et 'd' permettent de differencier
clairement a la lecture par un humain lequel des deux ??
est le mois et lequel est le jour
(dependant des conventions FR, US, UK ...)
- J'ai choisi l'ordre annee-mois-jour pour que l'affichage
se fasse dans l'ordre chronologique (ls ...)
- Ces trois valeurs numeriques sont recuperees par le script
arevi-config et forment un grand entier qui correspond
au numero de version
(ici 20040917, voir ``arevi-config --version'')
- Quand on compile, il y a desormais une macro AR_VERSION
qui a cette valeur. De plus la methode ArSystem::getVersion()
renvoie le numero de version de la bibliotheque AReVi compilee.
(il y a donc moyen de tester et comparer les numeros de version,
et bien sur l'ordre croissant correspond a l'ordre chronologique)
Concernant les scripts ``configure'' j'ai fait une petite modif.
- Desormais tout ce qui est au-dessous de la ligne
``build-makefile'' est recopie a l'interieur du makefile (plutot
vers le debut). Il n'y a donc plus de ``cat >> "EOF"''.
(il y a un ``exit'' a la fin de ``build-makefile'' afin que le
shell ignore la suite)
- Ainsi les passes ``flex/bison'' ou le preprocesseur ``moc''
(pour Qt) peuvent generer leur fichier avant que les dependances
soient calculees.
(avant je faisais a chaque fois un cas particulier !!!)
Thomas a ajoute une class Path (dans AReVi/Contrib) qui permet
de parcourir un chemin dans l'espace defini par un ensemble
de points de passage. Il y a de plus un repertoire Tools/PathEditor
qui propose un magnifique outil graphique pour generer ces chemins.
- une librairie d'animation d'humanoides Elle permet le chargement de modèles 3D animés (plugins Milkshape3D & Biovison pour le moment, hanim bientot), l'animation par cinematique directe ou inverse. - des chemins 3D Ca utilise les Nurbs d'Eric. L'utilisateur specifie des points de passage, ainsi que l'orientation associée & la durée de parcours. La classe trouve la courbe qui va bien pour sur tous les points. Cela permet de definir des chemins pour des caméras (pour vos demos par exemple), ou encore des chemins pour les humanoides... Je fournis un editeur de courbes avec. Le chemins 3D seront certainement inclus dans la prochaine version d'AReVi mais la librairie d'anim restera (je pense) à part. Si certains veulent tester maintenant, j'enverrai le source a la demande.
Sur ma page une nouvelle version d'AReVi.
Quelques changements :
- Les lancers de rayons permettent de remonter la
ShapePart3D de l'objet trouve (besoin Thomas).
- L'ordonnanceur peut faire du polling et declancher
des traitements lorsque des descripteurs de fichiers
evoluent (evite l'attente active).
- L'ordonnanceur temps reel ne consomme plus de ressources
inutilement en attendant la date de declanchement
de la prochaine activite. Le processus est endormi
pendant un petit temps (c'est lie au point precedent)
ce qui permet a la machine de ``respirer'' un peu.
Bien entendu c'est hors de propos en temps virtuel
(je repond par avance aux questions debiles ;^)
- Pour des raisons de portabilite en ce qui concerne
l'edition de liens dynamique, il est maintenant
obligatoire d'enregistrer les classes au lancement de
l'application. Concretement les macros AR_CLASS_DEF
et AR_CLASS_NOVOID_DEF fournisent une fonction
register_XXXX_Class() (XXXX etant le nom de la classe)
qu'il faut appeler en debut d'application (apres
l'initialisation d'ArSystem). Heureusement, pour
eviter d'ecrire tous ces appels a la main, il y a
un moulinette register-classes qui genere automatiquement
un fichier avec une unique fonction qui appelle toutes
les autres. Voir l'exemple Tests/Lib3D/configure
a propos de Tests/Lib3D/testUser.
testUser_FILES="testUser.cpp MyExt/myShape3D.cpp \
MyExt/myShapePart3D.cpp"
testUser_CLASSES="${LIBDIR}/register-classes userClasses.cpp \
:: registerUserClasses"
La variable testUser_CLASSES va provoquer la generation
de la fonction registerUserClasses() dans le fichier
userClasses.cpp. Cette fonction appelera toutes les fonctions
register_XXXX_Class() des classes definies dans les fichiers
designes par testUser_FILES. Le :: indique que ces classes
ne sont definies dans aucun namespace, sinon on indique
le namespace a cet endroit.
Bien entendu on n'est pas oblige de se servir de cette
moulinette ; dans de nombreux exemples je n'ai qu'une
ou deux classes que j'enregistre directement.
- Le lien avec Tcl et Java se fait maintenant en embarquant
l'application AReVi sous forme de plugin pour le langage
en question. Du cote de Java ca resoud pas mal de problemes
d'initialisation et de portabilite (pas tous malheureusement).
Voir les exemples Tests/Tcl et Tests/Java.
Sur ma page il y a l'AReVi du 9 juillet.
- File3D charge different formats de fichiers 3D (C. Septseault)
- La vision stereo fonctionne bien pour notre salle
(voir le fichier joint, il est aussi dans Vrac/stereo.txt)
Vous trouverez sur ma page la toute derniere version, d'AReVi (23 juin 2004). Comme nouveautes il y a essentiellement des contributions d'Eric Cazeaux, notamment la distribution et les nurbs.
J'ai mis a disposition sur ma page perso une nouvelle version d'AReVi. Je ne l'ai pas fait dans le CVS car il est en panne. J'ai fait des petites modifs par ci par la dans AReVi au fur et a mesure de la redaction de la doc. De plus j'ai incorpore des choses soumises par Thomas Jourdan et Eric Cazeaux. La doc dans son etat courant (loin d'etre finie et jamais relue) est dans Vrac/areviGuide.pdf Bon maintenant j'arrete pour un petit moment et je ne repond plus aux questions ... il faut que je fasse un cours de reseau pour la semaine 9 (c'est tres bientot !!!)
Je viens de mettre a disposition la derniere version
d'AReVi (04mar2004), sur le CVS et sur ma page.
Il y a eu pas mal de modifs en interne ...
Voici un resume non exhaustif des modifs ``visibles''
- Gestion des Shape3D/ShapePart3D :
- Les ShapePart3D sont des primitives qui constituent
les Shape3D.
- Il est bien sur possible d'en inventer de nouvelles
avec des vrais morceaux d'OpenGL dedans.
(voir Tests/Lib3D/MyExt/MyShapePart3D.cpp)
- Les VrmlShape3D existent toujours mais ne reposent
plus sur un cambouis interne ; elles utilisent les
ShapePart3D fournies. Les VrmlInteractors sont
toujours disponibles.
- Gestion des textures
- Avant les textures n'etaient pas reifiees pour
l'utilisateur (en interne elles l'etaient).
- Maintenant on a URLTexture, DataTexture et RenderTexture
(generee par un TextureRenderer3D)
- Justement, a propos des Renderer3D ...
- Avant on avait seulement Viewer3D, maintenant
on a Renderer3D, Window3D, EmbededWindow3D, Viewer3D
et TextureRenderer3D.
- Les interactions avec les Window3D ont ete simplifiees
et afinees. (voir SimpleInteractor)
Il y a surement d'autres bricoles mais je ne sais plus quoi ...
La toute derniere version d'AReVi (26jan2004) est disponible sur ma page et sur le CVS. Il n'y a rien de transcendant ... - ca fonctionne sous FreeBSD 5.2 - les makefiles ont disparu !!!!!! En fait ils ont ete remplaces par des scripts ``configure'' qui se chargent de generer les makefiles. Pour l'utilisateur, ces scripts sont plus simples a editer que les makefiles, il suffit de positionner quelques variables et ca roule. Le repertoire ``Tests/Make'' donne un exemple complet du procede en question. Il fabrique d'un seul coup 2 executables, 2 bibliotheques et 2 plugins, chacun ayant ses propres options de compilation/lien, histoire de montrer comment ca marche en general mais pour un cas concret c'est beaucoup plus clair (voir les autres exemples). D'une maniere generale, pour construire AReVi (et les exemples) il suffit de faire depuis la racine: $ ./armake conf # invoquer les divers scripts ``configure'' $ ./armake # compiler AReVi et les plugins $ ./armake tests # compiler les exemples # ./armake install # installer dans /usr/local ou encore la sequence habituelle: # ./configure ; make ; make tests ; make install De toutes facons c'est indique dans le README
!!! Attention !!! Je viens de corriger un bug severe que j'avais introduit dans la version du 20/11/03 !!!
Nouvelle version d'AReVi sur ma page et sur le CVS Le changement principal pour vous est une correction de bug dans le XmlParser (merci a Eric Cazeaux) qui entraine une modification de l'usage de cette classe (voir Eric pour les explications).
Il y a sur ma page une version d'AReVi (12_11_03) qui a pour principal interet d'integrer les diverses contributions qui m'ont ete proposees (XmlParser, AviRecorder, Text2Speech ...) Ce serait bien que ceux d'entre-vous qui utilisent AReVi (y compris les PFE) passent a cette version car cela eviterait de dependre des portions de code qui sont a l'origine de ces ``contributions'' mais qui s'echangeaient ``sous le manteau'' et qui necessitaient dans modifications locales d'AReVi ...
Ca y est, AReVi se promene en liberte dans le cyber-monde ...
http://www.enib.fr/~harrouet/