Grenoble meeting
See What was planned ?
Séminaire du 10/11 janvier 2007
Personnes présentes
- CIMIT (Boston) :
- Stéphane Cotin(scotin@partners.org)
- Jérémie Allard (jeremie.allard@imag.fr)
- ALCOVE (INRIA Lille, LIFL) :
- Christian Duriez (christian.duriez@inria.fr),
- Pierre-Jean Bensoussan (pierre-jean.bensoussan@lifl.fr)
- ASCLEPIOS (INRIA Sophia Antipolis) :
- Hervé Delingette (herve.delingette@inria.fr)
- François Poyer (francois.poyer@sophia.inria.fr)
- EVASION (labo LJK) :
- François Faure (francois.faure@imag.fr)
- Laure Heigeas (laure.heigeas@imag.fr)
- Matthieu Nesme (matthieu.nesme@imag.fr)
- Cesar Mendoza (cesarmendoza_serrano@yahoo.fr)
- Michael Adam (michael.adam@imag.fr)
- IRCAD (Strasbourg) :
- Clément Forest (Clement.Forest@ircad.u-strasbg.fr)
- MOAIS (labo ID) :
- Bruno Raffin (bruno.raffin@imag.fr)
- Everton Hermann (everton.hermann@gmail.com)
Fichiers d'entrée
- .XS3 utilisé par ASCLEPIOS : format non XML décrivant un sytème masse-ressort sans norme connue
- Liste des formats nécessaires : .OBJ, format volumique DICOM, .XML
- Jérémie propose de mettre en place une "RessouceFactory" afin de pouvoir charger mais aussi convertir en différents format (RessourceOBJ, RessourceXS3, RessourceXML)
- Michaël nous présente 2 formats de fichiers XML :
- .PML, physical model file
- .LML, forces et contraintes appliquées à l'objet au court du temps, tel un scénario
- = > convertisseur de .OBJ vers .PML et .LML : librairie GPL de TIMC (FF: quoi, il y a un convertisseur ?)
- (Michaël : ) Réponse à FF : Oui, dans les Tools de la lib fournie par Mahnu il existe :
Plugin :: SOFA :: pour Maya
- Graphe maya : Mesh --> SofaNode --> Collision Group <-- Grid <-- Mesh
- Mesh maya passée à :: SOFA :: : un pas de temps + collisions
- Maya récupère le Mesh et l'affiche
(Maya est un soft payant : 2000$ par machine environ)
Topologie
- Hervé présente son travail sur la topologie : voir avec Stéphane comment mettre tes slides sur le web ?
MMVR, 06/02/2007
- Mettre le papier sur le web (Stéphane)
- Démo
- Vidéo sur la chirurgie de l'oeil, proposée par Stéphane. Francois s'occupe du ray-tracer pour modéliser l'outil de découpe (découpe sur les "edges", collision sur les surfaces).
- Si cette démo marche bien, tentre de la faire en temps réel mais scriptée (.LML)
- Vidéo sur la laparoscopie
- Rajout d'un ressort sur l'outil pour amortir (Christian + Pierre-Jean)
- Y animer tous les organes (intestin ?)
- Exemples de l'article MMVR implémentés, commentés dans les tutoriaux (Laure)
SIGGRAPH, 05-09/08/2007
- Condition pour un stand INRIA
- Hervé, est-on seul ?
- Si non, une vidéo peut-elle suffire ?
- Si oui :
- Beau rendu : OGRE ou ...
- Interaraction temps réel
- Collision robuste avec retour haptic
- Flyer pour donner au gens : qui le fait ?
Paraléllisation
- Jérémie présente les slides du séminaire : voir avec Stéphane comment mettre tes slides sur le web ?
Rendu Inventor
- François F. fait une démo :: SOFA :: avec Inventor
- intérêt de l'éditeur de graphe de scene pour changer les "Fields" de chaque "Component"
- Mise en évidence de l'utilité d'exporter de la géométrie des VisualModel pour la visualiser dans différents moteurs de rendu
Licence pour la release
- Une version release : séparer le coeur de :: SOFA :: des modules, i.e. les "components"
- Stéphane attend la réponse de l'INRIA Rocquencourt via Sylvain Karpf (Chargés du développement et des relations industrielles, Lille)
- Une version fermée, celle en développement : :: SOFA :: DEV
- La release :
- Coeur = arbre, action (LGPL)
- Modules = GPL et LGPL
- Appli Qt = GPL
- Jérémie présente le découpage :
-
.../sofa/doc/*-sourcefiles.txt
-
.../sofa/doc/counts.txt
- A faire pour la release (Laure, d'ici le 26/01/2007)
- Pour la release et la dev
- Réorganiser les répertoires et les namespaces (suite aux discussions du wiki Namespaces)
- Core
- Module = component + simulation
- Application = GUI
- Renommer les fichiers data
.../sofa/Data/ et les .../sofa/src/Projects/ (François P. doit y rajouter le projet : DemoMatrixTest)
- Librairie compilée avec un seul projet : SofaQt (ex example1)
- Puis permettre à chaque répertoire Projects, Tutorials, CallStack d'être compiler à part
- Pour la release
- Faire du ménage (dont
.../sofa/doc/) : liste de ce qui est dans la release (Jérémie, peux-tu nous préciser la liste ?)
- Vérifier les dépendances pour la release :
-
.../sofa/Data/
-
.../sofa/src/Projects/
-
.../sofa/src/Tutorials/
-
.../sofa/src/CallStack/
Documentation
- Stéphane : comment faire pour que qqu'un prenne facilement le code en main ?
- Documenter les fichiers de scene
.../sofa/Data/*.scn : les différents "components" et "fields" associés
- Sur le wiki : expliquer les degrès d'abstraction : voir les "dynamic_cast dans "Factory"
- Organisation
- Documentation développeur
- Doxygen
- chacun commente son code (François F., Pierre-Jean (Core), Jérémie, César (Collision))
- Une version doxygen release archivée aussi sur le web et une pour la version dev sur le dashboard [1]
- A l'aide du code "Factory", établir une hierarchie descendante des classes (Jérémie)
- CallStack : exemple du papier MMVR (Laure)
- Documentation utilisateur sur le wiki
- Tutoriaux sur le wiki [Sofa Tutorials]
- Composition progressive d'une scene (Pierre-Jean)
- Exemples MMVR à commenter et à mettre sous forme tutorielle (Laure)
- Howto [GetStarted]
- Structures générales + action (François F.)
- Concepts mécaniques (Christian)
- Archives : slides de conférences, réunions, articles, vidéos, screenshot de conférence...
- ScreenShots
- ToDowload : archive à télécharger contenant doc développeur + doc utilisateur
- Réorganisation du Web par Stéphane (avant MMVR) :
- voir comment on peut charger d'autres formats de fichiers sur le wiki (.txt, .cpp, .h, .pdf,...)
- changer la page d'accueil, le menu et les pages telles "Documentation"
Boucle d'animation
- Christian : un tableau de bord pour contrôler la boucle d'animation, notamment pour avoir plus de souplesse pour le calcul de collisions
- Etude de
.../sofa/doc/callStackOneFixedSpring.h
- = > remplacer AnimateAction::processSolver() par une nouvelle classe Stepper::update(dt) ou Animator::update(dt)
- solver->integrate() puis DetectionCollision->process()
- cette classe similaire à BehaviorModel : une seule par GNode et prend le pas sur le solver
- exemples de BehaviorModel dans
.../sofa/src/Projects/ : Fluid eulérien de Jérémie et myNewBehaviorModel.zip
MechanicalObject, MechanicalDOF, MechanicalState ?
- Christian parle de l'architecture qu'il a implémenté pour les points de contact
- linear complementarity problem (LCP) : voir avec Stéphane comment mettre tes slides sur le web ?
- rajout dans les DOFs des contraintes telles les forces (qui y sont déjà représentées)
- Renommer MechanicalObject en MechanicalDOFvoire en MechanicalState... (On a fini par valider MechanicalState)
- (réflexion a posteriori de FF, à valider par Christian:) L'approche de Christian permet de représenter une hiérarchie d'objets mécaniques: des particules accrochées à un objet rigide. C'est différent de l'approche actuelle qui représente des hiérarchies de modèles (méca, collision...) d'un même objet. Les deux approches sont complémentaires et cela pourrait déboucher sur deux hiérarchies distinctes. Discussion à poursuivre sur le forum ?
P'tits changements d'architecture
- Changer la façon dont on décide "float" ou "double" : mettre un champ dans le "context"
- "Simulation" devient une classe à part entière, objet qu'on passe à une GUI, au lieu d'une classe factice avec des méthodes statiques
- GUI
- QGLViewer (Pierre-Jean après MMVR)
- DockWindow pour le "controller" au lieu du "viewer" (Laure après MMVR)
- Fields à éditer dans le graphe de scene (Laure après MMVR)
Meeting hebdomadaire
- Mercredi 15h30-16h00
- Comment pluguer un écran sur la visioconf ? (Laure)
|