HAL Id: hal-01902118
https://hal.archives-ouvertes.fr/hal-01902118
Submitted on 23 Oct 2018
HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.
Intelligence artificielle et conception en architecture et
bâtiment. Spécifications d’un poste de CAO en
architecture utilisant des techniques des langages à
objets
Jean-Pierre Goulette, Patrick Pérez
To cite this version:
Jean-Pierre Goulette, Patrick Pérez. Intelligence artificielle et conception en architecture et bâtiment. Spécifications d’un poste de CAO en architecture utilisant des techniques des langages à objets. [Rap-port de recherche] 480/88, Ministère de l’équipement, du logement, de l’aménagement du territoire et des transports / Bureau de la recherche architecturale (BRA); Ecole nationale supérieure d’architecture de Toulouse / Laboratoire d’informatique appliquée à l’architecture (LI2A). 1987. �hal-01902118�
Laboratoire d'inform atique appliquée à l’architecture
83, rue Aristide Maillol - 31 100 - TOULOUSE - FRANCE - Tél. 61 40 47 28
MINISTERE DE L'EQUIPEMENT DU LOGEMENT DE L'AMENAGEMENT DU TERRITOIRE ET DES TRANSPORTS
Ecole d'architecture de Toulouse
Intelligence Artificielle et Conception en Architectureet RâtiMgnt
lSfll
Spécifications d'un poste de CéO en Architecture utilisant des
technigpcff des langages
objets
Jean-Pierre Goulette Patrick Pérez
Rapport Final de Recherche
Rapport final d ’une recherche financée par le Ministère de l'Equipement, du Logement, de l'Aménagement du Territoire et des Transports, Direction de l'Architecture et de l'Urbanisme, Bureau de la Recherche Architecturale. (Décision de subvention ND 72263 du 3 Juin 87).
MINISTERE DE LEQUIPEMEMENT, DU LOGEMENT, DE L AMENAGEMENT DU TERRITOIRE ET DES TRANSPORTS
ECOLE D’ARCHITECTURE DE TOULOUSE
Etablissement public - Décret 81.833 du 6.481
Etablissement National d'Enseignement Supérieur d'Architecture et
d'ürbanisme
Departement de la recherche
Laboratoire Li2a
83 rue Aristide Mail loi
31100 Toulouse
61 40 47 28
Intelligence A rtific ie lle et Conception en Architecture et
Bâtiment (phase 1987)
Spécifications d’un poste de CAO en Architecture utilisan t des
techniques des langages à objets
Jean-Pierre Goulette
Patrick Pérez
Rapport Final de Recherche
Direction scientifique : Michel Léqlise
SUBVENTION du
Ministère de l'Equipement, du Logement, de l'Aménagement du Territoire
et des Transports, Direction de l'Architecture et de l'Urbanisme, Bureau
de la Recherche Architecturale.
(Décision de subvention N° 72263 du 3 Juin 87).
Le présent document constitue le rapport final d'une recherche remise au
Bureau de la Recherche Architecturale en exécution pour partie du
programme général de recherche mené par le Ministère de l'Equipement,
du Logement, de l'Aménagement du Territoire et des Transports avec le
Ministère de la Recherche et de la Technologie. Les jugements et opinions
émis par les responsables de la recherche n'engagent que leurs auteurs.
Spécifications d'un poste de CAO en Architecture utilisant des techniques des langages à objets
Ce rapport présente deux approches complémentaires et cohérentes qui permettent la définition d ‘un poste de travail CAO dédié à l'architecte. Ces deux approches partent du principe que l'intelligence contenue dans le geste de l'architecte, au sens large, devra se retrouver dans "1'intelligence" des outils. L'introduction de cette intelligence est présentée dans deux domaines :
- celui des outils de modélisation
- celui des outils___ d'assemblage___entre___de§___ objets d'architecture.
Le premier chapitre est consacré à l'évaluation d'un modeleur 3D spécialement destiné à l'architecture
Le deuxième chapitre porte sur la définition fonctionnelle d'un "poste architecte" dans la perspective de la nouvelle génération des systèmes de CAO intelligents.
Sont mises en forme par ailleurs des propositions concrètes pour la représentation_slêS___ objets___ architecturaux suivant
l'échelle de représentation.
Les deux approches présentées dans ces deux chapitres font référence toutes deux à des techniques de 1'intelligence artificielle communément nommées "langages orientés objets", ou
Spécifications d ‘ un poste de CAO en Architecture utilisant des techniques des langages à objets
Introduction ... 1
Chapitre 1 : Structure de données orientée "objet" et Géométrie des Eléments d'Architecture dans les Systèmes de Modélisation... 3
1. Introduction... 3
2. Présentation de l'outillage de base... 4
2.1. La facette... 4
2.2. De la facette à la forme... 5
2.3. Description des types de formes par leurs opérateurs... 5
2.3.1 Formes quelconques... 5
2.3.2. Les solides parfaits (platoniciens) et pré-définis... 6
2.3.3. Formes issues d ’opérateurs d'extrapolation... 6
2.3.3.1. Les projetés... 6
2.3.3.2 . Les tubes... 7
2.3.3.3. Les liaisons... 7
2.3.3.4. Les révolutions... 8
2.3.4. Formes issues d'opérateurs d ’interpolation... 8
2.4. Géométries issues de macro-opérateurs géométriques... 8
2.4.1. Macro-opérateurs d'extrapolation... 9
2.4.1.1. Travée simple... 9
2.4.1.2. Travée circulaire... 9
2.4.1.3. Parcours... 10
2.4.2. Formes issues de macro-opérateurs dits "booléens"... 10
3. Introduction d'une "intelligence" dans les opérateurs... 10
4. Séparations des niveaux fonctionnels et topologiques... 12
5. Les opérateurs... 12
6. De la formule à la classe... 16
7. Exploitation de la notion de liaison... 17
8. Conclusion... 19
Chapitre 2 : Spécifications du poste architecte ... 21
1. Introduction... 21
2. Présentation des éditeurs... 22
2.1 L'éditeur des objets du catalogue... 22
2.2 L'éditeur d'idées ... 23
2.3. L'éditeur du p r o j e t ... 24
2.4 L'éditeur de r e n d u ... 26
3 Description de l'éditeur D o c k ... 26
3.1 Présentation... 26
3.2 Schémas généraux présentant la structure de fonctionnement de D o c k ... 27 3.3 Un premier pas dans la résolution du
problème de l'échelle de représentation... 29 4. L'éditeur d'idées et l'éditeur de projets (Epik)... 30 4.1 Les éléments manipulables par l'utilisateur 31 4.2 Structure générale d'Epik ... 38 4.3 Structuration des informations et
orientation objet ... 39
4.4 Fonctions de base . . 40
4.4.1 Les fonctions de gestion du projet ... 40 4.4.2 Les fonctions de visualisation et de
repérage dans la projet ... 40 4.4.3 Les fonctions de manipulation des
objets du c a t a logue... 41
4 5 Le fonctionnement de l'historique 41
5. Conclusion... 43
Spécification» d'un poste de CAO en Architecture utilisant des techniques des langages à objets
Introduction
On trouvera dans ce rapport deux approches complémentaires et cohérentes qui permettent la définition d'un poste de travail CAO dédié à l'architecte. Ces deux approches partent du principe que l'intelligence contenue dans le geste de l'architecte, au sens large, devra se retrouver dans "l’intelligence" des outils L'introduction de cette intelligence est présentée dans deux domaines
- celui des outils de modélisation
- celui des outils d'assemblage entre des objets
d'architecture.
A l'observation des problèmes auxquels sont confrontés les architectes qui manipulent des systèmes de CAO, nous avons pu observer l'aspect crucial de la transmission des idées dessinées à l'ordinateur. La saisie devient la préoccupation et la faiblesse des systèmes de CAO actuels. L'importance que nous accordons aux aspects gestuels et à "l'intelligence des objets" dépasse donc le cadre de simples améliorations de l'ergonomie, pour devenir des propositions originales destinées à faciliter la maîtrise et l'usage des outils du concepteur par une "pseudo compréhension" par le logiciel de l'univers manipulé
Le passage permanent du "flou" d'une idée à sa matérialisation dessinée nécessite différents outils très souples qui permettent de simuler les qualités de la pratique du papier/calque.
Pour concevoir les spécifications de ce poste de travail, nous nous sommes imposés la règle suivante : le respect de la
logique de l'utilisateur est, et doit rester tout au long du cycle de vie d'un logiciel de CAO, la source et la condition sine qua non de tout développement. Ce respect est une complexité à part entière et ne peut se contenter de grossir après coup les lignes de code d'un programme : il doit bien plutôt en constituer le squelette et la peau.
Ce principe impose deux contraintes importantes tout d'abord respecter la facilité du geste (que ce geste soit
immédiat ou réfléchi ; il conviendra, dans ce deuxième cas, de ne proposer que des actions respectant la logique du concepteur) et, en second lieu, "munir d'intelligence" les objets manipulés
Il n'est donc pas dans notre esprit de spécifier un produit comparable aux logiciels de CAO traditionnels, et encore moins d'épouser la sempiternelle démarche : modeleur 3D traditionnel + éléments d'assitance = logiciel de CAO, où le deuxième opérande est subordonné aux modes de résolution du premier.
Le premier chapitre est consacré à l'évaluation d'un modeleur 3D spécialement destiné à l'architecture.
Après un travail sur la géométrie de l'espace et
l'architecture, ainsi que sur la définition de l'espace de travail, nous présentons l'intérêt d'implémentation de certains opérateurs volumiques.
Nous avons ensuite étudié la possibilité d'introduction d'une "intelligence" dans ces opérateurs, et en déduisons une ré union entre les niveaux fonctionnel et topologique. Nous pouvons alors proposer une structuration de base de données orientée "objets", qui, bien q u 'informatiquement complexe, préserverait les modes traditionnels de penser et d'agir des architectes.
Nous en avons déduit les caractéristiques générales d'un produit, dont nous avons commencé à développer la maquette.
Le deuxième chapitre porte sur la définition fonctionnelle d'un "poste architecte" dans la perspective de la nouvelle génération des systèmes de CAO intelligents
Cette recherche a été partiellement financée par le GIE "CAOMIP", dans le cadre du contrat "Krèpis" que nous menons avec lui pour le compte du Plan Construction (programme IN.PRO.BAT).
Le travail présenté ici, qui est la partie propre de participation du laboratoire Li2a au système "Krèpis", a résidé dans la recherche d ’un scénario d'utilisation d'une telle station de conception en architecture. Notre objectif de travail a été le suivant : étudier sur des volumes simples les principes d'ergonomie et d'interactivité nécessaires au respect de la démarche du concepteur.
Nous avons étudié comment chaque objet pourrait être assorti d'une base de données textuelles et d'un ensemble de lieux, dits "lieux remarquables", permettant d ’en particulariser certaines parties. Ces informations sont utilisées dans un "éditeur de projets" et permettent, dans une philosophie des "langages à
objets", d'adapter les actions de composition aux
caractéristiques de l'objet manipulé.
Nous avons par ailleurs mis en forme des propositions concrètes pour la représentation des objets architecturaux suivant l'échelle de représentation.
Les deux approches présentées dans ces deux chapitres font référence toutes deux à des techniques de l'intelligence artificielle communément nommées "langages orientés objets", ou "langages à objets". Ces techniques mettent en jeu des "messages" qui circulent entre des "objets". Ceci n'est pas sans entraîner des confusions conceptuelles, puisque sont manipulés aussi bien des "objets" au sens informatique du terme, que des "objets" au sens architectural du terme. Ce rapport est traversé par ces deux notions d'objets, qui ne sont évidemment pas identiques dans tous
Chapitre 1
Structure de données orientée “objet" et Géoaétrie des Eléments d ‘Architecture Hans les Systèmes de Modélisation.
Patrick Pérez
1, Introduction.
Depuis plusieurs années déjà, nous nous penchons sur le problème complexe de la communication homme-machine et plus particulièrement Architecte-machine dans le cadre de la C.A.A.O. Sur le plan de la communication de la géométrie des projets d'Architecture, cette recherche a pris son départ lors de la réalisation de modeleurs : nous avons été confrontés à l'énorme difficulté de communiquer de l'espace architectural (ne serait-ce qu'au plan de la géométrie), et cela, parce qu'il nous est apparu que si les outils de représentation utilisés par les architectes depuis plusieurs siècles pour communiquer l'espace - décrire la forme - s'avèrent être pertinents et probants, cela nous semble davantage dû à une interprétation du dessin au travers d'un véritable code de la re-présentation de l'espace, qu'à un illusoire homomorphisme entre le dessin de l'ouvrage et l'ouvrage réel. Nous pourrions exprimer plus trivialement cela en disant que, l'ensemble des documents que l'architecte élabore en phase de conception ne permet en aucun cas de générer directement un objet complet, au sens d ’une description complète de sa géométrie tri-dimensionnelle, mais que cette complétude est le fruit de l'intelligence. Il y a donc interprétation par des "hommes de l'art" pour pouvoir élaborer d'abord mentalement, puis concrètement un dessein contenu dans un dessin.
Dans la quête de cette transmission d'une information incomplète sans le recours de l ’intellect humain, deux voies complémentaires nous ont paru s'ouvrir : la première consiste dans l'utilisation de certaines techniques dites "de l'intelligence artificielle" (structurations 'objets' notamment), la seconde, plus difficile à introduire pour la profession mais sans aucun doute plus prometteuse, consistant à modifier la manière de "dessiner 1'espace".
L'introduction des techniques informatiques, tant dans la phase
de conception propremement dite que dans la phase de
représentation, a entraîné et entraînera un profond
bouleversement des habitudes et, plus que tout, un bouleversement du geste créateur. Considérons qu'au moyen d'un crayon, cette fois électronique mais la chose importe peu, il est d'ores et déjà possible de dessiner dans l'espace et non plus dans le plan seul. Vu la complexité des ouvrages d'Architecture, il n'est pas pensable d'en opérer la saisie complète point par point. Il convient donc de développer des outils pertinents permettant de "générer de la forme" à partir de l'interprétation d'un dessin lié à certains paramètres.
Les fonctions qui génèrent de la forme font depuis longtemps déjà l'objet d'études diverses, et certaines commencent à faire autorité. Malheureusement pour le bâtiment, les deux secteurs les plus concernés par l'introduction de la C.A.O. ont orienté toutes les recherches dans leurs propres directions celles de la mécanique et celles de l'aéronautique. L'outil principal de modélisation pour la mécanique est l'ensemble d'opérateurs dits "booléens" appliqués sur des éléments de base (des solides entièrement paramétrés et non décrits manuellement) Cette démarche qui consiste à décrire un solide complexe au moyen de diverses opérations de soustraction ou d'ajout de matière, se comprend tout à fait lorsque l'on a vu un atelier de mécanique au travail. On peut donc dire que, si l'informatique a calqué la machine-outil, elle a surtout permis le transfert d'un savoir-faire , une certaine expérience de la matière a engendré un ggl-taifl modèle & comment-faire. Il en est de même pour l'aéronautique qui utilise essentiellement des modules de surfaces complexes (splines, surfaces de Coons, tenseurs etc...) pour répondre aux problèmes de tôlerie.
Il s'agit donc pour nous de chercher et développer pour un futur système de C.A.A.O. des fonctions spécifiques à l'architecture dans le domaine de la modélisation et non de transférer des outils pertinents pour d'autre domaines.
C'est dans cet ensemble d'interrogations, que nous avons placé notre recherche. Recherche d'outils souples pour la création permettant de générer et de modifier des maquettes tri dimensionnelles en conservant à l'esprit que nous cherchons à garder l'intelligence des gestes de l ’architecte. L 1intelligence contenue dans le geste au sens large, devra se retrouver dans l ’intelligence des outils.
2. Présentation de 1 ’outillage de base.
Nous allons dans un premier temps rapidement passer en revue les divers outils de base dont nous disposons pour modéliser des objets. Cet aperçu sera nécessaire à la bonne compréhension des idées que nous introduirons plus loin. Le lecteur spécialement intéressé par ce sujet peut se repporter à [P.Pèrez-87-2].
2.1. La facette.
Le point de départ est la facette. C'est un ensemble de points liés par un parcours (ordre de lecture) fermé. Tous les points de la facette offrent la particularité d'être inscrits dans un même plan. Pour pouvoir construire et modifier les facettes avec une souplesse maximale, il faut disposer d'un excellent éditeur bi-dimensionnel (ce point nous paraît trop souvent négligé pour n'avoir pas à le signaler). Le plan de travail (plan dans lequel sont inscrits les points composant la facette en cours d'élaboration) dans lequel travaillera cet éditeur sera quelconque mais toujours parallèle pour l'architecte au plan de saisie-visualisation (retrouver la feuille de papier
1 ) Ainsi la facette à décrire ou modifier sera en grandeur vraie.
Les divers problèmes liés au développement d'un éditeur 2D, problèmes depuis longtemps déjà résolus, ne sauraient donc faire l'objet d'une étude ici ; nous admettrons donc pour la suite de notre exposé que nous disposons de cet outil.
2.2. De la facette à la forme
A partir d'une facette dans l'espace nous allons donc devoir générer des volumes. Ce qui revient donc à passer du plan à l'espace (R2 -> R3) au moyen de certains opérateurs.
Nous avons choisi de nommer ces opérateurs, opérateurs de types morphologiques, car leur action découle de l'analyse des différents types de formes que l'on est amené à produire en architecture. Ces types ne sont pas aussi nombreux que l'on pourrait le croire de prime abord. L'analyse des opérateurs et le mécanisme de leur production que nous proposons, font l'objet du paragraphe suivant.
2.3. Description des types de formes par leurs opérateurs
Nous avons dénombré sept types de formes différents, différents quant à la topologie bien sûr, mais différents surtout quant à la manière de produire chaque topologie. Ce qui nous amène à souligner le lien étroit existant entre la manière de construire une forme et la forme produite. Une technique particulière engendre donc une forme spécifique. On peut se demander si une forme est même mentalement concevable sans une technique pour la réaliser ou au moins pour l'approcher (en donner une idée !).
2.3.1 Formes quelconques.
Nous avons en premier lieu, les formes entièrement décrites dans R3, point par point, facette par facette. Il ne s'agit pas à proprement parler d'un type de forme, dans la mesure où tout est faisable ainsi (au prix, bien entendu, d u n e énorme masse de travail), mais plutôt d'un "mode opératoire" qui peut s'avérer indispensable dans certains cas. Il n'y a pas ici, en dehors de la saisie directe des points, à réaliser un opérateur spécifique si ce n'est un petit utilitaire consistant à aimanter les différents points des facettes pour coller le tout correctement (rattrapage des petites erreurs).
Opération d'aimantation ou "collage"
2.3.2. Les solides parfaits (platoniciens) et pré définis .
Les formes considérées comme parfaites par les Grecs, ne nécessitent pour leur génération que l'introduction du centre et du rayon de la sphère enveloppante, puis du rang du solide (nombre de facettes). On générera ainsi le cube,
1'icosahèdre, le dodécahèdre etc...
De même pourront être pré-définis certains solides comme : la boîte, le cylindre, le cône, le tronc de cône etc...
Du fait de l'absence de toute information géométrique nécessaire à la constitution de cés objets, on parlera pour les opérateurs produisant ces objets, d'opérateurs à génération numérique.
2.3.3. Formes issues d'opérateurs d'extrapolation.
2.3.3.1. Les projetés.
A partir d'une facette décrite manuellement ou extraite d'un volume, on peut générer toute une variété de formes issues de la projection de la facette au moyen d'un vecteur.
On peut étendre la notion de "projeté" aux variétés "tubes" qui sont des formes générées par glissement d'une facette tout au long d'un parcours. Ce parcours peut orienter la facette de base pour jouer alors le rôle de guide (orientation de la facette pour que le parcours soit en permanence tangent à la facette, d'où section constante de la forme tout au long d'un plan normal au guide)
Génération de type "tube".
2.3.3.3. Les liaisons.
Certaines formes ne peuvent être générées que par la liaison de deux facettes identiques dans leur topologie mais non dans leurs surfaces. Il va sans
dire qu'un certain nombre de conditions sont
nécessaires à la correcte utilisation de cet opérateur (orientations identiques, points de départ sur le parcours de chaque face identiques etc...).
ftfffUtlPf) M T Jfàlwn
fto e tte l
Il est possible au moyen d'une fibre (un profil) et d'un axe de créer des surfaces dites de révolution Ces formes sont très présentes en architecture
(coupoles, poteaux, colonnes etc...).
Génération M r révolution de profil
2.3.4. Formes issues d'opérateurs d'interpolation.
La modélisation de surfaces très complexes telles que des terrains, des coupoles aux courbures irrégulières etc..., ne sont obtenues que par l'interpolation de portions de sections connues. Des exemples de ces surfaces sont les Béziers, les B-splines, surfaces de Coons...
Génération M r interpolation.
2.4. Géométries issues de macro-opérateurs géométriques
Après avoir décrit les opérateurs de base qui nous sont nécessaires à la "génération de forme”, nous allons aller plus avant en exposant maintenant la catégorie des macro-opérateurs. Ces opérateurs n' ont pas pour éléments de base des facettes ou des sections mais des surfaces (ici, ensemble de facettes connexes). Ils visent donc à produire des formes plus complexes utilisant les opérateurs de base (donc des formes de base).
2.4.1.1. Travée simple.
Consiste â répéter une forme un certain nombre de fois, dans une certaine direction, avec un certain entre-axe (la distance et la direction étant fournis par un vecteur)
Travée simple
24.1.2. Travée circulaire.
Principe identique à la travée simple,
simplement le couple direction-entraxe est remplacé par un couple angle-axe de rotation.
Travée circu laire
121 À I I i I i + nb réotiuLm-w
C'est une opération de répétition d'une forme de base tout au long d'un parcours avec orientation de la forme sur le parcours ou non.
travée sur parcours
2.4.2.Formes issues de macro-opérateurs dits
"booléens".
Au moyen d'un ensemble d'opérateurs géométriques - de type union, intersection, différence etc... - (qualifiés dans la littérature spécialisée de "booléens"), de formes de base, et d'un arbre de construction, il est possible de décrire des formes relativement complexes. Ce type de modélisation cher à la mécanique, n'est pas très utilisé en architecture mais s'avère nécessaire dans certains cas.
3. Introduction d'une "intelligence" dans les opérateurs
Pour introduire la notion d' "intelligence" dans les opérateurs géométriques, nous allons commencer par présenter l'exemple de ce que l'on nomme l'arbre de construction dans les systèmes dits de "solid-modeling".
Dans ces systèmes, les objets les plus complexes ne sont modélisés que par des opérations booléennes (différences, intersections, unions) effectuées successivement sur des éléments au départ totalement paramétrés. Il est intéressant de noter qu'en mémorisant l'historique de la modélisation (totalement ancré dans une durée, car les actes conceptuels s'élaborent dans le temps, action après action), on peut obtenir un arbre de construction qui n'est plus lié au temps, mais peut s'exprimer comme instantané conceptuel de 1'objet.
pirftrpptt 1=2
Ce que 1'on peut exprimer comme suit : cylindrel:= ((type cylindre) (axe y) (hauteur 100
)
(rayon 20) (centre 0 0 0 ) ) cylindre2:= ((type cylindre) (axe y) (hauteur 2 0 0)
(rayon 5) (centre 0 0 0 ) ) picots : = ((type boite) (hauteur 5) (longueur 5) (largeur 50) (centre 0 0 0 ) ) moyeu : =(différence(union cylindrel picots) cylindre2)
C'est alors que l'on peut se rendre compte qu'en re interprétant l'arbre de construction, il est possible de recréer la topologie de 1'objet final. Deux bases de données peuvent donc co-exister dans la machine, d'une part la topologie de l'objet complet avec toutes ses facettes, d'autre part la représentation du même objet au moyen d'une symbolique permettant de refaire l'objet. Du coup l'objet est aisément modifiable car on peut accéder et modifier n'importe quel noeud ou n'importe quel paramètre de feuille dans l'arbre de construction. Cette possibilité d'exprimer une géométrie dans un langage formel permet d'entrevoir les énormes possibilités que nous allons maintenant présenter.
-4 Séparations des niveaux fonctionnels et topologiques
Les systèmes de modélisation en usage optent pour deux philosophies :
- La première veut que la topologie d'un objet soit entièrement portée par ses facettes: C'est le "tout graphique". Toute modification géométrique s'applique donc sur les facettes de l'objet, et les facettes transformées viennent se substituer aux précédentes. Si le système permet fort bien d'aller "de l'avant" (choix dans un menu d'une fonction de transformation, application de la fonction à la géométrie de l'objet, substitution du résultat aux anciennes facettes), il ne permet pas en revanche de revenir "en arrière". La seule possibilité de modification d'un objet étant alors d'agir directement sur les facettes des objets en redessinant tout ou partie de l'objet. L'utilisateur reste lié non seulement à la "topologie facettes", mais encore à l'accomplissement total dans le temps de la modification par le dessin sans pouvoir faire l'économie des actes conceptuels qui restent valides dans la nouvelle proposition.
- L'autre type de modeleur (solid modeling par arbre de construction) préconise la solution opposée qui consiste à décrire la géométrie des objets uniquement au moyen d'opérateurs. Cette technique est évidement très éloignée du savoir-faire d ’un dessinateur. Le graphique n'est alors qu'accessoire, il offre un contrôle visuel sur les objets, il est issu de l'interprétation de l'expression symbolique définissant l'objet. En revanche, les modifications sont toujours possibles et peuvent s'opérer uniquement sur le domaine posant problème.
Une démarche originale consiste â rendre les deux systèmes oo-existants en utilisant ce qu'ils ont de plus positif. Pour un objet donné, on tentera au niveau géométrique de lui associer deux existences équivalentes quand au résultat (l'expression graphique de l'objet) mais fondamentalement différentes dans la forme. On disposera pour un même volume d'un niveau topologique contenant les facettes de l'objet à l'instant T, et un niveau fonctionnel qui décrira l ’objet au moyen d'un langage symbolique.
5-. Les opérateurs.
Pour élaborer notre langage symbolique qui nous permettra la conservation de l'historique et donc la possibilité de modifier la géométrie des objets manipulés, il nous faut nous replacer dans le cas concret de l'utilisation d'un système de modélisation utilisant les types morphologiques cités au paragraphe 2. Dans un tel système, l'aspect principal doit résider dans l'ergonomie, la
souplesse d'utilisation. Il en découle tout naturellement que nous disposerons de menus déroulants présentant à l'utilisateur les divers types de formes générables.
Il convient alors de découvrir si ces types morphologiques sont exprimables au moyen d'une expression symbolique faite d'un ensemble d'opérateurs et de variables de base (le terme de variable doit être ici pris au sens le plus large puisque nous utiliserons des nombres bien sûr, mais aussi des vecteurs, des axes, des plans, des polygones ouverts ou fermés. Tout ces éléments devant être introduits de la manière la plus interactive possible par l'usage intensif d'une souris). Si c'est le cas, tout objet pourrait alors se voir attribuer en plus de sa représentation par facettes, l'expression symbolique qui lui correspond. Remarquons par ailleurs que nous transformons donc le temps et les actes de création d'un objet (l'historique) en une expression symbolique, objet perçu dans l'instant (comme la représentation graphique d'une surface) mais contenant pourtant
l'histoire de sa conception.
Nous donnons ci-dessous l'expression symbolique des
différents types morphologiques présentés au paragraphe 2. Solides platoniciens:
variables :
centre: un point, rayon: un scalaire.
type_solide: un numéro correspondant au solide. formule :
Solide_parfait(centre,rayon,type_solide)
Opérateurs d'extrapolation: Proietté:
variables :
facette: un polygone fermé, vecteur: un vecteur. formule : Jonction(facette,Translation(vecteur,Copie(facette)))
lafeaa.;.
variables : parcours: un polygone facette: un polygone fermé. formule : Tant_que Existe(Point_suivant(parcours)) Jonction_simple(ancrage(facette,parcours), ancrage(Copie(facette), Point_suivant(parcours) )) Suivant(parcours) Fin_tant_queLiaisons : variables ;
facettel: un polygone fermé. facette2: un polygone fermé. formule :
Jonction_simple(facettel,facette2)
Révolutions: variables :
profil; un polygone ouvert, axe: un axe de rotation. Formule. Tant_que Existe(Point_suivant(parcours)) Jonction_simple(Gen_poly(parcours,axe), Gen_poly(Point_suivant,axe)) Suivant(parcours) Fin_tant_que Opérateurs d ’interpolation. Bézier: variables :
contrôle: un ensemble ordonné de polygones, pas: un nombre (degré du polynôme).
formule :
Bézier(contrôle,pas)
B-splines:
variables :
contrôle: un ensemble ordonné de polygones, pas: un nombre (degré du polynôme).
formule : B_spline(contrôle,pas) Coons; variables : fibrel: un polygone. fibre2; un polygone,
pas: un nombre(degré du polynôme) formule :
Patoh (bi-cubiaueï: variables : fibrel: un polygone. fibre2: un polygone. fibre3: un polygone. fibre4: un polygone,
pas: un nombre(degré du polynôme) formule :
Patch(Cubic_spline(fibrel), Cubic_spline(fibre2) Cubic_spline(fibre3),Cubic_spline(fibre4),pas)
Extension de l'analyse aux opérateurs de groupe, Travée simple:
variables :
élément: un objet (issu d'un opérateur de base ou de groupe).
direction: un vecteur, quantité: un nombre entier. formule : Tant_que Existe(quantité) Créer(Translation(élément,direction)) quantité <- quantité-1 Fin_tant_que Travée circulaire: variables :
élément: un objet (issu d'un opérateur de base ou de groupe).
angle:un nombre réel, axe: un axe de rotation, quantité: un nombre entier. formule : Tant_que Existe(quantité) Créer(Rotation(élément,axe, angle)) quantité <- quantité-1 Fin_tant_que Travée parcours: variables :
parcours: un polygone ouvert, élément: un objet, formule : Tant_que Existe(parcours) Créer(Ancrage(élément,parcours)) Suivant(parcours) Fin_tant_que
Opérateurs Booléens: variables :
élémentl: un objet. élément2: un objet.
opérateur: "diff_sym”, "diffl:2", "diff2:l", "union", "inter",
formule
Booléen(élémentl,élément2,opérateur)
6. De la formule à la classe
Nous avons donc montré, qu'il était possible d'associer à une topologie par facettes, une expression symbolique selon le type morphologique dont un objet est issu. Cette expression symbolique recevra le nom de Formule de l'objet pour la clarté de l'exposé qui va suivre. Les formules permettent donc de regénérer et de modifier la géométrie des objets au moyen d'expressions symboliques. En connaissant ce langage, il est parfaitement possible de revenir en arrière, ou de “lire" l'évolution géométrique d'un objet. Mais la manipulation de ces formules est chose complexe pour le néophyte, étrangère pour l'architecte. Par contre, sachant que les formules des objets sont identiques au niveau des opérateurs pour tous les objets d'un même type morphologique, on introduira plutôt la notion de classe. Les classes sont vues par l'utilisateur comme une sorte de type de fiche signalétique d'un objet donné. Elles sont en fait le cadre d'expression d'un objet, un objet ne pouvant être que l'occurence d'une classe. Elles sont définies par un nom, une topologie, une formule et une définition des variables utilisées dans la formule.
Voyons comment l'utilisateur percevrait les choses. Pour chaque objet créé, il est possible de consulter sa fiche signalétique dont les différents champs sont conditionnés par la classe d'appartenance. Dans le cas d'un objet du type "portique" une telle fiche peut se présenter comme suit :
objet: P o rtiq u e c la s se : P ro je té face tte :
[rû
ve cte i topolc jr: (0,0 gie:n
,20)Imaginons maintenant un objet plus complexe constitué par une travée des dits portiques , la structure de donnée sera alors
la suivante :
Nous voyons donc q u ’en fonction des types morphologiques (et donc des classes) mis en oeuvre, un format particulier de base de donnée hiérarchique est sous-tendu par un tel système Gardons par ailleurs présent à l'esprit que ce type de base ne s'occupe exclusivement que de la géométrie de chaque objet
7 . Exploitation de la notion de liaison
Puisque le but visé par notre recherche est la possibilité de modification aisée de la géométrie des objets, explorons plus avant les conséquences naissant de la ré-interprétation des objets si l'on vient à modifier certaines variables.
Nous devons tout d'abord introduire les deux règles suivantes dans le système de gestion ;
Règle 1 :
Toute modification de la topologie d'un objet (par modification manuelle de ses facettes) transforme la
classe initiale de cet objet en classe DESCRIPTIVE. Règle 2 :
Toute modification des champs variables d'un objet entraîne automatiquement la réinterprétation de la topologie de cet objet, de ses ascendants et descendants s'il y en a,
Forts de ces deux règles, si nous modifions maintenant le champ "nombre de répétitions (nb-rep)" de l'élément 2 en substituant à 5 la valeur 3, la travée comptera dorénavant 5 portiques et non plus 3. Mais ce qu'il y a de beaucoup plus intéressant c'est que la modification de la facette du champ
"facette (à projeter)" dans l'objet Portique, entraîne non seulement la transformation de la topologie de Portique mais aussi de l'objet Travée.
De nouvelles possibilités voient le jour, si nous
introduisons dans ce type de base de donnée la notion de lien artificiel. En effet, dans le cas précédemment évoqué, le lien,
la relation existant entre l'objet Portique et l'objet Travée peut être considéré comme lien naturel dans la mesure où l'existence même de Travée est entièrement conditionnée par Portique : il y a dans l'objet Travée référence directe à l'objet Portique puisque ce dernier n'est ni plus ni moins qu'un champ - dans les variables - de l ’objet Travée. Il peut être judicieux de créer entre différentes occurences de classes, sur quelques
objets ponctuels, des liens artificiels entraînant des
dépendances géométriques entre ces objets. Ces liens artificiels contrôlent la valeur de certaines variables entre objets désignés et peuvent les modifier au moyen de formules appropriées.
Par exemple, prenons le cas d'une travée de poteaux , la fiche qui la désigne s'établit comme suit :
Créons un nouvel objet de la classe "travée", composé de murs bahuts faisant office de remplissages de l'entr'axe des poteaux
Les liens naturels de la structure de données font que par exemple une modification du poteau initial modifie toute la travée (voir l'exemple précédent).
Par contre une modification de la variable "nombre de répétitions (nb-rep)", fait que, si la réinterprétation de l'objet "travée de poteaux" est correcte, le remplissage en murs bahuts est par contre incorrect puisqn'i1 manque un élément. Ce problème est réglé par l'introduction d'un lien artificiel entre les deux travées au niveau de la-dite variable (un autre lien assurant la réciproque peut également être mis en oeuvre). On créera ce lien entre les objets "Travée" et "travée-bahut" en indiquant que la variable "nombre de répétitions (nb-rep)" de Travée est en relation avec la variable "Nombre de répétitions (nb-rep)" de l'objet Travée-bahut en proportion de N-l.
[Travée-bahut,nb_rep <- (Travée.nb_rep - 1)]
On force ainsi l'objet "Travée" à envoyer un message (la nouvelle valeur de nb-rep) à l’objet "Travée-bahut" dès que l'on modifie cette variable. Ce message permet la mise à jour du
paramètre concerné et entraîne automatiquement la ré-
interprétation de l'objet pour fournir la nouvelle topologie.
8_„ Conclusion
Nous pensons que cet exposé aura permis au lecteur d'entrevoir les possibilités d'un tel environnement au niveau d'un modeleur, environnement qui est relativement complexe à
mettre en oeuvre, ne serait-ce que sur le plan de la
d'informatique Appliquée à l'Architecture semblent très prometteurs et nous sommes en voie de définition d'un système complet de modélisation utilisant pour la partie "géométrie des objets" les concepts que nous avons esquissés ici. Les principaux problèmes rencontrés dans ce type d'application des structures dites "objets" résident essentiellement dans la mise en place de procédures de contrôle de cohérence de la base. D'autant plus que l'application la plus spectaculaire sera pour nous d'autoriser l'utilisateur architecte à créer de nouveaux types morphologiques d ’où de nouvelles classes, et ce, avec une intégration aux classes initiales du modeleur dans les menus du logiciel.
Chapitre 2
Spécifications du poste architecte Jeart-Pierre Goulette
1. Introduction
Nous citerons les quatres principes importants qui nous semblent impératif de respecter dans la conception ou la réalisation de logiciels de CAO :
- Permettre à l'utilisateur architecte de penser et de communiquer son projet dans un vocabulaire qui lui est familier. Pour ce faire, il nous semble nécessaire d'étudier
et de développer des fonctionnalités reflétant les
catégories descriptives du vocabulaire traditionnel de l'architecture ("au droit", "au nu" ...) ; nous regroupons l'ensemble de ces commandes spécifiques sous le terme "fonctions architecte” . De plus, dans le cadre d'une activité de recherche, l'adjonction d'un historique logiciel au programme de CAO permettra de tester la pertinence, la fréquence et le mode d ’utilisation de ces commandes et ainsi de dégager des éléments positifs objectifs pour assurer la maintenance adptative du programme.
Doter les objets manipulés par l'utilisateur de caractéristiques et de fonctionnalités facilitant la
description des attributs architecturaux que doit
nécessairement posséder un élément d'architecture manipulé dans le cadre d'un processus de conception. Il s'agit là, d'offrir pour chaque objet des fonctionnalités proches de celles d'une banque de données muti-média (regroupant des éléments graphiques, des textes libres, des valeurs
numériques ...) accessibles par l'utilisateur (pour
consultation ou modification) et par les fonctions
architecte (qui ajusteront leurs actions en fonction des caractéristiques précises de chaque objet).
- Offrir des fonctions de visualisation du projet possédant un haut degré d'ergonomie. Le but de ces fonctions doit être double :
- d'une part de permettre d'afficher d ’une manière simple et non contraignante (sans interrompre les taches de manipulations en cours) les différentes représentations du projet en fonction de l'échelle de visualisation et du degré de détail voulu.
- d'autre part de faciliter le repérage dans l'espace (qui n'est pas toujours évident sur un écran d'ordinateur) en permettant la création de pages de
visualisation dynamiques offrant des vues
particulières du projet nommées par l'utilisateur et pouvant être affichées sur simple demande.
- Préserver la liberté du geste de l'utilisateur dans les premiers instants de la conception. Pour ce faire, les fonctionnalités offertes par le programme doivent être
réparties en deux (ou plusieurs catégories) celles
permettant une grande liberté et donnant lieu à des résultats sans grande précision ou signification , celles dont la réalisation plus contraignante garantit un degré de précision ou de signification supérieur.
Notre travail a résidé dans la recherche d ‘un scénario d'utilisation d'un poste architecte intégré dans un système constitué de l ’ensemble des participants au Projet Architectural Cette analyse fonctionnelle nous a permis de dégager les différents composants du "programme architecte" et d'étudier les utilitaires nécessaires à chaque composant.
La station de conception est articulée autour de quatre éditeurs (dont deux sont étroitement liés comme nous le verrons par la suite) :
-L'éditeur des objets du catalogue -L'éditeur d'idées
-L'éditeur de projets -L'éditeur de rendus.
Ainsi, la décomposition de notre module de conception en éditeurs d'idées et de projets constituent les deux extrêmes d'une série d'éditeurs jalonnant le cheminement "du flou vers le précis".
2 Présentation des éditeurs
2.1 L'éditeur des obiets du catalogue
Il s'agit là de définir les objets de la construction manipulés par l'architecte ce sont les murs, les ouvertures,
les poteaux, les poutres, etc.
Notre démarche est donc fondée sur une méthode de conception par éléments, méthode commune à certains logiciels actuellement disponibles Nous avons pu constater que cette démarche s'adapte bien à une tradition de conception en architecture, à des habitudes acquises
C'est un éditeur 3D, dédié à la description volumétrique des objets. Il permet aussi (de manière facultative) la définition des composantes (parties remarquables, axes, nus, encombrement, éléments d'orientation...) et des propriétés susceptibles d'être utilisées par les "fonctions architecte" (voir plus loin,
l'éditeur du projet). Enfin, il offre la possibilité de décrire les relations existant entre l'objet en cours de définition et d'autres objets du catalogue par l'introduction d'un type particulier d'élément : l ’aimant. Chaque aimant, attaché sur un site précis d'un objet, détermine une relation de "proximité géométrique" avec son vis à vis (un aimant situé sur un autre objet). L'introduction de ce type d'élément permet de décharger l'objet de la mémorisation des caractéristiques des relations qui le lient à différents objets (création d'un couple d'aimants par type de relation).
De plus, chaque objet pourra être assorti d'une base de données textuelles. Ces informations, associées à chaque objet, seront utilisées dans l ’éditeur de projets dans une phase ultérieure.
Les objets de la construction sont définis un par un dans cet éditeur et insérés dans le catalogue.
Les utilitaires requis sont les suivants : Fonctions de tracé 3D
Fonctions de tranformations géométriques 3D.
Fonctions de définition des composantes et des propriétés Fonctions de définition et de positionnement des aimants et des lieux remarquables.
Fonctions de gestion du catalogue et des représentations en mémoire de masse.
2., 2 .IL éditeur d'idées
C ’est un éditeur (regroupant des primitives de tracé et de transformations géométriques orientées vers une grande souplesse d'utilisation) permettant la constitution du carnet de croquis de l"architecte. Ce carnet comporte des dessins du projet représentant des coupes, plans, élévations, mises en volume.,. réalisées par l'utilisateur pour fixer certaines idées dans les premiers instants de la conception. Il peut aussi contenir des études de détail très précises, des tracés régulateurs qui seront utilisés par la suite et... tout ce que le concepteur jugera intéressant de dessiner. Ces images sont "vides de sens" pour le programme qui ne mémorise qu'une suite de segments, Chaque dessin constituera une page du carnet stocké en mémoire de masse et appelable par la suite. Il y a un carnet par projet, les pages peuvent être échangées entre différents carnets.
On constatera là la préservation de la "liberté du geste" de l'Architecte, qui pourra ainsi "crayonner" ses premières idées. Ces idées seront reprises par la suite dans l'éditeur de projet.
et pourront constituer un calque de fond. Ce calque ne représentera pas un simple croquis passif, mais jouera un rôle actif dans le positionnement des objets manipulés dans l'éditeur de projet (rôle autorisé par la création d'un type d'aimant particulier).
Utilitaires requis ; Fonctions de tracé 2D
Fonctions de transformations géométriques 2D,
Fonctions de gestion des carnets et des représentations en mémoire de masse.
2,3. L'éditeur du projet
Il permet la manipulation d'objets 3D, mais pas leur définition (il ne possède pas de fonctions de tracé).
Il connait deux types d'élément : Les objets du catalogue. Les images du carnet.
Il regroupe, en plus des transformations géométriques standards, des utilitaires nommés "fonctions architecte". Il s'agit là des fonctions de description familières au concepteur et concernant les relations entretenues par les objets de l'architecture : au droit, à l'aplomb, au même nu, en retraite...
Notre souci est d ’implémenter oes attributs de description d'un bâtiment d'une manière fonctionnelle, et ainsi d ’obtenir un éditeur "parlant” (peu ou prou) le langage de l'architecture. Ces fonctions necéssitent bien sûr la connaissance (par le programme) des composantes et propriétés mises en causes (nus, axes,
encombrement...). Il est à noter que cette idée de
l'implémentation de fonctions utilisant le vocabulaire de l'architecture, plutôt que des utilitaires géométriques habituels utilisés aussi bien en mécanique qu'en architecture, se retrouve aussi dans le projet "Tecton" [TECTON], et marque à notre avis un changement qualitatif important révélant une évolution vers le respect du savoir-faire de l ’architecte.
L'éditeur de projets constitue le coeur du poste
architecte : une fois les Objets du catalogue définis, ceux-ci peuvent être manipulés dans cet éditeur en vue de la composition d'un bâtiment.
Nous avons décidé de doter cet éditeur d'un "historique" permettant de retracer la totalité des opérations effectuées par l ’utilisateur lors de la conception d'un bâtiment.
Cet historique, sauvegardé sur fichier en même temps que le projet, nous permettra d'étudier précisément l'utilisation du système que nous allons fournir. Nous n'avons pas, en effet, la prétention de définir Lg. poste architecte qui perdurera pendant
des décennies connue paradigme des postes architectes à venir Nous sommes conscients que le poste que nous spécifions comporte des lacunes et des défauts inhérents à la complexité de la tâche entreprise. Aussi, pour constituer les bases d'une évolution future, nous nous orientons vers la définition d'un système fournissant certains éléments de sa propre analyse.
L'étude de cet historique (étude par des procédures informatiques ou par un défilement pas à pas sur l'écran) nous permettrait d'évaluer deux types de résultats :
- d'une part l'étude, dans une situation informatisée particulière, du mode de conception et des fonctions d'assitance ou de composition le plus souvent utilisées par l'architecte (permettant une critique concrète de l ’analyse fonctionnelle du système)
- d'autre part, la reconstruction, a postériori, des "entités" manipulés par l'architecte durant les différentes étapes de la conception.
Le terme "entité" ne doit pas être assimilé ici, par une réduction simpliste, à la notion d'Objet du catalogue (ou encore moins à la notion d'objet informatique dont nous aurions, à priori, précisément défini les différentes facettes dans le code du système), mais doit plutôt être compris comme un "aggrégat malléable" d'Objets puisant sa signification dans la seule volonté de simplification conceptuelle de l'architecte. Nous ne croyons pas en effet à la pertinence de définir d'une manière formelle (et donc figée) ces entités , nous préférons fournir des utilitaires interactifs d'agrégations simples (voir plus loin) sans présumer des qualités spécifiques de l ’entité obtenue (qualités qui résident principalement, nous le pensons, dans l'image mentale de l'architecte à un instant particulier, dans un contexte précis et pour un projet donné).
Ce deuxième type de résultat nous permettra une critique exploratoire et "constructive" de la structure de données choisie.
Cet éditeur permet une mise en volume axonométrique du
projet ; toutefois, une modification (transformations
géométriques ou fonctions architecte) ne peut être effectuée qu'en vue géométrale (plan, coupe ou élévation).
Il contient des pages correspondant aux différentes vues réalisées par le concepteur en changeant de plan, de coupe ou de point de visée sur une mise en volume. Ces pages sont dynamiques et "mises à jour" lors de modifications sur d'autres vues. Chaque page peut recevoir un nom.
Une page du carnet et une vue du projet sont superposables Ceci permet :
- avec une page du carnet au premier plan d'ajouter de nouveaux tracés au dessin et de le modifier.
- avec une vue du projet au premier plan : de déplacer, modifier et d'insérer des éléments du catalogue avec un
"canevas" sous-jacent.
Les utilitaires requis sont les suivants :
Fonctions de tranformations géométriques 3D Fonctions architecte.
Fonctions de visualisation pour la mise en volume
Fonctions de gestion des pages et des représentations en mémoire de masse
Fonctions de gestion de la base de données du projet. Fonctions de superposition de page projet / page carnet.
2.4 L'éditeur de rendu
Il constituerait la suite logique des éditeurs précédents Il servirait à réaliser, partant de la base de données du projet, des planches de rendu par l'introduction de couleurs, texture, éléments d'ambiance...
Cet éditeur ne sera pas étudié dans le cadre de ce travail ; nous préférons en effet investir notre temps dans la recherche d'une souplesse et d'un confort d'utilisation du logiciel pour la mise en forme du projet.
3 Description de l'éditeur Dock
3.1 Présentation
Dans le cadre d'étude du système Krèpis [KREPIS-1], l'éditeur a fait l'objet d'une maquette nommée Dock (Définition des Objets du Catalogue de Krèpis).
La présentation est faite ici dans une optique de langage orienté objets, en soulignant parfois l'originalité de notre exploitation des principales caractéristiques de ce type de langage (modularité, possibilité de définition de données abstraites, création dynamique de liens, mécanismes d'héritage). Cette orientation objet est importante pour nous elle nous permet en effet d'être cohérent avec les autres postes (ceux-ci devant être conçus autour d'un langage du même type) et nous permet d'obtenir un code possédant de bonnes qualités de réutilisabilité.
Ainsi, la possibilité de création dynamique de liens et les mécanismes d'héritage nous ont permis de limiter, dans le cadre
