• Aucun résultat trouvé

Repr´ esentation de l’information contenue dans la sc` ene statique

CHAPITRE 5 SOLUTION PROPOS´ EE

5.2 Repr´ esentation de l’information contenue dans la sc` ene statique

Tel qu’expliqu´e au chapitre 2 dans la probl´ematique de notre projet, ce dernier est effectu´e en parall`ele avec un autre projet inclus dans le projet global GITAN. Celui-ci a pour but de g´en´erer, `a partir d’une description de sc`ene exprim´ee dans le format de repr´esentation abstraite pr´esent´e `a la section 5.1, une sc`ene statique en 3D comportant les objets n´ecessaires `

a l’animation de celle-ci. Consid´erant cela, la g´en´eration en parall`ele d’un plan d’animation `

a partir de la mˆeme description de sc`ene est un projet ind´ependant, mais requiert tout de mˆeme d’obtenir une petite quantit´e d’information de la sc`ene statique. Nous pr´esentons donc un format de repr´esentation simple permettant de transmettre cette information d’un projet `

a l’autre.

5.2.1 Information n´ecessaire

D’abord, il est n´ecessaire de d´efinir l’information `a repr´esenter par ce format. En effet, toutes les informations pr´esentes dans la sc`ene statique 3D ne sont pas utiles `a notre projet. Nous avons donc choisi de cr´eer un format simple de transmission de l’information afin de garder le processus d’analyse le plus efficace possible.

Dans le but de pouvoir g´en´erer un plan d’animation `a partir d’actions sur les objets de la sc`ene, il est d’abord n´ecessaire de connaˆıtre l’identit´e de tous les objets pr´esents dans la sc`ene. Certains d’entre eux, souvent les plus importants par rapport au d´eroulement de la sc`ene,

sont d´ej`a pr´esents de mani`ere conceptuelle dans la description de sc`ene. Par contre, d’autres ont pu ˆetre ajout´es dans la sc`ene pour plusieurs raisons dans le processus de g´en´eration de la sc`ene statique et ces objets doivent aussi ˆetre connus. Une de ces raisons peut ˆetre la n´ecessit´e de la pr´esence d’un objet pour assurer le fonctionnement d’un autre. Par exemple, pour effectuer l’action de boire de l’eau, celle-ci doit ˆetre contenue dans un contenant tel un verre ou une tasse. Bien que ces objets pouvaient ne pas ˆetre mentionn´es dans la description conceptuelle de la sc`ene, ils sont primordiaux `a son d´eroulement. D’autres raisons peuvent aussi justifier l’ajout d’objets dans la sc`ene, comme l’association courante entre deux objets (exemple : une chaise se place normalement `a cˆot´e d’une table), ou simplement pour peupler la sc`ene dans un contexte r´ealiste (exemple : ajouter des meubles pour repr´esenter l’int´erieur d’une maison). En cons´equence, la liste des objets pr´esents dans la sc`ene statique ne peut ˆ

etre d´eduite directement de la description conceptuelle de la sc`ene et doit ˆetre obtenue du processus de g´en´eration de la sc`ene statique.

En plus de connaˆıtre l’identit´e des objets pr´esents dans la sc`ene, une seconde information doit ˆetre connue afin de pouvoir connaˆıtre suffisamment l’environnement dans lequel le pro- bl`eme de planification sera r´esolu. Cette information concerne la position spatiale relative de ces mˆemes objets. Cela signifie que, sans obtenir explicitement de l’information num´erique sur le positionnement des objets, nous devons connaˆıtre ce qui fait office de contrˆole pour chacun de ceux-ci. Le concept de contrˆole, initialement d´efini par l’ontologie GUM-Space, pr´e- cise deux types distincts : le support (Support ) et le confinement (Containment ). `A quelques exceptions pr`es, tous les objets de la sc`ene doivent poss´eder un contrˆoleur unique, c’est-`a-dire soit un ´el´ement servant de support physique (exemple : une table soutenant une assiette) ou un ´el´ement pouvant le contenir (exemple : une boˆıte contenant des jouets). Lorsque le place- ment spatial des objets est effectu´e dans le processus de g´en´eration de la sc`ene statique, les objets se retrouvent obligatoirement contraints `a une relation de contrˆole avec un autre ´el´e- ment de la sc`ene. Cette information doit aussi nous ˆetre transmise afin de pouvoir connaˆıtre l’interaction entre les objets de la sc`ene et ainsi ´eventuellement en d´eduire des fonctionnalit´es. 5.2.2 Format

Le format que nous proposons est `a nouveau bas´e sur le langage XML et comporte une structure tr`es simple puisque l’information `a repr´esenter l’est ´egalement. Il consiste en une liste des objets pr´esents dans la sc`ene, pour lesquels est sp´ecifi´e leur contrˆoleur respectif. L’exemple de la figure 5.5 illustre la repr´esentation d’une boˆıte et d’une balle dans une sc`ene. L’´el´ement XML de base pour repr´esenter un objet de la sc`ene est object. Chaque objet est repr´esent´e par un identifiant unique (id ) et par sa classe dans notre ontologie des objets du monde (class). Cette logique suit celle de la repr´esentation de la sc`ene pr´esent´ee `a la

Figure 5.5 Repr´esentation XML d’objets de la sc`ene statique

section 5.1. Dans l’exemple pr´esent´e, nous pouvons constater la pr´esence de trois objets de types respectifs Ball, Box et Floor. Pour le premier objet (ball ), le contrˆoleur sp´ecifi´e r´ef`ere directement au deuxi`eme objet (box ) par son identifiant. Le type de contrˆole est ´egalement sp´ecifi´e comme ´etant de type Containment, ce qui signifie que le premier objet se retrouve confin´e par le deuxi`eme objet. Ce deuxi`eme objet (box ) poss`ede lui aussi un contrˆoleur r´ef´erant au troisi`eme objet (floor ) et indiquant que ce dernier est de type Support. Concr`etement, l’information obtenue `a partir de cette description indique qu’une balle est `a l’int´erieur d’une boˆıte, qui se retrouve elle-mˆeme sur le plancher. Nous pouvons remarquer que le troisi`eme objet (floor ) ne poss`ede pas de contrˆoleur. En effet, le sol ´etant la base physique de nos sc`enes, aucun contrˆole n’est n´ecessaire dans ce cas.

Ce format de repr´esentation combine simplicit´e et efficacit´e pour la description concep- tuelle des objets de la sc`ene statique. Sa similarit´e avec le format de repr´esentation concep- tuelle abstraite est aussi un avantage qui simplifiera le processus d’analyse des informations de la sc`ene pour la formulation du probl`eme de planification. Aussi, par souci de rigueur, un sch´ema de validation XSD a ´egalement ´et´e produit pour ce format de repr´esentation. Il est disponible `a l’Annexe B.