Valentin Popov Lozka Popova Giovanni De Paolipapers.cumincad.org/data/works/att/e184.content.pdf ·...

acadia’98Association for Computer-Aided Design in Architecture

316

Valentin PopovUniversity of Poitiers

[email protected]

Lozka PopovaUniversity of Poitiers

[email protected]

Giovanni De PaoliUniversity of Montreal

[email protected]

317

We propose a prototype “kernel” of an object-orientedlanguage, SOML (Scene Objects Modeling Language), intendedto assist in the declarative design of scenes in image synthesis.This language is an attempt to provide the designer with a tool tofacilitate the rapid prototyping of 3D scenes. It can also serve asa tool for knowledge acquisition and representation , and forcommunication and exchange of data with other tools in a de-sign environment.

Advantages offered by the implementation of SOML are:(a) from user’s viewpoint: the possibility of declarative descriptionof the initial concept associated with the target scene in terms ofproperties and constraint vocabulary, the possibility of quantita-tive and qualitative reasoning on these properties, the modifica-tion of the intermediate solutions to different levels of detail, theutilisation of previous solutions; and (b) from the implementationviewpoint: the structuring of the properties and methods in theform of domain knowledge, the optimal solution generation ac-cording to heuristic causal-probabilistic criteria, the transformationof the semantic concept description of the scene in generic entrycode for a geometrical CSG modeler or for rendering and visual-ization software, the integration of functionality for parameter gen-eration and modification, the compilation of a scene from compo-nents of other final scenes and operations of geometrical transfor-mations acting on groups of scenes.

We present the architecture of the object-based implanta-tion of the language and its interpreter, in the unified notationformalism UML. The utilization of the SOML language is illus-trated by some examples.

Towards an Object-Oriented Languagefor the Declarative Design of Scenes

Vers un langage à objets pour la conceptiondéclarative de scènes

Nous proposons un prototype de «noyau» à l’aide d’unlangage à objets SOML (Scenes Objects Modeling Language)destiné à aider à la conception déclarative de scènes par lasynthèse d’images. Ce langage est une tentative de fournir auconcepteur des outils de création rapide de prototypes de scènes3D. Il peut servir aussi comme moyen d’acquisition et représentationde connaissances, de communication et échange de donnéesavec d’autres outils dans un environnement de conception.

Les avantages offerts par la mise en oeuvre de SOML sont(a) du point de vue utilisateur: la possibilité de description déclarativedu concept initial associé à la scène en termes de vocabulaire depropriétés et contraintes, la possibilité de raisonner de manièrequalitative et quantitative sur ces propriétés, la modification desolutions intermédiaires à différents niveaux de détail, la réutilisationde solutions anciennes; (b) du point de vue mise en oeuvre: lastructuration des propriétés et des méthodes sous forme deconnaissances du domaine, la génération de solutions optimalesselon des critères heuristiques causal-probabilistes, la transforma-tion de la description des concepts sémantiques de scènes encode générique d’entrée d’un modeleur géométrique CSG (Con-structive Solid Geometry) et du logiciel de visualisation, l’intégrationdes fonctionnalités de génération et modification de paramètres,la compilation d’une scène à partir de composants d’autres scènesfinales et d’opérations de transformations géométriques de groupesde scènes.

Nous présentons ensuite l’architecture de l’implantation àobjets du langage et son interpréteur, dans le formalisme de nota-tion unifiée UML (Unified Modeling Language). L’utilisation dulangage SOML est illustrée par quelques exemples.


318

introductionThis study is in the scope of research on the

creation of tools to assist in the design of scenes inimage synthesis. Independent of its particular inter-pretation, the concept of scene is used in order torepresent a finite subset of objects within an appli-cation domain, defined formally in the universeparadigm (Gomes 1995; Gomes 1996). Thenotion of design is exploited in different domainsof man’s activities. It is a concept, associated withthe set of creative activities in society (Trousse1989). Its underlying methodologies face a sig-nificant evolution in the domain of mechanical andelectrical products manufacturing, and in the fieldof architecture. In general terms, design is a cyclicprocess of composition (assembly) stages of com-plex structures from completely specified compo-nents, and the decomposition of structures, the in-formation of which lacks precision. The durationof the design process is usually determined by howlong it takes to attain stable solution states.

In image synthesis the objects considered arethe components of the scene structure, the construc-tion and representation methods in 3D space, andits attributes. An object is characterized by a geo-metrical shape of any complexity, together withphysical features, which could be represented in arealistic manner on the computer screen as graphi-cal image. In terms of computer representation, thedesign in image synthesis encompasses variousmethodologies, integrating geometric models, pho-tometric models, cognitive models and their explo-ration for the construction and instantiation of vari-ous solution classes.

From a cognitive viewpoint, the scenes repre-sent a way of encoding of complex informationand its perception, and of reasoning about its un-known aspects belonging to numerous underlyingproblems. With the growing need for operationalmodels of this type, one notes during their creationand exploration, the existence of one major prob-lem. It is difficult to control the geometric appear-ance, usual, functional, technological etc. aspectsof complex 3D scenes at all the stages of their lifecycle. This has led to the development of method-ologies based on the creation of CAD tools fordesign assistance.

The current CAD market is dominated by sys-tems designed for specific applications, having onlya limited access to databases (Kehrer 1996). Inthese design assistance systems, the objects con-sidered are explicit in the case where knowledgeof all their parameters is complete, characteristicof a “from-the-ground-up” design. This fact pre-sents a limitation for the designer because hedoesn’t have the option of exploring partial solu-tions. Often, in the case of over-constrained prob-lems, it is useful to be able to relax the constraintsin the intermediate solutions. These systems arearticulated essentially around the geometrical as-pect, missing high level semantics better adaptedto the thought of a designer. As Charman (1995)underlines it, the geometry is only an artifice ofmanipulation for a universe with complex seman-tics.

One step toward the improvement of the disign-assistance tools is presented by the works dedi-cated to the creation of declarative CAD (Miaoulis1996; Colin 1997). The design of scenes by thedeclarative approach consists in offering ways toexpress the design needs in linguistic terms at ev-ery stage of the design cycle. The creation of afinal scene necessitates many repetitive attemptsof decomposition of the found solutions (intermedi-ate scenes) into their constituent elements in orderto refine them in accord with the goal requirementsand new constructions of the scene. It is a processof manipulation of initially unknown semanticallyrich properties in the cycle description- generation-knowledge understanding (Lucas 1990), the pro-cess of declarative design.

Among the numerous problems to be dealtwith in this approach, it is necessary to underlinethe difficulty of optimal management of the num-ber of solutions coherent with the imposed con-straints, of providing for the reusability of the expe-rience of other designers, and of developing a user-friendly description and control language, close tothe thought of the user and covering all the stagesof the design process. A promising approach inorder to address these difficulties resides in thedevelopment of knowledge based “intelligent” CADsystems. These systems represent a new way todeal with the problem of limited assistance in CADby integrating design knowledge into the geometri-

319

Towards an Object-Oriented Language forthe Declarative Design of Scenes

introductionCette étude s’inscrit dans un cadre de recher-

che visant la création d’outils d’aide à la concep-t ion de scènes en synthèse d’images.Indépendamment de son interprétation particulière,le concept de scène s’utilise toujours pourreprésenter un sous-ensemble fini d’un de sesdomaines d’application, définis formellement dansle paradigme univers (Gomes 1995, 1996).

Ces dernières années, la notion de concep-tion est exploitée dans différents domainesd’activités de l’homme. C’est un concept, associéà l’ensemble d’activités créatives dans la société(Trousse 1989). Les méthodologies créées à sabase ont subi une grande évolution dans ledomaine de fabrication de produits mécaniques,électroniques et dans le domaine de l’architecture.En termes généraux, la conception est un proces-sus d’enchaînement cyclique d’étapes de compo-sition de structures complexes à par tir decomposants complètement spécif iés et ladécomposition de structures, dont les informationsmanquent de précision. La durée d’un processusde conception est habituellement limitée parl’aboutissement d’états de stabilité des solutionsobtenues.

En synthèse d’images, les objets à concevoirsont les composants de la structure de la scène,des méthodes de construction et représentation dansl’espace 3D et ses attributs. Un objet est caractérisépar une forme géométrique de complexitéquelconque, munie de caractéris t iquesd’apparence physiques, qui peut être représentéede manière réaliste sur l’écran de l’ordinateur sousforme d’une image graphique. En termes dereprésentation informatique, la conception ensynthèse d’images comprend des méthodologies,intégrantes des modèles géométriques, modèlesphotométriques, modèles cognitifs et leurs explora-tions pour la construction et l’explicitation desclasses de solutions.

Du point de vue cognit i f, les scènesreprésentent un moyen de coder l’informationcomplexe, de la percevoir et de raisonner sur sesaspects inconnus faisant partie de nombreuxproblèmes sous-jacents. Avec le besoin de plus enplus nécessaire de tels modèles performants, on

constate durant leur création et exploration,l’existence d’un problème majeur. Il s’avère difficilede maîtriser l’aspect géométrique, d’apparence,fonctionnel, technologique etc. de scènes com-plexes 3D à toutes les étapes du cycle de leursvies. Tous ceci a provoqué l’apparition desméthodologies d’assistance, basées sur la créationd’outils CAO d’aide à la conception.

Le marché actuel de la CAO est dominé pardes systèmes destinés aux applications spécifiques,n’ayant qu’un accès limité aux bases de données(Kehrer 1996). Dans ces systèmes d’aide à la con-ception, les objets à concevoir ne sont explicitésque dans le cas où les connaissances de tous sesparamètres sont complètes, donnant une concep-tion ascendante. Ce fait présente une limitation pourle concepteur car il n’a pas de possibilitésd’expliciter des solutions partielles. Souvent, dansle cas de problèmes sur-contraintes, il est utile depouvoir contrôler la relaxation des contraintes dansles solutions intermédiaires. Ces systèmes sontarticulés essentiellement autour de l’aspectgéométrique, manquant de sémantique de hautniveau et aussi l’adaptation à la pensée duconcepteur. Comme le souligne Charman (1995),la géométrie n’est qu’un artifice de manipulationd’un univers dont la sémantique est complexe.

Un pas vers l’amélioration de l’assistance estprésenté par les travaux dédiés à la création deCAO déclaratives (Miaoulis 1996; Colin 1997).La conception de scènes par l’approche déclarativeconsiste à offrir des moyens pour exprimer en termesde langage les besoins de chaque étape du cyclede l’évolution du processus de conception.

La création d’une scène finale nécessite denombreux essais répétitifs de décomposition dessolutions trouvées (scènes intermédiaires) auxéléments à raffiner en accord avec les exigencesdes buts et des nouvelles reconstitutions de la scène.C’est un processus de manipulation des propriétéssémantiquement r iches, jamais connuesauparavant, dans la boucle description-génération-prise de connaissances (Lucas 1990), ce quisignifie une tâche de conception déclarative. Acause du nombre de problèmes à traiter dans cetteapproche, il faut souligner la difficulté de gestionoptimale du nombre des solutions cohérentes avec


320

thetic scenes, the MPCS refers to the conceptualand logical models of the scene components andgives the answer to the question of how to designthe scene. It allows one to consider the design froma new angle, like being a problem based on hy-brid knowledge resolution.

The work we present here is a contribution tocurrent CAD applications’ requirements of flexibil-ity, ease of use, possibility of integration with othertools, and functionality. In the sections that follow,we explain the context and essential features ofthe SOML kernel. Before concluding on the pros-pects for future research, we present the result ofone experiment.

problems of design languagesLanguage in general, thanks to its power of

expression, is a good existing way in man’s pos-session to describe, model and exploit the world.Computer technology today has provided a pano-ply of languages, varied according to the differentneeds and working techniques: imperative, func-tional, logical and lately object-based (Oussalah1997). In our study we are particularly interestedin the implementation of languages capable of of-fering functionality that could have as its objectivethe design of scenes, that is, activities of descrip-tion and knowledge acquisition, generation ofparametric solutions and their processing, gaininginformation by means of visualization, makingmodifications as necessary, and communicationwith the environment.

Within the methodology of declarative mod-eling, for the description of the properties and theconstraints according to different points of view,one uses a languages of “scripts.” Given this, oneobtains descriptions that constitute the externaldeclarative model (Plemenos 1991; Desmontil1995). These are languages of reduced syntax,structured on some restricted vocabularies, orientedtoward modeling. They are restricted to representonly the semantics of selected properties. The in-ternal geometric model, created by a declarativemodeler and the process of its exploration (Plemenos1991; Martin 1989) is coded in terms of impera-tive universal languages like Pascal, C, or of logi-cal languages (Prolog, Lisp). All these languagespresent the inconvenience that they can not bring

cal models (Kehrer 1996; Vargas 1995; Trousse1989). The modeling and the exploitation of thisknowledge is possible thanks to the couplings ofthe CAD systems with other advanced computingtools, in particular the coupling of traditional mod-elers based on object-oriented languages, infer-ence engines, systems of constraint resolution, andmethods of qualitative and quantitative reasoning.

With the exception of the work on declara-tive modeling in Geode (1997), which is dedi-cated to the problem of scene design within multi-media computer systems, one notes a lack of sci-entific communications about the use of such sys-tems. The reasons for this lack despite the impor-tance of the topic, are the diversity, complexity andmultidisciplinary character of the field. Neverthe-less one finds some descriptions of systems andutilities partially covering the needs of the differentdesign stages. These include tools that collect vari-ous abilities to facilitate geometric modeling andrealistic scene visualization.

Despite the obvious progress of systems fordesign assistance, one notes some limitations, sum-marized by Kehrer and Vatterrott: an insufficientlyopen evolution, a lack of configuration possibility,poor integration capacity, lack of possibility foroperational exchange between the systems, lackof capacities of cooperative design, obstacles tothe migration of the application domains, absenceof modularity, and awkward user interfaces.

The interest of our work lies in the propositionof one methodological support for the creation ofa “kernel” of a language integrating tools for syn-thetic scene design, SOML (Scene Object Model-ing Language), based on the “declarative” prin-ciple. The goal of the language is to offer function-ality to guide the designer in the activities definedby the Model of the Process of Scene Design(MPCS) throughout the different stages of the de-sign cycle. For the definition of the MPCS modelwe are inspired a great deal by the works of C.Vargas presenting the mechanical design as a tree-like structure made up of tasks/methods (Vargas1995). In their TROPES System, Genzel and Girardrepresent the tasks as cognitive units within a sys-tem for knowledge representation by multiple-view-point objects (Genzel 1997). In the case of syn-

321


les contraintes imposées ainsi que la réutilisationde l’expérience d’autres concepteurs et le besoind’un langage convivial de description et decontrôle, proche de la pensée de l’utilisateur etcouvrant toutes les étapes du processus de con-ception. Une approche prometteuse pour répondreà ces difficultés réside dans le développement desystèmes CAO «intell igents» basés sur lesconnaissances.

Ces systèmes représentent une voie nouvellepour aborder le problème d’assistance réduite enCAO en intégrant aux modèles géométriques desconnaissances de conception (Kehrer 1996;Vargas 1995; Trousse 1989). La modélisation etl’exploitation de ces connaissances est possiblegrâce aux couplages des systèmes CAO avecd’autres outils informatiques avancés, parmi lesquelson distingue les cas de couplage des modeleurstarditionnels basés sur les langages orienté objets,des moteurs d’inférence, des systèmes de résolutionde contraintes, des méthodes de raisonnementqualitatif et quantitatif.

Mis à part les travaux de modélisationdéclarative Geode (1997), dédiés aux problèmesde la conception de scènes dans le cadre desystèmes informatiques mult imédia et laméthodologie de conception à base déclarative,on constate un manque de communicationsscientifiques pour la mise en œuvre de tels systèmes.Les causes de cet état sont à chercher, malgrél’importance de sujets, dans la diversité, lacomplexité et le caractère multidisciplinaire dudomaine. Néanmoins, on trouve des descriptionsdes systèmes et des utilitaires couvrant partiellementles besoins d’assistance aux différentes étapes dela conception. Il s’agit de boites d’outils regroupantdes utilitaires facilitant la modélisation géométriqueet la visualisation réaliste des scènes.

Malgré le progrès évident des systèmes d’aideà la conception, on constate ses limites, résuméespar Kehrer et Vatterrott comme: l’ouvertureinsuffisante d’évolution, le manque de possibilitéde configuration, la pauvre capacité d’intégration,le manque de possibilité d’échange opérationnelentre les systèmes, le manque de capacités deconception coopérative, l’existence des obstaclespour la migration des domaines d’application,

l’absence de modularité, le manque des interfacesutilisateurs suffisamment conviviales.

L’intérêt de notre travail porte sur la propo-sition d’un support méthodologique pour la créationd’un «noyau» avec un langage intégrant des outilsd’aide à la conception de scènes synthétiquesSOML (Scene Objects Modeling Language) basésur le principe «déclaratif». L’objectif du langageest de proposer des fonctionnalités permettant deguider le concepteur à effectuer des activitésprévues par le Modèle du Processus de Concep-tion de Scènes MPCS aux différentes étapes ducycle de vie. Pour la définition du modèle MPCS,nous nous sommes inspirés des grandes lignes destravaux de C. Vargas présentant la conception enmécanique comme une structure arborescente detâches/méthodes (Vargas 1995), Genzel etGirard représentant les tâches comme des unitéscognitives au sein du système de représentationde connaissances par objets multi-points de vueTROPES (Genzel 1997). Dans le cas de scènessynthétiques, le MPCS se réfère aux modèlesconceptuels et logiques des composants de la scèneet donne la réponse à la question commentconcevoir la scène. Il permet d’aborder la con-ception sous un nouvel angle, comme un problèmede résolution à base de connaissances hybrides.

Le travail présenté est un effort de contri-bution aux exigences actuelles des applicationsCAO de flexibilité, facilité d’utilisation, possibilitéd’intégration d’autres outils et fonctionnalités. Dansles sectins suivante, nous exposons le contexte etles caractéristiques essentielles du noyau SOML.Avant de conclure sur les ouvertures à des futuresrecherches, nous présentons le résultat d’uneexpérimentation.

problèmes des langages dans la conceptionLe langage en général, grâce à son pouvoir

d’expression, est le meilleur moyen existant enpossession de l’homme pour décrire, modéliser etexploiter le monde. La technologie informatiqueactuelle a fourni une panoplie de langages,diversifiés selon les différents besoins et techniquesde fonctionnement: impératifs, fonctionnels,logiques et dernièrement par objets (Oussalah1997). Dans notre étude nous nous sommesintéressé particulièrement à la mise en œuvre de


322

geometrical primitives. These languages limit tosupport only some stages of the evolution cycle ofthe designed objects. In the case of complexscenes, the control on the design parameters, interms of structuring and of reusability of codes,becomes difficult. In the case of coupling of sys-tems based on knowledge resolution, it is neces-sary that the design language permit a global sup-port on all the levels of the design process.

In the following section, we show details ofthe philosophy of integration, in one specializedscene design language, of a functionality permit-ting the designer to create from solid primitives aCSG-constituted synthetic 3D scene, to representthe methods of its assembly and modification interms of methodical and causal probabilistic knowl-edge, and to interact with the environment or otherscenes. The causal-probabilistic solution allows oneto introduce the concept of hypothetical covering,reflecting the non-determinist nature of the possiblesemantic interpretation associated with the proper-ties related to the concept of the target scene. Inthis context, the result of the constraint resolution isthe choice of one subset of coverings (set of in-stance parameters) relevant to the constraints fordirect causes, sorted according to the criterion ofmaximal likelihood (Peng 1990).

For the conceptualization of a system weadopted the UML formalism (Lai 1997), becominga standard for the biggest publisher of industrialobject-oriented software. The formalism of objectUML modeling was created by the OMG Associa-tion with the goal of unifying the best existing meth-ods of analysis and object-oriented design. Thisformalism is the most advanced one at present,and it makes possible the elaboration of concep-tual and logical models of complex systems.

structure and main aspects of SOMLThe approach adopted in the choice of SOML

structure is a hierarchical layering of the functional-ity, implemented in the context of a design-assis-tance environment (Figure 1. UML-diagram of theobject-oriented conceptual model of SOML).

The components of the environment are ac-cessible by means of UNIX shell processes. Onedistinguishes the following layers: knowledge, mod-

out the modularity and the semantics of concreteconcepts presented by the scene models. They re-main far from the thought of the designer and thelinguistic schemes supported by natural language.They don’t permit a comfortable structuring of thedomain knowledge, nor the intervening of the de-signer in the cycle of design evolution.

In the field of product design, there are lan-guages better adapted to the particular needs. Forexample in the design of mechanical parts we havethe use of languages like “Maily” (Trousse 1988),“DDL” (Vargas 1995), “FDL” (Brunetti 1996), “EREP”(Chen 1995), as well as others. There also existsa group of languages designed to model the ac-tivities of computer systems in general, indepen-dently of the application domain, collecting themethods relevant to their application. The best-known are Common KADS, Merise, Graffcet etc.(Vargas 1995). They all have the constraint to benot directly usable for a particular domain.

In terms of knowledge representation and uti-lization within a system of scenes design assistance(Trousse 1989), the object-oriented paradigm en-ables the class based structuring of static knowl-edge (fields of attributes), and of dynamic knowl-edge (methods). In this context a class determinesa generic model that permits the “instantiation” ofsimilar objects. The cognitive aspects of the de-sign assistance systems is partially covered by thelanguages for knowledge modeling, based on thenotion of production rules, semantic networks andframes (SHIRKA, KRL, Kl-ONE).

In image synthesis, there are have been de-veloped script- based interpreted languages usedfor modeling, and the animation of scenes like “Put”(Clay 1996), “Smile” (Argues 91), “Sphigs” (Foley1995), “Mira” (Thalman 1988), “Fabule” (Gascuel1996), and of languages giving priority to the vi-sualization like “Pov-ray2” (Dif 1996), “MSDL2”(Gatenby 1993), “RayShade,” “Radiance,” and“RenderMan.” They all were conceived in order toanswer to the needs for tools, especially in the re-search laboratories of computer graphics and me-chanical CAD. In all these cases particular formatsfor graphical data were created(more than 40 dif-ferent types). The type of the languages is proce-dural, using as arguments the parameters of the

323


langages capables de proposer des fonctionnalitésqui puissent avoir comme objectif la conceptionde scènes, c’est-à-dire, des activités de descrip-tion et l’acquisition de connaissances, la générationde solutions parametrées et leurs instances, la prisede connaissance par visualisation, la modificationen cas de besoin, la communication avecl’environnement.

Au sein de la méthodologie de modélisationdéclarative, pour la description des propriétés etdes contraintes selon différents points de vue, onutilise des langages à «scripts», grâce auxquels onobtient des descriptions qui constituent le modèledéclaratif externe (Plemenos 1991; Desmontil1995). Ce sont des langages à syntaxe réduite,bâti sur des vocabulaires restreints, orientés vers lamodélisation. Ils se limitent à représenter lasémantique des propriétés visées. Le modèlegéométrique interne, créé par un modeleurdéclaratif et le processus de son exploration(Plemenos 1991; Martin 1989) sont programmésen termes de langages impératifs universels commePascal, C, ou de langages logiques (Prolog, Lisp).Tous ces langages présentent l’inconvénient de nepas pouvoir dégager la modularité et la sémantiquedes concepts concrets présentés par les modèlesdes scènes. Ils restent loin de la pensée duconcepteur et des schémas linguistiques supportéspar le langage naturel. Ils ne permettent pas unestructuration aisée des connaissances du domaine,ni l’intervention du concepteur dans le cycled’évolution de la conception.

Dans le domaine de conception de produits,nous trouvons des langages mieux adaptés auxbesoins particuliers. Par exemple dans la concep-tion en génie mécanique nous avons la mise enœuvre de langages comme «Maily» (Trousse 1988),«DDL» (Vargas 1995), «FDL» (Brunetti1996), «EREP»(Chen 1995), et bien d’autres.

Il existe également un groupe de langagesconçus pour modéliser les activités d’un systèmeinformatique en général, indépendamment dudomaine, regroupés selon les méthodes de leursapplication. Les plus connus sont Common KADS,Merise, Graffcet, etc. (Vargas 1995). Ils ont tousla contrainte de ne pas être utilisables directementpour un domaine particulier.

En termes de représentation et utilisation deconnaissances au sein d’un système d’aide à laconception de scènes (Trousse 1989), leparadigme orienté objets permet la structuration,sous forme de classes d’objets, des connaissancesstatiques (champs d’attributs de propriétés) et deconnaissances dynamiques (méthodes). Dans cecontexte une classe détermine un modèle génériquequi permet «l’instanciation» d’objets similaires. Lesaspects cognitifs des systèmes d’aide à la concep-tion sont partiellement couverts par les langagesde modélisation des connaissances, basés sur lanotion de règle de production, réseaux sémantiqueset frames (SHIRKA, KRL, Kl-ONE).

En synthèse d’images, se développent deslangages interprétés par des «scripts» utilisés pourla modélisation et l’animation de scènes comme«Put» (Clay 1996), «Smile» (Argues 1991),«Sphigs » (Foley 1995), «Mira» (Thalman 1988),«Fabule» (Gascuel 1996), et des langages donnantpriorité à la visualisation comme «POV-Ray» (Dif1996), «MSDL » (Gatenby 1993), «RayShade» ,«Radiance», «RenderMan». Ils ont été conçus afinde répondre aux besoins d’outils, surtout dans leslaboratoires de recherche, d’infographie et deCAO en mécanique. Dans tous ces cas, ils ontaussi été crées avec des formats de donnéesgraphiques particulières (plus de 40 typesdifférents). Ces langages sont de type procédural,utilisant comme arguments les paramètres desobjets–primitives géométriques. Ces langages selimitent à ne supporter qu’à certaines étapes ducycle d’évolution des objets en conception. Dansle cas de scènes complexes, le contrôle sur lesparamètres de la conception, en termes destructuration et de réutilisation du code, devientdifficile. Dans le cas de couplage de systèmes derésolution à base de connaissances, il estnécessaire que le langage de conception permetteun support global sur tous les niveaux de la con-ception.

Dans la section suivante nous montrons desdétails sur l’idéologie d’intégration, dans unlangage spécialisé pour la conception de scènes3D, des fonctionnalités permettant au concepteurde créer des primitives de solides CSG constituantune scène synthétique, de représenter les méthodesde son assemblage et modification en termes de


324

Figure 1a. Classes and instances of knowledge representation (multiple-viewpoint classification).

Figure 1b. Classes and instances of geometric modeling and of the photo-realistic aspect (Methodological knowledge).

Figure 1c. Classes and instances of classes and instances ofsolution prototypes (satisfaction of constraints).

<<MetaClass>>Tasks&Methods:

Viewpoints

objects_compo : Scene objects_contr : Constraints+ acquis ition ( )+ macroinstructions ( )

<<MetaClass>>Generators

Compile, Edit,Modify

parameters : Viewpoints+ instructions ( )

Locomotive:Tasks&Methods

generate.wheel()

gener ate.wheel2()

gene rate.link()

generate.suspension()

Ball Scene: Generators

generate_simple\ sphere\front_top\ distance 5\ unit 0 \ sphere small\0 1 0\0 0 0\

dimension\ black-wo od\ 3_args 0 0

Global model

primitives

<<MetaClass>>Materials:Viewpoints

Viewpoint : Domain+ acquis ition ( )+ macroinstructions ( )

methods

Functionalmodel

<<use>>

<<uses>>

<<uses>>

Materials(Locomotive):Viewpoints

mat.wood.black(loco.wheel)

mat.wood.white(loco.wheel)

mat.wood.black(loco.link)

mat.wood.black(loco.susp)

Knowledge Layer Examples

Localconceptualmodel ofsolution

Base globalede

connaissances

Internalgeometric model

<<compile>>

<<compile>>

Modeling layer Examples

materials

Classe

attributesmethod()

Instance of class

attributsmethod()

association héritage

Examples

Instance ofsolution

Model ofstorage data

<<MetaClass>>Primitives

arguments : Parameters+ commands( )+ primitives ()

solutions

<<MetaClass>>Graphical data

delta_scene : Parametersparam_scene: Parameters

use

useBase: Bases

/* template = * * * * */

#declare deltaX0template = 0.0

/* template = * * * * */

#declare X template = X0+deltaX0template +deltaXtemplate

Generation Layer

Model of theprimitives

generate

Instance ofdata

generate

325


Figure 1a. Classes et instances de représentati des connaissances (classification multi-vues).

Figure 1b. Classes et instances de modélisation géométrique et de l’aspect photo réaliste (connaissances méthodologiques).

Figure 1c. Classes et instances de solutions - prototypes (résolutinde contraintes).

<<MetaClass>>Tâches&Méthodes:Vues

objets_compo : Scène objets_contr : Contraintes+ acquis ition ( )+ macroinstructions ( )

<<MetaClass>>Générateurs

Compil. Editeur,Modificateur

paramètres : Vues+ instructions ( )

Locomotive:Tâches&Méthodes

generer.roue()

gener er.roue2()

generer.liaison()

generer.suspension()

Scène_Balle: Générateurs

genere_simple\ balle sphere\avant_au_dessus\ distance 5\ unites 0 \sphere petite\ 0 1 0\0 0 0\

dimension\ bois_noire\ 3_args 0 0

Modèle global

primitives

<<MetaClass>>Materiaux:Vues

Vue : Domaine+ acquis ition ( )+ macroinstructions ( )

méthodes

Modèlefonctionnel

<<utilise>>

<<utilise>>

<<utilise>>

Materiaux(Locomotive):Vues

mat.bois.noire(loco.roue)

mat.bois.blanc(loco.roue)

mat.bois.noire(loco.liaisn )

mat.bois.noire(loco.susp)

Couche Connaissances Exemples

Modèleconceptuellocal de

résolution

Base globalede

connaissances

Modèlegéométrique

interne

<<compile>>

<<compile>>

Couche Modélisation Exemples

matériaux

Roue: Primitives

#declare roue = object{ PG1roue

scale < XsPG1roue,YsPG1roue,ZsPG1roue >rotate < XrPG1roue ,YrPG1roue , ZrPG1roue >

translate< XtPG1roue, YtPG1roue, ZtPG1roue > } object { rouetransform TrS_roue }

Instance desolution

Modèle dedonnées

de stockage

<<MetaClass>>Primitives

arguments : Paramètres+ commands( )+ primitives ()

<<MetaClass>>Données graphiques

delta_scene : Paramètresparam_scène: Paramètres

<<utilise>>

<<utilise>>Base: Bases

/* template = * * * * */#declare deltaX0template = 0.0

/* template = * * * * */

#dec lare Xtemplate = X0+deltaX0template +deltaXtemplate

Couche Génération

Classe

attributsméthode()

Instance de Classe

attributsméthode()

association héritage

Modèle deprimitives

<<génére>>

Instance dedonnées

<<génère>>

Exemples


326

classes and instances, and structured in terms ofviewpoints and causal relations. The knowledge isof a hybrid type due to its heterogeneous nature(symbolic, qualitative and quantitative, causal,probabilistic). After structuring the information aboutthe scene domain, it becomes possible to infer (ac-tion of inference) non-explicit information from it.This information is available in the knowledge da-tabase and consists of solutions in terms of cover-ings, introduced by Peng (1990). These solutions(coverings) represent the semantic cognitive aspectof the final solutions, produced during the activitiesof compilation and generation.

The action of compilation consists in the trans-formation of information (views, classes of proper-ties, and causal relations) into models (geometric,photometric,functional, of construction methods,and others) in keeping with the semantics of “mul-tiple viewpoints.” The action of generation pro-duces instances of stable solutions. The solution ofa scene is the set of instances of classes of thescene’s properties, created by a concrete methodof construction, and satisfying the imposed con-straints. In terms of data, a solution is the set ofqualitative and quantitative values attained by theparameters of the construction method. Each solu-tion is named after its construction method, andnumbered based on the order in which it was cre-ated. The number of solutions can be very big,and in that case it is suitable to classify them interms of the acceptance interval for the values ofthe parameters. In this manner we generate classesof solution prototypes, to be used by default. Thisclassification sheds light on the knowledge baseof hybrid, multi-viewpoint information with respectto a new solution.

The solution of a problem in declarative de-sign is based on the integration of an analytic learn-ing method (supported by the causal-probabilisticmodel, CPM) and a hybrid method of spatial con-straint resolution. The causal-probabilistic model,proposed by Peng (1990) and generalized byDubois (1995) offers analytic and probabilisticlearning formalisms. This learning consists in ac-quiring methodological knowledge by means offew examples, often alone, and a very rich theoryof the domain. The resolution of spatial constrainsis a necessary activity for the instantiation of topo-

eling, and generation. These will be presented inthis chapter. The functionality supported by SOMLrevolves around the three principal phases of theiterative design process; description, model gen-eration and information gathering. This functional-ity is intended for the creation of cognitive geomet-ric models with a realistic appearance, and thegeneration of solutions (instances). It includes ac-tions performed on the objects constituting the de-sign assistance environment. The principal actionsare: representation, compilation, modification,duplication, classification, and inference. Eachaction is described in terms of macro-instructions,instructions, SOML commands and arguments; struc-tures according to a multi-layer hierarchy, to bedescribed below.

A real or virtual scene can be described as aSy system with different states–initial, intermediate,or final. Such a system is capable of transforminga set of properties observed upon entry into a newset of properties observed upon exit. These prop-erties resemble constraints when they are of a geo-metric, mechanical, topological, or other nature.There is often a fine line between the notions ofproperties and constraints. We distinguish two typesof properties: those which are explicitly stated bythe designer, and those which are implicit, i.e. re-lated to a particular domain of application andare not stated during the action of description. Theactivity of description is a process of acquisitionand external representation (external declarativemodel) of the properties and constraints on theobjects constituting the scene (and on the sceneitself). This activity is expressed by a set of con-junctions of natural statements. The linguisticschemes used are based on unary and binary re-lations. A statement, for example, is a disjunctionof pairs (attribute_identifier, value), and triples( t a r g e t _ a t t r i b u t e _ i d e n t i f i e r , v a l u e ,reference_attribute_identifier), where these attributeidentifiers are described by means of a limitedvocabulary derived from natural language (Figure15) and adapted to each specific case (Plemenos1991; Lucas 1996; Desmontils 1995). The state-ment expresses the semantics of the property un-der consideration.

In terms of cognitive units, the properties arerepresented (action of representation) by means of

327


connaissances méthodologiques et de résolutioncausale-probabil is te et d’interagir avecl’environnement ou d’autres scènes. La résolutioncausale-probabiliste permet d’introduire les con-cepts de couverture hypothétique reflétant la na-ture non déterministe de l’interprétation dessémantiques possibles associées aux propriétéscouvrant le concept d’une scène cible. Dans cecontexte, le résultat de la résolution est le choixd’un ensemble de couvertures (ensemble deparamètres) pertinentes aux contraintes de causalitédirecte, triées selon un critère de vraisemblancemaximale (Peng 1990).

Pour la conceptualisation du système nousavons adopté le formalisme Unified Modeling Lan-guage-UML (Lai 1997), devenu un standard pourles plus grands éditeurs de logiciels industriels dansla modélisation objet. Le formalisme demodélisation objet UML est crée par l’associationObject Management Group-OMG avec le soucid’unifier les meilleures méthodes existantes dansl’analyse et la conception orienté objets. Ceformalisme est le plus évolué à l’heure actuelle et ilpermet l’élaboration des modèles conceptuels etlogiques dans un environnement de systèmes com-plexes.

Structure et aspects principaux du SOMLLa solution adoptée pour le choix d’architecture

de SOML est la structuration hiérarchiquemulticouche des fonctionnalités, implantées dansle contexte d’un environnement d’aide à la con-ception (Figure 1. Diagramme UML du modèleconceptuel des dépendances classes/instances dulangage SOML).

Les composants de l’environnement sontaccessibles par l’intermédiaire de processus Unixet le shell de ce système d’exploitation. On distingueles couches Connaissances, Modélisation etGénération présentées dans ce chapitre. Lesfonctionnalités supportées par SOML s’articulentautours des trois principales phases, constituant lesétapes du processus itératif de conception : de-scription, génération et prise de connaissances(Lucas 1990). Ces fonctionnalités visent la con-struction des modèles cognitifs, géométriques,d’apparence réaliste et la génération d’instances–solutions. Elles incluent des activités exécutées sur

les objets constituant l’environnement d’aide à laconception. Les activités principales sont descrip-tion, représentation, compilation, modification,clonage, classification, inférence. Chaque activitéest représentée en termes de macroinstructions,instructions, commandes et arguments SOML,structurés dans une hiérarchie multicouche, detailléeplus loin.

Une scène réelle (ou virtuelle) peut êtrereprésentée comme un système Sy avec des étatsdifférents - initial, intermédiaire ou final. Un telsystème est capable de transformer un ensemblede propriétés affectées à son entrée dans un nouvelensemble de propriétés observées à sa sortie. Cespropriétés s’apparentent beaucoup à descontraintes lorsque celles-ci sont géométriques,topologiques, mécaniques ou autres. Souvent lafrontière entre les notions de propriétés et contraintesest particulièrement floue. Nous distinguons deuxtypes de propriétés: celles qui sont explicitementénoncées par le concepteur et celles qui sontimplici tes, c’est -à-dire l iées au domained’application et ne sont pas déclarées pendantl’activité de description.

L’activi té description est un processusd’acquisition et de représentation externe (modèledéclaratif externe) des propriétés et des contraintessur les objets physiques qui composent la scène (etsur la scène elle-même). Cette activité s’exprimecomme un ensemble de conjonctions de phrasesnaturelles. Les schémas linguistiques utilisés sontbasés sur des relations unaires et binaires. Unephrase par exemple est une disjonction de couples(identificateur_d’attribut, valeur) et de triples( i den t i f i ca t eu r _d ’a t t r i b u t _ c ib l e , va l eu r,identif icateur_d’attr ibut_référence ) où lesi d e n t i f i c a t e u r _ d ’ a t t r i b u t ,identificateur_d’attribut_(référence ou cible) sontdénotés par un vocabulaire restreint spécialisé dulangage naturel (Figure 16) adopté pour chaquecas concret (Plemenos 1991; Lucas 1996 ;Desmontils 1995). La phrase exprime la sémantiquede la propriété visée.

En termes d’unités cognitives, les propriétéssont représentées (activité représentation) parclasses et instances, structurées en «vues» et rela-tions de causalité (Couche Connaissances). Les


328

logical models of spatial configuration, and isbased on spatial-temporal logic (Allen 1983,Donikian 1992).

The paradigm for our approach to solvingdesign problems can be summarized by the fol-lowing rules:

R1: If the designer does not know how to con-struct the scene, then the new solution = infer-ence from the most similar existing solution +duplication of the most similar existing solu-tion + eventual modification.

R2: If the designer knows how to contruct thescene, then the new solution = description +representation + compilation + generation +classification.

The duplication (or “cloning”) operation hasthe aim of deriving a “generic” copy of the methodof construction of the scene or its parts referencedin terms of the most similar existing solution and itsinstantiation. The copy is reinstantiated as a newsolution in a new context (the referenced welcomescene). The new solution is renamed and can besubsequently modified. For example, the interme-diate scene “hub” of Figure 18 created by themethod “generate_hub” and shown in Figure 18,is derived from the intermediate scene “wheel” andmodified locally without affecting the rest of thescene in terms of the properties “dimensions” and“photometric aspects.” The search for existing so-lutions and the test for similarity is effected with thehelp of decisional (causal-probabilistic) heuristics,and remains outside the scope of this work.

design environmentThe environment of the assisted design consti-

tutes the application context of the SOML language.Its architecture is founded on the coupling of anextended geometrical modeler (MoCSG), an in-terpreter (ISOML) of programs (PgSOML), a mod-ule of knowledge treatment (TrCo), a graphical userinterface (IGU), the software of visualization POV-Ray (RePov), and the data bases: knowledge data(BaCo), graphic data (DoGra), picture data (DoIm)and the Unix shell.

The architecture of the environment is con-ceived in view of providing declarative modeling

of scenes, using strategies and techniques of quali-tative reasoning and causal probabilistic heuristics.The reasoning task concerns the obtaining of ananswer to questions about the composition (e.g.,what are the components of a scene?), the geom-etry (e.g., which is the scene with the given pro-portions?), the spatial configuration (e.g., what arethe possible configurations in the available space?)and the realistic aspect of some scenes (e.g., whichare the scenes with the given appearance?).

The coupling of the tools accomplished throughdata exchange actions. This provides the advan-tages of management and modular manipulationof data through the language in using knowledgebased optimization strategies. In the following para-graphs we present the conceptual context and thearchitecture of the kernel SOML language. Theyare specified in terms of conceptual and logicalmodels, expressed by classes and their associa-tions, in the conceptualization formalism UML.

knowledge layer and MCRAt this level of the hierarchy, the functionality

is defined according to MCR (Model of Concep-tual Resolution). This model is build on the basis ofconcepts stemming from the OBR (Objects-basedrepresentation) formalism of object oriented mod-eling of domain knowledge by multiple views(Caponi 1995, 1997) and the MCP (Causalprobabilistic model) model of reasoning based onthe application of the causal probabilistic strate-gies of resolution.

According to MCR, a scene is viewed as acognitive model of a designed world. The proper-ties and the constraints of the scenes and also themethods of their treatment, are defined as cogni-tive objects–units of knowledge. They constitute thedomain knowledge according to the different pointsof view of the scene. The knowledge is structuredon the basis of the object oriented formalism OBR,defined by the SHIRKA-TROPES methodology(Caponi 1995; Gensel 1997; Schmeltzer 1995).The MCR formalism permits the enumeration andthe attachment of properties to the objects of thescenes and the application of strategies for resolu-tion defined by MCP.

Multiple points of view, classes, instances and

329


connaissances sont de type hybride due à sa na-ture hétérogène (symbolique qualitative et quanti-tative, causale et probabiliste). Après la structurationdes connaissances du domaine des scènes, ildevient possible d’en inférer (activité inférence) desinformations non explicites, disponibles dans labase de connaissance, à savoir des solutions entermes de couvertures, introduit par Peng (Peng1990). Ces solutions (couvertures) représententl’aspect sémantique cognitif des solutions finales,produites pendant l’activité compilation etgénération.

L’activité compilation consiste à la transforma-tion des connaissances (vues, classes de propriétéset relations de causalité) sous formes de modèles:géométriques, d’apparence photométrique,méthodes de construction, fonctionnels, et d’autresconformes aux sémantiques des «vues». Lagénération produit des instances de solutionsconsistantes. La solution d’une scène est l’ensembledes instances des classes des propriétés de lascène, créées par une méthode concrète de con-struction, étant consistantes avec les contraintesimposées. En termes de données, une solution estl’ensemble des valeurs quantitatives et qualitativesaffectées aux paramètres de la méthode de con-struction. Chaque solution est nommée par le nomde sa méthode, énumérée par le numéro d’ordrede la génération. Le nombre des solutions peut êtretrès grand et il est convenable de les classifier parl’intervalle d’acceptation pour les résultats del’évaluation des propriétés paramétriques. De cettemanière nous allons générer des classes de proto-types solutions, utilisées par défaut. La classifica-tion met à jour la base de connaissances hybridesmulti-vues par rapport à une nouvelle solution.

La résolution d’un problème de conceptiondéclarative est basée sur l’intégration d’uneméthode analytique d’apprentissage (supportée parCausal probabilistic Model CPM) et une méthodehybride de résolution des contraintes spatiales. Lemodèle causal probabiliste CPM, proposé par(Peng 1990) et généralisé par (Dubois 1995) offredes formalismes d’apprentissage analytique etprobabiliste. Cet apprentissage consiste àapprendre des connaissances méthodologiques àtravers peu d’exemples, souvent un seul, et unetrès riche théorie du domaine. La résolution de

contraintes spatiales est une activité nécessaire pourl’instanciation des modèles topologiques de con-figuration spatiale et s’appuie sur le raisonnementspatio-temporel issu de la logique (Allen 1983;Donikian 1992).

Le paradigme de notre approche de résolutiondu problème de conception s’exprime par les règlessuivantes :

R1: Si le concepteur ne sai pas comment construirela scéne, alors la nouvelle solutin = inférencede la solution existante, la plus similaire +clonage de la soluti existante, la pls similaire+ éventuelle modification.

R2: Si le concepteur sait comment construire lascéne, alors la nouvelle solution = description+ répresentation + compilation + génération+ classification.

L’opération clonage vise la dérivation d’unecopie “générique” de la méthode de constructionde la scène (ou une partie de la scène) référencéecomme solution existante et son instance la plussimilaire. La copie sera reinstanciée comme unenouvelle solution dans un nouveau contexte (lascène d’accueil référencée). La nouvelle solutionsera renommée et peut subir des modificationséventuelles. Par exemple la scène intermédiaire“scène hublot” de la Figure 17 crée par la méthode“génére.hublo,” montrée dans l’image sur la Figure19, est dérivée da la scène intermédiaire“scene_roue” et modifiée (activité de modificationlocale sans affecter le reste de la scène) selon lespoints de vue “dimensions” et “aspectphotométrique”. La recherche de solutionsexistantes et le test de l’évaluation de la similarités’effectue à l’aide d’heuristiques décisionnelles(causales probabilistes) reste au dehors del’intention de ce travail.

EnvironnementL’environnement d’aide à la conception

constitue le contexte d’utilisation du langage SOML.Son architecture est fondée sur le couplage d’unmodeleur géométrique CSG (MoCSG) régulariséet étendu, un interpréteur ( IntpSOML) deprogrammes (PgSOML), un module de traitementdes connaissances (TrCo), une interface graphique


330

ization) and can be instantiated at different levelsof the hierarchy. This characteristic makes it pos-sible to simplify the modeling phase of a designsession, the price being a loss of details (Plemenos1996b) A possible inference goal could be knowl-edge classification, i.e. finding the class of anobject of which one knows an instance. The “Meth-ods” point of view, for example, regroups the dif-ferent methods used in constructing the componentsof a domain. These methods make up the hierar-chies of resolution tasks in terms of methodologicalknowledge.

Causal probabilistic knowledge and MCP. Thecausal-probabilistic model describes the causalrelations existing among units of knowledge, de-noted by the terms “causes” and “effects” (manifes-tations). Causal knowledge is “deeper” than theheuristic knowledge used by a designer to solve aproblem. The Sy system corresponding to a de-scription has definite states defined by n-tuples ofbinary attributes (Dubois 1995). According to thissystem, If ai = 1, there are manifestations mi; and ifai = 0, they are absent. If there are no manifesta-tions present, we say that the system is in its nor-mal (initial) state and can be described by n-tuplesof the form (0,...,0).

Let M denote a set of n possible manifesta-tions (m1...mn). Let D denote the set of direct causesof these manifestations (d1...dn). a cause can bepresent or absent. To each di is associated a seteffects (di) of manifestations which are a conse-quence of the presence of the causes di. The rela-tion R on DxM is defined as (di,mi) ∈ R ⇔ mi ∈effects (di). And this associates the manifestations

OBR. The universe of the scene is represented bya collection of cognitive objects structured hierar-chically by class, instances and multiple points ofview. These objects are autonomous, characterizedby the object-oriented knowledge representationOBR. A generic family of objects itself is modeledby a concept, subdivided according to differentpoints of view (Figures 1-3). The objects communi-cate between themselves and the environment bythe help of data exchange interfaces in a specialunified format for all types of designed scenes.

In terms of data the classes of properties (in-cluding the constraints) can be likened to the fields(members) of a structure. The range of possiblevalues for the fields is defined in the space of primi-tive types (integers, reals, character strings, or struc-tured data types). The objects are considered fromdifferent “viewpoints.” Each viewpoint determinesa set of fields visible from it. For example, the scenecan be regarded as a complex geometric shape(Geometric Class of Shapes), as an object locatedat a precise point of space (Spatial Configurationviewpoint), as a structure composed of objects fromother scenes (Class of Composition), etc. This mul-tiple-viewpoint approach has the advantage of alocal grouping of the properties classes relevant toa particular vision of the designer, in conformitywith his area of expertise. The classes of instancesof concepts making up a “viewpoint” are hierar-chically-structured.

This procedure presents the advantage of alocal and distributed approach, allowing for par-allel and cooperative design of scenes. The classesare hierarchical (interms of the relation of special-

enecs_fo_tpecnoCstniopweivnoitisopmoc_fo_epytelpmisxelpmoctxetnoc

noitcelloctnenopmocsetubirtta_fo_sessalcseitreporp_tniopweivsdohtem_tniopweivstniartsnoc_tniopweiv

=::=::=::=::=::=::=::=::=::=::=::=::

stniopweivsetubirtta_fo_sessalc|noitisopmoc_fo_epyt

xelpmoc|elpmis]txetnoc[tnenopmoc

]txetnoc[MGevitimirp|noitcellocxelpmoc|elpmis|gnithgil|noitavresbo|tniopecnerefer

}tnenopmoc{eman MGevitimirpdi

stniartsnoc_tniopweivsdohtem_tniopweivseitreporp_tniopweiv...egdelwonk_citsilibaborp_lasuac_sessalcnoitarugifnoc_laitaps_sessalc

|slavretni_ciremun_sessalc|stniartsnoc_cirtemoeg_sessalcezis_tniartsnoc_sessalc|slavretni_laitaps_sessalc

Figure 2. BNF definition of the OBR scene concept.

331


utilisateur (IGU), le logiciel de visualisation–rendud’images POV-Ray (RePov), et les bases dedonnées: connaissances (BaCo), donnéesgraphiques (DoGra), données images (DoIm) et leshell Unix.

L’architecture de l’environnement est conçueen vue de fournir des moyens nécessaires pourl’application de l’approche de modélisationdéclarative dans la conception de scènes, enutilisant des stratégies et des techniques deraisonnement qualitatif et des heuristiquesexploratoires causales-probabilistes. Le but duraisonnement concerne l’obtention d’une réponseaux questions sur la composition (par ex. Quellessont les composants d’une scène ?), la géométrie(p. ex. Quelle est la scène avec les proportionsdonnées ?), la configuration spatiale (par ex.Quelles sont les configurations possibles dansl’espace disponible ?) et l’aspect réaliste desscènes (par ex. Quelles sont les scènes avecl’apparence donnée ?).

Le couplage des outils est fait à base d’actionsd’échange de données. Celui-ci offre les avantagesd’une gestion et manipulation modulaire desdonnées par l’intermédiaire du langage en utilisantdes stratégies d’optimisation basées sur lesconnaissances causal probabilistes. Dans lesparagraphes suivants nous présentons le supportthéoriques du contexte conceptuel et l’architecturedu langage SOML. Ils sont spécifiés en termes demodèles conceptuels et logiques, exprimés parclasses à objets et leurs associations. Le formalismede représentation choisi est l’utilisation desdiagrammes conceptuels UML.

Couche connaissances et CRMA ce niveau de la hiérarchie, les fonctionnalités

sont définies conformément au modèle conceptuelde résolution CRM (Conceptual Resolution Model).Ce modèle est construit sur la base de conceptsissus du formalisme objet orienté multi-vuesOBR(Objects based representation) de modélisationde connaissances du domaine (Caponi 1995) etdu modèle de raisonnement basé à l’applicationdes stratégies de résolution causal probabilisteCPM.

Selon CRM, une scène est vue comme unmodèle cognitif du monde de la conception. Lespropriétés et les contraintes des scènes mais aussiles méthodes de leur traitement, sont définies commedes objets cognitifs–unités de connaissance. Ils con-stituent les connaissances du domaine selon lesdif férents points de vue sur la scène. Lesconnaissances sont structurées à base du formalismeOBR définie par la méthodologie SHIRKA-TROPES(Caponi 1995; Schmeltzer 1995). Le CRM permetl’énumération et l’attachement de propriétés ou descontraintes aux objets des scènes et l’applicationde stratégies de résolution définies par CPM.

Le multi point de vue, classes, instances etOBR. L’univers de la scène est représenté par unecollection d’objets cognit i fs structuréshiérarchiquement par des classes, des instances etdes multi-points de vue. Ces objets sont autonomes,caractérisés par une représentation de sesconnaissances orienté objets. Une famille génériqued’objets se modélise par un concept, partitionnéen différents points de vue (Figures 1-3). Les objetscommuniquent entre eux et l’environnement par le

enècs_fo_tpecnoCweuvnoitisopmoc_ed_epytelpmisexelpmocetxetnocnoitcelloctnasopmocsetubirtta'd_sessalc

sétéirporp_euv

sedohtém_euv

setniartnoc_euv

=::=::=::=::=::=::=::=::=::=::

=::

=::

seuvsetubirtta'd_sessalc|noitisopmoc_ed_epyt

exelpmoc|elpmis]etxetnoc[tnasopmoc

]etxetnoc[MGevitimirp|noitcellocexelpmoc|elpmis|noitanimulli|noitavresbo|erèper

}tnasapmoc{eman eman eman eman eman MGevitimirpdi

setniartnoc_euvsedohtém_euvsétéirporp_euvsetsilibaborp_selasuac_sessalcelaitaps_noitarugifnoc_sessalc

snoitamroféd_te_seuqirtémoég_sevitimirp_sessalcerusem_te_noisnemid_etsilaértcepsa_sessalc|noitacifidom_te_noitidé'd_sessalc|euqirtèmarap_elèdom_ed_noitarénég_sessalc

setniartnoc_ed_noitcafsitas_sessalc|elasuac_ecneréfni_sessalc|seuqirémun_sellavretni_sessalc|seuqrtemoég_setnartnoc_sessalc

elliatsetnartnoc_sessalc|selaitaps_sellavretni_sessalc

Figure 2. Définition BNF du concept de scène selon OBR.


332

for the design.

For each ”view” of the scenes one creates alocal knowledge base, represented by a bipartitegraph with two types of nodes: the nodes di repre-senting the direct causes of the effects mi and thenodes of the effects mj (Figures 3, 5). To the edgesjoining the two types of nodes are associatedprobabilistic weights cij (strength of causality) re-flecting domain knowledge in terms of normalizednumeric values in the interval [0,1]. For examplethey can be the frequency of occurrence of thecognitive concept of a scene property in an event(scene present). The basis is completed by the ad-dition of a priori probabilities of the existence ofthe causes di in a domain.

Probabilistic knowledge about a domain isused to calculate a criterion named “measure oflikelihood”, which makes it possible to evaluatethe plausibility of the different hypotheses aboutpotential solutions in terms of coverings. As men-tioned above, it is possible to have other semanticassociations between the two types of nodes ofFigure 3. The nodes di for the direct causes, in-stead of representing scenes, could represent prop-

with the causes.

For a Sy system there are various possibleschemes of semantic associations, allowing one toobtain different types of solutions. For example, ifone is interested in representing the taxonomy ofthe scenes based on their different properties, it isappropriate to associate to the manifestations Mthe concepts of properties (or property attributes),and to the causes D, the concepts of scenes pos-sessing these properties. All this expresses the factof having one class of properties due to the exist-ence of scenes characterized by these properties.

Given a set M+ representing the set of prop-erties that are present (described or required), thesolution to a design problem consists in finding thescene having these properties. We define the setM- = M - M+ = ¬M+, to be the set of propertiesthat are not present, that is, all the manifestationspresent are observable. The mode of abductivereasoning used here allows us to look for possiblecauses (e.g. scenes) explaining or justifying theeffects (eg. the properties) observed. In other words,we look for explanations in terms of possible exist-ing scene solutions for the set of properties required

Figure 3. Example of creation of a local base of hybrid knowledge (view “materials”, scene “locomotive”).

wood m.color

loco.2

b.blanc

châssis.2

wood m.color

loco.1

b. v&r

cabin.1

b. blanc

châssis.1

Aspect viewpoint (attributs)

b. vert

cabin.2

b.noir

motor.1b. noir

motor.2

description

Viewpointrealistic aspect.materials

cabin = cause(loco) ;châssis = cause(loco) ;

CPRepresentation

External declarative model

Local internalmodel

Propertieswood white&green&red (loco.1)

wood bla&ve&no (loco.2)wood green&red (cabin.1)wood white&red (cabin.2)wood white (châssis.1)wood white (châssis.2)wood black (motor.1)wood black (motor.2)

Knowledge base

OBRRepresentation

Classification Knowledge

m1

d2

m1

d1

d2

Causal viewpoint(attributs)

d1

d3d3

c11

c21

c31

c11

c21

c31

Causal-probabilisticknowledge

effeteffet

causes causes

333


biais d’interfaces d’échange de données dans unformat particulier unifié pour tous les types de scènesconçues.

En termes de données, les classes despropriétés (les contraintes inclues) peuvent êtreassimilées aux champs d’une structure. Lesdomaines des valeurs des champs sont définis dansl’espace des types de primitives (entiers, réels,chaînes de caractères ou de types structurés). Lesobjets sont vus de différents «points de vue».Chaque point de vue détermine un ensemble dechamps visibles par celui-ci. Par exemple, la scènepeut être vue en tant qu’une forme géométriquecomplexe du point vue Classes géométriques deformes, un objet situé à un endroit précis dansl’espace selon le point de vue Configurationspatiale, une structure composée d’autres objetsde scènes spécifiées dans Classes de composi-tion, etc. Cette approche multi-vues présente lesavantages d’un regroupement local des classes depropriétés pertinentes par rapport à une visionparticulière du concepteur, conforme à sacompétence. Les classes des instances des con-cepts dans un «vue» sont structurées

hiérarchiquement.

Cette démarche propose l’avantage d’untraitement local et distribué, permettant une con-ception parallèle et coopérative de scènes com-plexes. Les classes sont hiérarchiques (par relationde spécialisation) et peuvent être «instanciées» auxdif férents niveaux de la hiérarchie. Cettecaractéristique permet la simplification de l’étapede modélisation dans une session de conception,au prix d’une perte de détails (Plemenos 1996b).Un possible but d’inférence peut être la classifica-tion de la connaissance, c’est-à-dire la recherchede la classe d‘un objet auquel on connaît l’instance.

Le point de vue Méthodes par exempleregroupe les différents méthodes utilisées pour laconstruction des composants d’un domaine (Fig-ure 4). Ces méthodes constituent des hiérarchiesde tâches de résolution comme étant desconnaissances méthodologiques.

Connaissances causales probabilistes et CPM.Le modèle CPM (Causal Probabiliste Model) décritdes relations causales existantes entre les unités deconnaissances, dénotées par les termes «causes»

Figure 3. Exemple de création d’une base locale des connaissances hybrides (Vue “Matériaux”, scène “locomotive”).

bois m.couleur

loco.2

b.b lancchâssis.2

bois m.couleur

loco.1

b. v&r

cabine.1

b . blanc

châssis.1

vue aspect (attributs)

b. vert

cabine.2

b.noir

moteur.1b. noir

moteur.2

description

Vueaspect réaliste.matériaux

cabine = cause(loco) ;châssis = cause(loco) ;

ReprésentationCP

Modèle déclaratif externe

Modèleinterne local

Propriétésbois blanc&verte&rouge (loco.1)

bois bla&ve&no (loco.2)bois vert&rouge (cabine.1)bois blanc&rouge (cabine.2)

bois blanc (châssis.1)bois blanc (châssis.2)bois noire (moteur.1)bois noire (moteur.2)

Base de connaissances

ReprésentationOBR

Connaissances declassification

m1

d 2

m1

d1

d 2

Vue causale (attributs)

d 1

d 3d3

c11

c21

c31

c11

c21

c31

Connaissances causalesprobabilistes

effeteffet

causes causes


334

Figure 4. Example of tasks/methods of geometric parametric model generation for the “locomotive” scene.

Figure 5. Logical representatiion of the causal dependencies by means of matrices.

erties, and the effects mi, instead of representingproperties, could represent scenes (Figure 5). Thesymbols cgij express the probabilistic weights inthe heirarchical causal graph, where edges arejoined by means of a logical operator ET. In thecase where this connection is expressed by meansof the logical “or” operator, we use the symbolcgij. For the example in Figure 5 each row of thecausal dependency matrix allows one to infer aproperty, and each column of the matrix allowsone to infer a scene.

We are also interested in knowing all thecauses belonging to the alternative possible cover-ings which can lead to a given state of the systemSy, and furthermore to propose an arrangement ofthe coverings, considered as hypothetical solutions,in terms of their level of likelihood. The coveringscan be classified as being redundant or non-re-dundant. The concept of a covering is useful forfinding subsets of instances of property attributes

that will lead to solutions in terms of scenes. Weare interested in non-redundant coverings satisfy-ing the specified optimization criteria.

We define a non-redundant covering M+ asbeing the set of causes di ∈ D, linked with themanifestations mi ∈ M+, and not containing anysubsets that are also coverings of M+. The hypo-thetical coverings are calculated by exploring thegraph of the CPM model. For this one needs thenotion of “alternative generators” and the algebraicoperation on sets: division, remainder, augmentedremainder, that are derived from the classical setoperations union, intersection and difference. (Peng1990). By applying the operations union (joining)and projection to the local CPM graphs, one ob-tains the global basis for the scene concept. Fig-ures 6-7show possible inference examples in termsof coverings (Peng 1990) for the causal knowl-edge base of Figure 5. The two coverings loco.1

locomotived causes m m:d m1 (d1 )

loco.1 d1(m1) ca11

l 2 d ( )

d est cause de m m:d m1

(d1 )m2

(d2 )mj

(dj )

chassis.1 d1 (m1) cg11 cg12

cabin.1 d2 (m2) cg21

cabin.2 d3 (m3) cg32

machine.1 d4 (m4) cg41 cg42

object.i d5 (m5) ca51

Bilateral passage d ↔ m

m - effect = name of scene conceptd - cause direct = name of propertyc onceptm:d - event "d is a possible direct cause of m"

ca - weight of an alternative ORcg - weight of a genera tor AND↔ - exchange

Inference of property d1 d2

chassis.1 m1 cg11 cg12

Inference of scene m2

chassis.1 d1 cg12

cabin.1 d2 cg32

cabin.2 d3 cg42

object.i d5 ca52

Classes of generating tasks Input Output1. task .motor engine, chimney motor2. task .chassis front suspension

rear suspensionchassis

3. task .cabin roof, win.l &win.r.4. task .engine5. task .chimney6. task .roof7. task .left window.

&right window8. task .left wheel9. task .right wheel10. task .front suspension11. task .rear suspension12. task .door13. task .link14. task .cylinder15. cube

Tâchelocomotive

1 32

10

11

4 6

7

98 76

1 514

15 Méthode élémentaire de bibliothèque

Entrée Sortie

335


Figure 4. Exemple de tâches/méthodes de génération de modèle géométrique paramétrique de la scène “locomotive.”

Figure 5. Types of possible inferences from a causal knowledge base. [Représentation logique des dépendances de causalité par matrice.]

Figure 7. Examples of inference of covering solutions. [Exemples d’inférence de soluti couvertures.]

Figure 6. Types of possible inferences from a causal knowledge base. [Types d’inférences possibles à partir d’une base de connaissancescausales.]

locomotived est cause de m m:d m1 (d1 )loco.1 d1(m1) ca11

loco.2 d2(m2) ca21

d est cause de m m:d m1

(d1 )m2

(d2 )mj

(dj )châssis.1 d1 (m1) cg11 cg12

cabine.1 d2 (m2) cg21

cabine.2 d3 (m3) cg32

machine.1 d4 (m4) cg41 cg42

objet.i d5 (m5) ca51

passerelle bilatérale d ↔ m

m - effet = nom de concept de scèned - cause directe = nom du concept de propriétém:d - événement "d est une cause possible directe de m"ca - poids d'une alternative OR (OU)cg - poids d'un générateur AND (ET)↔ - remplacement mutuelle

Inférence propriété d1 d2

châssis.1 m1 cg11 cg12

Inférence scène m2

châssis.1 d1 cg12

cabine.1 d2 cg32

cabine.2 d3 cg42

objet.i d5 ca52

Classes des tâches degénération

Entrée Sortie

1. tâche .moteur engin, cheminée moteur2. tâche .châssis suspens. avant,

suspens. derrièrechâssis

3. tâche .cabine toit, fen.g&fen.d.4. tâche .engin5. tâche .cheminée6. tâche .toit7. tâche .fenêtre gauche.

&fenêtre droite8. tâche .roue gauche9. tâche .roue droite10. tâche .suspens. avant11. tâche .suspens. derrière12. tâche .portière13. tâche .liaison14. tâche .cylindre15. cube

Tâchelocomotive

1 32

10

11

4 6

7

98 76

1 514

15 Méthode élémentaire de bibliothèque

Entrée Sortie

propriétés annoncés propriétés inférés (solutions couvertures)

1 {di } ⊂ D {mj } ∈ M, di : mj {dij} ∈ { di : mj | di }, {di } ∈ D

2 {mj+} ⊂ M {dij }∈ {di : mj | di }, {di } ∈ D

3 {di }, {mj +}, {di } ⊂ D, {mj

+} ⊂ M {dij } ∈ {di : mj | di }, {di } ∈ D, {mj } ∈ M

4 {mj +}, {di }, {di } ⊂ D, {mj

+} ⊂ M {dij } ∈ {di : mj | di }, {di } ∈ D, {mj } ∈ M

propriétés annoncés propriétés inférés (solutions couvertures)«␣ ,␣ » = ET logique

1 {châssis.1} ⊂ {loco.1, loco.2} {chassis.1, cabine.1, cabine.2, machine.1, objeti}{châssis.1 : loco.1 , chaâssis.1: loco.2}loco.1 = { chassi.1, cabine.1, machine.1}loco.2 = { chassi.1, cabine.2, machine.1}

2 {loco.1} ⊂ {loco.1, loco.2} {chassi.1, cabine.1, machine.1}

{loco.2} ⊂ {loco.1, loco.2} {chassi.1, cabine.2, machine.1} OU{ objet.i}3 {châssis.1 }, {loco.1}, loco.1 = {chassi.1, cabine.1, machine.1}4 {loco.2}, {châssis.1 } loco.2 = {chassi.1, cabine.2,machine.1} OU{obej.i}


336

and loco.2 offer alternative explanations for theexistence of the “locomotive” scene. This provesuseful in the situation described in R1 above. Ifinformation about the designer’s intended scene islimited and insufficient, he can formulate a requestfor help, by describing his goals (scene concepts,represented by tasks and their methods (Figure 4).The request leads to a prediction of one or morescene concepts and their properties. These lead tothe generation of hypothetical solutions nine setsof instances of classes of attributes in causal rela-tion with the concepts stated as goals).

modeling layerTo this level of the hierarchy, the functionality

is defined consistently to the functional model ofSOML language. This model is build on the baseof functionality concepts kept on this work phase,represented in terms of class in the diagram of theFigure 8.

Functional concepts and geometric internalmodel. The SOML language permits the creationof geometrical scene models which can be modi-fied in later stages of the design process. The nec-essary mechanisms for these activities are groupedinto the classes Edition, Generation- Integration,Spatial Configuration and Interrogation. Theseclasses contain mechanisms for a) instantiation andintegration of the primitive components in order toobtain a final solution (Generation- Integration); b)modification of the solution shapes, the photo-real-istic aspect and the context (Edition); c) position-ing and reconfiguration of scenes and their com-ponents in 3D space (Spatial configuration); d)obtaining answers to the questions about the statesof scenes (Interrogation).

According to the conceptual model, presentedbriefly in the previous paragraphs the prototype offinal solution of a scene is a set of instances of thedata structure fields of the properties class. Thissolution is generated from the geometric paramet-ric model of the scene in a process of constraintresolution and qualitative reasoning on the spatialconfiguration. The geometric parametric model ofscene is a list of SOML commands stored in thegraphical data base (DoGra) of the environment.The command structure is constituted from lexicalelements of the geometrical canonical primitives of

POV format. This presents the advantage of onefacilitated coupling of geometrical model instanceswith the rendering software POV-Ray.

The list of commands contains implicitly theCSG tree of geometrical and appearance primi-tives, of not instanced variable of their parameters,a set of geometrical transformations and a bool-ean operations permitting one to make a solutionexplicit by means of a graphical photo-realisticshape. The code of the model is “compiled” bythe interpreter of the environment from the methodsof the scenes tasks.

Spatial configuration, qualitative resolution,and positioning scenario. A scene is constitutedeither of individual components located in 3Dspace, or of components to be used in a futureassembly. In each case one is faced with the prob-lem of spatial configuration, constituting a task ofpositioning. In a declarative way the user expresseshis goal , usually in a qualitative manner, using thesyntax and vocabulary of positioning provided bynatural language (Donikian 1992). The statementis converted into coordinates in the local referencesystem of the scene. We now examine how to simu-late the problem of declarative control of the 3Dobjects’ spatial configuration.

The method used is based on the formalism ofspace discretization by means of trees of “octree”form and Allen spatial intervals (Mäntylä 1988;Foley 1995). The target space is considered to belike a box with dimensions width, height and depth,measured with respect to the frame of referencechosen for that specific context. The volume of thisspace is recursively subdivided into octants, up tothe moment where primitive boxes will be com-pletely bounded. The bounding boxes O of posi-tioned objects have the dimensions O.width,O.eight and O.depth, defined with respect to theframe of reference.

generation layerOnce the parametric model of the scene is

created, it must be instantiated by the values of thenumeric constraints.

The system of coordinates. The system of co-ordinates (frame of reference of the scene) used is

337


et «effets» (manifestations). Les connaissancescausales sont «plus profondes» que lesconnaissances heuristiques utilisées par leconcepteur pour résoudre un problème.

Le système Sy du à une description possèdedes états définis par le n-uple d’attributs binaires(a1,.., ai, ., an) (Dubois 1995). Si ai = 1, onaccepte qu’il y a des manifestations mi présentes,et si ai = 0, les manifestations mi sont absentes. S’iln’y a pas de manifestations présentes, nous disonsque le système Sy se trouve dans son état normal(initial) et qu’il peut se décrire par des n-uples (0,..., 0, ..., 0).

Soit M la dénotation d’un ensemble de nmanifestations possibles {m1, .., mj, .., mn}. Soit Dun ensemble de causes directes des manifestationspossibles {d1,.., di, ., dk}. Une cause peut êtreprésente ou absente. Pour chaque di est associéun ensemble effets(di) de manifestations qui sontune conséquence de la présence des causes di.La relation R sur D × M est définie comme (di, mj)Œ R ´ mj Œ effets (di) et celle-ci associe des mani-festations et des causes.

Pour un système Sy sont possibles différentsschèmes d’associations sémantiques, permettantd’obtenir différents types de solutions. Par exemplesi l’on s’intéresse de représenter les taxonomies desscènes par rapport aux différentes propriétésqu’elles possèdent, il est convenable d’associer auxmanifestations M les concepts de propriétés (en-core attributs de propriétés) et aux causes D lesconcepts de scènes possédant ces propriétés. Tousceci exprime le fait d’en avoir une classe depropriétés due à l’existence des scènes, caractériséspar ces propriétés.

Etant donnée un ensemble M+ de propriétésprésentes (décrites ou demandées par une requête),le problème de résolution résulte d’en trouver la(es) scène(s) qu’elle puisse(ent) posséder lespropriétés de l’ensemble M+. Nous supposons quel’ensemble M- = M - M+ = ¬(M+) est l’ensemble depropriétés absentes, c’est-à-dire toutes les manifes-tations présentes sont observables. Le mode deraisonnement abductif que nous utilisons permet larecherche de causes (par ex. scènes) possiblesjustifiant (ou expliquant) les effets (par ex. les

propriétés) observées. Autrement dit, nouscherchons des explications en termes de solutionsde scènes existantes possibles pour un ensembledes propriétés demandés pendant une conception.

Pour chaque «vue» des scènes, on crée unebase locale, représentée par un graphe bipartiepossédant deux types de noeuds: les noeuds dides causes directes de l’effet mj et les noeuds deseffets mj (Figure 3, Figure 5). Aux liens entre cesdeux types de noeuds sont associés des poidsprobabilistes cij, (force de causalité) reflétant lesconnaissances du domaine en termes des valeursnumériques normalisées dans l’intervalle [0,1]. Parexemple elles peuvent être les fréquencesd’occurrences de chaque concept cognitif depropriété de scène dans un événement «scèneprésente». La base est complétée aussi par desprobabilités à priori de l’existences des causes didans un domaine.

Les connaissances probabilistes du domaineservent à calculer un critère, appelé «mesure devraisemblance» permettant l’évaluation de lacrédibilité des différentes hypothèses de solutionspotentielles en termes de couvertures. Comme il aété déjà noté plus haut il est possible d’en avoird’autre type d’associations sémantiques sur les deuxtypes des noeuds de la Figure 3. Les noeuds dides causes directes au lieu de représenter desscènes, ils peuvent représenter des propriétés, etdes effets mj au lieu de représenter des propriétés,ils peuvent représenter des scènes (voir la Figure5). Les symbole cgij expriment les poidsprobabilistes dans le graphe causal hiérarchique,où les branches sont liées avec un opérateur ETlogique. Dans le cas où cette liaison est expriméepar l’opération OU logique nous utilisons lesymbole caij. Pour l’exemple de la Figure 5, chaqueligne de la matrice de dépendances causalespermet d’inférer une propriété et chaque colonnede la même matrice permet d’en inférer une scène.

Nous nous intéressons aussi de connaître toutesles causes appar tenant aux couver turesconcourantes (alternatives) possibles qui peuventconduire vers un état donné du système Sy, et enplus de proposer un rangement des couvertures,considérées comme des hypothèses des solutionspossibles selon leur niveau de vraisemblance. Les


338

of type” left-handed”: the X axis is oriented to theright of the screen before the observer, the axis Y isoriented upward and the Z axis is oriented awayfrom the observer. The dimensions on the three axesare expressed by some real number or by the per-centage with regard to the 3D of the boundingvolume where there exists the equivalence right ↔“+ X,” left ↔ “ -X,” high ↔ “+ Y,”low ↔ ” -Y,”before ↔ “ Z” and behind ↔ “+ Z.” The localiza-tion in the reference point O(X, Y, Z) ↔ O(right,high, behind) is specified by vectors of real of oneor three arguments. For the position, the orienta-tion, the dimensions and their modifications oneuses geometric parametric transformations, in ourcase according to expression 3-1, 3-2, 3-3(Foley1995).

Parametric model of the primitives. The ge-neric parametric primitives are represented by somecharacteristic points according to the visualization

format of POV. An example of such (canonical)primitives is the sphere algebraic class representedby the points {<CENTER>, RADIUS}.

In the following paragraph we present thebasic theoretical concepts and the principal tech-niques used for the definition and the experimenta-tion of the data storage definition model, exploredby SOML during a design session

Data Model. In terms of data a concrete so-lution consists in a list of instances of the param-eters of the geometric primitives of the model, sat-isfying the imposed constraints. These data have aparticular format visible by means of the renderingsoftware POV and they reside in the graphical database. The data of one scene solution are definedin the object-oriented conceptualization formalismaccording to the diagram presented in the Figure11. This model defines the concepts and the classes

Figure 9. Class diagram for the internal parametric model.

SOML Functions

Spatialconfigura tion

Editing GenerationIntegration

Interrogation

Modification ofscene

Modification ofcontext

Consultation ofbases

Consultation ofdata

Consultation ofknowledge

Parametric scene

Data of type"param"

component Data of type"delta"

Operationscontext

Observation Baseconsultation

Data consultation Knowledgeconsultation.

Light Reference point

Figure 8. Diagram of functional classes for SOML.

339


Figure 8. Diagramme des classes de fonctis mantenues par SOML.

Figure 10. Calculation of the parameters of an instance of the object “Instance_paramscene.” [Calcule des paramètres géométriques d’uneinstance de l’objet “Instance_paramscene”.]

Figure 9. Diagramme des classes du modèle paramétrique interne.

Scène paramétrique

Données"param"

composant Données"delta"

Opérationscontexte

Observation Consultation desbases

Consultationdes données

Consultationde connaiss.

Lumière Repère

Fonctions SOML

Configurationspatiale

Edition Générationintégration

Interrogation

Modificationscène

Modificationcontexte

Consul tation desbases

Consultation desdonnées

Consultation deconnaissances

op rations de transformationop rations de transformationop rations de transformationop rations de transformationop rations de transformation

X

Y

Z

f

X

Y

Z

X deltaX

Y deltaY

Z deltaZ

deltaX

deltaY

deltaZ

*

*

*

* *

* *

* *

*

*

*, ,

=

+++

0

0

0

0 0

0 0

0 0

(3-1)

* ∈{s-scale, t-translate, r-rotate, R-rayon, D-distance, A-sommet min, B-sommet max,V-vecteur de 1 arg.} f = fonction de modification

positionscène (X,Y, Z) = f (univers (X0, Y0, Z0), init(X0 + deltaX0, Y0 + delta Y0, Z0 + deltaZ0),

modif(deltaX0, deltaY0, deltaZ0)) (3-2 )

X, Y, Z coordonnées de positionnement de la scène

X0, Y0, Z0 coordonnées initiales du repère de la scène englobante

deltaX0, deltaY0,deltaZ0, incréments de modification des coordonnées de la scène englobante

deltaX, deltaY, deltaZ incréments de modification de coordonnées de la scène

modif(deltaX0,deltaY0,deltaZ0) = (X0,Y0,Z0)T+(deltaX*0,deltaY*0,deltaZ*0)

T+ (deltaX*, deltaY*, deltaZ*)T (3-3)


340

Figure 11. Conceptual diagram of the data storage model of a scene. [Schéma conceptuel du modèle de données de stockage d’unescène.

Figure 12. Sample scenario of actions involved in generating the “wheel” scene. [Exemple de scénario d’actions de génération de la scène“roue”.]

<<MetaClass>>

Sol scène

<<MetaClass>>

complexe<<MetaClass>>

simple

bases composants bases scène

deltascène

paramsscè ne

deltacompo

paramc ompo

compo locales

deltaPG

p aramPG

deltacont

paramcont

contexte

← Type données p aramètres

← Type données delta

← Type bases

← Type de attributs

← Type des bases

couches

globales

roue contexte

Base de scènes

sphère box

Base de primitives géométriques

scene.roue

PG.balle

11

scene.roue

PG.roue

9

scene.boite

PG.boite

1

7

2

scene.roue

PG.roue

10

scene.balle

PG.ba lle

4

4

scene.roue

PG.ba lle

PG.boite

5

6

8

3

341


spetS spetS

:snoitcurtsniehtgnitucexeretfa

\)llab(elpmis_etareneg)llab_llams,leehw,llab,llab_enecs(ecalp



)xob(elpmis_etareneg)xob_talf,leehw,xob,xob_enecs(ecalp

:ledomcirtemarapfonoitalipmoc

"cni.leehw_atled"edulcni#"cni.leehw_marap"edulcni#

"cni.leehw_txetnoc_atled"edulcni#"cni.leehw_txetnoc_marap"edulcni#

"cni.leehw_txetnoc"edulcni#}llab_llams{tcejbo"cni.llab_llams"edulcni#


"cni.leehw_atled"edulcni#"cni.leehw_marap"edulcni#

"cni.leehw_txetnoc_atled"edulcni#"cni.leehw_txetnoc_marap"edulcni#

"cni.leehw_txetnoc"edulcni#}llab_llams{tcejbo"cni.llab_llams"edulcni#

}xob_talf{tcejbo"cni.xob_talf"edulcni#



\)xob(elpmis_etareneg\)xob_talf,leehw,xob,xob_enecs(ecalp

noitcesretni,xob_talf,llab_llams(xelpmoc_etareneg


"cni.leehw_esab"edulcni#"cni.llab_llams"edulcni#"cni.leehw_txetnoc"edulcni#

"cni.xob_talf"edulcni#noitcesretni=leehw1GPeralced#

}}enots_talf{tcejbo}llab_llams{tcejbo{leehw1GP{tcejbo=leehweralced#

>leehw1GPsZ,leehw1GPsY,leehw1GPsX<elacs>leehw1GPrZ,leehw1GPrY,leehw1GPrX<etator

}>leehw1GPtZ,leehw1GPtY,leehw1GPtX<etalsnart}leehw_SrTmrofsnartleehw{tcejbo

Figure 14. Steps in creating the geometric parametric model of the “wheel” scene. [Les étapes de création dumodèle géométrique paramétrique de la scène “roue”.]

Figure 13. Graph of the production scenario of the spatial structure o the “locomotive” scene. [Graphe du scénariode production de la structure spatiale de la scène “locomotive.”]

Liaison 14Roue 9 Roue 1 0 suspension

Habitation 4toit Porte 2

Fenêtre 3 Cabine 8Fenêtre 3

C hâssis 13

locomotive

Machine 6

Suspension 11

Cheminée 1

Engin 6

origine

origine

Symbole graphique d’une structure spatiale

+X.droite

-X.gauche

+Y.haut

-Y .bas

-Z.avant

+Z.derrière

Point de contacteRègle de productionDernière transformation

Suspension 12


342

of objects necessary for the generation of one con-crete solution.

A scene is considered to be of “complex” typeif it must manage the data for its constituent com-ponents; otherwise it is of type “simple” and con-tains only a single geometric structure. The methodof “simple” scene generation doesn’t use booleanoperations in the final stage of the design. A sceneof “complex” type, on the other hand, is obtainedby means of methods containing instructions withregular boolean operations.

In the example of the Figure 14, the sceneobtained by the method containing the last instruc-tion “generate.simple” (ball, sphere,...) is of type"simple". In the same example the scene "wheel" isof type "complex". The two types of scenes refer tothe two classes of objects representing the basicconcepts in the data bases: "scenes database" and"components database". The class "scenes data-base" specializes to "global database" and "localdatabase."

language structureThe language is structured on the basis of a

multiple layer hierarchy of different functionalityclasses supported by the context of the design-as-sistance environment. Every class belongs to amodel and to a particular view of the scene de-fined by the conceptual model (Figure 1). Theclasses of one layer contain methods constitutingthe type of the sub-language corresponding to thelinguistic schemes at this level. One distinguishesthree levels of functionality represented by the lay-ers: knowledge (acquisition, representation), mod-eling (geometric, photometric), and generation (con-straint resolution, instantiation). To every layer cor-responds a sub-language: macro-instructions ofdescription of the methodical and causal probabi-listic knowledge; instructions for geometric andphotometric modeling; and commands, forinstantiation of primitives and of operations (geo-metric transformations, boolean operations). Suchan approach appears to be consistent with thedeclarative methodology’s characteristic feature ofallowing a certain inaccuracy and incompletenessin the scene description. By subdividing the meansof description into classes one insures the possibil-ity of conceptualizing the scenes from partial de-

scriptions of properties belonging to the knownviews.

macro-instructions and tasksThe role of the macro-instructions of the upper

layer is to provide a way of modeling the tasks ofthe design process as being methodological knowl-edge. We distinguish macro-instructions: (a) mak-ing possible, according to the concepts defined inthe MCR model, a description of the tasks, madeup of incremental methods of construction of scenesolutions; and (b) serving to describe the proper-ties and their causal dependencies according tothe CPM model. The notion of a task permits acompact and structured representation of a scenedesign problem and information about its solutionin terms of methods and scenarios of assembly/disassembly. This strategy is represented by a graphof specialization and decomposition into sub-prob-lems of reduced complexity. In the lowest layer thedecomposition of the problem becomes a singletask, and its solution strategy consists in calling onemethod from the domain knowledge base.

The simplified syntax is as follows:

task ::= macro [name_task] {knowledge}[status]macro ::= {vocabulary[argo] }vocabulary ::= generate | modify |...knowledge ::= descending | task | cause | effect | relation | inferencename_task ::= [alpha]alpha ::= letter|-|0|...|9.letter ::= a|b|...|z|A|...|Zstatus ::= complex | final | entry | exit

The strategy for executing the tasks is a causalchaining between the levels in the hierarchy. Theinference engine explores the space of the sub tasksbased on the causality knowledge, valued to dif-ferent levels of detail. The role of the reasoning isto identify the sequence of tasks to execute startingfrom data entry in a general and incomplete case.The set macro-instructions of causal links descrip-tions is intended to give causal probabilistic knowl-edge containing the identifiers of the nodes of thecauses and the effects and the values of the cau-sality strengths between those nodes.

instructions layer, taxonomy of methodsThe execution of the methods of the tasks of

343


couvertures peuvent être classifiées comme desredondantes ou irredondantes. Le concept decouverture sert à trouver des sous-ensemblesd’instances d’attributs de propriétés qui vontévoquer des instances de solutions en terme descènes. Nous nous intéressons de couverturesirredondantes satisfaisant les critères d’optimisationchoisis.

Définition : Une couverture irredondante deM+ est l’ensemble de causes di ∈ D, liées avec lesmanifestations mi ∈ M+, mais qui ne contient pasdes sous ensembles étant aussi des couvertures deM+.

Les couvertures - hypothèses sont calculées parexploration du graphe du modèle CPM. Pour cecisont ut i l isées les notions de générateursd’alternatives et des opérations algébriquesensemblistes reste, division et reste augmentédérivés des opérations classiques union, intersec-tion et différence (pour des détails voir Peng 1990).En appliquant des opérations de jointure et de pro-jection sur les graphes CPM locaux s’obtient labase de connaissances globale du concept de lascène. Les Figure 6-7 montrent des exemplesd’inférence possibles en termes de couvertures,introduit par (Peng 1990) pour la base deconnaissances causalles de la Figure 5. Les deuxcouvertures loco.1 et loco.2 sont en compétitionpour expliquer l’existence de la scène “locomo-tive.” Ceci s’avère utile dans le cas formuléantérieurement par la règle R1. Si les informationsconnues sur la scène visée par le concepteur sontréduites et insuffisantes, il peut formuler une requêted’assistance, exprimée par une description des buts(concepts de scènes, représentés par tâches et sesméthodes (Figure 4). La requête provoque laprédiction d’un ou plusieurs concepts de scènes etdes propriétés, existantes. Ces derniers déclenchentla génération d´hypothèses de solutions (ensemblesd’instances des classes d’attributs étant en relationsde causalité avec les concepts énoncés commedes buts).

Couche modélisationA ce niveau de la hiérarchie, les fonctionnalités

sont définies conformément au modèle fonctionneldu langage SOML. Ce modèle est construit à basede concepts de fonctionnalité retenus à ce stade

du travail, représentés en termes de classes dansla diagramme de la Figure 8.

Concepts fonctionnels et modèle géométriqueparamétrique interne. Le langage SOML permetla création de modèles cognitifs et géométriquesde scènes, spécifiés dans les différentes «vues» quipeuvent être postérieurement modifiées dans lesétapes successives de l’évolution de la conception.Les mécanismes nécessaires pour l’exécution deces activités sont regroupes dans les classes Edi-tion, Génération-Intégration, Configuration spatialeet Interrogation. Ces classes regroupent desmécanismes pour (a) l’instanciation et l’intégrationdes primitives des composantes afin d’obtenir unesolution finale (Génération-Intégration); (b) la modi-fication des solutions de formes, l’aspect photo etle contexte( Edition); (c) l’effectuer le positionnementet la reconfiguration des scènes et ses composantsdans l’espace 3D (Configuration spatiale ); (d)l’obtention de réponses aux questions concernantles états de scènes (Interrogation).

Selon le modèle conceptuel, présentébrièvement dans les paragraphes précédents, leprototype de solution–finale d’une scène est unensemble d’instances des champs de la structurede données des classes des ses propriétés. Cettesolution est générée à partir du modèle géométriqueparamétrique de la scène dans un processus derésolution des contraintes et de raisonnementqualitatif sur la configuration spatiale.

Le modèle géométrique paramétrique d’unescène (Figure 9) est une liste de commandes SOMLstockées dans la base de données graphiques(DoGra) de l’environnement. La structure descommandes est constituée des éléments lexicauxdes primitives géométriques canoniques du formatPOV. Ceci présente l’avantage d’un couplagefacilité des instances du modèle géométrique avecle logiciel du rendu d’images réalistes POV-ray.

La liste de commandes contient implicitementl’arbre CSG, constitué de primitives géométriqueset d’apparence, de variables non instanciées deleurs paramètres, d’un ensemble de transformationsgéométriques et d’opérations booléennespermettant d’expliciter une solution sous formed’image photo réaliste. Le code du modèle est


344

the macro-instructions layer decomposes into chainsof instructions associated to the different activitiesnecessary to construct the geometric parametricmodel of the designed scene. The instructions areinterpreted by the ISOML interpreter belonging tothe environment. The principal types of instructionsmake up the sub-languages: Generation and Inte-gration of Scenes, Configuration of Scenes, Edit-ing (modification of scenes, modification of con-text- initial bounding scene), and Interrogation (ac-cessing the graphical and knowledge data bases).

Generation and Integration of Scenes. Theinstructions of generation and integration of theprimitive are the tools for constructing scenes fromcanonical geometric and photometric primitives,by means of CSG construction operations andconstraint resolution. Reserved words are as fol-lows:

Generation and integration of scenes:generate_simple, generate_complex,generate_context, generate_box.

Scene editing: place, displace, erase, con-straint, reposition.

Modification of scenes: modifie taille, modifieorientation, initialise.

Modification of context: modify observation,modify light, modify texture.

Information gathering: create scene, attachgeometry, attach base of primitives, attach infor-mation, attach Spatial configuration,render image,visualize scene.

command statementsThe level of the commands depends on the

type of geometric modeler used and specifies theformat of the primitives expected by this modeler.The software validating this stage of the approach,SOML is based on a solids modeler that supportsstandardized expanded CSG operations, con-structed from public domain utilities availablethrough the Internet. The primitive commands key-words and syntax of commands is:

primitive commands - reserved keywords:sphere, box, cylinder, cone, plane, etc.

scene := language_directives camera{camera_items} object_statementsatmosphere_statements

global_statements{global_items}

command ::= [#declare] [name alpha] [=object][{PG1] name alpha {operation}

operation ::=␣ transform “<“ vector “>”vector ::= {axis index [PG1 name]}

axis ::= X | Y | Zindex ::= s | r | t

transform ::= scale | rotate | translate [object {] nametransform TrS_[name]}

execution scenariosThe design scripts determine the possible se-

quence of tasks, predicted in the conceptual modelof the scene. An example of such a script is shownin the Figure 12. The labels above the arrows re-flect the order of execution of the different stages.In order to facilitate the representation of the sce-nario of one spatial configuration, we propose thediagrammatic formalism based on the use ofgraphic symbols, shown in Figure 13. The advan-tage of this approach consists in the possibility ofcreating a language and a grammar of structuresfor the production of other spatial configurations.It is possible to have more than one scenario forthe construction of the target scene. These are allpart of the methodological knowledge explainedabove. A scenario is made up of a sequence oftargeted methods of executing the tasks of thescene. It can be compiled either automatically fromthe global model of scene knowledge, or as-sembled and modified with the SOML tools of theInstructions layer.

experimental resultsTo illustrate the above-mentioned ideas, in the

Figures 15-18, we present one example of thedesign of the scene of the wooden toy “train.” Thedescriptions of the known properties (Figure 15)will be converted into a set of SOML instructions(Figure 16), constituting the methods of construc-tion (Figure 17).

conclusionThe creation of software to assist with scenes

design is a difficult task due to the complexity ofthe underlying problems. Indeed the requirementsof functionality necessitate a computer system re-grouping several objects and methods of treatment.The potential advantages resulting from the use of

345


«compilé» par l’interpréteur de l’environnement àpartir des méthodes des tâches de la scène.

Configuration spatiale, résolution qualitativeet scénario de positionnement. Une scène estconstitués soit de composants individuels localisésdans l’espace 3D, soit de composants d’un as-semblage futur. Dans les deux cas on se heurteavec le problème de configuration spatiale,constituant une tache de positionnement. Dans uncadre déclaratif l’utilisateur exprime son but surtoutqualitativement par un vocabulaire appartenant auxsyntagmes locatifs du langage naturel (Donikian1992). L’énoncé est converti sous forme decoordonnées dans le repère local de la scène. Lesujet concerne la simulation du problème ducontrôle déclaratif de l’aménagement spatiald’objets 3D.

La méthode qualitative quantitative utilisée estbasée sur le formalisme de discrétisation del’espace par intervalles spatiaux d’Allen sous formed’arbre octree (Allen 1983; Mäntylä 1988; Foley1995). L’espace cible est considéré comme étantune boite avec des dimensions largeur, hauteur etprofondeur définies par rapport au repère ducontexte choisi. Le volume de cet espace estpartitionné recursivement en octants jusqu’au lemoment où les boites des primitives à positionnerpourront être englobées complètement. Les boitesenglobantes des objets à positionner O ont desdimensions O.largeur, O.hauteur et O.profondeurdefinies par rapport du centre du repère.

Couche générationUne fois créé, le modèle paramétrique de la

scène doit être «instancié» par les valeurs desdonnées des contraintes numériques.

Le système de coordonnées. Le système decoordonnées (repère de la scène) utilisé est de type«main gauche»: l’axe X est orientée vers la droitede l’écran devant l’observateur, l’axe Y est orientévers le haut et l’axe Z est orienté dans le sensopposé de l’observateur. Les mesures sur les troisaxes sont exprimées par des réels ou par lepourcentage par rapport aux 3 dimensions duvolume englobant où il existe l’équivalence droite↔ « +X », gauche ↔ «-X», haut ↔ «+Y» , bas ↔«-Y «, avant ↔ «-Z» et arrière ↔ «+Z».

Les allocations dans le repère O(X,Y,Z) ↔O(droite, haut, arrière) sont spécifiées par desvecteurs de réels de 1 ou 3 arguments. Pour laposition, l’orientation, les dimensions et leurs modi-fications on utilise des transformations géométriques,parametrées dans notre cas selon expression 3-1,3-2, 3-3 (Foley 1995).

Modèle paramétrique des primitives. Les primi-tives génériques paramétriques, sont représentéspar des points caractéristiques selon le format devisualisation POV. Un exemple de telle primitivecanonique est la classe algébrique sphèrereprésentée par les points caractéristiques { <CEN-TER > , RADIUS }.

Dans le paragraphe suivant nous présentonsles concepts théoriques de base et les techniquesprincipales ut i l isées pour la défini t ion etl’expérimentation du modèle de définition desdonnées de stockage, explorés par SOML au coursd’une session de conception

Modèle des données. En termes de donnésune solution concrète se traduit dans l’obtentiond’une liste d’instances de paramètres des primi-tives du modèle géométrique satisfaisant lescontraintes imposées. Ces données possèdent unformat particulier visible par le logiciel de renduPov est elles résident dans la base de donnéesgraphiques. Les données d’une solution de scènesont définies dans le formalisme conception objetorienté selon le schéma conceptuel présenté dansla Figure 11. Ce modèle définit les concepts et lesclasses d’objets nécessaires pour la générationd’une solution concrète.

Une scène est considérée comme un type«complexe» si elle doit gérer les données descomposants qu’elle englobe par contenance sinonelle est du type «simple» et elle ne contient qu’uneseule structure géométrique. Les méthodes degénération de scènes «simples» n’utilisent pasd’opérations booléennes à l’étape finale de laconception. La scène de type «complexe» aucontraire, s’obtient par l’intermédiaire des méthodescontenant des instructions ayant des opérationsbooléennes régulières.

Dans l’exemple de la Figure 4-5, la scène


346

the language consists in its functionality enabling itto be of assistance during all stages of the designprocess of complex scenes. Beyond these initialencouraging results, there remains to improve thedegree of application of these cognitive techniquesof representation and knowledge exploitation; tointegrate Bayesian learning; to perfect theterminology(i.e. to create a base of terminologicalknowledge, BCT, that will facilitate the use of theSOML language for different types of applications);to develop a linguistic scheme; and to create aconvivial work environment.

To this end, as already emphasized, the SOMLlanguage makes possible the creation of modelsof scenes, including such features as geometry,topological configurations, realistic aspects, meth-ods of construction, etc., that can be modifiedduring subsequent stages of the design process.Indeed, a designer’s most important task is to makeprecise the often vague and ambiguous objectivesstated by the client or by specialists from other fields,to fulfill these objectives, and thereby identify thefundamental purpose of the system (Rivero 1977).

By analyzing how a designer works, we canenvisage an application of the SOML languageas design-assistance tool in Architecture. Indeed,early in the design process, when communicatingwith a client, an architect might use a sketch, whichis a link between the design concept and the realworld. By analogy with this evolving sketch, wecan say that a language which takes into accountthe descriptive declaration of the initial concept,and the possibility of reasoning in a qualitative andquantitative manner about the properties of themodel, is related to the architectural design pro-cess. We see in this language a tool based notonly on the production of synthetic and realisticimages of 3D scenes (i.e. drawings), but also ontheir development. In this process, the form is notthe result of an analysis of solutions, nor of a simplelist of functions, but rather the result of cyberneticactivity. The functions (activities) can be consideredas a process of verification of the architectural idea;the mental pre-conceptualization of a problemthroughout the evolving representation of the form(Portoghesi 1981).

The use of computers in design leads to re-

tniopweiVfoepyT noitpircseD"larutaN" snoitaleRdecudeD

fonoitpircseD1#tniopweiv

"noitisopmoC"

stnenopmoc5fopuedamsiniartenecsehT3.ocol,2.ocol,1.ocoleraevitomocolstnenopmocehT

2.nogaw,1.nogawranogawstnenopmocehT

)5,stnenopmoc()1.ocol,1.opmoc(

)2.nogaw,5.opmoc(

fonoitpircseD2#tniopweiv

"noitarugifnoClaitapS"

.tfelehtnosi1.ocoltnenopmoC.elddimehtnisi2.ocoltnenopmoC

thgirehtnosi3.ocoltnenopmoC1.ocoltnenopmocfothgirehtotsi1.nogawtnenopmoC

3.ocoltnenopmocfotfelehtotsi2.nogawtnenopmoC

)tfel_no,1.ocol()elddim_ni,2.ocol(

)thgir_no,3.ocol()1.ocol,thgir_no,1.nogaw(

)3.ocol,tfel_no,2.nogaw(

...stniopweivrehtO ..........

1 2 3 4 5 6

\ecalp\ocolocol_enecs

1.ocolniart\noitisop

\evoba\ecnatsid

0stinu6

\evom\1.ocolniart

\0rehgih\ecnatsid

0stinu7


\2.ocolniart\noitisop

\fo_thgir_ot\ecnatsid

0stinu01

\ezis_egnahc\2.ocolniart

\0rellams5.0ecnatsid

0stinu

\evom\2.ocolniart

\thgir_ot_erom\stinu7ecnatsid

\0rehgih\ecnatsid

0stinu7


\3.ocolniart\lnoitisop\fo_tfel_ot

\ecnatsid0setini02

7 8 9 01 11 21

-iart\ezis_egnahcrellams\3.ocoln

5.0\ecnatsid\00setinu

\evom\2.ocolniart

\0thgir_ot_evom\ecnatsid

\stinu7\0rehgih\ecnatsid

\etor\2.ocolniart

_latnoziroh\0tfel_ot

\elgna\stinu06

\etor\3.ocolniart


\elgna\stinu03

-lpmoc_etareneg\0niartxe\00noinu

\stinu2\doow_etihw

\3003ocol2ocol1ocol

_yfidom\noitavresbo

\col_cniart\0tnorf_ot_erom

\06ecnatsid\0thgir_a_sulp

\ecnatsid0stinu001

# #noitcurtsni-orcam

)dohtem( )enecs( )enecs( )enecs(3.tixe

)enecs(stnemmoC

.1 leehw.etareneg llab xob - leehw leehwfonoitareneg

.2 buh.etareneg 2.llab 2.xob buh 2leehwfonoitareneg

.3 knil.etareneg tfel.edis thgir.edis exa knil knilfonoitareneg

.4 isnepsus.etareneg leehw leehw knil noisnepsus noisnepsusfonoitareneg

.5 sissahc.etareneg noisnepsus noisnepsus - sissahc sissahcfonoitareneg

.6 2.sissahc.etareneg 2.noisnepsus 2.noisnepsus - 2.sissahc 2.sissahcfonoitareneg

.7 foor.etareneg xob llab - foor foorfonoitareneg

.8 esoobac.etareneg xob g.wodniw d.wodniw esoobac esoobacfonoitareneg

.9 2.esoobac.etareneg xob g.wodniw d.wodniw 2.esoobac 2.esoobacfonoitareneg

.01 nibac.etareneg esoobac foor - nibac nibacfonoitareneg

.11 2.nibac.etarneg 2.esoobac foor - 2.nibac 2.nibacfonoitareneg

.21 yenmihc.etareneg diolobrepyh 1.edis 2.edis yenmihc yenmihcfonoitareneg

.31 enigne.etareneg 1edis rednilyc 2.edis enigne enignefonoitareneg

.41 enihcam.etareneg enigne yenmihc - enihcam enihcamfonoitareneg

.51 ocol.etareneg enihcam nibac sissahc ocol evitomocolfonoitareneg

.61 nogaw.etareneg 2.noibac 2.sissahc mpgaw nogawfonoitareneg

.71 niart.etareneg 1.ocol 1.ogaw 2.ogaw niart niartfonoitareneg

Figure 15. Part of the declarative description of the “train” scene.

Figure 16. Instructions for the construction method for the class“wooden trains:” generate.train.

Figure 17. Incremental method of hierarchical generation of the“train” scene.

347


obtenue par la méthode contenant comme dernièreinstruction genere.simple(balle, sphère, ....) est dutype «simple». Sur la même Figure la scène «roue»est du type «complexe». Les deux types de scènesse réfèrent aux deux classes d’objets représentantles concepts de base des données de stockage:«bases scènes» et «bases composants». La classe«bases scène» est spécialisée en «bases globales»et «bases locales».

StructureLa structure du langage est définie à la base

de l’architecture constituée de la hiérarchie declasses correspondantes aux dif férentesfonctionnalités supportées dans le contexte del’environnement d’aide à la conception. Chaqueclasse appartient à une couche et à une vueparticulière sur la scène définie par le modèleconceptuel (Figure 1). Les classes d’une couchepossèdent de méthodes constituant le type du sous–langage correspondant au schémas linguistiquesassociés à ce niveau.

On distingue 3 niveaux de fonctionnalitésreprésentés par les couches Connaissances (ac-quisi t ion et représentation), Modélisation(géométrique photométrique) et Génération(résolution de contraintes et instantiation). A chaquecouche correspond un sous-langage: Macroinstruc-t ions de description des connaissancesméthodologiques et causal probabilistes, Instruc-t ions de modélisation géometrique etphotometrique, Commandes d’instantiation deprimitives et d’operations ( transformationsgéométriques et opérations booleennes).

Une telle approche nous semble très cohérenteavec la caractéristique de la méthodologiedéclarative de permettre une certaine inexactitudeet incomplétude de la description. En partageantles moyens de description par classes nous assuronsla possibilité de concevoir des scènes à partir dedescription partielle des propriétés appartenant auxvues connues.

Niveau de macroinstructions et tâchesLe rôle des macroinstructions du niveau

supérieur est de fournir un moyen pour lamodélisation des tâches de la conception commeétant des connaissances méthodologiques. On

euVedepyT "ellerutan"noitpircseD setiudédsnoitaleR

edtniopednoitpircseD1°Neuv

"noitisopmoC"

stnasopmoc5edeésopmoctse"niart"enècsaL,"2.ocol","1.ocol"tnos"evitomocol"stnasopmocseL

"3.ocol"2.nogaw,1.nogawtnos"nogaw"stnasopmocseL

)5,stnasopmoc()1.ocol,1.opmoc(

)2.nogaw,5.opmoc(

edtniopednoitpircseD2°Neuv

"elaitapsnoitarugifnoC"

.ehcuagàtse"1.ocol"tnasopmoceL.ueilimuatse"2.ocol"tnasopmoceL

etiordàtse"3.ocol"tnasopmoceL"1.ocol"tnasopmocudetiordàtse"1.nogaw"tnasopmoceL

tnasopmocudehcuagàtse"2.nogaw"tnasopmoceL"3.ocol"

)ehcuag_à,1.ocol()ueilim_uà,2.ocol(

)etiord_à,3.ocol()1.ocol,etiord_à,1.nogaw(

)3.ocol,ehcuag_à,2.nogaw(

"seuv"sertua'd ..........

1 2 3 4 5 6


1.ocolniart\elaitaps_noitisop

\ed_sussed_ua\ecnatsid0setini6

\ecalped\1.ocolniart\0tuah_sulp

\ecnatsid0setinu7


\2.ocolniart\elaitaps_noitisop

\ed_etiord_ua\ecnatsid0setini01

\elliat_egnahc\2.ocolniart

\0etitep_sulp5.0ecnatsid

0setinu

\ecalped\2.ocolniart

\etiord_a_sulp\setinu7ecnatsid

\0tuah_sulp\ecnatsid0setinu7


\3.ocolniart\elaitaps_noitisop

\ed_ehcuag_a\ecnatsid0setini02

7 8 9 01 11 21

\elliat_egnahc\3.ocolniart

\0etitep_sulp\ecnatsid

0setinu5.0

\ecalped\2.ocolniart

\0etiord_a_sulp\ecnatsid\setinu7

\0tuah_sulp\ecnatsid0setinu7

\etor\2.ocolniart_elatnoziroh\0ehcuag_a

\elgna\setinu06

\etor\3.ocolniart


\elgna\stinu03

xelpmoc_ereneg\0niart

\00noinu\setinu2

\cnalb_siob\300

3ocol2ocol1ocol

_eifidom\noitavresbo

\col_cniart\0tnava_sulp

\06ecnatsid\0etiord_a_sulp

\ecnatsid0setinu001

# #noitcurtsni-orcam

)dohtem(1.eértne)enècs(

2.eértne)enècs(

3.eértne)enecs(

3.eitros)enécs(

eriatemmoC

.1 euor.etareneg ellab etiob - euor leehwednoitareneg

.2 tolbuh.etareneg 2.ellab 2.etiob tolbuh 2euorednoitareneg

.3 nosiail.etareneg hcuag.siorap etiord.siorap exa nosiail nosiailfonoitareneg

.4 isnepsus.etareneg euor euor nosiail noisnepsus noisnepsusednoitareneg

.5 sissahc.etareneg noisnepsus noisnepsus - sissâhc sissâhcednoitareneg

.6 2.sissahc.etareneg 2.noisnepsus 2.noisnepsus - 2.sissâhc 2.sissâhcednoitareneg

.7 tiot.etareneg etiob elab - tiot tiotednoitareneg

.8 tatibah.etareneg etiob g.ertênef d.ertênef noitatibah noitatibahednoitareneg

.9 2.tatibah.etareneg etiob g.ertênef d.ertênef 2.noitatibah 2.noitatibahednoitareneg

.01 enibac.etareneg noitatibah tiot - enibac enibacednoitareneg

.11 2.enibac.etarneg 2.noitatibah tiot - 2.enibac 2.enibacednoitareneg

.21 eenimehc.etareneg ediolobrepyh 1.siorap 2.siorap eenimehc eenimehcednoitareneg

.31 nigne.etareneg 1iorap erdnilyc 2.siorap nigne nigneednoitareneg

.41 enihcam.etareneg enigne énimehc - enihcam enihcamednoitareneg

.51 ocol.etareneg enihcam nibac sissâhc ocol evitomocolednoitareneg

.61 nogaw.etareneg 2.enibac 2.sissâhc nogaw nogawednoitareneg

.71 niart.etareneg 1.ocol 1.ogav 2.ogav nert niartednitareneg

Figure 17. Méthode incrémentale de générati hiérarchique de lascène “train”.

Figure 16. Le jeu d’instructions de la méthode de constructiond’une classe de trains de boi “generer.train.”

Figure 15. Une partie de la description déclarative de la scène“train.”


348

search on systems that manipulate not only thecomponents of a scene, but also the design pro-cess itself. These systems simplify the stages of analy-sis, synthesis, and design evaluation, right from thebeginning of the design phase. A distinctive fea-ture of this research is the form of reasoning used;based on inferences (deductions, abductions, orCSP) and the use of a symbolic approach insteadof numeric calculations. This makes the design pro-cess more explicit and transparent. Other researchin this direction, notably that of GRCAO and GE-ODE (research groups in computer-aided design),proposes using modeling methods based on thedeclarative description of the construction processand its translation into computer input, makingpossible a complete parameterization of the model(SGDLsoft 1995). In this way we can produce simu-lations and an interaction between the vision ofthe architect and the shape of the object. This re-

Figure 18. Image of the final “train” scene resulting from a designscenario. [Image de la scéne final “train” obtenue par uneséquence d’activitiés exécutés selon un scénario de conception.]

349


distingue des macroinstructions permettant selon (a)les concepts définis dans le modèle MCR, la de-scription des tâches qui sont constituées desméthodes de construction incrementale descomposants des scènes; (b) le modèle CPM, ladescription des propriétés et leurs dépendancesde causalité.

Une tâche permet une représentationcompacte et structurée d’un problème de concep-tion des scènes et les connaissances de sa résolutionen termes de méthodes et scénarios d’assemblage/désassemblage. Elle spécifie les données d’entrée,le résultat et la stratégie de la résolution. Cettestratégie est représentée sous forme d’un graphede spécialisation et décomposition en sousproblèmes de complexité réduite. Au niveau le plusbas la décomposition du problème devient uneseule tâche, et sa stratégie de résolution consistedans l’appel d’une méthode de la base desméthodes du domaine.

Le syntaxe simplifié est donné ci-dessous :

tache ::= macro [nom_tache]{connaissance}[statut]macro ::=␣ {vocabulaire[argo] }

vocabulaire ::= génère | modifie | ...connaissance ::= descendante | tache | cause | effet | relation

| inférernom_tache ::= [alpha]

alpha ::= letter|-|0|...|9.letter ::= a|b|...|z|A|...|Zstatut ::= complexe | final | entrée | sortie

La stratégie de résolution des tâches est unchaînage causal entre les niveaux de la hiérarchie.Le moteur d’inférence explore l’espace des sous-tâches à base des connaissances de causalité,estimées à différents niveaux de détail entre lesobjets des différentes vues. Le rôle du raisonnementest d’identifier la séquence de tâches à exécuter àpartir des donnée d’entrée dans un cas général etincomplet.

Le jeux des macroinstructions de descriptionsde liens de causalité est destinées à construire unebase de connaissances causales-probabilistescontenant les identificateurs des noeuds des causeset des effets et les valeurs des forces de causalitéentre ces noeuds.

Niveau d’instructions et taxonomie des méthodesL’exécution des méthodes des tâches du niveau

macroinstructions se décompose en chaînesd’instructions associées aux différentes activitésnécessaires pour construire le modèle géométriqueparamétrique de la scène sous conception. Les in-structions sont interprétées par l’interpréteurIntpSOML faisant partie de l’environnement.

Les types principaux des instructions constitu-ent les sous - langages de Génération et intégrationde scènes, de Configuration de scènes, d’Edition(Modification de scènes, Modification de contexte- scène initiale englobante), d’interrogation (Con-sultation des bases graphiques, de données et deconnaissances). Les instructions de génération etd’intégration des primitives sont les outils de con-struction de scènes à partir de primitivesgéométriques et photométriques canoniques etopérations de construction CSG et assemblage parrésolution de contraintes. Génération et intégrationde scènes - mots réservés: génère simple, génèrecomplexe, génère contexte, génére boite.

Langage d’édition de scènes

Edition de scénes - mots réservés: place, déplace,efface, rote contrainte, repositionne;

Modification de scénes - mots réservés: modifie taille,modifie orientation, initialise; Modification decontexte - mots réservés: modifie observation,modifie lumière, modifie texture;

Prise de connaissances - mots réservés: crée scène,affiche géométrie, affiche base primitives,affiche connaissances, affiche config.Spatiale, rendu image, visualise scéne

Commandes. Le niveau des commandesdépend du type du modeleur géométrique utiliséet spécifie le format des primitives prévues pour cemodeleur. La validation logiciel à ce niveau del’approche, SOML est basée sur un modeleur desolides supportant d’opérations CSG régulariséesétendues, construites à base d’utilitaires disponiblesdans le domaine public d’Internet.

Les classes de primitives géométriquesparamétriques et syntaxe d’une commande:

commandes de primitives - nots réservès sphere, box,


350

search complements the use of SOML in the de-clarative design of scenes.

Knowledge and mastery of these tools enablethe architect to shed new light on design prob-lems, improve classical design methods, and speedup the development of new methods. Through com-puter use, architecture will be able to evolve to-wards the goal of establishing a link between clas-sical and modern methods (De Paoli 1996,Miaoulis 1996).

references

Allen, J. F., 1983. “Maintaining Knowledge aboutTemporal Intervals,” Communications of theACM, vol. 26, n° 11, 832-843, 1983

Argués, Didier, and Stéphane Aubert, 1994."Modélisation de scenes tridimensionnellespour l’animation en synthèse d’images: no-tion d’arbres ECSG et computation," AFIG’94,Toulouse.

Brunetti, Gino, Ana Sofia Viera, and JivkaOvtcharova, (). “Towards a Feature Descrip-tion Language.”

Caponi, Cecile, 1995. “Identification etexplicitation des types dans un model deconnaissances à objets,” These enInformatique LIFIA/IMAG.

Charman, Ph., 1995. Gestion des contraintesgéométriques pour l’aide à l’aménagementspatial. Thèse de doctorat de l’Ecole Nationaledes Ponts et Chaussées.

Chen, Hiangpiung, 1995. Representatin, Evalua-tion and Edition of Feature-based and Con-straint-based Design. Doctoral Dissertation,Purdue University.

Clay, Sharon, and Jane Wilhelms, 1996. “Put:Language-Based Interactive Manipulation ofObjects,” IEEE Computer Graphics and Ap-plications.

Christian, Colin and Emmanuel Desmontils, Jean-Yves Martin, Jean-Philippe Mounier, 1997.“Modélisation déclarative: Vision del’utilisateur,” Rapport de recherche , Ecole desMines de Nantes 97-8-INFO, IRIN-152.

De Paoli, Giovanni, and Alain Marty, 1996. “Ar-chitecture, simulation informatique et créationindustrielle,” rapport de recherche, Ministèrede l’enseignement supérieur, Québec.

Dif, Jean, 1996. “Images 3D,” Sybex.Desmontils, 1995. “Les modeleur déclaratifs,” RR

IRIN, Nantes.Donikian, Stéphane, 1992. Une approche

déclarative pour la création de scenestridimensionnelles: applications à la concep-tion architecturale. Thèse à l’Université deRennes 1.

Dubois, Didier, and Henri Prade, 1995. “Fuzzyrelation equations and causal reasoning,”Fuzzy sets and systems, 95:119-134.

Foley, et al, 1995. Introduction à l’Infographie.

351


cylindre, cône, plane, etc.sol_scene := language_directives camera

{camera_items} object_statementsatmosphere_statementsglobal_statements{global_items}

commande ::= [#declare] [name alpha] [=object][{PG1] name alpha {operation}

opération ::=␣ transform “<“ vecteur “>”vecteur ::= {axe index [PG1 name]}

axis ::= X | Y | Zindex ::= s | r | t

transform ::= scale | rotate | translate [object {] nametransform TrS_[name]}

scénarios d’exécutionLes scénarios de conception déterminent la

séquence possible d’activités des tâches, prévuesdans le modèle conceptuel de la scène. Unexemple de tel scénario est montré dans la Figure12. Les étiquetés au dessus des flèches reflètentl’ordre d’exécution des différentes étapes.

Pour faciliter la représentation du scénario deconfiguration spatiale, nous proposons leformalisme diagrammatique basé sur l’utilisation desymboles graphiques, montrés sur la Figure 13.L’avantage de cette approche consiste dans lapossibilité de créer un langage et une grammairede structures permettant la production d’autres struc-tures spatiales.

Il est possible d’en avoir plusieurs scénariospour la construction de la scène ciblée. Ils fontpartie des connaissances méthodologiques,expliquées ci-dessus. Un scénario est constituéed’une séquence de méthodes ciblées d’exécutiondes tâches de la scène. Il peut être compilé soitautomatiquement à partir du modèle global desconnaissances de la scène, soit composé et modifiéavec les outils SOML de la couche Instructions.

résultats d’expérimentationA titre d’illustration des idées mentionnées et

présentées ci-dessus, dans les Figure 15-18, nousprésentons l’extrait d’un exemple de conceptionde la scène du jouet de bois «train». La descrip-tion des propriétés connues (Figure 16) serontconverties dans un ensemble d’instructions SOML(Figure 16), constituant les méthodes de construc-

tion (Figure 17).

conclusionLa création d’un logiciel d’aide à la concep-

tion de scènes est une tâche difficile vis à vis de lacomplexité des problèmes sous-jacents. En effet lesexigences de fonctionnalité font de lui un systèmeinformatique regroupant plusieurs objets etméthodes de traitement. Les avantages potentielsprovenant de l’utilisation du langage résident dansses fonctionnalités permettant une assistance àtoutes les étapes du processus de conception descènes complexes.

Outre les résultats initiaux encourageants, ilreste encore à améliorer le niveau d’applicationdes techniques cognitives de représentation et ex-ploitation des connaissances, l’intégrationd’apprentissage Bayesien, le perfectionnement desvocabulaires (création d’une base deconnaissances terminologiques - BCT, qui va faciliterl’utilisation du langage SOML pour différents typesd’application envisagés), des schémas linguistiqueset la convivialité de l’environnement de travail.

À ce propos, nous avons déjà souligné quele langage SOML permet la création de modèlesde scènes (géométriques, configurationstopologiques, d’aspect réaliste, de méthodes deconstruction etc), qui peuvent être postérieurementmodifiées dans les étapes successives de l’évolutionde la conception. Or, la tâche la plus importantedu concepteur est de préciser les objectifs souventflous et ambigus, définis par le client ou par lesspécialistes d’autres domaines, satisfaire à cesobjectifs et ainsi identifier le dessein fondamentald’un système (Rivero 1977).

Figure ?-1. Image de la scène final “train” obtenue par uneséquence d’activités exécutés selon un scénario de conception.

Nous pouvons entrevoir, en analysant la tâchedu concepteur, une utilisation du langage SOMLcomme outil d’aide à la conception en architec-ture. En effet, au début de l’idée architecturale,pour communiquer avec un client, l’architecte utilisele croquis qui est un rapport entre un concept et laréalité des choses. C’est par ce croquis qui évolue,que nous pouvons dire qu’un langage qui tientcompte de la description déclarative du concept


352

New York, NY: Addisson-WesleyGascuel, 1996. "Fabule : Un environnement de

recherche pour l’animation et la simulation,"iMAGIS/IMAG-INRIA.

Gatenby, Neil, Martin Preston, and W. T. Hewitt,1993. “The Manchester Scene DescriptionLanguage,” CGU 88, Manchester Comput-ing Centre.

Geode, 1997. Web serveur Geode:http://w w w. e m n . f r / d e p t . i n f o / G E O D E /welcome.html.

Gomes, Jonas, and Bruno Coste, Lucia Darsa, LuizVelho, 1996. “Graphical objects,” VisualComputer, 12:269-282.

Gomes, and Velho, 1995. “Velho Abstractionparadigms for computer graphics,” Vis Com-puter 11:227-239.

Kehrer and Vaterrott, 1996. “Integration Aspectsof STEP and their Expression in the CAO Ref-erence Model,” Modellings and Graphics inScience and Technology. Springer.

Lai, Michael, 1997. “UML La notation demodélisation objet. Application en JAVA,” In-ter Edition.

Lucas, Michel, 1990. “Emmanuel Desmontils, Lesmodeleurs déclaratifs,” Review de CFAO.

Mäntilä, Martti, 1988. Introduction to Solid Mod-eling. Computer Science Press.

Martin, P., 1989. “Un système de générationdéclarative de polyèdres.” rapport N 89-02,LISIT, Université de Nantes, juin 1989.

Miaoulis, Georges and Dimitri Plemenos, 1996.“Le projet MultiCad,” Rapport de rechercheMSI 96-03.

Oussalah, Chabane , 1997. “Ingénierie Objet,”Interedition.

Peng, Yun and James A. Reggia, 1990. AbductiveInference Models for Diagnostic Problem-Solv-ing. Springer-Verlag.

Plemenos, Dimitri, 1991. Contribution à l’étudeet au développement des techniques demodélisation, génération et visualisation descenes . Thèse de doctorat d’état eninformatique, Université de Nantes.

Paolo, Portoghesi, 1981. Au-delà de l’architecturemoderne. Editions de l’équerre, Paris.

Rivero, Victor, 1977. Une contribution à la con-ception architecturale assistée par ordinateur.Thèse de doctorat Institut Polytechnique,Grénoble.

Schmeltzer, 1995. Modélisation de cartesgénomiques. Une formalisation et unalgorithme de construction finale sur leraisonnement temporel, Thèse, L’université J.Fourier, LIFIA/IMAG.

SGDLsoft, 1995. Manuel de SGDLsoft. S.G.D.L.Technology S.A., Lyon.

Thalman D., 1988. “Les systèmes de synthèse etd’animation des images de MIRALab,” in T.Lieblins and H. Röthlisberger (eds),Infographieet applications. Masson.

Trousse, Brigitte, 1989. Coopération entresystèmes à base de connaissances et outilsde CAO : l’environnement multi -agentANAXAGORE. Thèse de Doctorat del’Université de Nice Sophia Antipolis.

Vargas,Cataline, 1995. Modelisation du proces-sus de conception en Ingénierie des systèmesmécaniques. Thèse en Informatique, EcoleNormale Supérieure de Cachan.

353


initial et de la possibilité de raisonner d’une façonqualitative et quantitative sur les propriétés dumodèle s’apparente au processus de conceptionen architecture. Nous voyons dans ce langage unoutil basé non seulement sur la production des im-ages synthétiques réalistes de scènes 3D (dessins), mais aussi sur leur formation. Selon cettedémarche, la forme n’est pas la résultante d’uneanalyse-solution, ni d’une simple liste de fonctions,mais elle est le résultat d’une activité cybernétique.Les fonctions (activités) sont considérées comme unprocédé de vérification de l’idée architecturale, lapréfiguration mentale d’un problème à travers lareprésentation évolutive de la forme (Portoghesi1981).

L’adoption de l’ordinateur par les concepteurspousse la recherche vers des systèmes manipulantà la fois des connaissances sur les composants dela scène et aussi sur le processus de conceptionlui-même. Ceci facilite les étapes d’analyse, desynthèse et d’évaluation du design dès le début dela phase de conception. Ces nouveaux systèmesse distinguent par le type de raisonnement basésur des inférences (déductions, abductions, ou CSP)et l’utilisation d’une approche symbolique plutôtque d’un calcul numérique. Ce qui contribue àrendre le processus de design explicite et plus trans-parent. Plusieurs autres recherches se sont déjàorientées dans cette direction, notamment cellesdu GRCAO et du GEODE (Groupes de recherchesen CAO), qui proposent l’utilisation des méthodesde modélisation basées sur la descriptiondéclarative du processus de construction et la tra-duction informatique de ce processus, ce qui permetde rendre le modèle totalement paramétrable(SGDLsoft 1995). Nous pouvons ainsi produire dessimulations et une interaction entre l’oeil del’architecte et la forme de l’objet. Ces démarchestrouvent leur complémentarité avec celle du SOMLpour la conception déclarative des scènes.

La connaissance et la maîtrise de ces outilspourront apporter à l’architecte un nouvel éclairageaux problèmes de la conception architecturale,l’aider à améliorer les méthodes classiques etaccélérer la mise au point de méthodes nouvellesdans l’élaboration du projet architectural. Par lebiais de l’informatique, l’architecture pourra évoluervers un projet qui consiste à établir un pont entre

les méthodes architecturales classiques et lesnouvelles (De Paoli 1996; Miaoulis 1996).

Valentin Popov Lozka Popova Giovanni De Paolipapers.cumincad.org/data/works/att/e184.content.pdf ·...

Documents

Transcript of Valentin Popov Lozka Popova Giovanni De Paolipapers.cumincad.org/data/works/att/e184.content.pdf ·...