FR2749421A1 - Dispositif de transfert client-serveur de donnees graphiques a niveaux multiples - Google Patents

Abstract

L'invention concerne un système de transfert perfectionné client-serveur de grand modèle, à niveaux multiples, qui comprend un système serveur, un système client, et un trajet de données qui les connecte. Il comprend un moyen d'élagage à l'intérieur du système serveur pour élaguer des objets qui ne doivent pas être tracés par le client; et un moyen de suppression (28, 30, 32, 34) à l'intérieur dudit système client pour éliminer, avant l'envoi de données par le serveur au client par ledit trajet de données, les données associées à des objets qui ne seront pas visionnés. Ceci permet d'accélérer le traçage de graphiques. L'invention concerne aussi un procédé correspondant.

Description

La présente invention concerne des systèmes d'ordinateurs client-serveur. En particulier, l'invention concerne une nouvelle approche de l'envoi de données, plus particulièrement, de données graphiques, d'un serveur à un système client.

Au fur et à mesure que les systèmes d'ordinateurs ont gagné en acceptation et en succès auprès du public, la facilité d'utilisation est devenue un problème. A de nombreux points de vue, ce sont des interfaces dites "conviviales" qui font la différence quant au succès de leur développement. Les utilisateurs s'attendent maintenant à ce que les ordinateurs ne soient pas simplement à base de texte, mais qu'ils incluent aussi des interfaces graphiques, ainsi que des applications graphiques.

Jusqu'ici, une limitation au succès de la mise en oeuvre des systèmes graphiques résulte de leurs exigences intensives en matériel. En particulier, pour les avancées dans l'art des graphiques d'ordinateurs, l'approche classique a consisté à augmenter la puissance du matériel, pour gagner une meilleure résolution, gagner des affichages plus rapides à l'écran, et gagner en outre un accès plus rapide et meilleur aux données disponibles.

Jusqu'à un certain point, cette approche de "force brute" était effectivement nécessaire. Par exemple, il faut un moniteur à plus haute résolution pour afficher des graphiques de haute résolution, et un processeur rapide pour pouvoir mettre rapidement à jour des images sur l'écran. Cependant, un problème qui subsiste est que l'approche de "force brute" ellemême souffre de limitations. En particulier, il est très onéreux d'augmenter de façon continue la puissance du matériel et, à moins que tous les aspects du matériel ne puissent être augmentés en puissance, il existe des limitations aux bénéfices globaux du système, simplement parce que les performances d'un système sont toujours limitées par le maillon le plus faible du système.

Ces limitations sont particulièrement vraies dans des systèmes client-serveur, ctest-à-dire les systèmes dans lesquels un serveur qui contient de grandes quantités de données est appelé par un système client à fournir les données afin que le client puisse tracer une image ou, en d'autres termes, effectuer un rendu d'une telle image. Dans de tels systèmes, l'approche précédente qui consiste à envoyer au client toutes les données disponibles et à laisser le client traiter les données et créer une image sur l'écran, est tout simplement inefficace. Cette inefficacité est encore amplifiée dans le cas ou le serveur dispose de grandes quantités de données à utiliser pour engendrer des images tridimensionnelles, ou "3-D", sur le système du client.

Le mode de réalisation préféré de la présente invention résout le problème du transfert de grandes quantités de données graphiques, en particulier de données associées à des images graphiques tridimensionnelles, d'un serveur à un client.

L'invention réalise un système de transfert perfectionné client-serveur de grand modèle, à niveaux multiples, qui comprend un système serveur, un système client, et un trajet de données qui connecte ledit système serveur audit système client. Selon l'invention, ce systèmes est caractérisé par:
un moyen d'élagage à l'intérieur du système serveur pour élaguer des objets qui ne doivent pas être tracés par le client, ledit moyen d'élagage éliminant lesdits objets hors de l'ensemble des objets qui seront transmis par ledit système serveur audit système client;
un moyen de suppression des éléments indésirables, appelé simplement de suppression dans ce qui suit, à l'intérieur dudit système client pour éliminer, avant l'envoi de données par le serveur au client par ledit trajet de données, les données associées à des objets qui ne seront pas visionnés ni tracés,
grâce à quoi des données qui ne sont pas nécessaires audit client peuvent être élaguées par ledit système serveur avant l'envoi de données par ledit trajet de données audit système client, et des données qui ne font pas partie de la scène peuvent être supprimées par ledit système client avant d'être tracées.

De préférence, ledit moyen d'élagage interne audit serveur inclut:
(a) un moyen d'effectuer une Elimination par
Hiérarchie d'objets;
(b) un moyen d'effectuer une Elimination par Cône de Vision;
(c) un moyen d'effectuer un tri d'objets d'avant en arrière; et
(d) un moyen d'effectuer un Rejet d'Objets
Cachés.

Le moyen d'effectuer une Elimination par
Hiérarchie d'Objets peut comprendre une structure hiérarchique de données qui définit la relation entre un premier objet et un deuxième objet en se basant sur le fait que ledit premier objet contient ou non ledit deuxième objet ou est contenu ou non par ledit deuxième objet et on peut alors en particulier prévoir que
ladite structure hiérarchique de données définit la relation entre ledit premier objet et ledit deuxième objet en se basant sur le fait que ledit premier objet et ledit deuxième objet sont ou non contenus par un troisième objet, et/ou que
ladite structure hiérarchique de données définit la relation entre ledit premier objet et ledit deuxième objet en se basant sur le fait que ledit premier objet est ou non contenu par un quatrième objet qui contient aussi ledit deuxième objet.

Ledit moyen d'effectuer une Elimination par Cône de Vision peut comprendre un moyen destiné à déterminer si un objet graphique, dont le rayon et la position dans l'espace sont définis, est ou non à l'intérieur du champ de vision d'un observateur qui regarde dans une direction particulière selon un angle de vision défini.

Ledit moyen d'effectuer un tri d'objets d'avant en arrière peut comprendre un moyen de déterminer las distances relatives, à partir d'un observateur, d'autres objets graphiques.

Ledit moyen d'effectuer un Rejet d'Objets Cachés peut comprendre un moyen destiné à déterminer si un premier objet graphique dont le rayon et la position dans l'espace sont définis est ou non caché par des objet graphiques plus proches d'un observateur, le rayon opaque et la position dudit objet plus proche étant définis et le rayon et la position dudit premier objet graphique étant définis.

Selon un deuxième aspect, la présente invention fournit un procédé perfectionné de traçage de scènes graphiques sur un système client servi par un serveur par l'intermédiaire d'un trajet de données, caractérisé par les étapes consistant à:
(a) mémoriser les données sous forme d'une hiérarchie d'objets sur ledit serveur, lesdites données d'objets étant mémorisées dans une hiérarchie dont la forme est celle d'une structure d'arbre dans laquelle des objets contenus par d'autres objets sont à des niveaux différents de ladite structure d'arbre, chaque objet pouvant indiquer un objet parent quelconque dans lequel ledit objet est contenu, un objet enfant quelconque que ledit objet contient, et tous les objets ayant le même parent immédiat, qui sont contenus par le même objet parent;
(b) élaguer des objets hors de ladite structure d'arbre s'ils ne sont pas contenus par ledit objet ou s'ils ne sont pas contenus par les même objets parentaux qui contiennent ledit objet, un objet parental étant, soit un parent dudit objet, soit un objet ayant le même parent immédiat qu'un parent dudit objet, soit un objet parental d'un objet parent;
(c) élaguer, parmi les objets qui n'ont pas été élagués, les objets qui sont à l'extérieur du champ de vision de l'observateur;
(d) trier les objets qui n'ont pas été élagués, et élaguer parmi lesdits objets triés les objets qui seraient cachés par des objets plus proches de 1 'observateur;
(e) transmettre audit client, par l'intermédiaire dudit trajet de données, des données qui n ont pas été élaguées;
(f) supprimer desdites données transmises les objets qui présentent un détail minimal;
(g) supprimer des données restantes les objets dont le volume frontière est à l'extérieur du tronc de cône de vision de l'observateur;
(h) supprimer des données restantes les objets qui peuvent être éliminés par l'API de graphique; et
(i) tracer les objets restants.

Les buts, particularités et avantages de la présente invention exposés ci-dessus ainsi que d'autre seront mieux compris à la lecture de la description détaillée qui suit d'un mode de réalisation préféré de celle-ci, dans laquelle les majuscules utilisées ci dessus dans la définition de l'invention ne seront plus utilisées en général, en se référant aux dessins dans lesquels:
la Fig. 1 est un schéma d'un système typique client-serveur du type auquel on se réfère ici;
la Fig. 2 est une illustration d'un organisation hiérarchique de données du type utilisé dans la présente invention;
la Fig. 3 est une illustration des étapes prises par le serveur en réponse au besoin, exprimé par le client, d'afficher une scène vue à partir d'un emplacement particulier en regardant dans une direction particulière;
la Fig. 4 est une illustration des étapes prises par le serveur pour mettre en oeuvre ses opérations d'élagage;
la Fig. 5 est une illustration de la structure à base d'arbre utilisée par la présente invention;
les Fig. 6 et 7 sont des illustrations de la géométrie de vision utilisée pour l'étape d'élimination par cône de vision;
la Fig. 8 est une illustration qui représente la manière dont un objet peut être à l'intérieur, ou à l'extérieur, du champ de vision d'un autre objet;
la Fig. 9 est une illustration qui représente la manière dont un objet peut être caché par un autre objet plus proche;
la Fig. 10 est un schéma logique qui représente les étapes de suppression effectuées par le client; et
la Fig. 11 est une illustration qui représente la manière dont un volume formant frontière, appelé volume frontière, d'un objet est utilisé pour déterminer si l'objet sera visible par un observateur en se basant sur le fait qu'une partie quelconque du volume frontière est ou non à l'intérieur du tronc de cône qui est visible par l'observateur.

Afin de simplifier la compréhension de la présente invention et des avantages qu'elle apporte, il est utile d'examiner d'abord les systèmes de l'art antérieur. En se référant donc à la Fig. 1, un système typique 10 client-serveur y est représenté. Dans le système 10, un serveur 12 qui mémorise des données peut envoyer ces données par un trajet 16 de données à un client 14 qui a besoin de ces données. Divers problèmes posés par cette approche résultent de la quantité de données qui peut être mémorisées sur le serveur 12 par rapport à la quantité de données sont le client 14 peut effectivement avoir besoin pour fournir à un utilisateur un affichage graphique souhaité.

Les problèmes sont généralement résolus jusqu'ici de la manière suivante: le client 14 demande des données au serveur 12, le serveur 12 transfère les données au client 14 par l'intermédiaire du trajet 16 de données, et le client 14 détermine celles des données que l'affichage graphique doit afficher réellement au client 14. Au fur et à mesure que la résolution des affichages graphiques s'améliore, et que les serveurs peuvent mémoriser davantage de données, les données doivent être transférées du serveur 12 au client 14 par l'intermédiaire du trajet 16 de données, chaque fois que le client 14 doit tracer une image, et le client 14 doit alors sélectionner les données à afficher et les afficher. A chaque avancée de la résolution, il faut aussi jusqu'ici des avancées pour le transfert et la manipulation des données. Cette approche de "force brute" augmente sans cesse les exigences concernant les cadences d'accès aux données, les cadences de transfert des données et le matériel et le logiciel d'affichage.

En se référant à la Fig. 2, selon la présente invention, une nouvelle approche a été développée dans laquelle des données sont représentées et mémorisées sur le serveur 12 selon une hiérarchie à niveaux multiples. En particulier, des données sont appelées des objets 18, qui sont constitués de graphiques 20 qui sont eux-mêmes constitués de primitives 22, par exemple des lignes, des triangles et des polygones.

Par conséquent, selon la présente invention, les niveaux multiples de représentation de données peuvent être utilisés initialement par le serveur 12 pour déterminer si les données qui concernent un objet particulier 18 sont même en fait nécessaires au client 14. Si un objet particulier n'est pas nécessaire pour satisfaire à une demande particulière du client 14, il n'est nullement nécessaire que le serveur 12 transfère soit le graphique 20, soit les primitives 22 qui lui sont associées, au client 14 avec cet objet 18 de données
Si le serveur 12 peut déterminer initialement que le client 14 n'aura pas "dans sa vision" un objet particulier 18, aucun transfert de données n'est en fait nécessaire, en ce qui concerne cet objet 18.

Ainsi donc, comme illustré à la Fig. 3, le serveur 12 est responsable de la mise en oeuvre de deux étapes, à savoir enlever, ou "élaguer" selon la terminaison retenue ici, des objets 24 inutiles, et transférer au client 14 les données qui sont associées à des objets 26 qui peuvent être nécessaires. La première étape de la présente invention est donc d'éliminer, ou élaguer, des objets que le serveur 12 peut déterminer comme inutiles pour le client 14. Cette étape est effectuée par un processus qui implique quatre étapes, illustrées à la Fig. 4.

Comme représenté à la Fig. 4, l'étape d'élagage des objets inutiles est accomplie par les étapes d'élimination 28 par hiérarchie d'objets, d'élimination 30 par cône de vision, de tri 32 d'objets d'avant en arrière, et de rejet banal 34 d'objets cachés. Ces étapes qui sont toutes mises en oeuvre au serveur 12 sont expliquées de façon plus détaillée dans la suite. L'homme de l'art comprend cependant que cet élagage réduit de façon significative la quantité de données à transférer au client 14, en réduisant donc de façon significative le temps nécessaire au client 14 pour tracer une scène.

Malgré ces avantages, le client 14 n'a nul besoin d'un matériel plus rapide. L'approche de "force brute" de l'art antérieur est donc éliminée;
L'étape d'élimination 28 par hiérarchie d'objets, représentée à la Fig. 4, peut maintenant être expliquée de la façon suivante. Selon l'invention, à un degré élevé d'abstraction de données, un objet est considéré comme un récipient d'autres objets. En particulier, un objet peut être contenu par un autre objet, qui est appelé son "parent", et il peut contenir d'autres objets, appelés ses "enfants".

Chaque objet peut aussi avoir ce que l'on appellera des "frères", ce qui correspond aux autres enfants du parent de l'objet. Par conséquent, en utilisant cette abstraction, on peut considérer que la structure d'un objet est la suivante: où struct désigne une structure, prev: précédent, next: suivant, float: flottement et radius: rayon.

struct objet
struct objet
*parent /*ce qui contient cet objet*/
*enfant /*ce que cet objet contient*/
*prev, *next /*liste liée de frères*/
Float
pos[3] /*position dans l'espace*/
radius /*sphère frontière de tous graphiques*/
opaquerad/*rayon opaque: cache tous objets
situés derrière lui*/
/*autres informations, incluant graphiques*/
Selon la structure de données précédente, un objet est considéré comme pourvu d'un indicateur vers son parent, c'est-à-dire *parent, et il peut être pourvu d'un indicateur vers l'un des ses enfants, c'est-à-dire *enfants. Puisque chaque objet est, dans le mode de réalisation préféré de la structure de données, pourvu d'indicateurs formant une liste, vers ses frères c'est-à-dire *prev et *next, il est toujours possible de trouver tous les enfants d'un objet, même s'il n'est pourvu que d'un seul indicateur vers l'un de ses enfants.

La structure de données indique aussi que chaque objet sait où il se trouve dans l'espace tridimensionnel, c'est-à-dire Pos[3], et qu'il connaît tant la sphère frontière qui contient toutes ses données graphiques, c'est-à-dire rayon, que le rayon de celle-ci qui cache tous les objets situés derrière l'objet, c'est-à-dire son rayon opaque désigné par opaquerad.

En se référant maintenant à la Fig. 5, il y est illustré une structure d'arbre qui met en oeuvre la présente invention. A titre d'exemple, un objet graphique, qui est une bille 36, est contenu dans une tasse 38, qui est contenue dans une armoire 40, qui est contenue dans un local 42, qui est contenu dans une maison 44.

Une assiette 48 et un bol 52 sont des frères de la tasse 38. De même, une table 52 et une chaise 54 sont des frères de l'armoire 40, qui contient la tasse 38; un local 56 est un frère du local 42, qui contient l'armoire 40; et des maisons 58, 60 sont des frères de la maison 44, qui contient le local 42. Comme illustre, toutes les maisons 44, 58, 60 sont contenues dans le monde 46, le monde 46 étant l'objet qui contient tous les autres objets. Alors qu'un certain nombre d'objets est illustré à la Fig. 5, de nombreux autres pourraient faire partie des données du serveur 12, comme indiqué symboliquement par les diverses indications: "...autres".

Selon le mode de réalisation préféré de la présente invention, chaque fois qu'un client 14 indique à un serveur 12 que le client 14 souhaite tracer une scène, le serveur 12 doit fournir au client 14 des données dont le client 14 a besoin pour tracer la scène, en se basant sur l'emplacement de l'observateur qui regarde dans une direction particulière à partir d'un point particulier. Par conséquent, la présente invention suppose qu'il existe un observateur 48 qui est à l'emplacement de l'objet, la bille 36, qui est vue.

Une représentation textuelle de la hiérarchie d'arbre illustrée à la Fig. 5 est: monde(
maison ...autres
maison
local
armoire
assiette {}
tasse
bille (
observateur {)
bol
...autres
...autres
table ...autres
chaise
...autres
...autres
local
...autres
...autres
maison
...autres
...autres
Selon la présente invention, un observateur comme l'observateur 48 ne peut voir que certains objets. Par conséquent, les objets que l'observateur ne peut pas voir peuvent être élagués de la structure de données, comme illustré à la référence 24 de la Fig. 3. Des objets qui ne peuvent pas être élagués sont tous ses frères "transversalement", c'est-à-dire la bille, 36; les enfants de ses frères "en descendant" dont il n'existe aucun élément à la Fig. 5; son parent, la tasse 38, et les frères de ses parents, l'assiette 48 et le bol 50; son grand-parent, l'armoire 40, et les frères de son grand-parent, la table 52 et la chaise 54. etc. jusqu'à la racine de l'arbre.

En pseudocode /* tracer frères et enfants de frères */ pour (obj = observateur - > parent- > enfants; obj;
obj = obj - > suivant){
pour (enfant = obj- > enfants; enfant;
enfant = enfant- > suivantf
Tracerobjet(enfant);
tracerobjet(obj); /* tracer parents et frères des parents */ pour (parent = observateur - > parent; parent;
parent = parent - > suivant)(
si (parent- > parent)
pour (obj = parent- > parent- > enfants; obj;
obj = obj- > suivant)(
Tracerobjet(obj);
L'algorithme précédent donne des résultats satisfaisants pour élaguer plusieurs types de scènes, y compris des scènes classiques ville-maison-local et des scènes impliquant l'espace, c'est-à-dire le système solaire: système - planète - lunes satellite. En utilisant l'algorithme précédent, il est possible d'élaguer tous les objets non vus en se basant simplement sur leur hiérarchie dans la structure d'arbre. Par conséquent, la procédure précédente est appelée ici l'élimination par hiérarchie d'objets, qui est l'étape 28 de la Fig. 4, et elle constitue la première étape d'élagage effectuée par le serveur 12.

Après l'élimination par hiérarchie d'objets, l'étape suivante de la présente invention est appelée l'élimination par cône de vision, qui est l'étape 30 de la Fig. 4. L'élimination par cône de vision, qui forme le deuxième niveau d'élagage effectué par le serveur 12 implique le rejet banal d'objets qui sont à l'extérieur du cône de vision de l'observateur 48.

Tel qu'il est utilisé ici, le terme de "cône de vision" est défini par la position de l'observateur, un axe de vision, et un champ de vision, désigné par "FOV". La définition de la structure de données de FOV est donc: struct FOV(
float Pos[3]
float Axe [3]
float FOV
Comme représenté ci-dessus, un objet qui est considéré pour un rejet banal possède une position, dans l'espace tridimensionnel, et un rayon, à l'intérieur duquel tous ses graphiques s'ajustent, qui sont définis en tant que partie de ses données:
float objpos[3]
float radius;
En se référant à la Fig. 6, il y est représenté une illustration de la géométrie de vision. A l'illustration, le vecteur objdir est calculé comme différence vectorielle entre la position de l'objet, objpos, et la position de l'observateur, pos, de sorte que
objdir = objpos - obj.

Si la longueur du vecteur objdir est inférieure au rayon de l'objet, c'est-à-dire la valeur rayon, un rejet banal n'est pas possible puisque la position de l'observateur, pos, est à l'intérieur de l'objet, comme représenté à la Fig. 7. Dans le cas contraire, un rejet banal peut être possible comme expliqué cidessous.

A la Fig. 6, l'angle a, qui correspond à la moitié de la dimension angulaire de l'objet vu par l'observateur, et l'angle B, qui correspond à la séparation entre l'objet et l'axe de vision de l'observateur, peuvent être calculés de la manière suivante:
Objdir est pris pour unité
a = asin(radius / objdist)
B = acos(VDOT(Axe, objdir)
où objdist est la longueur du vecteur d'origine objpos - pos; objdir est le vecteur objpos - pos normalisé, à une longueur de 1; radius signifie rayon, et VDOT est une fonction qui calcule le produit scalaire des vecteurs contenus entre les parenthèses.

Etant donné a, ss et FOV, on peut rejeter banalement un objet si
(ss - a) > (FOV) / 2
Comme représenté à la Fig. 8, l'objet 62 est à l'extérieur du champ de vision FOV de l'observateur, de sorte qu'il peut être rejeté banalement sur la base de l'étape d'élimination par cône de vision, désignée par 30 à la Fig. 4.

Après l'élimination par cône de vision, c'est le tri d'objet d'avant en arrière, désigné par 32 à la
Fig. 4, qui est effectué. Pour réaliser le tri d'objet d'avant en arrière, tous les objets qui ont été rejetés jusqu'ici sont placés dans une liste qui est triée sur la base de leur distance à l'observateur. La liste triée est parcourue d'avant en arrière, ctest-à- dire du point le plus proche au plus éloigné de l'observateur, les objets restants étant envoyés au client 14 pour traçage, sauf s'ils ne satisfont pas au test de rejet d'objet caché décrit ci-dessous.

Le test de rejet d'objet caché est mis en oeuvre de la manière suivante. En plus des informations de position et de rayon, les données de chaque objet incluent un nombre "rayon opaque". Le rayon opaque d'un objet est le rayon à l'intérieur duquel l'objet est complètement opaque. Au fur et à mesure que la liste triée est parcourue, des objets tracés sont placés dans une autre structure de données destinée à des recherches rapides. Un exemple d'une telle structure est appelé un "quadtree", c'est-à-dire littéralement un arbre quadruple, dans la vue en plan.

Chaque nouvel objet est comparé aux objets qui ont déjà été sélectionnés pour être tracés. L'objet est ensuite retenu pour traçage sauf si un objet qui a déjà été tracé, ou sélectionné pour être tracé, le cache, ctest-à-dire s'il est entièrement derrière un objet "plus proche" qui le cache totalement.

Le fait de cacher est basé sur le rayon opaque des objets, de sorte que le champ opaque d'objet 64 est calculé, en se référant à la Fig. 9, de la manière suivante, où eyepos désigne la position de l'oeil, opaquefield signifie champ opaque et other: autre;: opaquedir = other- > pos - eyepos; opaquedist = VLEN(opaquedir);
VNORM( opaquedir) opaquefield = asin(opaquerad / opaquedist); objdir = obj- > pos - eyepos; objdist = VLEN(objdir);
VNORM(objdir); a = asin(objradius / objdist);
B = acos(VDOT(objdir, opaquedir);
Donc l'objet désigné par obj est complètement caché par l'autre objet, désigné par other, si, et seulement si
(a + ss) < opaquefield
En se référant à la Fig. 9, l'objet 65 est complètement situé derrière l'objet 64 et caché par lui, de sorte que l'objet 65 peut être supprimé. Le parcours de la liste triée peut être exprimée en pseudocode de la manière suivante, où for signifie pour, sortedobj: objet trié, if: si, rejected: rejeté, false: faux; true:vrai; First~possible~obscurer: premier cachant possible, next~possible~obscurer cachant possible suivant, break: interruption; et from obscure-loop: de boucle de cache, et où les deux dernières ligne signifient respectivement: envoyer obj à client (obj); et ajouter obj à arbre quadruple.

for( i = O; i < NumObjs; i++) {
Obj = SortedObjs[i];
ObjDir = Obj- > Pos - EyePos;
ObjDist = VLEN( ObjDir );
VNORM( ObjDir;
alpha = asin( Obj- > Radius / ObjDist);
Rejected = FALSE;
for(Other= FIRST~POSSIBLE~OBSCURER(ObjDir);
Other;
Other = NEXT POSSIBLE OBSCURER(Other)) {
OtherDir = Other- > Pos - EyePos; /* line a */
OtherDist = VLEN( OtherDir ); /* line b */
VNORM( OtherDir); 1* line c
OpaqueField = asin( OtherDist / Other- > OpaqueRadius );
/* line d */
beta = acos( VDOT( ObjDir, OtherDir) );
if( (alpha + beta) < = OpaqueField ) (
Rejected = TRUE;
break; /*From obscure-loop*/
.} if (! Rejected)
SendObjToClient( Obj);
AddObjToQuadtree( Obj);
On note que les lignes a, b, c et d peuvent être calculées au préalable dans AddObjToQuadTree. De plus,
FIRST~POSSIBLE~OBSCURER(Vec) utilise l'arbre quadruple pour trouver le premier du quadrant que Vec croise.

NEXT~POSSIBLE~OBSCURER renvoie le suivant de ce quadrant. Finalement une heuristique peut être utilisée pour réduire le nombre d'objets de l'arbre quadruple. Ainsi, il suffit de ne mémoriser que des objets dont le champ opaque est égal ou supérieur à une certaine valeur.

Selon la présente invention, aucun autre traitement ne se produit au serveur 12. Ceci signifie que c'est ici que les données concernant les objets restants, dont le traçage n'a pas pu être éliminé par les procédures d'élagage précédentes, sont envoyées par l'intermédiaire du trajet 16 de données au client 14 où les données sont, soient supprimées, soit tracées, comme illustré à la Fig. 10. En d'autres termes, c'est ici que la couche de transport de réseau se produit, c'est-à-dire que les données sont effectivement envoyées au client 14 par l'intermédiaire du trajet 16 de données, comme représenté à la Fig. 1.

Selon le mode de réalisation préféré de l'invention, chaque objet comprend plusieurs graphiques qui sont identifiés par des identifiants, ou ID, spéciaux de 24 bits qui sont envoyés au client 14 accompagnés d'une matrice de transformée 4 x 3 par graphique. Selon l'invention, le client 14 prend cette matrice et l'identifiant de graphique, et il trace l'identifiant demandé, sur la base d'autres contrôles de suppression.

Le premier contrôle de suppression qui est effectué par le client 14 est appelé la suppression de niveau-de-détail. Pour mettre en oeuvre la suppression de niveau-de-détail, le client 14 associe chaque graphique à un volume frontière tridimensionnel. Ce volume frontière tridimensionnel est transformé par la matrice fournie par le serveur 12 au client 14, et sa dimension calculée sur écran est utilisée pour calculer un bit niveau-de-détail ou "LOD". Par exemple, quatre bits appelés LOD-TINY, LOD-SMALL, LOD
MEDIUM et LOD~LARGE, c'est-à-dire LOD minuscule, LOD petit, LOD moyen et LOD grand, respectivement, sont de préférence calculés. Lorsque le bit approprié a été calculé, si ce bit est placé pour un graphique particulier, il est tracé, Dans le cas contraire, il n'est pas tracé. Puisque des identifiants de graphiques peuvent indiquer un groupe d'identifiants associés de graphiques, un grand nombre de primitives peuvent être soumises à la suppression en n'utilisant qu'un seul contrôle.

La suppression au niveau-du-détail peut être commandée de deux manières selon le procédé préféré de la présente invention. En premier lieu, le concepteur des objets et des graphiques peut étiqueter les graphiques au moyen de drapeaux qui indiquent si le graphique doit être affiché lorsqu'il est minuscule, petit, moyen ou grand sur l'écran. La client 14 qui trace sélectionne alors le graphique approprié en tenant compte de la superficie en pixels du "bounding box" ou "BBox", ou cad satisfaisant pour tous les types de graphiques mis en oeuvres par le client 14, y compris, d'une manière non limitative, des sphères, des tores, des cônes, des cylindres, des anneaux et des disques, des polygones convexes, des mailles triangulaires, des mailles quadrilatérales, des mailles d'altitude, des surfaces de révolution, et des extrusions.

Les superficies exactes sur l'écran, qui provoquent la sélection des divers niveaux-de-détail, sont réglables et sont sujettes à expérimentation. La manière dont le niveau de détail est sélectionné et tracé est illustrée par le pseudocode suivant pour lequel on donnera d'abord la signification des parties de texte en clair.

Dans ce pseudocode, VERT signifie sommet,
SelectLOD: sélectionner LOD; returns the appropriate flag: renvoie le drapeau approprié; based on the onscreen area of the given bounding box (BBox) transformed by the modeling matrix Mat: sur la base de la superficie sur l'écran du cadre frontière transformé par la matrice de modélisation MAT.

Puis, convert bounding box to 8 vertices on box signifie: convertir cadre frontière à 8 sommets sur cadre; transform bounding box into world coordinates:
Transformer cadre frontière en coordonnées monde;
Words per vertex is 3, # of vertices is 8. Mots-parsommet est 3, nombre de sommets est 8; transformpoints signifie: transformer points, Find on-screen bounding rectangle of bounding box: trouver sur écran rectangle frontière de cadre frontière; Worldtoscreen: littéralement monde à écran, graphic: graphique, else: sinon, return: renvoyer, Area, Tinyarea, Samllarea, et
MediumArea: respectivement superficie, superficie minuscule, superficie petite, et superficie moyenne.

Puis, render a graphic to the screen signifie: tracer un graphique sur l'écran; note that graphics have among other things, the following fields: noter que les graphiques possèdent, entre autres, les champs suivants; PrimitiveListLargeVersion: Liste de primitives pour version grande et Medium, Small et
Tiny ont leurs significations habituelles,
Enfin, where PrimitiveList is, for example, an
OPenGL ou Starbase display list signifie: où une liste de Primitives est, par exemple un liste d'affichage
OpenGL ou Starbase, void: vide, Display: affichage;
ActualLOD: littéralement LOD réel; Figure out what résolution to draw: calculer à quelle résolution tracer; see if we can draw this one. . .: essayer si l'on peut tracer celle-ci..., This graphic has automatically generated LODs: Ce graphique a engendré automatiquement des LOD, switch: commuter, case: cas,
Render: tracer, This graphic is to be displayed at the computed level: ce graphique doit être affiché au niveau calculé.

Le pseudocode est alors
/* SelectLOD - returns the appropriate flag LOD TINY, LOD SMALL,
* LOD~MEDIUM, or LOD~LARGE based on the on-screen area of
* the given bounding box (BBox) transformed by the modelling
* matrice Mat *l
int SelectLOD( float BBox[6], float Mat[4J[4J)
float
Verts[8*3];
int
i;
float
x, y, Area,
XMin, YMin,
XMax, YMax;
/* Convert bounding box to 8 vertices on box */
Verts 0] = BBox[0]; Verts[ 1] = BBox[l]; Verts[ 2] = BBox[2];
Verts[ 4] = BBox[0]; Verts[ 5] = BBox[l]; Verts[ 6] = BBox[5];
Verts[ 7) = BBox[0]; Verts[ 8] = BBox[4]; Verts[ 9] = BBox[2];
Verts[l0] = BBox[0]; Verts[l 1] = BBox[4]; Verts[12] = BBox[5];
Verts[13] = BBox[3]; Verts[14] = BBox[1]; Verts[15] = BBox[2];
Verts[16] = BBox[3]; Verts[17] = BBox[1]; Verts[18] = BBox[5];
Verts[19] = BBox[3]; Verts[20] = BBox[4]; Verts[21] = BBox[2];
Verts[22] = BBox[3]; Verts[23] = BBox[4]; Verts[24] = BBox[5];
/* Transform bounding box into world coordinates *l /* Words-per-vertex is 3, # ofvertices is 8 */
TransformPoints( Verts, 3, 8, Mat );
/* Find on-screen bounding rectangle of bounding box */
WorldToScreen( Verts[0], Verts[1], Verts[2], & XMin, & YMin ); XMax=XMin; YMax = YMin;
for(i= l;i < 8;i++) {
WorldToScreen( Verts[3*i], Verts[3 *i+ 1], Verts[3 *i+2], & x,
if(x < XMin)XMin=x; if(x > XMax)XMax=x;
if(y < YMin ) YMin = y; if(y YMax ) YMax = y;
Area = (XMax XMin) * (YMax- YMin);
if( Area < TinyArea) return LOD~TINY;
else if( Area < SmallArea) return LOD~SMALL;
else if( Area < MediumArea) returri LOD~MEDIUM;
else return LOD~LARGE; /* Render a graphic to the sorte. */ Note that graphics have, among other things,
* the following fields:
* struct Graphic (
* float BBox[6];
* int LodBits;
* PrimitiveList LargeVersion;
* PrimitiveList MediumVersion;
* PrimitiveList SmallVersion; * PrimitiveList TinyVersion; * * * where a PrimitiveList isw for example, an OpenGL * or Starbase display list.

*l void DisplayGraphic( struct Graphic *Gfx, float Mat[4][4])
int
ActualLOD;
/* Figure out what resolution to draw */
ActualLOD = SelectLOD(Gfx- > BBox, Mat );
/* See ifwe can draw this one...

if( Gfx- > LodBits & LOD AUTOMATIC ) {
/* This graphic has automatically generated LODs +/
switch( ActualLOD){
case LOD~TINY:
RenderGraphic( Gfx- > Tiny Version );
break; case LOD SMALL:
RenderGraphic( Gfx- > SmallVersion );
break;
case LOD~MEDIUM:
RenderGraphic( Gfx- > MediumVersion );
break;
case LOD~LARGE:
RenderGraphic( Gfx- > LargeVersion );
break;
}
else if( Gfx- > LodBits & ActualLOD) {
/* This graphic is to be displayed at the cornputed
* level-of-detail *l
RenderGraphic( Gfx- > LargeVersion );
En se référant à la Fig. 11, l'étape suivante, réalisée elle aussi par le client 14, est appelée l'effet de frontière, ou "Bounding". I1 est réalisé ici un rejet banal de graphique à base de volume.

Pour le mettre en oeuvre, le volume frontière transformé utilisé dans les suppressions de niveau-dedétail est réutilisé ici. Comme illustré à la Fig. 11, le tronc de cône de vision 66 est entouré par six plans formant frontière: inférieur 68, de côté gauche 70, de côté droit 72, avant 74 et arrière 76 et supérieur 78.

Les côtés du volume de vision transformé 80 sont définis par huit sommets 82, 84, 86, 88, 90, 92, 94, 96, comme représenté. Si chacun des huit sommets 82 à 96 du volume de vision transformé 80 est situé à l'extérieur de l'un quelconque des six plans frontières 68 à 78 du tronc de cône de vision 66, le graphique est soumis à suppression. Pour déterminer si l'un quelconque des sommets 82 à 96 est à l'intérieur du tronc de cône de vision 66, chacun des plans 68 à 78 du tronc de cône de vision est pris en compte successivement. Ici aussi, la construction à groupage peut éliminer de grands nombres de primitives au moyen d'un contrôle unique.

En considérant le volume de vision transformé 80, représenté à la Fig. 11, il est possible de déterminer directement que les huit sommets se trouvent tous à droite du côté droit 72 du tronc de cône de vision 66. Par conséquent, le graphique défini à l'intérieur du volume de vision 80 n'est pas visible, et il est donc supprimé.

A ce point, les graphiques restants, qui n'ont été ni élagués ni supprimés, sont convertis en primitives, et ils sont tracés par le client 14. Dans les modes de réalisation préférés de l'invention, les graphiques sont de préférence tracés au moyen d'un API graphique, par exemple Starbase ou OpenGL de Hewlett
Packard. L'API graphique effectue les deux niveaux finaux d'élagage/suppression, ctest-à-dire la suppression de face arrière et la découpe de vision.

Puisque ces deux deniers niveaux font partie de 1'API graphique, l'homme de l'art reconnaîtra leur mode de fonctionnement.

Comme l'homme de l'art le reconnaîtra, des variantes de procédés peuvent être utilisées pour l'élimination par cône de vision et pour le rejet d'objets cachés. Ainsi, alors qu'un procédé destiné à utiliser des sphères a été décrit pour l'élimination par cône de vision et pour le rejet d'objets cachés, un polyèdre convexe quelconque pourrait également être utilisé sans s'écarter de la présente invention. Dans l'exemple qui suit, opaque signifie opaque, area: superficie, transformed vertices of: sommets transformés de, more stuff, object hierarchy, etc: éléments additionnels, hiérarchie d'objet, et que les trois dernières lignes signifient: les réseaux
XformedBox et XformedOpaque sont créés exactement comme dans le calcul BBox-to-verts de SelectLOD cidessus. Alors, à titre d'exemple, en utilisant un cadre frontière,
struct Object (
float BBox[63; /* XYZ minimax ofobject Gfx */
float OpaqueBBox[6J; /* XYZ minimaux 0f opaque area */
float XformedBox[l8*3]; /* 8 transfonned vertices of object */
float XformedOpaque[8*3]; /* 8 " " of opaque bbox */
/* More stuff, object hierarchy, etc. */
};
/* The XformedBox and XfonnedOpaque aiiays are created
* exactly like the BBox-to-verts calculation in SelectLOD,
* above.

*/
Comme illustré, l'élimination par cône de vision devient élimination par tronc de cône. Ici aussi, exactement comme pour un graphique sur le côté client, les sommets transformés du cadre frontière sont utilisés pour déterminer s'ils sont tous situés sur l'extérieur de l'un des six plans du tronc de cône de vision. Ceci est facile à réaliser avec un simple test de plan de manière bien connue de l'homme de l'art des graphiques par ordinateur.

Afin de réaliser le rejet d'objets cachés en pseudocode, il est possible d'effectuer la procédure suivante, les significations des termes en clair étant données ici après le pseudocode for( i = 0; i < NumObjs; i+t ) (
Obj = SortedObjs[i];
ObjDir = Obj- > Pos - EyePos;
Rejected = FALSE;
for( Other = FIPST~POSSIBLE~OBSCURER(ObjDir);
Other;
Other = NEXT~POSSIBLE~OBSCURER(ObjDir) )
AllObscured = TRUE;
for( n = O; AllObscured & & (n < 8); n++) (
To[O] = Obj- > XformedBox[3*n];
To[1] = Obj- > XformedBox[3*n+ 1];
To[2] = Obj- > XformedBox[3*n+2];
if( NOT RayBoxIntersect( Eye, To, Other- > XformedOpaque ))
AllObscured = FALSE;
if( AllObscured)(
Rejected = TRUE;
break; /* From obscure-loop */
if( !Rejected)(
SendObjToClient( Obj);
AddObjToQuadtree( Obj); où Sortedobj signifie objet trié, Allobscured: tous cachés, RayBoxIntersect: littéralement intersection de cadre de rayon, from obscure-loop: de boucle de cache,
SendObjttoClient: envoyer objet à client et
AddObjToQuadtree; Ajouter objet à arbre quadruple.

Comme décrit ci-dessus, la superficie opaque et le volume frontière peuvent être un polyèdre convexe arbitraire; Dans le cas général, ceci est réalisé en substituant le nombre de sommets à "8" dans la boucle interne, et en substituant un appel
RayPolyhedronintersect, ctest-à-dire littéralement intersection de polyèdre de rayon, à Rayboxintersect.

Evidemment, pour des polyèdres suffisamment complexes, davantage de temps alors nécessaire pourrait être utilisé par le serveur 12 pour effectuer le test d'objets cachés. Par conséquent, un cadre frontière est efficace et suffisant.

Claims (9)

REVENDICATIONS

1. Système de transfert perfectionné clientserveur de grand modèle, à niveaux multiples, qui comprend un système serveur (12), un système client (14), et un trajet (16) de données qui connecte ledit système serveur (12) audit système client (14), caractérisé par:

un moyen d'élagage (24) à l'intérieur du système serveur (12) pour élaguer des objets qui ne doivent pas être tracés par le client (14), ledit moyen d'élagage éliminant lesdits objets hors de l'ensemble des objets qui seront transmis par ledit système serveur (12) audit système client (14);

un moyen de suppression (28, 30, 32, 34) à l'intérieur dudit système client (14) pour éliminer, avant l'envoi de données par le serveur (12) au client (14) par ledit trajet (16) de données, les données associées à des objets qui ne seront pas visionnés,

grâce à quoi des données qui ne sont pas nécessaires audit client (14) peuvent être élaguées par ledit système serveur (12) avant 1 envoi de données par ledit trajet (16) de données audit système client (14), et des données qui ne font pas partie de la scène peuvent être supprimées par ledit système client (14) avant d'être tracées.

2. Système de transfert selon la revendication 1, caractérisé en ce que ledit moyen d'élagage interne audit serveur inclut:

(a) un moyen d'effectuer une Elimination (28) par

Hiérarchie d'Objets;

(b) un moyen d'effectuer une Elimination (30) par

Cône de Vision

(c) un moyen d'effectuer un tri (32) d'objets d'avant en arrière; et

(d) un moyen d'effectuer un Rejet (34) d'Objets

Cachés.

3. Système de transfert selon la revendication 1 caractérisé en ce que

le moyen d'effectuer une Elimination (28) par

Hiérarchie d'Objets comprend une structure hiérarchique de données (Fig. 5) qui définit la relation entre un premier objet et un deuxième objet en se basant sur le fait que ledit premier objet contient ou non ledit deuxième objet ou est contenu ou non par ledit deuxième objet.

4. Système de transfert selon la revendication 3 caractérisé en ce que

ladite structure hiérarchique de données (Fig. 5) définit la relation entre ledit premier objet et ledit deuxième objet en se basant sur le fait que ledit premier objet et ledit deuxième objet sont ou non contenus par un troisième objet.

5. Système de transfert selon la revendication 3 caractérisé en ce que

ladite structure hiérarchique de données (Fig. 5) définit la relation entre ledit premier objet et ledit deuxième objet en se basant sur le fait que ledit premier objet est ou non contenu par un quatrième objet qui contient aussi ledit deuxième objet.

6. Système de transfert selon la revendication 2 caractérisé en ce que

ledit moyen d'effectuer une Elimination par Cône de Vision comprend un moyen destiné à déterminer si un objet graphique, dont le rayon et la position dans l'espace sont définis, est ou non à l'intérieur du champ de vision d'un observateur qui regarde dans une direction particulière selon un angle de vision défini (Fig. 6, 7).

7. Système de transfert selon la revendication 2 caractérisé en ce que

ledit moyen d'effectuer un tri (32) d'objets d'avant en arrière comprend un moyen de déterminer las distances relatives, à partir d'un observateur d'autres objets graphiques.

8. Système de transfert selon la revendication 2 caractérisé en ce que ledit moyen d'effectuer un Rejet (34) d d'Objets

Cachés comprend un moyen destiné à déterminer si un premier objet graphique dont le rayon et la position dans l'espace sont définis est ou non caché par des objet graphiques plus proches d'un observateur (Fig. 8, 9), le rayon opaque et la position dudit objet plus proche étant définis et le rayon et la position dudit premier objet graphique étant définis.

9. Procédé perfectionné de traçage de scènes graphiques sur un système client (14) servi par un serveur (12) par l'intermédiaire d'un trajet (16) de données, caractérisé par les étapes consistant à:

(a) mémoriser les données sous forme d'une hiérarchie d'objets sur ledit serveur (12), lesdites données d'objets étant mémorisées dans une hiérarchie dont la forme est celle d'une structure d'arbre (Fig. 5) dans laquelle des objets contenus par d'autres objets sont à des niveaux différents de ladite structure d'arbre (Fig. 5), chaque objet pouvant indiquer un objet parent quelconque dans lequel ledit objet est contenu, un objet enfant quelconque que ledit objet contient, et tous les objets, ayant le même parent immédiat, qui sont contenus par le même objet parent;

(b) élaguer des objets (24) hors de ladite structure d'arbre (Fig. 5) s'ils ne sont pas contenus par ledit objet ou s'ils ne sont pas contenus par les même objets parentaux qui contiennent ledit objet, un objet parental étant, soit un parent dudit objet, soit un objet ayant le même parent immédiat qu'un parent dudit objet, soit un objet parental d'un objet parent;

(c) élaguer, parmi les objets qui n ont pas été élagués, les objets qui sont à l'extérieur du champ de vision de l'observateur;

(d) trier les objets qui n'ont pas été élagués, et élaguer parmi lesdits objets triés les objets qui seraient cachés par des objets plus proches de 1 'observateur,

(e) transmettre audit client, par l'intermédiaire dudit trajet de données, des données qui n'ont pas été élaguées;

(f) supprimer desdites données transmises les objets qui présentent un détail minimal;

(g) supprimer des données restantes les objets dont le volume frontière est à l'extérieur du tronc de cône de vision de l'observateur;

(h) supprimer des données restantes les objets qui peuvent être éliminés par 1'API de graphique; et

(i) tracer les objets restants.