BuildNewServ

Un article de OpenMASKWiki.

Jump to: navigation, search

Ce document est une introduction à la programmation d'un nouveau service de présentation.

Sommaire

Introduction

Un service de présentation est un objet de simulation extensible qui prend en charge un service de rendu visuel, sonore, physique ou autre, pour tous les OSO de l'application. Cet OSO est soit connecté aux autres OSO par des flux de données, soit à l'écoute de leurs messages. Le service transforme des propriétés abstraites d'un OSO en rendus concrets pour les utilisateurs.
Nous avons développé un premier service de présentation : le service de visualisation, spécialisé pour la bibliothèque Ogre 3D.
Nous pouvons constater que l'architecture de base de ce service pourrait convenir à tout service de présentation. Nous avons donc dégagé un ensemble de classes qui constitue un squelette de construction d'un service de présentation. Ce squelette est disponible dans le plugin OMKBaseNewServ-Plugin faudra spécialiser pour le service ciblé.
Les classes de ce squelette sont elles même des spécialisations de classes du package Vis OpenMASK.
Le nouveau service de rendu visuel basé sur OpenSG est une première ré-utilisation de ce squelette.

Architecture d'un service de présentation

Un service de présentation est un ESO OpenMASK, constitué d'une liste d'objets de service, eux même composés d'une liste d'animateurs. La communication entre un animateur et un OSO peut etre assurée automatiquement à l'exécution par un plug.

  • L'ESO gère globalement le service de présentation en lien avec les bibliothèques spécialisées du rendu ciblé.
  • Chaque objet de service concentre, en général, les relations avec un OSO de la simulation, dit partenaire.
  • Chaque animateur met en relation une propriété abstraite d'un OSO avec le rendu de la propriété concrête correspondante dans le service de présentation.

Création / destruction

La création et la destruction des objets de service et des animateurs sont basées sur la réception et le traitement d'évènements par les classes de base. Les listes d'objets de service et d'animateurs sont en général décrites dans le fichier de configuration associé à l'ESO du service de présentation. Cependant, il serait possible d'analyser des descriptions et d'envoyer les événements correspondants depuis tout autre OSO de la simulation. Cela pourrait faire l'objet de nouvelles extensions traitant un type de propriété d'un OSO en assurant la mise en relation automatisée avec le service de présentation correspondant.

Initialisation

Chaque composant d'un service commence par une phase d'initialisation :

  • L'ESO met en place l'initialisation du service de rendu ciblé dans loadParameters et éventuellement dans init
  • Chaque objet de service ajoute les paramètres globaux propres à un ESO partenaire dans son constructeur et dans readConfigurationParameters
  • Chaque animateur met en place ses paramètres de rendu dans son constructeur et doit décider des mécanisme de communication avec la (ou les) propriété(s) concernée(s) de l'OSO partenaire.
    • lorsqu'il n'y a qu'une propriété concernée, il est préférable de déléguer cette opération au mécanisme des plug (ConnectTo, ListenedEvent). Cela repousse le choix de mise en oeuvre à l'exécution.
    • dans les autres cas, le programmeur met en place son propre mécanisme de communication (entrée, événements).

Itérations

Le fonctionnement de chaque composant s'inscrit dans le fonctionnement fréquentiel ou itératif des OSO d'OpenMASK. L'essentiel des traitements spécifiques de rendu est réalisé par les animateurs. L'ESO et les objets de service ont un fonctionnement plus prédéfini.
A chaque pas de simulation :

  • L'ESO va donner la main à chacun de ses objets de services (comportement hérité de VisBase::computeParameters), puis éventuellement réaliser un traitement personnel dans son computeParameters
  • Chaque objet de service va donner la main à chacun de ses animateurs (comportement hérité de VisualObject::update), puis éventuellement réaliser un traitement personnel dans visualise
  • Chaque animateur spécialisé réalise la mise à jour de sa propriété concrète à partir des valeurs de la propriété abstraite :
    • si le programmeur s'appuie sur le mécanisme des plugs, il lui suffit de réaliser la concrétisation dans selfProcessVis (comportement hérité de Animator::processVis).
    • dans les autres cas il doit redéfinir la méthode processVis et y intégrer ses concrétisations.

Terminaison

Il y a un comportement automatisé hérité des classes de base :

  • l'ESO va détruire tous ses objets de service dans VisBase::finish
  • Chaque objet de service va détruire tous ses animateurs dans VisualObject::destructeur
  • Chaque animateur détruit son plug de communication dans Animator::destructeur

Chaque comportement peut éventuellement être complété par des destructions spécifiques à la classe.

Composants du package Vis d'OpenMASK

Ce package contient les classes de base, réutilisables pour programmer tout nouveau service de présentation. Mais, pour des raisons historiques, il contient aussi les classes du service de visualisation Ogre 3D. A terme, il serait utile de séparer ces deux groupes pour ne plus avoir à compiler OpenMASK avec Ogre lorsqu'on n'utilise plus cette bibliothèque graphique.
Les classes de base ont gardé leurs noms inspirés par le service de visualisation initial. Pour l'instant nous les conservons mais considérez qu'ils ont un sens plus général de "Présentation".

Classe VisBase

Cette classe met en place et gère les services d'événements pour la création et la destruction des objets de service (VisualObject) et des animateurs (Animator).

Classe VisualObject

Cette classe va gérer sa liste d'animateurs.
Tout visualObject peut déclarer dans le fichier de configuration une position initiale Position de type OMK::Type::Transform (ou Translate, Rotate (Euler) and Scale (Uniform ou 3 facteurs) )

Classes Animator et AnimatorT

Un animateur peut être typé ou non. Il hérite alors respectivement des classes de base AnimatorT <Type> ou Animator.
Plusieurs classes sont greffées autour des classes Animator(T) afin de répondre à la prise en compte de tout type d'attributs et tout type de communications (flots ou événements).

Plugs

La mise en oeuvre du mécanisme de communication peut être automatisé via la déclaration d'un plug dans toute nouvelle classe Animator(T).
Un plug gère deux types de communication selon la déclaration des paramètres de l'animateur dans le fichier de configuration :

  • flot de données : en fournissant le nom de l'OSO à connecter et le nom de son attribut
ConnectTo  ["mobile1" "Position"] 
  • evenement : en fournissant le nom de l'émetteur et le nom de l'événement. L'événement peut être valué ou non.
Emitter spot2
ListenedEvent OnOff-Light2
  • signal : si aucun nom d'émetteur n'est fournit, le service écoute tous les objets
ListenedEvent OnOff-Light1

Un seul de ces trois mécanismes est retenu selon l'ordre de présence des paramètres : flot - événement - signal.

Plugin de base à spécialiser

Le plugin OMKBaseNewServ-Plugin organise les spécialisations des classes de base du package Vis selon l'architecture de service de présentation que nous avons proposée.

Plugin à télécharger

OMKBaseNewServ-Plugin est un modèle de plugin à télécharger depuis la forge d'OpenMASK. Il fournit les sources de base et peut être construit via cmake. La compilation de ce plugin sans aucune modification fournit un service de présentation qui trace le passage dans les différentes méthodes des classes de l'architecture proposée. Un exemple de fichier de configuration est disponible dans le répertoire config-test/A-Serv-mini .
Pour le spécialiser, vous commencez par substituer les noms des classes par des noms plus suggestifs du service ciblé. Vous complétez les fichiers cmake pour intégrer les bibliothèques du service ciblé si nécessaire. Puis vous refaites le build et vous commencez à programmer .

Liste des classes à re-programmer

  • NEWVisOSO : l'ESO représentant le service ciblé.
  • NEWVO : une classe générique pour les objets de service du service ciblé. Cette classe servira ensuite de classe de base pour les différents types d'objets de service nécessaire au service ciblé. Vous avez un exemple d'une telle spécialisation avec la classe NEWVOunit.
  • NEWAnimator et NEWAnimatorT <T> : Deux exemples de classes génériques d'animateurs, dédiées au service ciblé, servant de classes de base à de nouveaux animateurs pour votre nouveau service. Un exemple d'une telle spécialisation est la classe NEWTransformAnimator.
Navigation