BuildAppOMK

Un article de OpenMASKWiki.

Jump to: navigation, search

Ce document est une introduction à la définition d'une nouvelle application OpenMASK, soit par réutilisation de composants existants, soit par programmation de nouveaux composants .

Sommaire

Introduction à OpenMASK

OpenMASK (OMK) est une plateforme de Développement et d'exécution d'applications en Réalité Virtuelle : applications immersives, interactives, collaboratives, multi-sensorielles, distribuées, etc...

Machine virtuelle générique, extensible et distribuable

OpenMASK est perçu par le programmeur comme une machine virtuelle unique assurant le fonctionnement et les communications de différents objets de simulation. Seul l'expérimentateur perçoit et définit le déploiement des objets en différents processus sur différentes machines réelles.
Les composants de base d'OpenMASK sont les objets de simulations. On distingue les classes simples OSO (OMK::SimulatedObject) et les classes extensibles ESO (OMK::ExtensibleSimulatedObject). OpenMASK définit ses propres types de données afin d'y associer de nouvelles propriétés [1] et [2].
Un OSO dispose d'entrées [3], de sorties [4] et de paramètres de contrôle [5]. Il manipule également des évènements [6].
Mais actuellement nous vous encourageons à programmer systématiquement des ESO pour bénéficier des extensions et des attributs.
Les paramètres d'un ESO sont principalement des attributs [7] et [8]. Ceux ci peuvent se décliner en entrée, en sortie ou encore être associés à un évènement. Ces associations peuvent éventuellement être déclarées dans le fichier de configuration.
Les extensions pour ESO (EDO) sont définies par dérivation de classes d'extension OMK (OMK::Extension). Une extension peut être spécifique à un objet de simulation ou bien générique. Dans ce dernier cas elle peut étendre tout type d'objet.

Plateforme pour la réalité virtuelle

Nous avons utilisé OpenMASK pour des applications de réalité virtuelle et développé en conséquence un ensemble de classes d'objets spécifiques.
Notre architecture d'application est inspirée du modèle PAC (Présentation-Abstraction-Contrôle) et organisée autour d'une ou plusieurs Cabines Virtuelles d'Immersion et d'Interaction (CVII ) Nous considérons trois parties dans une application de réalité virtuelle interactive :

  • le monde virtuel à investir
  • les (ou l'unique) utilisateurs avec leurs outils réels ou virtuels
  • les services de rendus des propriétés de la scène globale.

OpenMASK propose des services pour chacun de ces trois constituants d'une application de réalité virtuelle.
La scène globale est la scène virtuelle constituée du monde virtuel à investir et des nouveaux objets virtuels (ou avatars) liés aux éventuelles représentations des équipements de rendus, des utilisateurs et de leurs outils d'interaction.
Le monde virtuel est d'abord considéré à un niveau abstrait. Dans OpenMASK, il sera constitué d'un ensemble d'objets de simulation communicant entre eux par des flots de données ou des événements. Ce monde virtuel inclus dans la scène globale ne sera perçu par les utilisateurs qu'après le travail des services de rendus.
Une Cabine Virtuelle d'Immersion et d'Interaction gère de façon cohérente l'immersion de l'utilisateur et de ses outils dans le monde virtuel à investir. Cette CVII permet aussi de décrire à l'initialisation l'ensemble des équipements de rendu et d'interaction associé à un site de travail d'un ou de plusieurs utilisateurs. La connaissance des équipements par la CVII permet à l'utilisateur et à ses partenaires une meilleure perception d'eux même de leurs équipements.
Le premier service de rendu développé pour OpenMASK 4 a été le service de rendu visuel Ogre. L'architecture de ce premier développement a permis de définir une classe générique de gestion d'un service de rendu qui peut s'adapter au rendu de la plupart des propriétés concrètes des objets abstraits. Cette classe a, en plus des mécanismes générique d'extension d'OpenMASK, son propre mécanisme d'extension par objets de service et par animateurs . Actuellement le nom de la classe générique des services est toujours (OMK::Vis::VisBase), celui des objets de service (OMK::Vis::VisualObject) et celui des animateurs (OMK::Vis::Animator) mais ces classes peuvent servir à construire tout type de service.

Architecture PAC

L'architecture fonctionnelle d'OpenMASK est inspirée du modèle PAC -Présentation, Abstraction, Contrôle.
La présentation est constituée des différents OSO de services de rendu (ou service de présentation).
Le contrôle est constitué du noyau d'OpenMASK avec sa machine de communication, et des OSO gérant les outils d'interaction.
L'abstraction est constituée des OSO gérant les propriétés fondamentales du monde virtuel à investir.
Dans l'exemple simple, constitué d'un cube attaché à un autre cube, lui même étant contrôlé par les déplacements de la souris VRPN, on aurait le découpage suivant :

  • Présentation : OSO visualiseur gérant l'objet visuel de chacun des deux cubes
  • Abstraction : OSO trajectoire, OSO SupportedObject du 1er cube et OSO ARTSupportedObject du 2eme cube
  • Contrôle : noyau OMK, OSO Client VRPN délivrant la position de la souris (valeurs x, y entre 0 et 1) et un filtre transformant deux infos analogiques en une position OpenMASK

Dans ce cas, l'abstraction se résume à définir et contrôler une position dans l'espace.
Cet exemple est disponible dans le répertoire Samples\1Basic-tests\architecture-PAC. Il faut lancer un serveur VRPN pour la souris. Puis en coursz de session, si vous bouger votre souris sur l'écran de votre station, le cube va bouger lui aussi.

Modularité par plugin

Dans ce document, un composant est une classe dérivée des classes d'objets de simulation (OSO ou ESO) ou des classes d'extensions pour des objets extensibles (EDO). Nous considérons également comme composant des classes de visual objects ou des classes d'animators pour un OSO-visualiseur, et de façon générique tout objet de service et animateur de service de tout service de rendu.
Un ensemble choisi de classes de composants peut être compilé en une bibliothèque dynamique C++ (.dso ou .dll) que nous appelons plugin.
Une application OpenMASK est définie en décrivant dans un fichier de configuration les différentes instances de composants la constituant. Une procédure principale de référence lit ce fichier, crée les objets de simulation et lance la simulation.

Les anciens utilisateurs d'OpenMASK pourrons lire un résumé des différences entre la version 4 et la version 3 sur cette page.

Nouvelle application OpenMASK

Afin de privilégier la réutilisation de code, nous fournissons une application de référence qui construit votre application à partir d'un fichier de configuration :

OMKReferenceApplication2 -o config.omk

En général, une application OpenMASK est donc définie par un fichier de configuration.
Seuls certains cas, bien particuliers de cohabitation avec d'autres logiciels ne pouvant pas être gérés dans un plugin, vous obligeront peut être à construire une nouvelle procédure principale pour votre application, en remplacement de l'application de référence.

Vous serez donc face à deux situations pour construire une nouvelle application OMK :

  • soit vous trouvez vos besoins dans les classes existantes d'objets réutilisables. Il vous suffira alors d'écrire votre fichier de configuration.
  • soit vous devrez programmer de nouvelles classes qui seront enregistrées dans un nouveau plugin OMK, afin de vous retrouver dans le cas précédent.

Réutiliser : Fichiers de configuration

Le premier niveau de construction d'une nouvelle application OpenMASK est atteint en sachant construire un nouveau fichier de configuration qui fait appel à des classes d'OSO existantes.

Fichiers .omk

Nous utilisons un format maison spécifique, analysé par une procédure ANTLR.
Vous pourrez découvrir rapidement l'usage et l'écriture des fichiers de configuration via un tutoriel dans cette page : DecouverteRapideOMK.

Un système de traçage de l'exécution est disponible et contrôlable via le fichier de configuration. Une description des services de trace existants (TraceFile, TraceAll, TraceIds) est faite dans cette page [9].

Classes d'objets OMK réutilisables

Les classes d’objets OMK sont accessibles dans des librairies dynamiques C++ que nous appelons plugin OMK. Ce sont des classes de tout type de composants OpenMASK (OSO, ESO, extensions OMK, visual objects, animators).
Vous trouverez dans la documentation en ligne les informations décrivant les plugin existants proposés par notre équipe.
Nous rassemblons dans la page wiki suivante des informations sur les différents composants réutilisables connus d'OpenMASK. Vous y trouverez également une descriptions de classes intéressantes pour les applications de réalité virtuelle comme le visualiseur Ogre (OgreVisu) ou la cabine virtuelle d'immersion et d'interaction (CVII).

Créer : Programmation OpenMASK

Toute programmation d'un nouveau composant OpenMASK doit être inclus dans un nouveau plugin.

Plugin OMK

Un plugin OMK est une librairie dynamique C++. Un plugin OMK peut contenir différents composants OMK.
Un plugin doit être construit selon le modèle OMK de plugin qui est définit dans la bibliothèque OBT [10].

  • Voici une proposition d'organisation d'un nouveau plugin OMK et la recette de personnalisation du squelette fourni : BuildNewPlugin
  • Voici la version anglaise d'intégration d'un nouveau "package" dans la distribution officielle d'OpenMASK : AddNewPackage

Programmation basique

Une fois votre plugin défini, il vous faudra programmer chaque composant OpenMASK.
Bien sûr vous écrirez du C++ mais il est primordial de penser d'abord "API OpenMASK". En particulier, vous devez exclure tout appel de méthode C++ entre deux composants OpenMASK car lors du déploiements ils peuvent se retrouver dans des processus différents. Par contre, au sein d'un composant, vous avez tout liberté pour le réaliser en autant de classes C++ que vous le souhaitez. Celles ci seront toutes appelées depuis les méthodes propres du composant référentiel et ne pourront en aucun cas être un bais pour communiquer avec un autre composant OpenMASK.
Les notions à maîtriser sont principalement la classe d'objet de simulation extensible, la classe d'extension et les attributs. Nous vous proposons une introduction aux composants Openmask et une liste de séquences types de programmation :

Vous pourrez utiliser et compléter le service de trace d'exécution proposé par OpenMASK : voir cette page [11].
Vous veillerez à réaliser une documentation en ligne avec Doxygen et éventuellement compléter les pages du wiki OpenMASK.

Programmation d'un service de présentation

Le service de visualisation a été bâti sur un ensemble de classes de base qui pourraient être ré-utilisées pour construire de nouveaux services, non seulement visuels mais aussi de sonorisation, de physique, etc ... Nous proposons donc un squelette de spécialisation de ces classes de base pour démarrer la construction d'un nouveau service (NEWVis).
NEWVis peut donc effectivement être utilisé pour programmertout type de nouveau service de présentation. Il propose uniquement les classes devant être spécialisées. Il s'appuie sur des classes génériques du package Vis du noyau OpenMASK.
Le squelette est présenté sous forme d'un plugin OMK : OMKBaseNewServ-Plugin . Pour le spécialiser, vous consulterez sa documentation en ligne et les pages wiki correspondantes.
L'application de test (A-Serv_mini dans config-tests) affiche la trace de passage dans les différentes méthodes des nouvelles classes spécialisées d'ESO, de VisualObject et d'Animator.

Programmation participative pour la réalité virtuelle

Du fait que nous utilisions OpenMASK pour des applications de réalité virtuelle immersives, interactives et collaboratives, nous avons développé des ensembles de services (cvii, interaction, ...) qui ont leurs propres règles de programmation. Si votre nouveau composant s'intègre ou communique avec ces services, vous devrez respecter leurs règles de programmation.

Navigation