Modélisation multi-échelle procédurale de scènes animées
Frank Perbet - 2004/04/25

next up previous contents
Next: A. Exemple du cube Up: main Previous: 7. Dynamic Graph :

Sous-sections



8. Conclusion


8.1 Discussion

8.1.1 Une modélisation par entité

8.1.1.1 Un langage descriptif ``constructif''

Dynamic Graph propose un langage décrivant la construction d'un modèle. Ce type de description permet notamment une représentation très compacte. On peut prendre ici la métaphore du corps humain : représenter naïvement sa structure prend une place mémoire énorme. En revanche, on peut stocker une simple cellule souche et simuler la construction du corps. La molécule d'ADN est en quelque sorte une compression du corps humain.

Les générateurs d'amplifieurs jouent un rôle similaire aux règles de construction de la molécule ADN. Le modèle est le plus possible réduit à sa paramétrisation minimale. On peut voir la modélisation avec Dynamic Graph comme une compression manuelle dans une base de fonctions extrêmement variées.

8.1.1.2 Structure continue

Les règles de construction imposées par Dynamic Graph sont bien particulières : les amplifieurs sont stockés dans un arbre d'évaluation. Ceci impose des relations de dépendance très strictes : un amplifieur n'a qu'un seul parent. La précision est ajoutée de façon élémentaire : par exemple, les éléments «branches» sont ajoutés à l'élément «enveloppe». Dans le cas du modèle d'arbre présenté dans le chapitre précédent, cette décomposition est assez simple. Dans d'autre cas de nature plus continue, c'est moins évident.

Dans le modèle d'arbre présenté dans la section 7.3, le tronc est une structure continue unidimensionnelle. La gestion de la précision d'une telle structure n'est pas prise en charge par Dynamic Graph : ce sont les super-cylindres qui gèrent cela de façon autonome. Le problème serait le même pour un terrain : Dynamic Graph est incapable de faire mieux que les algorithmes existants.

Dans le cas de structures continues, Dynamic Graph n'est donc pas très adapté. En revanche, rien n'empêche d'intégrer des algorithmes dédiés (de simplification par exemple) au sein d'un amplifieur. Pour pouvoir utiliser l'algorithme de visibilité de Dynamic Graph, il faut cependant que ces algorithmes permettent d'afficher la structure en plusieurs étapes, de l'avant vers l'arrière.

8.1.1.3 Entité distincte

Même s'il est possible d'intégrer localement des structures continues, Dynamic Graph impose une sorte de décomposition stricte. Il est envisageable d'assouplir les relations de dépendance. Par exemple, on pourrait imaginer non plus un arbre d'évaluation, mais un graphe sans cycle : un amplifieur aurait plusieurs parents.

Néanmoins, le c\oeur de Dynamic Graph se base sur une entité très autonome : l'amplifieur. Cette approche va complètement à l'encontre d'un univers régi par des particules élémentaires et des lois simples. La modélisation avec Dynamic Graph consiste initialement à identifier des phénomènes et à les représenter individuellement. Par construction, les mondes de Dynamic Graph sont très peu interconnectés : un arbre d'une forêt ignorera tout de ses voisins.

Cette localisation des phénomènes me semble être le prix à payer pour un algorithme efficace.


8.1.2 Trop de choses à la fois

Comme tout outil, Dynamic Graph impose une certaine conception de la modélisation. C'est en quelque sorte le squelette d'un objet qu'il faut saisir, et non son apparence.

8.1.2.1 Deux sortes d'animations

Modéliser l'ajout de précision est finalement très similaire à la modélisation de l'animation. Le ``mouvement'' multi-échelle est induit par les mouvements de la caméra, alors que le ``mouvement'' de l'animation est induit par l'écoulement du temps. Mais conceptuellement, il s'agit dans les deux cas de paramétrer convenablement le modèle afin d'exhiber les degrés de liberté pertinents. Le créateur doit donc imaginer un mécanisme capable de deux mouvements simultanément :

Est-ce que cette double quête est tout le temps possible ? Cela n'a rien d'évident au premier abord. Les mécanismes nécessaires à l'animation peuvent très bien aller à l'encontre de ceux nécessaires aux changements d'échelle. Heureusement, dans ces deux types de mouvement, une certaine marge de manoeuvre est permise.

8.1.2.2 L'animation influence la multi-échelle

Il n'existe pas qu'une seule façon d'ajouter de la précision à un objet. Par exemple, pour les arbres, on aurait pu choisir de représenter le feuillage dans son ensemble et indépendamment des branches. Mais il aurait été alors difficile de rendre compte du mouvement induit par les branches. En revanche, il aurait été peut-être plus facile de réaliser des opérations globales telles que des feuilles qui tombent en automne.

Il est clair que le choix des niveaux de détail influence les possibilités d'animation. Selon les besoins, on peut préférer une représentation particulière. On regrettera éventuellement qu'un modèle ne soit pas plus polyvalent. Il me semble que c'est le prix à payer de toute modélisation par complexification : le créateur, avant de commencer un modèle, doit déjà plus ou moins savoir les traitements qu'il veut lui faire subir. En conséquence, il choisira les niveaux de détail adéquats aux besoins de l'animation.

8.1.2.3 La multi-échelle influence l'animation

Les mécanismes d'animation modélisés avec Dynamic Graph ne cherchent pas le réalisme à tout prix. Une approche phénoménologique permet de mimer un certain nombre de comportements dans la mesure du possible. Pour éviter lorsqu'on le peut une description au niveau le plus fin, des phénomènes émergents sont identifiés et décrits globalement (comme les bourrasques de vent).

Cette approche simpliste permet d'animer des modèles complexes. Par exemple, les bourrasques de vent de la prairie animent de la même façon les niveaux 2.5D et 3D. Après la conception du modèle inanimé, on récupère en quelque sorte les degrés de liberté : il est facile ``d'en faire quelque chose''. En conséquence, le créateur choisira les méthodes d'animation en fonction des niveaux de détail du modèle.

8.1.2.4 Le juste milieu

Le rôle du créateur est donc de jouer entre les fonction d'animation et de transition pour arriver à ses fins. Il n'y a pas de règle précise ici, et c'est certainement là le point commun à tout acte de création. Néanmoins, la marge de man\oeuvre est peut-être finalement assez étroite. Essayez de trouver un autre modèle de prairie animé sous le vent... La démarche, au bout du compte, est très naturelle.


8.1.3 Une création délicate

8.1.3.1 Trop difficile ?

En décrivant un modèle par des générateurs d'amplifieurs, celui-ci est décrit par une méthode de construction bien particulière : la précision est progessivement ajoutée au modèle. N'est-ce pas trop demander au créateur que de lui imposer une telle conception de l'objet ?

Tout d'abord, il est évident que Dynamic Graph peut encore être énormément amélioré. Notamment, une interface graphique augmenterait beaucoup l'ergonomie du programme. Malheureusement, je vois mal à quoi peut ressembler une interface graphique assurant une expressivité aussi grande que celle requise par Dynamic Graph. Mais mettons de côté cette implémentation particulière et abordons la question du point de vue général de la complexification.

8.1.3.2 Quelques exemples

Enrico Coen [Coe00] prend l'exemple d'un peintre qui réalisait ses oeuvres en commençant par une version très grossière et en ajoutant progressivement de la précision. La figure 8.1 montre les différentes étapes de la modélisation d'un chat réalisé dans le cadre du travail de recherche de Philippe Decaudin [Dec96]. Ces exemples sont bien entendu en faveur de l'hypothèse d'une conception par complexification facile.

Figure 8.1: Exemple de modélisation dont les opérations pourraient très bien être enregistrées puis rejouées selon la précision. Remarquez que ce modèle n'a pas été réalisé spécialement pour l'occasion : c'est la preuve que dans certain cas, une modélisation multi-échelle est naturelle.
\begin{figure}\begin{center}
\input{chats.pstex_t}\end{center}\end{figure}

Néanmoins, soyons honnêtes, ces exemples ne sont pas la majorité. J'ai un jour demandé à un utilisateur de Maya expérimenté s'il modélisait habituellement du plus grossier au plus fin. Par chance, il était en train de créer un personnage et avait gardé la liste de toutes les opérations depuis le début du modèle. Quand il les a rejouées devant moi, j'ai beaucoup douté de ma thèse... Le modèle semblait commencer par le pied droit et remonter la jambe, puis le corps et les bras et enfin la tête.

Ici, de nombreux arguments peuvent étayer le débat. Tout d'abord, un utilisateur, dans une certaine mesure, s'adapte à un outil. Ensuite, il est tout simplement possible d'imposer une certaine ``discipline'' au créateur en forçant une modélisation du plus grossier au plus fin. En effet, pourquoi ne pas limiter les mouvements de caméra : le créateur ne s'autorise à zoomer que s'il est satisfait de lui à l'échelle courante.

8.1.3.3 Ordre des opérations

Enfin, on pourrait envisager des méthodes de ``remise en ordre'' : les opérations que réalise le créateur seraient triées de la plus grossière à la plus précise automatiquement. Mais il semble très difficile de briser des relations de dépendance pour les relier de manières différentes.

La seule façon de faire cela à mon avis serait d'utiliser des opérations plus simple et d'imposer un certaine certaine représentation visuelle, tel que le maillage. Mais cela va à l'encontre de la grande force de la modélisation procédurale : sa grande expressivité. On est encore une fois confronté au dilemne entre expressivité et automatisme. Ces deux caractéristiques semblent être quasi-antinomique.


8.2 Perspectives

8.2.0.1 Modélisation par complexification

La modélisation par complexification porte bien son nom : d'une part elle propose une description de forme visible par ajout de détails (la forme se complique), d'autre part elle utilise des langages descriptifs procéduraux, c'est-à-dire complexes. L'utilisation de langages très expressifs pour décrire des scènes tridimensionnelles permet des variations d'échelles inégalables. De plus, et c'est peut-être le plus important, l'animation est permise.

Mais il ne faut pas se voiler la face : la modélisation par complexification, et la modélisation procédurale en général, demandent beaucoup d'efforts de la part de l'utilisateur. Dynamic Graph propose de simplifier cette tâche et dans l'ensemble, il y parvient. Les performances, les modèles obtenus et les retours utilisateurs de deux intervenants extérieurs amènent un bilan dans l'ensemble très positif.

8.2.0.2 Vers une interface graphique

Néanmoins, l'interface reste essentiellement textuelle. La question se pose : est-il possible de créer une interface graphique intuitive pour assister la modélisation procédurale ? J'en suis convaincu, mais le travail est colossal. En fait, compte tenu de l'expressivité nécessaire à une telle interface, sa réalisation est équivalente à celle d'un environnement graphique pour le développement. Ceci entraîne une nouvelle interrogation : est-il possible de supprimer (ou en tous cas de réduire) le texte des environnements de programmation ?

Dans bien des cas, cette question revient à se demander s'il est possible de supprimer le texte de votre éditeur de texte favori... Pourtant, le langage textuel n'est pas inhérent à la programmation, il n'est qu'un moyen de permettre à notre intelligence de s'exprimer et de la pérenniser au sein d'un circuit électronique. D'autres moyens sont possibles, ils restent à inventer.

8.2.0.3 Trop ambitieux ?

L'avenir de la modélisation par complexification est incertaine : son utilisation prend à revers la plupart des méthodes traditionnelles. Notamment, ne pas connaître la scène a priori peut décourager de nombreux utilisateurs potentiels. Pourtant, j'ai la conviction que Dynamic Graph montre la bonne direction : la modélisation et le rendu de scènes tridimensionnelles animées avec de grandes variations d'échelle doivent forcément passer par une modélisation procédurale multi-échelle.

Néanmoins, même s'il montre la bonne direction, Dynamic Graph me semble au bout du compte assez prétentieux. En effet, pourquoi s'attaquer au problème posé par la multi-échelle animée tridimensionnelle alors que le cas 2D est largement suffisant pour dégager les principales difficultés ? J'irai encore plus loin : la réalisation de Dynamic Graph et sa mise en pratique m'ont convaincu que beaucoup de travail reste à faire dans le cas unidimensionnel !

Remarquons ici qu'un programme est finalement représenté par un tableau $1D$ de caractères8.1. Une application évidente d'une étude de la multi-échelle procédurale dans le cas $1D$ est une interface graphique pour un environnement de développement. Par deux chemins différents, nous retombons sur la même conclusion.

Je pense qu'une telle réalisation compte parmi les défis scientifiques majeurs actuels et qu'elle sera la motivation d'un pont essentiel entre la synthèse d'image et l'interaction homme-machine.



Notes

... caractères8.1
Un programme est généralement visualisé, il est vrai, en deux dimensions.

next up previous contents
Next: A. Exemple du cube Up: main Previous: 7. Dynamic Graph :
Frank Perbet
2004/04/25