Une cr´eation d´elicate

Trop difficile ?

En d´ecrivant un mod`ele par des g´en´erateurs d’amplifieurs, celui-ci est d´ecrit par une m´ethode de construction bien particuli`ere : la pr´ecision est progessivement ajout´ee au mod`ele. N’est-ce pas trop demander au cr´eateur que de lui imposer une telle conception de l’objet ?

Tout d’abord, il est ´evident que Dynamic Graph peut encore ˆetre ´enorm´ement am´elior´e. No-tamment, une interface graphique augmenterait beaucoup l’ergonomie du programme. Malheu-reusement, je vois mal `a quoi peut ressembler une interface graphique assurant une expressivit´e aussi grande que celle requise par Dynamic Graph. Mais mettons de cˆot´e cette impl´ementation particuli`ere et abordons la question du point de vue g´en´eral de la complexification.

Quelques exemples

Enrico Coen [Coe00] prend l’exemple d’un peintre qui r´ealisait ses oeuvres en commen¸cant par une version tr`es grossi`ere et en ajoutant progressivement de la pr´ecision. La figure 8.1 montre les diff´erentes ´etapes de la mod´elisation d’un chat r´ealis´e dans le cadre du travail de recherche de Philippe Decaudin [Dec96]. Ces exemples sont bien entendu en faveur de l’hypoth`ese d’une conception par complexification facile.

N´eanmoins, soyons honnˆetes, ces exemples ne sont pas la majorit´e. J’ai un jour demand´e `a un utilisateur de Maya exp´eriment´e s’il mod´elisait habituellement du plus grossier au plus fin. Par chance, il ´etait en train de cr´eer un personnage et avait gard´e la liste de toutes les op´erations depuis le d´ebut du mod`ele. Quand il les a rejou´ees devant moi, j’ai beaucoup dout´e de ma th`ese... Le mod`ele semblait commencer par le pied droit et remonter la jambe, puis le corps et les bras et enfin la tˆete.

Ici, de nombreux arguments peuvent ´etayer le d´ebat. Tout d’abord, un utilisateur, dans une certaine mesure, s’adapte `a un outil. Ensuite, il est tout simplement possible d’imposer une certaine “discipline” au cr´eateur en for¸cant une mod´elisation du plus grossier au plus fin. En effet, pourquoi ne pas limiter les mouvements de cam´era : le cr´eateur ne s’autorise `a zoomer que s’il est satisfait de lui `a l’´echelle courante.

Ordre des op´erations

Enfin, on pourrait envisager des m´ethodes de “remise en ordre” : les op´erations que r´ealise le cr´eateur seraient tri´ees de la plus grossi`ere `a la plus pr´ecise automatiquement. Mais il semble tr`es difficile de briser des relations de d´ependance pour les relier de mani`eres diff´erentes.

La seule fa¸con de faire cela `a mon avis serait d’utiliser des op´erations plus simple et d’impo-ser un certaine certaine repr´esentation visuelle, tel que le maillage. Mais cela va `a l’encontre de la grande force de la mod´elisation proc´edurale : sa grande expressivit´e. On est encore une fois confront´e au dilemne entre expressivit´e et automatisme. Ces deux caract´eristiques semblent ˆetre quasi-antinomique.

8.2 Perspectives

Mod´elisation par complexification

La mod´elisation par complexification porte bien son nom : d’une part elle propose une des-cription de forme visible par ajout de d´etails (la forme se complique), d’autre part elle utilise des langages descriptifs proc´eduraux, c’est-`a-dire complexes. L’utilisation de langages tr`es expressifs pour d´ecrire des sc`enes tridimensionnelles permet des variations d’´echelles in´egalables. De plus, et c’est peut-ˆetre le plus important, l’animation est permise.

Mais il ne faut pas se voiler la face : la mod´elisation par complexification, et la mod´elisation proc´edurale en g´en´eral, demandent beaucoup d’efforts de la part de l’utilisateur. Dynamic Graph propose de simplifier cette tˆache et dans l’ensemble, il y parvient. Les performances, les mod`eles obtenus et les retours utilisateurs de deux intervenants ext´erieurs am`enent un bilan dans l’ensemble tr`es positif.

Vers une interface graphique

N´eanmoins, l’interface reste essentiellement textuelle. La question se pose : est-il possible de cr´eer une interface graphique intuitive pour assister la mod´elisation proc´edurale ? J’en suis convaincu, mais le travail est colossal. En fait, compte tenu de l’expressivit´e n´ecessaire `a une telle interface, sa r´ealisation est ´equivalente `a celle d’un environnement graphique pour le d´eveloppe-ment. Ceci entraˆıne une nouvelle interrogation : est-il possible de supprimer (ou en tous cas de r´eduire) le texte des environnements de programmation ?

Dans bien des cas, cette question revient `a se demander s’il est possible de supprimer le texte de votre ´editeur de texte favori... Pourtant, le langage textuel n’est pas inh´erent `a la programmation, il n’est qu’un moyen de permettre `a notre intelligence de s’exprimer et de la p´erenniser au sein d’un circuit ´electronique. D’autres moyens sont possibles, ils restent `a inventer.

Trop ambitieux ?

L’avenir de la mod´elisation par complexification est incertaine : son utilisation prend `a revers la plupart des m´ethodes traditionnelles. Notamment, ne pas connaˆıtre la sc`ene a priori peut d´ecoura-ger de nombreux utilisateurs potentiels. Pourtant, j’ai la conviction que Dynamic Graph montre la bonne direction : la mod´elisation et le rendu de sc`enes tridimensionnelles anim´ees avec de grandes variations d’´echelle doivent forc´ement passer par une mod´elisation proc´edurale multi-´echelle.

N´eanmoins, mˆeme s’il montre la bonne direction, Dynamic Graph me semble au bout du compte assez pr´etentieux. En effet, pourquoi s’attaquer au probl`eme pos´e par la multi-´echelle anim´ee tridimensionnelle alors que le cas 2D est largement suffisant pour d´egager les principales difficult´es ? J’irai encore plus loin : la r´ealisation de Dynamic Graph et sa mise en pratique m’ont convaincu que beaucoup de travail reste `a faire dans le cas unidimensionnel !

Remarquons ici qu’un programme est finalement repr´esent´e par un tableau 1D de caract`eres1. Une application ´evidente d’une ´etude de la multi-´echelle proc´edurale dans le cas 1D est une

interface graphique pour un environnement de d´eveloppement. Par deux chemins diff´erents, nous retombons sur la mˆeme conclusion.

Je pense qu’une telle r´ealisation compte parmi les d´efis scientifiques majeurs actuels et qu’elle sera la motivation d’un pont essentiel entre la synth`ese d’image et l’interaction homme-machine.

Annexe A

Exemple du cube de Sirpienski

Afin d’avoir une id´ee pr´ecise de ce `a quoi peut ressembler un mod`ele r´ealis´e avec Dynamic Graph, voici le code du cube de Sirpienski. Pour plus de renseignement sur cet outil, je vous renvoie `a la documentation en ligne sur http://www-evasion.imag.fr/∼Frank.Perbet/these.

A.1 Le g´en´erateur d’amplifieurs

Voici le g´en´erateur d’amplifieurs que le cr´eateur doit ´ecrire. Une fois la phase de cr´eation ou de modification termin´e, ce bout de code est compil´e et charg´e `a la vol´ee durant l’´ex´ecution de Dynamic Graph. class ty_square: public ty_drawableNodeBase { public: // square size ty_float size; // branching order ty_uint branchingOrder; // color vec3 color; public:

// constructor without ancestor ty_square::ty_square(

ty_pt_nodeBase pt_father, ty_localID li,

const ty_uint& _branchingOrder, const ty_float& _size,

const vec3& _color, ty_repere initialRepere): ty_drawableNodeBase(pt_father,li,createDefaultNodeContainer(), initialRepere,ty_sphericalBB(_size)), branchingOrder(_branchingOrder), color(_color), size(_size) { // Nothing

}

// constructor with ancestor ty_square::ty_square(

ty_pt_nodeBase pt_father, ty_localID li,

ty_nodeBase& _ancestor,

const ty_uint& _branchingOrder, const ty_float& _size,

const vec3& _color, ty_repere initialRepere): ty_drawableNodeBase(pt_father,li,createDefaultNodeContainer(),_ancestor, initialRepere,ty_sphericalBB(_size)), branchingOrder(_branchingOrder), color(_color), size(_size) { // Nothing } // visitor: generation

virtual void upDown(parserFunction::ty_generation& v) {

setMaturity(v.getNodeInfo()); if(branchingOrder>0)

{

ty_float reductionCoef = 1.0;

ty_float coef = reductionCoef+(1.0-reductionCoef)*(1.0-maturity()); size*=coef;

}

if(precision()>0) {

// create child node childGeneration(v); } else { draw(); } } protected:

// creation of child node

void childGeneration(parserFunction::ty_generation& v) {

ty_ncRedirection& childContainer =

static_cast<ty_ncRedirection&>(container()); static boost::array<vec3,8> dec = {{

vec3(1.0,1.0,-1.0), vec3(1.0,-1.0,1.0), vec3(1.0,-1.0,-1.0), vec3(-1.0,1.0,1.0), vec3(-1.0,1.0,-1.0), vec3(-1.0,-1.0,1.0), vec3(-1.0,-1.0,-1.0) }};

ty_tmpChildList tmpList = childContainer.startGeneration(); for(int i=0;i<8;i++)

{

vec3 newPosition = dec[i]*(size/4.0); ty_float newSize = size/2.0;

vec3 newColor = color;

ty_pt_nodeBaseBase it = childAncestor(i); if(it.isValid()) { ty_nodeBase& a = static_cast<ty_nodeBase&>(it.ref()); ty_nodeBase* newChild; NEW(ty_square,newChild) (this,i,a,branchingOrder+1,newSize, newColor,globalRepere*ty_repere(newPosition)); childContainer.addChild(tmpList,newChild); } else { ty_nodeBase* newChild; NEW(ty_square,newChild) (this,i,branchingOrder+1,newSize, newColor,globalRepere*ty_repere(newPosition)); childContainer.addChild(tmpList,newChild); } } childContainer.endGeneration(tmpList); }

// opengl draw function void drawCore() { glPushMatrix(); glMultMatrix(globalRepere); glColor(color); draw_cube(1,0xFF,get_rapport(),size); glPopMatrix(); }

/// opengl draw function void drawDebug(ty_glViewer& v) {

ty_float pos=-30; v.strBuf()<<"size = "<<size<<std::endl; v.drawText(10,vpSize[1]-(pos+=30)); v.strBuf()<<"branchingOrder = "<<branchingOrder; v.drawText(10,vpSize[1]-(pos+=30)); v.strBuf()<<"precision = "<<ty_maturity::precision(); v.drawText(10,vpSize[1]-(pos+=30)); v.strBuf()<<"maturity = "<<ty_maturity::maturity(); v.drawText(10,vpSize[1]-(pos+=30)); } }; // end of ty_square