CR du GT visualisation du 24/03/05

Différentes présentations ont été faites durant ce groupe de travail :

Présentation de différentes interactions 3D par Jérôme Grosjean (LSIIT-IGG).
Présentation des librairies VR Juggler, Net Juggler et FlowVR par Bruno Raffin et Jérémie Allard (INRIA Rhônes-Alpes, laboratoire ID-IMAG, projet APACHE). Net Juggler permet l'exécution d'applications VR Juggler en environnement multi-projecteurs sur grappe de PCs, tandis que FlowVR est un middleware pour la distribution d'applications interactives sur grappe ou grille permettant le couplage de codes parallèles et un contrôle fin de la cohérence entre les flux de données.
Présentation d'une nouvelle librairie de visualisation distribuée pour environnements immersifs (Reality Center, CAVE, ...) par Xavier Cavin et Christophe Mion (Loria, projet ISA) permettant d'effectuer en autres de la visualisation volumique de données temporelles.

Présentation de Jérôme Grosjean : « interactions 3D » (slides de la présentation)
Différents points sont à prendre en considération dans le cadre de l'interaction en Réalité Virtuelle :
- le problème de l'immersion,
- l'espace de manipulation et de visualisation sont confondus,
- le plongement dans l'univers,
- la visualisation stéréoscopique.
Il existe différentes contraintes au niveau de l'équipement. En effet, l'équipement doit être amené dans l'espace virtuel et ne doit donc ne pas être encombrant (on ne peut avoir un clavier à 102 touches par exemple, mais seulement 2/3 boutons à notre disposition). Il y a ainsi un équilibre à trouver. De plus, au niveau de l'interface, celle-ci ne doit pas obstruer la scène.

Il existe énormément d'équipements différents : certains sont tenus en main (stylo avec des formes d'outil) ou d'autres sont portés (clavier sur le bras).

Il faut au final dissocier trois types de tâches d'interaction :
- La navigation : déplacement dans la scène
  - La marche : la vue s'adapte, mais elle est limitée à la taille de la salle (utilisation de tapis roulant pour y remédier).
  - Le poste de conduite : l'environnement se déplace mais l'utilisateur reste immobile (volant, cockpit).
  - Le déplacement virtuel : sélection de la destination (téléportation), manipulation de caméra, accélération + destination.
- La sélection/manipulation : désigner un objet et le déplacer, modifier la taille de l'objet
  - La main : main virtuelle (avatar de la main) : Go-Go gadget, bi-manuel.
  - Un pointeur : permet de désigner des objets :
    - stylo,
    - sphère de sélection pour une plus grande facilité,
    - lancer de rayons prolongeant le doigt de l'utilisateur (l'objet est «embroché», mais augmente l'erreur),
    - cône de sélection avec un débattement contrôlé par l'utilisateur,
    - différentes échelles dans la scène : les objets éloignés deviennent proches (on devient plus grand), association d'une scène de taille normale et d'une petite scène dans laquelle la sélection est réalisée.
- Le contrôle d'applications : tâches de type menu, déclenchement d'une action
  - Gestion des menus
    - son, parole pour donner des ordres ;
    - sélection gestuelle (permet de mémoriser les menus) ;
    - menu graphique (reprendre les menus 2D et les mettre dans la scène 3D, utilisation de paradigmes 3D) : problème de la taille avec une résolution souvent insuffisante.
  - Sélection : normalement une tâche 1D, mais on est en 3D (dimensions gênantes, utilisation de fenêtres flottantes)
  - PDA : retour au problème 2D
  - menu en forme d'anneau : spin menu, C3, Tulip.

Présentation de Bruno Raffin et Jérémie Allard : «FlowVR» (slides de la présentation)
- Utilisation de composants standards
  A partir de 1995, dans le domaine du calcul parallèle, les machines propriétaires de type Cray ont été remplacées par de nouvelles machines parallèles, les grappes de PCs, combinées à un réseau de communication désormais performant.
  
  A partir de là, l'objectif était alors de transposer ceci dans le monde de la Réalité Virtuelle, en remplaçant les Onyx fort coûteuses, par des grappes dédiées au graphisme. De même, les projecteurs Barco ont été peu à peu remplacés par des vidéos-projecteurs moins coûteux. Cette évolution matérielle permet de passer à l'échelle en terme de coût (plus facile d'acheter plusieurs vidéos-projecteurs) et de plus le matériel a le mérite d'être renouvelé plus rapidement (processeurs Intel en perpétuelle amélioration, alors que SGI, trop spécialisé, ne suit pas).
  
  De plus dans le monde de la Réalité Virtuelle, il est nécessaire de pouvoir utiliser des ports PCI/USB pour pouvoir employer les derniers «gadgets », or ceci est problématique pour les machines SGI. C'est pourquoi, l'utilisation de composants standards est primordiale dans le domaine de la RV.
- Logiciels intelligents
  Il est alors nécessaire de concevoir des logiciels intelligents, devant compenser ce qui n'a pas encore été réalisé en usine ou au niveau matériel :
  - calibrage des couleurs pour les vidéos-projecteurs,
  - Sofgenlock : synchronisation des signaux vidéos (genlock) pour faire de la stéréo active. Ce logiciel est associé à une plaque à construire comprenant quelques composants électroniques.
  - NetJuggler / ClusterJuggler : permettent de dupliquer une application VR Juggler sur une grappe de PCs en utilisant ou non la couche de communication MPI pour diffuser les événements de trackeurs. Le swapock est alors employé pour synchroniser les swaps des noeuds de la grappe.
  - WirGL / Chromium : permettent de distribuer les primitives graphiques d'une application sur différents noeuds.
- Verrous actuels
  Les applications ne sont pas encore à la hauteur des équipements. C'est pourquoi il est nécessaire de réaliser une couche logicielle. La difficulté réside alors dans l'aspect modulaire des applications, pour pouvoir réutiliser des codes existants.
- Applications distribuées avec contraintes de temps réel
  L'objectif réside dans la réalisation d'une plate-forme couplant différents codes parallèles et notamment dans le couplage d'applications distribuées ayant des contraintes de temps réel.
  
  Il faut alors considérer d'une part les temps de latences (faibles) et d'autres part les taux de raffraîchissements (élevés). Différentes politiques de communications peuvent être par ailleurs considérées : FIFO (First In First Out), communications collectives, ...
- Environnements existants
  - Middleware (couches de communication) : CORBA, PADICO
    Mais ces codes sont complexes, coûteux, et ne proposent que des schémas de communications FIFO.
  - Environnements parallèles : PVM, MPI, OpenMP
  - Visualisation scientifique : OpenDX, VTK
    Ces environnements débutent seulement au niveau parallèle.
  - Environnements de RV : VR Juggler, OpenMask, Chromium
    Ces bibliothèques emploient souvent des politiques FIFO dans le sens où seul le dernier événement reçu est récupéré (les autres sont jetés). Par contre la problématique du couplage de codes parallèles n'est pas encore abordée dans ces environnements.
- FlowVR
  Au sein de l'environnement FlowVR, une application est vue comme un ensemble de modules reliés entre-eux par un réseau. Chaque module est alors défini par des ports d'entrées et des ports de sorties, et l'utilisateur défini de plus les connections qui existent entre les différents modules de l'application.
  
  Il est de plus possible de définir des noeuds de routage au sein de l'application, permettant de modifier la configuration initiale en utilisant notamment différents filtres permettant de gérer la politique de communication.
  
  Ensuite il est également possible de rajouter des synchronisations entre les différents modules.
  
  Les filtres doivent obligatoirement être codés en C++, par contre les modules peuvent être codés en Fortran, en C, en Java, ... Il est également possible d'employer des estampilles et d'effectuer des compromis sur la cohérence des synchronisations.
  
  A partir de là, il ne reste plus qu'à exécuter le graphe de flots de données ainsi défini.
  
  A noter que le lancement de l'application est décrite via un fichier XML autorisant tous types de lancement (mpirun, atharun, ...).
  
  Le graphe de flots de données est également changé à l'exécution selon le nombre de noeuds employés. Chaque module FlowVR est ensuite vu comme un processus, et les messages sont stockés dans une mémoire partagée.
  
  Par ailleurs, il est également possible de coupler l'application à des systèmes haptiques.
- FlowVR Render pour la phase de rendu
  Les objets graphiques sont décrits au sein de la boucle de rendu (coordonnées des points, couleurs, textures, shaders, ...). Il est ainsi possible d'utiliser différents viewers.
  
  Il est ensuite possible de paralléliser la phase de rendu, soit en distribuant les primitives graphiques aux différents noeuds, soit en distribuant les événements.
  
  Les primitives graphiques définissent les shaders employés (paramètres, données : IndexBuff, ...), puis seules les mises à jour sont diffusées.
- Vidéos issues de la plate-forme GrImage :

Présentation de Xavier Cavin et Christophe Mion : «DViz2 » (slides de la présentation)
L'objectif est de faire de la visualisation distribuée haute-performance sur la grille (Globus, DataGrid, Grid 5000), c'est-à-dire de globaliser les cartes graphiques disponibles en utilisant des réseaux haut débit (VTHD++) ou bien d'employer les réseaux locaux des laboratoires associés à un cluster de PCs (grille de taille réduite).

Le Loria dispose notamment de 5 noeuds bi-Pentium IV et de 16 noeuds de calcul, d'un CAVE (en cours de construction) et d'un Reality Center.

Les applications visées concernent notamment des applications de décomposition de domaine où un maillage est décomposé en plus petits domaines.

L'objectif est alors d'effectuer à la fois les calculs et la visualisation sur la grille.
- DViz2
  La librairie DViz2 offre un binary swap optimisé (la méthode du binary swap consiste à décomposer le volume de données initial en différents fragments, pour faire en sorte que chaque noeud effectue seulement une partie du rendu final ; une recomposition de l'image est ensuite réalisée pour obtenir ce dernier).
  
  Au niveau de la phase de rendu, de nouvelles primitives sont utilisées (primitives cylindres).

Menu

CR du GT visualisation du 24/03/05