FR2870374A1 - Architecture client-serveur pour la visualisation d'une maquette numerique tridimensionnelle - Google Patents

Abstract

L'invention concerne une architecture client-serveur pour la visualisation d'une maquette numérique tridimensionnelle comprenant : une base de données (1) tridimensionnelles relative à ladite maquette ; un serveur (2) comportant un module de synchronisation réseau (24) ; et un ou plusieurs clients (3, 3a), chaque client comportant un module de visualisation (30) pour la représentation de ladite maquette et un module de synchronisation réseau (31), ledit serveur (2) et le ou lesdits clients (3, 3a) étant compris dans un réseau de communication (4), lesdits modules de synchronisation (24, 31) étant aptes à mettre à jour un état de scène relatif à cette maquette, au sein du réseau (4), entre le ou les clients (3, 3a) et le serveur (2). L'invention s'applique en particulier a la visualisation de maquette par un pluralité d'utilisateur souhaitant interagir sur cette maquette.

Description

ARCHITECTURE CLIENT-SERVEUR POUR

LA VISUALISATION D'UNE MAQUETTE NUMERIQUE

TRIDIMENSIONNELLE

L'invention concerne une architecture client-serveur pour la visualisation d'une maquette numérique tridimensionnelle (3D) ainsi qu'une méthode de visualisation d'une telle maquette.

De nombreuses entreprises conçoivent des produits en utilisant des outils de conception assistée par ordinateur (CAO). Les outils de CAO permettent essentiellement de concevoir mais aussi de visualiser et d'interagir sur des maquettes numériques 3D représentant les futurs produits.

Ces maquettes sont utilisées au cours des différentes étapes de conception et de validation des produits en vue de vérifier leur aspect esthétique, de simuler leur comportement, par exemple, leur résistance aux chocs ou leur encombrement, de résoudre les contraintes de fabrication, voire de promouvoir les produits auprès de clients potentiels ou de former du personnel sur ces produits.

Toutefois, ces étapes de conception, validation, promotion et de formation, nécessitent bien souvent l'intervention simultanée d'une pluralité d'utilisateurs sur les maquettes, ces utilisateurs étant situés en des lieux différents, quelquefois même dans des pays différents.

C'est la raison pour laquelle, on a développé des architectures du type client-serveur permettant à une pluralité d'utilisateurs, physiquement éloignés, de visualiser une même maquette.

Une telle architecture est divulguée dans le document WO 01/84501. Cette architecture met en uvre un serveur, un réseau de communication et au moins un client. Le serveur comprend, d'une part, un module de rendu configuré pour permettre le rendu d'une image en deux dimensions (2D) générée à partir de données de scène 3D et, d'autre part, une interface configurée pour transmettre ces images aux clients, au travers du réseau. Le poids des images 2D, c'est-à-dire la quantité d'information qu'elles comportent en bits, octets ou multiples de ces unités, est suffisamment faible pour permettre la transmission rapide des images au travers d'un réseau de faible débit et leur affichage au niveau du client même si ce dernier ne bénéficie pas d'une machine performante. Un système de commande/réponse permet au client d'interagir sur l'image et, en liaison avec le serveur, sur les données de scène de ce serveur.

Aussi, dans l'architecture divulguée dans le document WO 01/84501, le client ne dispose pas de données 3D représentatives des données de scène de sorte qu'il n'est pas possible, pour l'utilisateur, d'interagir sur lesdites données de scène.

D'autres architectures sont divulguées dans les documents US-6,377,257 et US-6,384,821. Dans ces architectures, les données 3D d'une scène, notamment des données géométriques, sont transmises entre un serveur et un ensemble de clients dans un réseau. Le client possède généralement un module de rendu pour permettre la visualisation des données 3D.

Néanmoins, dans ces architectures, la connexion des clients au réseau de communication doit impérativement être une connexion à large bande passante de manière à autoriser un débit important de données géométriques du serveur auxdits clients. En outre, les machines clients doivent eux-mêmes disposer de cartes graphiques puissantes comportant un module de rendu de haute qualité pour pouvoir gérer ces données géométriques et conférer un rendu suffisant aux représentations graphiques visualisées.

Considérant l'état de la technique précité, un problème que se propose de résoudre l'invention est de réaliser une architecture client-serveur pour la visualisation d'une maquette numérique tridimensionnelle, ainsi qu'une méthode correspondante, qui permettent à un ensemble d'utilisateurs de visualiser, interagir et finalement collaborer sur des données 3D partagées au sein d'un réseau.

La solution de l'invention au problème précité a pour premier objet une architecture client-serveur pour la visualisation d'une maquette numérique tridimensionnelle comprenant: - une base de données tridimensionnelles relative à ladite maquette; - un serveur comportant un module de synchronisation réseau; et - un ou plusieurs clients, chaque client comportant un module de visualisation pour la représentation de ladite maquette et un module de synchronisation réseau, ledit serveur et le ou lesdits clients étant compris dans un réseau de communication, lesdits modules de synchronisation étant aptes à mettre à jour un état de scène relatif à la maquette, au sein du réseau, entre le ou les clients et le serveur.

Elle a pour second objet une méthode de visualisation d'une maquette tridimensionnelle dans une architecture client-serveur, caractérisée en ce qu'elle comporte les étapes suivantes selon lesquelles: - on fournit une base de données tridimensionnelles relative à ladite maquette, un serveur comportant un module de synchronisation réseau, un ou plusieurs clients, chaque client comportant un module de visualisation pour la représentation de ladite maquette et un module de synchronisation réseau, et un réseau de communication; - le serveur génère, à partir de la base de données tridimensionnelles, une représentation tridimensionnelle de la maquette; et - des états de scène de cette représentation tridimensionnelle sont mis à jour, au sein du réseau, entre le ou les clients et le serveur, au moyen des modules de synchronisation.

Ainsi, les modifications des états de scène de la maquette tridimensionnelle effectuées chez un client sont mises à jour au sein du réseau, via le serveur, de sorte que l'ensemble les utilisateurs puissent non seulement visualiser la maquette de manière synchrone et cohérente, mais aussi interagir collaborativement avec celle-ci et ce, avec une haute qualité visuelle, quelle que soit la complexité de la maquette, quelle que soit la bande passante du réseau et quelle que soit la puissance graphique dont dispose les clients.

L'invention sera mieux comprise à la lecture de la description non limitative qui va suivre, rédigée en référence aux dessins, dans lesquels: - la figure 1 schématise l'architecture client- serveur selon l'invention; la figure 2 illustre la division du calcul d'une image en couches indépendantes représentant différents types d'effets visuels pour la mise en oeuvre de l'invention; la figure 3 illustre les différents niveaux de qualité associés à la couche Ombre montrée à la figure 2 la figure 4 illustre la gestion du rendu 20 progressif opérée pour la création d'une image selon l'invention; - la figure 5 est un exemple de métalangage de niveaux utilisé pour la définition de couches selon l'invention; - la figure 6 illustre les actions de composition d'une image effectuées par le module de visualisation client dans une architecture selon l'invention, lorsque les paramètres d'une ombre sont modifiés; la figure 7 schématise différentes étapes d'un 30 synchronisation réseau selon l'invention; - la figure 8 illustre le découplage de la complexité selon l'invention; la figure 9 illustre le rendu progressif distant opéré par le serveur ainsi que l'enrichissement progressif en local; la figure 10 illustre le principe de visualisation collaborative selon l'invention; - la figure 11 détaille les différents modules logiciels ou matériels d'un serveur partie d'une architecture selon l'invention; et - la figure 12 détaille les différents modules logiciels ou matériels d'un client partie d'une architecture selon l'invention.

Ainsi que cela est montré à la figure 1, l'architecture client-serveur selon l'invention comporte une base de données tridimensionnelles 1, un serveur 2 et un ou plusieurs clients 3, 3a distants du serveur 2. Le serveur 2 et les clients 3 sont connectés entre eux au sein d'un réseau de communication 4.

La base 1 comporte des données tridimensionnelles natives concernant une maquette numérique 3D. Ces données sont enregistrées dans une mémoire non volatile par exemple d'un disque dur. Ce disque dur est partie du serveur 2 ou en liaison avec celui-ci, comme dans le cas de la figure 1.

Le serveur 2 est d'un type connu comportant une carte mère munie d'au moins un microprocesseur pour le traitement des données, de cartes informatiques ainsi que de supports mémoire volatile et non volatile. Ce serveur 2 comporte en outre, selon l'invention, un module 20 d'importation et de conversion des données natives, un module 21 pour la génération de tridimensionnelles et la gestion des générer des représentations 3D allégées, gestion des attributs d'une scène l'association de matériaux ou les et un module 23 de rendu 3D de progressif permettant l'obtention de représentations photo-réalistes des maquettes 3D. Le serveur 2 comporte enfin un module de synchronisation 24 des espaces virtuels serveur/clients.

Chaque client 3, 3a est formé par un ordinateur, par exemple de type ordinateur personnel, comportant un module de visualisation 30 d'objets allégés de basse résolution et un module de synchronisation réseau 31. Une interface utilisateur 32 permet à un utilisateur d'interagir avec les différents modules client.

Le réseau 4 est un réseau par exemple du type Internet ou privé. Le serveur 2 et les clients 3, 3a ont accès à ce réseau 4 selon une bande passante qui leur est propre. Les données circulant au sein du réseau pour la mise en uvre de l'invention sont susceptibles d'être cryptées, par exemple selon le protocole SSL (Secure Sockets Layer).

Le module de conversion 20 du serveur 2 importe les données natives des maquettes 3D, qui proviennent d'outils de CAO existants tels que CatiaTM, Pro-EngineerrM, VDA-FS', IGESTM, AutodeskTM, AliasTM ou SoftimageTM, les traduit, et génère une description de ces données dans un format spécifique apte à être géré par le module de représentations détails apte à un module 22 de 3D tels que paramètres de qualité, très haute qualité et visualisation client 30. Ce format spécifique est adapté aux besoins de l'invention et permet notamment une gestion ultérieure des niveaux de détail, une lecture en continu, un découplage de la complexité et une association de matériaux.

Le module de gestion des détails 21 du serveur 2 génère des niveaux de détails topologiques à partir des données 3D importées et converties par le module 20. Ces représentations sont plus ou moins précises et plus ou moins lourdes en termes de poids mémoire. En particulier, les détails peuvent être générés à partir des informations surfaciques ou polygonales selon une méthode minimisant les déformations. La représentation 3D obtenue par le module de gestion de détails 21 est ainsi allégée de manière à faciliter, d'une part, leur transfert au sein du réseau 5 et, d'autre part, leur affichage par les machines clients ne disposant pas de capacités graphiques élevées.

Le module de gestion de scènes 22 gère les modifications apportées aux scènes 3D, qui portent par exemple sur la position des objets, leurs attributs de rendu tels que la visibilité, la couleur, la transparence, la texture ou les reflets, et gère les propriétés globales de rendu 3D telles que la qualité, les effets de contour, le brouillard ou les effets de lentille optique.

Le module ou moteur de rendu progressif 23 calcule des images 2D de haute qualité à partir des descriptions de scènes 3D obtenues du module 22 et des représentations topologiques des maquettes 3D obtenues du module 21.

A cet effet, il divise le calcul de l'image en couches indépendantes représentant les différents types d'effets visuels, tels que les ombres, la réflexion, la transparence, les effets volumiques comme par exemple la fumée et tels que les effets de lentille comme par exemple la profondeur de champ. Cette division ou découpe en couches indépendantes est illustrée à la figure 2 au regard de couches Matière et Illumination, Ombre, Transparence et Reflet. Elle permet l'exécution des calculs de chaque couche de manière indépendante et sur une pluralité de machines, les clients effectuant les travaux les plus simples, le serveur prenant le relais pour les travaux plus complexes. Elle permet en outre d'améliorer la qualité de l'image de manière progressive, cette amélioration progressive étant visible par l'utilisateur. Elle permet enfin la réalisation de calculs sur chaque couche selon des méthodes différentes, plus ou moins rapides et/ou de plus ou moins bonne qualité.

D'ailleurs, le module de rendu progressif 23 définit et gère des niveaux de qualité de manière matérielle ou logicielle pour chacune des couches et gère par suite le temps de calcul de chacune des couches d'image. La figure 3 illustre les différents niveaux de qualité associés à la couche Ombre de la figure 2. Au niveau de qualité 0, le temps de calcul est de 40 ms et l'ombre projetée est de basse qualité. Au niveau de qualité 1, le temps de calcul est de 1 s et l'ombre projetée est de bonne qualité. Au niveau de qualité 2, le temps de calcul est de 10 s et un lancé de rayons de l'ombre prend en compte la transparence et la couleur de l'objet. Au niveau de qualité 3, le temps de calcul est de 1 min et le lancé de rayons précité prend alors en compte le calcul de la pénombre.

En définitive, ainsi que cela est montré à la figure 4, le rendu progressif est décrit par un graphe d'opérations dans lequel chaque n ud correspond à un type d'effets, un n ud pouvant être calculé avec différents moteurs, chaque moteur apportant une qualité plus ou moins haute en fonction de sa performance.

Bien entendu, un métalangage de niveaux est défini de manière à permettre l'encapsulation des concepts gérés par les moteurs de rendu classiques. Ce métalangage supporte le concept de la découpe en couches et assure une exécution optimale des effets visuels. Les différentes variables de ce langage se réfèrent aux couches elles-mêmes, aux niveaux de qualité disponibles pour une couche donnée et aux effets susceptibles d'être obtenus pour ladite couche. Un exemple d'organisation des niveaux selon ce métalangage est montré à la figure 5, pour les couches Matière et Illumination (Illumination Layer), Transparence (Transparency Layer) et Ombre (Shadow Layer). Ainsi que cela est montré dans cette figure, on définit, pour chaque couche, des paramètres tels que les paramètres Couleur (Color) , Texture, Brillance (Shininess). On définit en outre, pour chaque couche, des niveaux de qualité disponibles tels que Qualité 0, 1, 2 ou 3 (Quality 0, 1, 2 or 3) ainsi que des pointeurs tels que phong-OGL ou phong-software , désignant les moteurs de rendu destinés à exécuter les calculs.

Le module de visualisation 30 fournit un support visuel local à chaque client 3, 3a. Il permet d'interagir avec les maquettes 3D pour changer de point de vue ou éditer les propriétés de rendu. Ce module 30 reçoit les versions allégées des maquettes 3D dans lesquelles le niveau de qualité est défini automatiquement en fonction de la puissance de la machine hôte. Il hérite de technologies mises en uvre dans le module de rendu progressif 23 du serveur 2 puisqu'il est apte à calculer certains niveaux de basse qualité en dépendance avec la puissance de la machine hôte client. De surcroît, le module de visualisation 30 incorpore un moteur de composition d'images 2D qui permet d'assembler en temps réel les différentes couches calculées par le module de rendu progressif 23. Dans l'exemple de la figure 6, un utilisateur modifie les paramètres de l'ombre d'une maquette numérique. Le serveur 2 recalcule cette ombre et renvoie le résultat de ce calcul au client 3, 3a. Le client 3, 3a recompose alors une nouvelle image avec cette ombre recalculée ainsi que les autres couches qui n'ont pas subi de modifications.

Les modules de synchronisation réseau 24, 31 mettent à jour les états de scène, non seulement, entre un client donné et le serveur, mais aussi, entre le serveur et les autres clients, ce qui permet une collaboration entre les utilisateurs. La figure 7 représente les différentes actions générées au sein de l'architecture selon l'invention lorsqu'un utilisateur U1 modifie la couleur d'un objet. Dans ce cas, la modification est transmise (A) au module de synchronisation 31 du client 3 correspondant à cet utilisateur Ul. Ce module de synchronisation 31 informe (B) le module de synchronisation 24 du serveur 2 de la modification effectuée. Le gestionnaire de scènes 22 reçoit (C) cette modification qui est par la suite transmise (D) au module de rendu, qui relance le calcul de l'image en tenant des changements. Le module de synchronisation 24 informe(E) alors les autres clients 3a de la modification. En particulier, l'utilisateur U2 reçoit (F) la modification de couleur effectuée par l'utilisateur U1.

En définitive, selon l'invention, on a créé un format spécifique des données qui peut être géré par le module de visualisation client. Il y a par suite un découplage entre le format natif des données tridimensionnelles et le format spécifique des données de l'invention. Ce découplage permet à un utilisateur non familiarisé avec les langages de CAO d'interagir sur des maquettes tridimensionnelles quel que soit le format des données d'origine de cette maquette. Etant donné que ce format supporte les niveaux de détails, des versions dégradées de données natives peuvent être générées. Cela facilite le transfert des données représentatives des maquettes au travers du réseau et la visualisation de ces maquettes par les utilisateurs disposant de machines de faibles capacités graphiques. Le découplage de la complexité est illustré à la figure 8. Il apparaît que la dégradation des données natives diminue la qualité de visualisation des maquettes numériques 3D (image de basse résolution). Toutefois, grâce à la haute qualité du serveur de rendu 3D, l'image locale et dégradée de la maquette est enrichie, dans le temps, par l'envoi de pixels 2D photoréalistes calculés sur le serveur puissant. La représentation de la maquette s'enrichit, sur l'écran de l'utilisateur, progressivement. Le travail en local au niveau du client ainsi que l'enrichissement progressif de la représentation de la maquette visualisée par le client par l'envoi de données du serveur sont illustrés en figure 9. En définitive, grâce à sa haute qualité, le module de rendu du serveur vient en soutien du client en générant des images 2D de haute qualité pour améliorer progressivement cette représentation. L'utilisateur voit l'image qu'il visualise s'améliorer par enrichissement progressif.

La figure 10 illustre finalement le principe de visualisation collaborative selon l'invention. Ainsi que cela est montré dans cette figure, des utilisateurs localisés dans des endroits différents peuvent, au même moment visualiser à la même image représentative d'une maquette numérique telle qu'une maquette de lunettes ou une maquette de carrosserie automobile et interagir sur cette maquette, collaborativement.

Les figures suivantes, référencées 11 et 12, détaillent les différents modules logiciels et matériels présent sur le serveur 2 et le client 3, dans un mode particulier de mise en oeuvre de l'invention.

Ainsi que cela est montré à la figure 11, le serveur 2 comporte un module de gestion de données 200, un module de rendu progressif 214 et un module de synchronisation 222.

Le module de gestion des données 200 remplit les fonctions décrites cidessus des modules de conversion 20, de gestion des détails 21 et du gestionnaire de scène 22. A cet effet, il comprend un module de gestion de commandes 201, un module de conversion des données 202, un module 203 de génération de niveaux de détails géométriques, un gestionnaire de modèles de données 204, un gestionnaire de scène 205, un gestionnaire de session 206, un gestionnaire de librairies de matériaux 207, un gestionnaire des utilisateurs 208, un gestionnaire de résolutions géométriques associées aux scènes 209, un gestionnaire d'évènements 210 et un dictionnaire de requêtes 211.

Le gestionnaire de scènes 205 maintient une base de données de scènes 3D comprenant des fichiers natifs ainsi que les données associées auxdits fichiers telles que les niveaux de résolution. Le gestionnaire de modèles de données 204 permet d'associer des outils spécifiques à chaque type de données. Par exemple, ce gestionnaire comporte des outils qui permettent de convertir les données du type Catiarm au format spécifique selon l'invention et qui permettent de générer les différents niveaux de détails géométriques. Le gestionnaire de modèles de données 204 assure la gestion de tels modèles. Le module de conversion de données 202 permet de convertir les données natives vers le format spécifique de l'invention. Toutefois, ce module se contente d'exécuter les commandes gérées par le module de gestion de commandes 201 et ne contient pas de technologie de conversion de données sensu stricto. Le module de gestion de commandes 201 comporte un module de script et interpréteur 212 et un gestionnaire d'outils externes 213. Le module de script et interpréteur 212 permet d'écrire et d'exécuter des scripts. Le gestionnaire d'outils externes 213 gère et référence les logiciels externes qui peuvent être appelés à partir du langage de script en vue de former des commandes complexes. Le module de génération de niveaux de détails géométriques 203 génère les niveaux de détails en exécutant les commandes disponibles dans le gestionnaire de commandes 201. Le gestionnaire de session 206 gère les accès ainsi que les processus associés de visualisation et d'interaction sur une scène 3D par un utilisateur. Le gestionnaire des utilisateurs 208 gère les utilisateurs pouvant participer aux sessions. Le gestionnaire de librairies de matériaux 207 gère les librairies associées aux différents éléments d'une scène. Le gestionnaire des résolutions géométriques 209 associées aux scènes permet de choisir un niveau de résolution adapté à chaque client dans le cadre d'une session. L'interaction sur une scène génère différents évènements qui doivent être synchronisés entre les clients 3, 3a et le serveur 2. Le gestionnaire d'évènements 210 assure cette fonction. Il s'agit par exemple des évènements suivants: modification du point de vue, mouvement d'objets, association de matériaux, édition des paramètres des matériaux. La synchronisation des différentes instances d'une même scène entre les clients 3, 3a et le serveur 2 est réalisée par l'envoi et la réception de requêtes. Une requête permet de définir une action et contient des informations décrivant le type d'action, la cible, l'utilisateur ayant effectué l'action etc.... Le dictionnaire de requêtes 211 permet de définir les actions possibles. Ces requêtes sont ensuite traduites en évènements.

Le module de rendu progressif 214 comporte un gestionnaire de couches 215, un gestionnaire de niveaux de qualité 216, un gestionnaire de tâches 217, un gestionnaire du métalangage de niveaux 218 et un gestionnaire de moteurs de rendu 219.

Le gestionnaire de couches 215 comporte un gestionnaire de dépendances entre les couches 220 et un module d'optimisation des calculs entre les couches 221. Il gère l'exécution du calcul de chaque couche d'effet constituant une image. Une couche d'effet a trait par exemple à la couleur, l'ombre, les reflets ou la réflexion. Certaines couches doivent être calculées avant d'autres, par exemple, le reflet d'un objet. Le gestionnaire de dépendances entre les couches 220 assure le bon ordonnancement du calcul des différentes couches pour obtenir une image finale cohérente. Le module d'optimisation 221 analyse les paramètres d'une scène pour éliminer les calculs non nécessaires (objets cachés et/ou de petites tailles). Le gestionnaire des niveaux de qualité 216 permet de définir le niveau de qualité pour le calcul des différentes couches. Il permet de gérer l'envoi des données correspondant aux couches de haute qualité aux clients 3, 3bis connectés à une session. Le gestionnaire de tâches 217 permet d'exécuter le calcul de certaines couches sur des ordinateurs distants pour améliorer la vitesse de calcul en faisant intervenir d'autres ressources matérielles de calcul. Le gestionnaire de métalangage de niveaux 218 réalise la syntaxe et l'interprétation de ce métalangage. Il permet de décrire l'effet visuel d'une matière en tenant compte les différentes couches et procédés pour calculer les différents niveaux de qualité. Le gestionnaire de moteurs de rendu 219 répertorie l'ensemble des moteurs de rendu logiciels et matériels disponibles et gère ces moteurs de rendu pour le calcul des couches et des niveaux de qualité.

Le module de synchronisation 222 comporte un gestionnaire de flux 223, un gestionnaire de requêtes 224 et un gestionnaire de connexion 225.

Le gestionnaire de flux 223 gère le transfert des flux d'information dans le réseau (transfert de fichiers ou transfert en continu (streaming)). Le gestionnaire de requêtes 224 permet de recevoir et envoyer des requêtes entre les clients 3, 3bis et le serveur 2. Le gestionnaire de connexion 225 gère les connexions notamment de bas niveau au sein du réseau entre les clients et le serveur et gère en particulier les pare- feux et les routeurs.

Ainsi que cela est montré à la figure 12, chaque client 3, 3a comporte une interface de programmation (API) 300, un gestionnaire de graphes de scène 3D 301, un gestionnaire d'évènements 302, un dictionnaire de requêtes 303, un compositeur de couches 304, un gestionnaire de couches 305, le gestionnaire de métalangage de niveaux 306, un moteur de rendu matériel 307, un gestionnaire de topologie de scène 308, et un module de synchronisation réseau 309.

L'API 300 est utilisée pour construire des applications de l'utilisateur final et permet d'accéder aux informations d'une scène et de commander les actions. Le gestionnaire de graphes de scènes 3D 301 gère les paramètres de graphe des scènes tels que l'information de parenté, la position de la caméra, les paramètres de translation, l'orientation et la taille des objets, ou le nom des objets. Le gestionnaire d'évènements 302 et le dictionnaire de requêtes 303 du client ont des fonctions identiques au gestionnaire d'évènements 210 et au dictionnaire de requêtes 211 du serveur, respectivement. Le compositeur de couches 304 effectue la composition des différentes couches, telle que la couche couleur, la couche ombre ou la couche reflets, pour l'obtention de l'image finale. Le gestionnaire de couches 305 et le gestionnaire de métalangage de niveaux 306 ont des fonctions identiques au gestionnaire de couches 215 et au gestionnaire de métalangage de niveaux du serveur, respectivement. Le moteur de rendu matériel 307 est un moteur de rendu permettant un calcul rapide, mais approximatif, des différentes couches. Le gestionnaire de topologie de scène 308 gère les informations géométriques des scènes à un niveau de résolution compatible avec les capacités graphiques du client et de la bande passantes du réseau entre celui-ci et le serveur. Enfin, le module de synchronisation réseau 309 du client est similaire au module de synchronisation réseau 222 du serveur et comporte de ce fait, de même que ce module 222, un gestionnaire de flux 310, un gestionnaire de requêtes 311 et un gestionnaire de connexion 312.

Claims (12)

REVENDICATIONS

1. Architecture client-serveur pour la visualisation d'une maquette numérique tridimensionnelle comprenant: une base de données (1) tridimensionnelles relative à ladite maquette; un serveur (2) comportant un module de synchronisation réseau (24) ; et un ou plusieurs clients (3, 3a), chaque client comportant un module de visualisation (30) pour la représentation de ladite maquette et un module de synchronisation réseau (31), ledit serveur (2) et le ou lesdits clients (3, 3a) étant compris dans un réseau de communication (4), lesdits modules de synchronisation (24, 31) étant aptes à mettre à jour un état de scène relatif à cette maquette, au sein du réseau (4), entre le ou les clients (3, 3a) et le serveur (2).

2. Architecture selon la revendication 1, caractérisée en ce que le serveur (2) comporte en outre un module (20) de conversion de données apte à convertir les données tridimensionnelles de la base de données (1) tridimensionnelles, d'une pluralité de formats, dans un format spécifique apte à être géré par le module de visualisation client (30).

3. Architecture selon l'une des revendications 1 ou 2, caractérisée en ce que le module (21) pour la génération de représentations tridimensionnelles du serveur (2) est apte à générer des représentations allégées de ladite maquette tridimensionnelle pour une communication facilitée au sein du réseau de communication (4).

4. Architecture selon l'une des revendications 1, 2 ou 3, caractérisée en ce que le serveur (2) comporte en outre un module (22) de gestion d'attributs de scène.

5. Architecture selon l'une des revendications précédentes, caractérisée en ce que le serveur (2) comporte en outre un module de rendu (23).

6. Architecture selon la revendication 5, caractérisée en ce que le module de rendu (23) est progressif.

7. Architecture selon la revendication 5, caractérisée en ce que le module de rendu (23) est apte à diviser une image en couches, un coefficient de qualité étant affecté à chaque couche.

8. Architecture selon l'une des revendications précédentes, caractérisée en ce qu'un métalangage de niveaux est défini, ce métalangage étant apte à gérer les couches ainsi que les niveaux de qualités associés à ces couches.

9. Méthode de visualisation d'une maquette numérique tridimensionnelle dans une architecture client-serveur, caractérisée en ce qu'elle comporte les étapes suivantes selon lesquelles: on fournit une base de données (1) tridimensionnelles relative à ladite maquette, un serveur (2) comportant un module (21) pour la génération de représentations tridimensionnelles de ladite maquette et un module de synchronisation réseau (24), un ou plusieurs clients (3, 3a), chaque client (3, 3a) comportant un module de visualisation (30) pour la représentation de ladite maquette et un module de synchronisation réseau (31), et un réseau de communication (4) ; des états de scène de cette représentation tridimensionnelle sont mis à jour, au sein du réseau (4), entre le ou les clients (3, 3a) et le serveur (2), au moyen des modules de synchronisation (24, 31).

10. Méthode selon la revendication 9, caractérisée en ce que les données tridimensionnelles de la base de données (1) sont converties, dans un format spécifique, par un module (20) de conversion de données.

11. Méthode selon l'une des revendications 9 ou 10, caractérisée en ce qu'un module de rendu (23) du serveur (2) divise le calcul d'une image en couches indépendantes représentant chacune un effet visuel et gère des niveaux de qualité.

12. Méthode selon l'une des revendications 9, 10 ou 11, caractérisée en ce que le module de rendu (23) génère des images 2D de haute qualité qui vont enrichir progressivement la représentation de la maquette visualisée par le client.