FR2901439A1

FR2901439A1 - METHOD FOR SELECTING AT LEAST ONE SERVER PAIR FOR TRANSMITTING VISUALIZATION DATA, TERMINAL, SERVER, AND CORRESPONDING COMPUTER PROGRAM PRODUCT.

Info

Publication number: FR2901439A1
Application number: FR0604566A
Authority: FR
Inventors: Romain Cavagna; Christian Bouville; Jerome Royan
Original assignee: France Telecom SA
Current assignee: Orange SA
Priority date: 2006-05-22
Filing date: 2006-05-22
Publication date: 2007-11-23
Also published as: WO2007135336A2; WO2007135336A3

Abstract

L'invention concerne un procédé de sélection d'au moins un pair serveur pour la transmission de données de visualisation d'un contenu à destination d'au moins un pair client au sein d'un réseau de pairs, lesdites données étant organisées sous la forme de noeuds d'un arbre hiérarchique comprenant au moins un noeud parent et au moins un noeud fils, un élément visualisable étant associé à chacun desdits noeuds.Selon l'invention, un tel procédé comprend une phase de sélection d'au moins un desdits pairs serveur comprenant au moins une partie desdites données de visualisation et/ou au moins une partie dudit arbre hiérarchique, ladite phase de sélection tenant compte d'au moins une information représentative d'une taille de données d'au moins un desdits éléments visualisables.The invention relates to a method for selecting at least one peer server for the transmission of data for viewing content for at least one peer client within a peer network, said data being organized under the node form of a hierarchical tree comprising at least one parent node and at least one child node, a displayable element being associated with each of said nodes. According to the invention, such a method comprises a selection phase of at least one of said nodes. peer server comprising at least a portion of said visualization data and / or at least a portion of said hierarchical tree, said selection phase taking into account at least one information representative of a data size of at least one of said viewable elements.

Description

- Pair Serveur : Le Pair Serveur est un Pair d'un réseau de Pair à Pair- Pair Server: The Pair Server is a Pair of a Peer-to-Peer Network

qui peut effectuer un rôle de serveur de données pour d'autres Pairs qui s'y connectent ; Pair Client : Le Pair Client est un Pair d'un réseau de Pair à Pair qui 5 demande de l'information à des Pairs Serveurs. Arbre de sélection : L'arbre de sélection est une description simplifiée d'une représentation hiérarchique ne contenant que les informations de sélection. L'arbre de sélection est utilisé pour déterminer les noeuds qui sont visibles pour un point de vue donné ; 10 - Connectivité : la connectivité représente la manière dont sont connectés les Pairs les uns avec les autres. Dans notre cas la connectivité est fonction de la position des pairs dans un espace virtuel (i.e. de leur proximité directe) ; TTS (de l'anglais Time To Serve pour temps de service ) : temps que met l'application distante à répondre à une requête particulière. Ce 15 temps inclut le TTL (de l'anglais Time To Live pour Temps de Vie ) qui est le temps de transport des données sur le réseau ; Pourcentage de réalisation : Le pourcentage de réalisation correspond au pourcentage de requêtes acquittées par l'application distante ; Pourcentage de chargement : Le pourcentage de chargement correspond au 20 pourcentage de données chargée pour un point de vue donné par rapport à ce qui devrait être chargé si l'application distante disposait de toute cette information ; Upload (pour chargement ) : L'Upload est le débit que peut fournir le pair distant. Il peut être mesuré, ou transmis par le pair distant s'il décide 25 d'allouer une bande passante particulière pour l'envoi des données. 2 SOLUTIONS DE L'ART ANTERIEUR 2.1 Art antérieur Depuis la popularisation de l'Internet, de nombreuses personnes et entités ont mis en places des moyens logiciels permettant la création de mondes virtuels 30 en trois dimensions. Ces moyens logiciels se sont concrétisés par la mise en oeuvre de techniques de compressions, de définition d'environnement en trois dimensions ou d'environnements multimédias et de techniques de transfert de l'information. Cependant, les mondes virtuels en trois dimensions sont caractérisés par d'importants volumes de données. Les architectures centralisées classiques n'offrent pas de performances suffisantes pour permettre un échange dynamique des informations de constitution des environnements en trois dimensions en temps réel à un nombre d'utilisateurs important. Des alternatives ont été proposées pour pallier les problèmes de performances. Elles consistent généralement à précharger, au sien du terminal considéré, une base de données locale décrivant l'intégralité d'un monde virtuel. Les informations reçues depuis le serveur et envoyées à ce dernier peuvent alors se limiter à des échanges d'interaction d'un utilisateur avec l'environnement dans lequel il évolue et non plus des échanges visant à permettre au terminal de construire un environnement en temps réel. De telles solutions ont cependant leurs limites, telles que par exemple l'obligation de mettre à jour régulièrement tout ou partie de l'environnement sur le terminal considéré, ce qui peut poser des problèmes quand le volume des données à télécharger est conséquent ou encore lorsque le terminal considéré possède des capacités de stockages limités. Il n'est donc pas pertinent d'installer les environnements virtuels statiquement, au sien des terminaux. who can perform a data server role for other peers who connect to it; Peer Client: The Peer Client is a Peer-to-Peer Network Pair who requests information from Peer Servers. Selection tree: The selection tree is a simplified description of a hierarchical representation containing only the selection information. The selection tree is used to determine which nodes are visible for a given point of view; 10 - Connectivity: Connectivity is the way peers are connected to each other. In our case connectivity is a function of the position of peers in a virtual space (i.e. of their direct proximity); Time To Serve (TTS): The time that the remote application responds to a particular request. This time includes TTL (Time To Live for Life Time) which is the transport time of the data on the network; Percentage of realization: The percentage of realization corresponds to the percentage of requests paid by the remote application; Load Percentage: The Load Percentage is the percentage of data loaded for a given viewpoint relative to what should be loaded if the remote application had all this information; Upload (Upload): Upload is the rate that the remote peer can provide. It can be measured, or transmitted by the remote peer if it decides to allocate a particular bandwidth for sending the data. PRIOR ART SOLUTIONS 2.1 Prior Art Since the popularization of the Internet, many people and entities have set up software means for the creation of virtual worlds in three dimensions. These software means were concretized by the implementation of compression techniques, three-dimensional environment definition or multimedia environments and information transfer techniques. However, virtual worlds in three dimensions are characterized by large volumes of data. Traditional centralized architectures do not provide sufficient performance to allow dynamic exchange of information constituting environments in three dimensions in real time to a large number of users. Alternatives have been proposed to overcome performance problems. They generally consist of preloading, in his own terminal, a local database describing the entirety of a virtual world. The information received from the server and sent to the latter can then be limited to interaction exchanges of a user with the environment in which it evolves and no longer exchanges to allow the terminal to build a real-time environment . Such solutions, however, have their limits, such as for example the obligation to regularly update all or part of the environment on the terminal in question, which can cause problems when the volume of data to be downloaded is substantial or when the terminal in question has limited storage capacity. It is therefore irrelevant to install the virtual environments statically, to the terminals.

Une nouvelle technique très récente présentée dans le document A Case For 3D Streaming on Peer-to-Peer Networks de Shun-Yun Hu , National Central University of Taiwan 2006, présente une technique de partage des informations de constitution des environnements en trois dimensions basée sur le principe des réseaux de pair à pair. Selon cette technique, chaque terminal possède, à un instant donné, une partie des informations de constitution de l'environnement dans lequel il évolue (des cellules). Il peut avoir obtenu ces informations soit de la part d'un pair serveur, soit de la part d'un serveur central. Plus particulièrement, la technique proposée permet à des terminaux voisins qui sont situés dans une même portion d'un espace virtuel de s'échanger des informations de constitution de cet espace (les cellules qu'ils connaissent) sans qu'il soit obligatoirement nécessaire pour les terminaux d'interroger un serveur central. En effet, les terminaux dont un utilisateur interagit dans une portion d'espace commune à plusieurs autres terminaux (dont d'autres utilisateurs interagissent également dans cette portion d'espace) peuvent, par le biais de techniques de transmissions de données entre pairs voisins, s'échanger des informations de constitution des cellules communes. Le serveur central est alors déchargé de tout ou partie des requêtes en provenance des clients. Du point de vue du serveur, une telle technique présente de nombreux avantages, notamment le fait de la décharger d'une grande partie des demandes de transfert des informations de constitution de l'environnement 3D. Grâce à une telle technique, les terminaux, quant à eux, s'échangent des données sans qu'il soit théoriquement nécessaire d'attendre une réponse de la part d'un serveur. Cependant, l'intérêt principal attendu de cette technique de l'art antérieur est de permettre une scalabilité étendue et une utilisation simultanée par un très grand nombre d'utilisateur. 2.2 Inconvénients de l'art antérieur Un inconvénient de cette technique d'échange de pair à pair de l'art antérieur est notamment lié à l'absence de prise en compte de la constitution de la portion d'espace virtuel à échanger entre des pairs. En effet, cette technique de l'art antérieur définit bien un environnement commun entre les pairs (les cellules). Cette portion commune de l'environnement est partagée par tous les pairs dont un utilisateur évolue dans cette partie de l'environnement. Cependant les cellules ne distinguent pas les niveaux de détail de l'environnement. Ainsi, les utilisateurs situés dans une même portion d'espace virtuel partagent l'intégralité de la définition de cet espace, et ce quelle que soit, par exemple, la distance virtuelle qui sépare deux utilisateurs dans un espace. Par exemple, si on considère, dans une portion d'espace visible, deux avatars différents (représentation de deux utilisateurs différents dans la portion d'espace), le premier avatar se situant à deux mètres d'un point d'intérêt et le second avatar se situant à vingt mètres de ce même point d'intérêt. A new, very recent technique presented in Shun-Yun Hu's A Case For 3D Streaming on Peer-to-Peer Networks, National Central University of Taiwan 2006, presents a technique for sharing information about building three-dimensional environments based on the principle of peer-to-peer networks. According to this technique, each terminal has, at a given moment, part of the constitution information of the environment in which it evolves (cells). It may have obtained this information either from a peer server or from a central server. More particularly, the proposed technique allows neighboring terminals that are located in the same portion of a virtual space to exchange information constituting this space (the cells they know) without it being necessary to terminals interrogate a central server. Indeed, the terminals of which a user interacts in a portion of space common to several other terminals (which other users also interact in this portion of space) can, by means of data transmission techniques between neighboring peers, exchange information of formation of the common cells. The central server is then unloaded all or part of the requests from the clients. From the point of view of the server, such a technique has many advantages, including the fact of offloading a large part of the requests for transfer of information constituting the 3D environment. With such a technique, the terminals, meanwhile, exchange data without the theoretical need to wait for a response from a server. However, the main interest expected from this technique of the prior art is to allow extended scalability and simultaneous use by a very large number of users. 2.2 Disadvantages of the Prior Art A disadvantage of this technique of peer-to-peer exchange of the prior art is notably related to the fact that the constitution of the portion of virtual space to be exchanged between peers is not taken into account. . Indeed, this technique of the prior art defines a common environment between peers (cells). This common portion of the environment is shared by all the peers a user evolves in that part of the environment. However cells do not distinguish levels of detail from the environment. Thus, users in the same portion of virtual space share the entire definition of this space, regardless of, for example, the virtual distance between two users in a space. For example, if we consider, in a portion of visible space, two different avatars (representation of two different users in the space portion), the first avatar being two meters from a point of interest and the second avatar located twenty meters from this same point of interest.

Selon la technique de l'art antérieur, ces deux pairs rechercheront et obtiendront, auprès d'autres pairs situés dans la même portion d'environnement, les mêmes informations de constitution. Une telle obtention se révèle inadéquat du fait que les deux avatars n'ont manifestement pas la même perception du point d'intérêt considéré. Un autre inconvénient de cette technique de l'art antérieur est du à l'incapacité d'un pair client considéré à prendre en compte le volume des données à télécharger depuis des pairs serveurs. En effet, la technique de l'art antérieure décrit bien un mode de sélection des pairs serveurs par un pair client en tenant compte d'un temps de latence, d'une capacité de bande passante et d'une capacité des pairs serveurs considérés à fournir l'information attendue. Cependant, une telle technique ne permet pas de gérer correctement les transferts de données entre les pairs. En effet, selon cette technique de l'art antérieur, le pair serveur qui répond le mieux à ces critères de classification sera privilégié par un pair client pour l'obtention de données manquantes. Cependant, même si ce pair serveur est très performant, la technique de l'art antérieur ne tient pas compte du volume de données à télécharger, pas plus que d'une présence d'une file d'attente éventuelle. Ainsi, l'utilisation d'une méthode de transfert de pair à pair par cette technique de l'art antérieure n'est pas à même de garantir un temps de téléchargement inférieur à celui que fournirait un serveur. 3 RESUME DE L'INVENTION La solution proposée par l'invention permet de pallier ces inconvénients de l'art antérieur, grâce à un procédé de sélection d'au moins un pair serveur pour la transmission de données de visualisation d'un contenu à destination d'au moins un pair client au sein d'un réseau de pairs, lesdites données étant organisées sous la forme de noeuds d'un arbre hiérarchique comprenant au moins un noeud parent et au moins un noeud fils, un élément visualisable étant associé à chacun desdits noeuds. Selon l'invention, un tel procédé comprend une phase de sélection d'au moins un desdits pairs serveur comprenant au moins une partie desdites données de visualisation et/ou au moins une partie dudit arbre hiérarchique, ladite phase de sélection tenant compte d'au moins une information représentative d'une taille de données d'au moins un desdits éléments visualisables. Ainsi, l'invention repose sur une approche nouvelle de la sélection de pairs 5 serveur dans le cadre de la transmission de données de visualisation d'un contenu en utilisant la taille des informations à transmettre afin de sélectionner au mieux les pairs serveur susceptibles de transmettre l'information. Selon un aspect particulier de l'invention, ladite phase de sélection comprend une étape d'identification d'un ensemble de pairs voisins comprenant 10 au moins une partie desdites données de visualisation et/ou au moins une partie dudit arbre hiérarchique. La sélection selon la taille porte donc tout autant sur la structure définissant les données de visualisation que sur les données de visualisation elles même. En effet, selon l'invention, il est possible de sélectionner un pair qui va 15 transmettre une partie de la structure de visualisation tout en sélectionnant un autre pair pour transmettre les données de visualisation en tant que telles. Ce procédé offre donc une scalabilité importante lors de la transmission des données entre pairs d'un réseau de pair à pair. Selon un mode de mise en oeuvre particulier, ladite phase de sélection 20 comprend les étapes suivantes : détermination, par ledit au moins un pair client, d'un espace virtuel de navigation courant, représenté par un sous-arbre de visualisation courant dudit arbre hiérarchique ; sélection, par ledit au moins un pair client, d'au moins un pair serveur 25 voisin présent au sein dudit espace virtuel de navigation courant, formant ledit ensemble de pairs voisins ; transmission, audit pair client, par au moins un desdits pairs serveurs voisins, d'au moins un noeud de visualisation dudit sous-arbre de visualisation courant, suite à au moins une requête dudit pair client ; 30 - association d'au moins un desdits pairs serveurs voisins, dit pair serveur associé, à chacun desdits noeuds dudit sous-arbre de visualisation en fonction des noeuds de visualisation contenus dans chacun desdits pairs serveur ; classement, par ledit pair client, desdits pairs associés, selon ladite taille de données desdits éléments visualisables desdits noeuds de visualisation transmis, pour chacun desdits noeuds ; transmission, par lesdits pairs associés, d'au moins une donnée de visualisation desdits éléments visualisables suite à au moins une demande de transmission émise par ledit pair client, en fonction dudit classement. According to the technique of the prior art, these two peers will seek and obtain, from other peers located in the same portion of environment, the same constitution information. Such an acquisition proves to be inadequate because the two avatars clearly do not have the same perception of the point of interest considered. Another disadvantage of this technique of the prior art is due to the inability of a client peer considered to take into account the volume of data to download from peer servers. Indeed, the technique of the prior art describes a method of selection of peer servers by a client peer taking into account a latency, bandwidth capacity and capacity of the peer servers considered to provide the expected information. However, such a technique does not properly manage data transfers between peers. Indeed, according to this technique of the prior art, the peer server that best meets these classification criteria will be favored by a client peer for obtaining missing data. However, even if this peer server is very powerful, the technique of the prior art does not take into account the amount of data to download, nor a presence of a possible queue. Thus, the use of a method of peer-to-peer transfer by this technique of the prior art is not able to guarantee a download time lower than that provided by a server. SUMMARY OF THE INVENTION The solution proposed by the invention makes it possible to overcome these drawbacks of the prior art, by means of a method for selecting at least one peer server for transmitting data for viewing content at destination. at least one peer client within a peer network, said data being organized in the form of nodes of a hierarchical tree comprising at least one parent node and at least one child node, a viewable element being associated with each said nodes. According to the invention, such a method comprises a selection phase of at least one of said peer server comprising at least a part of said display data and / or at least a part of said hierarchical tree, said selection phase taking into account from least information representative of a data size of at least one of said viewable elements. Thus, the invention is based on a new approach to the selection of server peers in the context of the transmission of data for viewing a content by using the size of the information to be transmitted in order to best select the peer servers likely to transmit information. According to a particular aspect of the invention, said selection phase comprises a step of identifying a set of neighboring peers comprising at least a part of said display data and / or at least a part of said hierarchical tree. The selection according to the size therefore relates as much to the structure defining the visualization data as to the visualization data themselves. Indeed, according to the invention, it is possible to select a peer that will transmit part of the display structure while selecting another peer to transmit the display data as such. This method therefore offers significant scalability when transmitting data between peers of a peer-to-peer network. According to a particular embodiment, said selection phase comprises the steps of: determining, by said at least one client peer, a current virtual browsing space, represented by a current viewing subtree of said hierarchical tree ; selecting, by said at least one client peer, at least one neighboring peer server present within said current browsing virtual space, forming said set of neighboring peers; transmission, to said peer client, by at least one of said neighboring peer servers, of at least one display node of said current display subtree, following at least one request from said client peer; Associating at least one of said neighboring peer servers, said associated server pair, with each of said nodes of said visualization subtree according to the viewing nodes contained in each of said peer servers; classifying, by said peer client, said associated pairs, according to said data size of said viewable elements of said transmitted display nodes, for each of said nodes; transmission, by said associated pairs, of at least one display data of said viewable elements following at least one transmission request sent by said client pair, according to said classification.

Le pair client dispose ainsi d'un processus permettant de sélectionner les pairs serveur en fonction d'un espace virtuel de navigation courant dans lequel il se trouve. Cet espace de navigation est représenté par un arbre hiérarchique. L'arbre hiérarchique, définissant la structure des données de visualisation, est transmis au pair client suite à une requête de celui-ci en fonction des pairs serveurs qui sont connectés. Les requêtes de transmission de l'arbre hiérarchique peuvent tenir compte de la taille des données de constitution de l'arbre à transmettre. Le pair client associe les pairs serveur voisin en fonction de la taille des données de visualisation obtenues grâce à l'arbre hiérarchique puis il effectue un classement des pairs serveurs en fonction de cette taille. Il émet ensuite des requêtes de transfert des données de visualisation aux serveurs en fonction de ce classement. Selon une caractéristique originale, ladite étape de classement tient également compte d'au moins un des paramètres appartenant au groupe comprenant au moins : une quantité de bande passante disponible pour la transmission ; un temps de service ; un temps de téléchargement ; un niveau de détail dudit au moins un noeud de visualisation ; les données présentes sur lesdits pairs serveurs ; - le pourcentage de chargement ; le taux d'acquittement ; la position desdits pairs serveurs. Ainsi, l'étape de classement ne tient pas uniquement compte de la taille pais aussi d'autres paramètres permettant de s'assurer de la disponibilité et des capacités des pairs serveur ainsi que d'un niveau de détail souhaité par le pair client. Par exemple, un pair client qui requiert des données de visualisation d'un niveau de détail faible peut tout à fait interroger un pair serveur disposant de capacité faible si le volume des données à transmettre est faible. Selon un aspect particulier de l'invention, ledit procédé de sélection met en oeuvre au moins un pair, dit pair de connectivité, gérant l'accès d'un pair client à un réseau de pairs, et ladite étape de détermination d'un espace virtuel de navigation courant comprend les sous-étapes suivantes : connexion dudit pair client à au moins un desdits pairs de connectivité, de façon à permettre audit pair client d'accéder audit réseau de pairs ; -interrogation, par ledit pair client, d'au moins un pair dont un identifiant est fourni par au moins un desdits pairs de connectivité de façon à obtenir ledit sous-arbre de visualisation ; De cette façon, le pair client obtient une connexion au réseau de pairs par le biais d'un pair qui joue le rôle de pair de connectivité. Ce pair de connectivité permet au pair client considéré d'obtenir une liste de ses voisins dans l'espace virtuel au sein duquel il évolue. Cette liste permet dans un premier temps au pair client de déterminer les pairs serveurs susceptibles de lui délivrer de l'information. L'invention concerne également un signal de données échangées entre au 25 moins un pair serveur et au moins un pair client. Selon l'invention un tel signal comprend au moins un champ d'information d'au moins une information représentative d'une taille de données d'au moins un desdits éléments visualisables. Dans un autre mode de réalisation, l'invention concerne également un 30 produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur. Selon l'invention, dans au moins un mode de réalisation, un tel produit programme d'ordinateur comprend des instructions de code de programme pour l'exécution du procédé de sélection de pairs serveur tel que décrit précédemment. L'invention concerne également un terminal comprenant un pair client de sélection d'au moins un pair serveur pour la transmission de données de visualisation d'un contenu au sein d'un réseau de pairs, lesdites données étant organisées sous la forme de noeuds d'un arbre hiérarchique comprenant au moins un noeud parent et au moins un noeud fils, un élément visualisable étant associé à chacun desdits noeuds. Selon l'invention, un tel terminal comprend des moyens de sélection d'au moins un desdits pairs serveur comprenant au moins une partie desdites données de visualisation et/ou au moins une partie dudit arbre hiérarchique, ladite phase de sélection tenant compte d'au moins une information représentative d'une taille de données d'au moins un desdits éléments visualisables. Dans un autre mode de réalisation, un tel terminal peut comprendre également des moyens de mise en oeuvre des étapes du procédé de sélection tel que décrit précédemment. The client peer thus has a process for selecting the peer server based on a current virtual browsing space in which it is located. This navigation space is represented by a hierarchical tree. The hierarchical tree, defining the visualization data structure, is transmitted to the client peer following a request from the peer client based on the peer servers that are connected. The transmission requests of the hierarchical tree may take into account the size of the constitution data of the tree to be transmitted. The peer client associates the neighboring peer server based on the size of the visualization data obtained from the hierarchical tree and then ranks the peer servers by that size. It then sends requests for the transfer of visualization data to the servers according to this classification. According to an original characteristic, said classification step also takes account of at least one of the parameters belonging to the group comprising at least: a quantity of bandwidth available for transmission; a time of service; download time; a level of detail of said at least one display node; the data present on said peer servers; - the percentage of loading; the acquittal rate; the position of said peer servers. Thus, the ranking step does not only take into account size but also other parameters to ensure the availability and capabilities of the peer server as well as a level of detail desired by the peer client. For example, a client peer that requires visualization data of a low level of detail can fully query a peer server with low capacity if the volume of data to be transmitted is low. According to a particular aspect of the invention, said selection method implements at least one pair, called peer of connectivity, managing the access of a peer client to a peer network, and said step of determining a space The current navigation virtual system comprises the following substeps: connecting said client peer to at least one of said connectivity peers, so as to enable said peer client to access said peer network; -requesting, by said peer client, at least one peer whose identifier is provided by at least one of said connectivity peers so as to obtain said viewing subtree; In this way, the peer client obtains a connection to the peer network through a peer that acts as a connectivity peer. This connectivity peer enables the peer client to obtain a list of its neighbors in the virtual space in which it is evolving. This list first allows the peer client to determine the peer servers that can deliver information. The invention also relates to a data signal exchanged between at least one peer server and at least one peer client. According to the invention, such a signal comprises at least one information field of at least one piece of information representative of a data size of at least one of said viewable elements. In another embodiment, the invention also relates to a computer program product downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor. According to the invention, in at least one embodiment, such a computer program product includes program code instructions for executing the peer server selection method as described above. The invention also relates to a terminal comprising a client pair for selecting at least one peer server for the transmission of data for viewing content within a peer network, said data being organized in the form of data nodes. a hierarchical tree comprising at least one parent node and at least one child node, a displayable element being associated with each of said nodes. According to the invention, such a terminal comprises means for selecting at least one of said peer servers comprising at least a part of said display data and / or at least a part of said hierarchical tree, said selection phase taking account of least information representative of a data size of at least one of said viewable elements. In another embodiment, such a terminal may also comprise means for implementing the steps of the selection method as described above.

L'invention concerne également un serveur comprenant un pair serveur pour la transmission de données de visualisation d'un contenu, à destination d'un pair client au sein d'un réseau de pairs, lesdites données étant organisées sous la forme de noeuds d'un arbre hiérarchique comprenant au moins un noeud parent et au moins un noeud fils, un élément visualisable étant associé à chacun desdits noeuds, Selon l'invention, un tel serveur comprend des moyens de transmission, d'au moins une donnée de visualisation desdits éléments visualisables suite à au moins une demande de transmission émise par ledit pair client, en fonction d'un classement desdites données de visualisation selon une information représentative d'une taille de données d'au moins un desdits éléments visualisables. 4 LISTE DES FIGURES D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 présente un modèle tridimensionnel de connexion entre pairs en fonction de leur position dans l'espace virtuel ; la figure 2 démontre l'apport de la méthode de sélection des pairs connectés à la figure 1, selon l'invention - la figure 3 décrit la transmission des structures arborescentes avec mise à jour de la connectivité ; la figure 4 illustre les étapes d'initialisation de la structure arborescente par le pair client suivie de la visualisation de la représentation ; la figure 5 décrit la liste des noeuds de la structure arborescente qui sont 15 actifs et fusionnables pour un niveau de détail donné ; la figure 6 illustre le découpage d'un arbre de description ; la figure 7 décrit un exemple d'étapes conduisant à la création d'un sous-arbre de visualisation ; la figure 8 décrit également un exemple d'étapes conduisant à la création 20 d'un sous-arbre de visualisation ; la figure 9 présente un synoptique de la représentation visuelle d'un objet en fonction de la position de l'utilisateur dans la scène ; la figure 10 présente un synoptique de la représentation visuelle d'un objet en fonction du point de vue de l'utilisateur ; 25 - la figure 11 présente un diagramme de décision conduisant à la répartition des requêtes entre les pairs connectés et le serveur central ; la figure 12 illustre l'architecture matérielle d'un pair client selon l'invention ; la figure 13 illustre l'architecture matérielle d'un pair serveur selon 30 l'invention ; la figure 14 décrit le contenu du paquet HDescRPck ; la figure 15 décrit succinctement le contenu du paquet HDescAPck ; la figure 16 décrit une méthode de reconstruction de l'arbre hiérarchique ; la figure 17 décrit le graphe de scène correspondant à l'utilisation d'un HDescNode et d'un FootprintSetNode ; la figure 18 décrit précisément le contenu du paquet HDescAPck . 5 DESCRIPTION DETAILLEE DE L'INVENTION 5.1 Rappel du principe de l'invention Le principe général de l'invention repose donc sur la prise en compte d'une taille de données à télécharger lors de la sélection de pairs serveurs par un pair client. Cette prise en compte est effectuée à deux niveaux : lors de la constitution d'un arbre de description de l'espace virtuel, permettant par le pair client suite à l'interrogation des pairs serveur : la taille des données à télécharger est alors calculée au fur et à mesure de la réception des réponses de la part des pairs serveurs et du niveau de détail recherché. On calcule, pour chacun des noeuds de l'arbre de description, la taille des données géométriques qui y sont associées. Après génération de l'arbre de description hiérarchique, un découpage de celui-ci peut être effectué de manière a ce qu'il puisse être lui aussi transmis de manière progressive en fonction du point de vue l'utilisateur. Si un tel découpage est effectué, les informations concernant la taille des données ainsi que les index des parties dépendantes sont ajoutées dans les entêtes des différentes parties. Ainsi, après réception de la première partie de l'arbre de description, chaque pair est en mesure de demander les parties manquantes de l'arbre de description en tenant compte de leurs tailles respectives. Il en est de même pour les informations géométriques dont la taille est elle aussi connue. lors de la sélection et du classement des pairs serveur à partir desquels le pair client décide de télécharger les données de visualisation de l'espace virtuel considéré. The invention also relates to a server comprising a peer server for the transmission of data for viewing a content, to a peer client within a peer network, said data being organized in the form of nodes of a hierarchical tree comprising at least one parent node and at least one child node, a displayable element being associated with each of said nodes, According to the invention, such a server comprises transmission means, at least one data display of said elements viewable following at least one transmission request sent by said client pair, according to a classification of said display data according to information representative of a data size of at least one of said viewable elements. 4 LIST OF FIGURES Other features and advantages of the invention will emerge more clearly on reading the following description of a preferred embodiment, given as a simple illustrative and nonlimiting example, and the appended drawings, among which: Figure 1 presents a three-dimensional model of peer connection as a function of their position in the virtual space; FIG. 2 demonstrates the contribution of the method for selecting the pairs connected to FIG. 1, according to the invention; FIG. 3 describes the transmission of the tree structures with updating of the connectivity; FIG. 4 illustrates the steps of initialization of the tree structure by the client peer followed by the visualization of the representation; Figure 5 depicts the list of nodes of the tree structure that are active and mergeable for a given level of detail; Figure 6 illustrates the splitting of a description tree; FIG. 7 describes an example of steps leading to the creation of a visualization subtree; Figure 8 also describes an example of steps leading to the creation of a viewing subtree; Figure 9 shows a block diagram of the visual representation of an object according to the position of the user in the scene; Figure 10 shows a block diagram of the visual representation of an object according to the point of view of the user; FIG. 11 shows a decision diagram leading to the distribution of requests between the connected peers and the central server; FIG. 12 illustrates the hardware architecture of a client peer according to the invention; Figure 13 illustrates the hardware architecture of a peer server according to the invention; Figure 14 describes the contents of the packet HDescRPck; Figure 15 briefly describes the contents of the HDescAPck packet; Figure 16 describes a method of rebuilding the hierarchical tree; FIG. 17 describes the scene graph corresponding to the use of a HDescNode and a FootprintSetNode; Figure 18 precisely describes the contents of the HDescAPck package. DETAILED DESCRIPTION OF THE INVENTION 5.1 Recall of the Principle of the Invention The general principle of the invention is therefore based on taking into account a data size to be downloaded when selecting peer servers by a client peer. This consideration is carried out at two levels: when constituting a tree of description of the virtual space, allowing by the peer client following the interrogation of the peer server: the size of the data to be downloaded is then calculated at as the response from the peer servers and the level of detail sought. For each of the nodes of the description tree, the size of the geometric data associated therewith is calculated. After generation of the hierarchical description tree, a division thereof can be carried out so that it can also be transmitted in a progressive manner according to the user's point of view. If such a split is performed, the information about the size of the data as well as the indexes of the dependent parts are added in the headers of the different parts. Thus, after receiving the first part of the description tree, each peer is able to request the missing parts of the description tree taking into account their respective sizes. It is the same for geometric information whose size is also known. when selecting and ranking the peer server from which the client peer decides to download the visualization data of the virtual space considered.

Le principe de l'invention peut être mis en oeuvre selon un processus qui comporte les étapes suivantes : on associe au client courant les pairs dont l'observateur associé est proche dans l'espace virtuel courant de navigation ; lorsqu'au cours de sa navigation dans l'espace virtuel courant, le client manque de données de modélisation pour la navigation, par exemple lors d'un déplacement dans l'espace de navigation à partir d'un nouveau point de vue (ou à partir d'un premier point de vue) ou lorsque la scène a évoluée..., le client va solliciter au moins un pair serveur identifié par un paramètre de priorité, puis si celui-ci ne possède pas l'information le pair suivant selon ce même critère. De manière optionnelle, le paramètre de priorité tient compte d'au moins l'un des éléments suivants : le délai de réponse pour obtenir un premier bit (le temps de service) ; - la capacité d'émission ; la capacité de réception ; les données présentes sur le pair ; le pourcentage de chargement ; le taux d'acquittement ; - la position. Egalement de manière optionnelle, certains pairs sont référencés comme serveurs, avec un paramètre de complétude pour les données qu'ils possèdent. Toujours optionnellement, la mise à jour de la liste des pairs et/ou de leur paramètres associés est effectuée périodiquement ou suivant des évènements tels que : une absence de réponse de la part d'un pair ; une évolution des paramètres (éloignement constatée du pair, temps de réponse en augmentation, débit non assuré ...) ; Selon un mode de réalisation particulier, on décrit par la suite un enchaînement de différentes étapes menant à la sélection des pairs serveurs par un pair client et à la prise en compte de la taille des données à télécharger lors de la sélection. Ces étapes sont les suivantes : Initialisation de la connectivite du pair client ; Mise à jour de la connectivité du pair client ; Tri des pairs serveur en fonction de leurs temps de service ; Récupération des données de visualisation au niveau des pairs serveurs. 5.1.1 Initialisation de la connectivité Cette première étape correspond à la connexion au monde virtuel. Le pair client reçoit alors une liste de pairs serveurs auxquels il doit se connecter. La nouvelle liste de voisin auquel le pair doit se connecter peut être récupérée soit via le noeud pair à pair auquel il est connecté, soit via un serveur central qui gère la connectivité. Ces pairs correspondent à des voisins dans le monde virtuel et leur nombre peut être limité par la capacité du pair considéré. 5.1.2 Mise àjour de la connectivité Cette deuxième étape est effectuée à intervalles réguliers. Elle consiste à mettre à jour la connectivité du pair considéré. Entre chaque itération les pairs se déplacent au sein de l'espace virtuel. La connectivité des pairs varie donc en fonction du temps. A chaque connexion à un nouveau pair serveur, le pair considéré récupère ou mesure l'Upload disponible du nouveau pair ainsi que le temps de réponse de l'application ( Time To Serve ). Dans le cas ou un pair mesure l'Upload et le TTS , il doit re-effectuer ces opérations a intervalle régulier. L'Upload est une bande passante maximum allouée par un pair pour servir les autres pairs. Le pair utilisera une partie ou toute la bande passante disponible du pair interrogé. Une contrainte pourra par exemple de ne pas prendre plus de bande passante que celle disponible compte tenu du nombre d'autres pairs qui sont connectés au pair que l'on souhaite interroger. Il pourrait par exemple être avantageux de répartir équitablement de manière continue (ou dynamique) cette ressource en bande passante disponible via le pair que l'on souhaite mettre a contribution (ou éventuellement d'être informé du nombre de pairs qui utilisent la bande passante pour que tous ceux qui l'utilisent le fassent de manière équitable). 5.1.3 Tri des pairs en fonction du TTS Cette troisième étape peut elle aussi être effectuée à intervalle régulier. The principle of the invention can be implemented according to a process that comprises the following steps: the current client is associated with the peers whose associated observer is close in the current virtual browsing space; when during its navigation in the current virtual space, the customer lacks modeling data for navigation, for example when moving in the navigation space from a new point of view (or from a first point of view) or when the scene has evolved ..., the client will request at least one peer server identified by a priority parameter, and if it does not have the information the next peer according to this same criterion. Optionally, the priority parameter takes account of at least one of the following: the response time to obtain a first bit (the service time); - the transmission capacity; the reception capacity; the data present on the peer; the percentage of loading; the acquittal rate; - the position. Also optionally, some peers are referenced as servers, with a completeness parameter for the data they have. Optionally, the updating of the list of peers and / or their associated parameters is carried out periodically or following events such as: a lack of response from a peer; an evolution of the parameters (noted distance of the peer, increased response time, uninsured flow ...); According to a particular embodiment, a sequence of different steps leading to the selection of peer servers by a client peer and to the taking into account of the size of the data to be downloaded during the selection is described below. These steps are: Initializing the connectivity of the client peer; Update the connectivity of the client peer; Sort server peers based on their service times; Recovery of visualization data at the peer server level. 5.1.1 Initialization of connectivity This first step corresponds to the connection to the virtual world. The peer client then receives a list of peer servers to connect to. The new neighbor list to which the peer must connect can be retrieved either through the peer-to-peer node to which it is connected, or via a central server that manages connectivity. These peers correspond to neighbors in the virtual world and their number may be limited by the peer's ability. 5.1.2 Updating Connectivity This second step is performed at regular intervals. It consists of updating the peer's connectivity. Between each iteration the peers move within the virtual space. Peer connectivity therefore varies with time. At each connection to a new peer server, the peer considered retrieves or measures the available upload of the new peer and the response time of the application (Time To Serve). In the case where a peer measures the Upload and the TTS, it must re-perform these operations at regular intervals. Upload is a maximum bandwidth allocated by a peer to serve other peers. The peer will use some or all of the available bandwidth of the peer polled. A constraint may for example not to take more bandwidth than that available given the number of other peers that are connected to the peer that we want to query. For example, it might be advantageous to distribute the available bandwidth resource in a continuous (or dynamic) way via the peer that is to be used (or possibly to be informed of the number of peers that use the bandwidth to all who use it do so fairly). 5.1.3 Sorting peers by TTS This third step can also be performed at regular intervals.

Elle consiste à trier les pairs en fonction du temps de réponse qui a été mesuré. Le pair qui a le temps de réponse le plus court est celui susceptible de fournir la donnée requise le plus rapidement possible. La volumétrie des données intervient alors. En effet, cette étape de tri tient compte de la cohérence de la taille des données à télécharger avec les capacités de chargement ( Upload ) disponibles au niveau du pair serveur considéré. Par exemple, dans le cas d'une faible volumétrie, (par exemple quand le niveau de détail est faible), un pair serveur disposant de capacités faible, voire très faible pourra tout de même être considéré comme étant le pair serveur pertinent pour le chargement du noeud considéré, par opposition à un pair disposant de très fortes capacités, mais d'un TTS plus important. Cette caractéristique est intéressante dans le contexte d'une représentation hiérarchique progressive. C'est-à-dire que pour pouvoir décoder un niveau de détail particulier, il est nécessaire de disposer des niveaux de détails plus grossiers. On transmet dans les noeuds de géométrie le delta par rapport à la représentation plus grossière. Les noeuds situés dans la partie haute de l'arbre sont donc les plus importants et il est judicieux de chercher à les récupérer le plus rapidement possible. 5.1.4 Récupération des données de visualisation Une fois que le pair est connecté à un nombre fini de pairs voisins (le serveur qui héberge la représentation complète est considéré comme un voisin qui dispose de toute l'information), le pair client démarre la procédure utile pour récupérer les données nécessaires à sa visualisation (initialisation de la récupération), puis il procède au téléchargement (récupération des données). 5.1.4.1 Initialisation de la récupération La première phase correspond à l'initialisation du client. Après une procédure de connexion, il reçoit dans un fichier une description simplifiée de l'objet ou une première partie de la description simplifiée de l'objet (c'est à dire. les niveaux de détail très grossiers). Ce fichier peut être demandé à n'importe lequel des pairs auxquels il est connecté (En particulier le serveur qui héberge la représentation complète). Puis le processus comprend alors les étapes suivantes : Emission de tout ou partie du fichier de description de l'arborescence par les pairs serveurs ou par le serveur central. Le fichier de description contient pour chaque noeud associé à un niveau de détail de l'arbre, sa position dans le repère de la scène ainsi qu'une zone de sélection. On obtient donc un fichier qui peut être progressif (donc découpé selon les contraintes de l'arbre hiérarchique) qui contient pour chacun des noeuds qui y sont inclus : L'index du noeud ; La position du centre du noeud (position x,y,z du centre de gravité par exemple) ; La zone de sélection pour ce noeud (rayon r par exemple) qui est en fait un critère d'erreur ; L'index du noeud père. La taille de la donnée associée (géométrique par exemple) ; Dans un mode de réalisation particulier, Il est possible d'utiliser une numérotation adaptée des noeuds, Afin de ne pas transmettre les index des noeuds. Dans un autre mode de réalisation, on peut optionnellement ajouter une aura correspondant à la boite englobante du noeud pour limiter le nombre de noeuds géométriquessélectionnés pour une position donnée (compte tenu de la pyramide de vue). It consists of sorting the peers according to the response time that has been measured. The peer with the shortest response time is the one that can provide the required data as quickly as possible. The volumetry of the data then intervenes. Indeed, this sorting step takes into account the coherence of the size of the data to be downloaded with the upload capabilities available at the server peer considered. For example, in the case of low volumetry, (for example when the level of detail is low), a peer server with low or very low capacity can still be considered as the relevant peer server for loading. of the considered node, as opposed to a peer with very strong capabilities, but a larger TTS. This characteristic is interesting in the context of a progressive hierarchical representation. That is, to be able to decode a particular level of detail, it is necessary to have coarser levels of detail. The delta is transmitted in the geometry nodes with respect to the coarser representation. The nodes in the upper part of the tree are the most important and it is wise to seek to recover them as quickly as possible. 5.1.4 Retrieving Viewing Data Once the peer is connected to a finite number of neighboring peers (the server that hosts the complete representation is considered a neighbor with all the information), the peer client starts the process useful for recovering the data necessary for its visualization (initialization of the recovery), then it proceeds to the download (recovery of the data). 5.1.4.1 Initializing the recovery The first phase corresponds to the initialization of the client. After a connection procedure, it receives in a file a simplified description of the object or a first part of the simplified description of the object (that is, the very coarse levels of detail). This file can be requested from any of the peers to which it is connected (especially the server that hosts the complete representation). Then the process then comprises the following steps: Emission of all or part of the description file of the tree by the peer servers or by the central server. The description file contains for each node associated with a level of detail of the tree, its position in the frame of the scene and a selection area. One thus obtains a file which can be progressive (thus cut according to the constraints of the hierarchical tree) which contains for each of the nodes which are included there: The index of the node; The position of the center of the node (position x, y, z of the center of gravity for example); The selection zone for this node (radius r for example) which is in fact an error criterion; The index of the father node. The size of the associated data (geometric for example); In a particular embodiment, it is possible to use an appropriate numbering of the nodes, so as not to transmit the indexes of the nodes. In another embodiment, an aura corresponding to the bounding box of the node may optionally be added to limit the number of geometric nodes selected for a given position (given the pyramid of view).

L'entête de la partie du fichier de description, s'il est progressif, contient de manière optionnelle : - le nombre de fils de la partie ; Puis pour chaque partie : l'index de la partie fils ; la taille de la donnée de la partie fils ; le nombre de noeuds terminaux (c'est à dire auxquels il manque des fils) dont des fils sont contenus dans la partie fils considérée. (cette information est utile pour le décodage et pour déterminer quelle partie de la description est nécessaire si il manque des fils dans l'arbre hiérarchique). Optionnellement le centre de gravité et l'aura de perceptibilité des différentes parties. Cependant, ces informations peuvent aussi être déterminées après réception de la partie de description que l'on considère notamment grâce aux informations de sélection contenues dans les noeuds de description transmis. Réception du fichier de description de l'arborescence par le client. Ce dernier décode le fichier puis reconstruit la structure arborescente qui a été transmise. Le fichier reçu peut correspondre à une partie de la structure hiérarchique si le fichier de description est progressif. Chaque élément du fichier de description contient les informations concernant la taille et les index de ses fils de manière à pouvoir repartir la charge de la même façon que pour la géométrie. Optionnellement on peut rajouter pour chacun des éléments une position et une aura qui correspondra à la zone dans laquelle cet élément est requis. (deux solutions possibles: transmettre ces informations dans l'entête de la partie ou les déterminer après réception de la partie de description: connaissant les noeuds dont les fils sont inclus dans la partie de description qui est requise on peut déterminer une liste de pairs serveurs a interroger) Cette information permettra à chacun des pairs de déterminer parmi ses voisins ceux qui sont susceptibles de disposer de l'information souhaitée. 5.1.5 Récupération des données Cette deuxième phase correspond à la visualisation de la scène au sein du pair client : Pendant la visualisation, le client se charge de la sélection des noeuds (de l'arbre de description) à visualiser. Il utilise le fichier de description qui lui a été transmis à l'initialisation. Si la position courante de l'utilisateur est incluse dans la zone de sélection d'un noeud (géométrique ou partie de la description hiérarchique), celui-ci est sélectionné. A chaque instant, en fonction des données chargées et des noeuds requis, le client envoie des requêtes au meilleur pair serveur qu'il a déterminé de manière à recevoir les données de visualisation. La position du pair voisin est utilisée pour déterminer s'il doit avoir dans son cache la donnée requise. On utilise à cet effet des informations de sélection de LOD connus et la position du voisin pour savoir s'il dispose dans son cache de l'information considérée. Cette information est pondérée par le pourcentage de réalisation mesuré (qui correspond au taux de réponse acquittées dans le temps requis) ainsi que le pourcentage de chargement déterminé par le pair voisin (qui correspond au pourcentage de noeuds stockés dans le cache du voisin parmi ceux qui sont perceptibles compte tenu de son point de vue). La pondération se fait en triant les clients qui sont susceptible de disposer du noeud requis. Les pairs distants qui disposent potentiellement de l'information sont triés en fonction du pourcentage de chargement et de réalisation puis parmi ceux-ci et dans une limite imposée on les trie en fonction du TTS. Une fois que l'Upload d'un pair serveur a été atteint, il ne peut plus être utilisé jusqu'à acquittement des requêtes qui lui ont été transmises (ou jusqu'à ce qu'un timer de réinitialisation soit atteint s'il ne peut pas acquitter les requêtes). The header of the part of the description file, if it is progressive, optionally contains: - the number of children of the game; Then for each part: the index of the son part; the size of the data of the child part; the number of terminal nodes (that is to say that there are missing son) whose son are contained in the son part considered. (This information is useful for decoding and determining which part of the description is needed if there are missing threads in the hierarchical tree). Optionally the center of gravity and the aura of perceptibility of the different parts. However, this information can also be determined after receiving the description part that is considered in particular thanks to the selection information contained in the description nodes transmitted. Receipt of the description file of the tree by the client. The latter decodes the file and then reconstructs the tree structure that has been transmitted. The received file may correspond to a part of the hierarchical structure if the description file is progressive. Each element of the description file contains information about the size and indexes of its threads so that the load can be distributed in the same way as for the geometry. Optionally one can add for each of the elements a position and an aura that will correspond to the zone in which this element is required. (two possible solutions: to transmit this information in the heading of the part or to determine them after reception of the part of description: knowing the nodes whose son are included in the part of description which is required one can determine a list of peer servers This information will allow each peer to determine among its neighbors those who are likely to have the desired information. 5.1.5 Data recovery This second phase corresponds to the visualization of the scene within the client pair: During the visualization, the client takes care of the selection of the nodes (of the description tree) to be visualized. It uses the description file that was sent to it during initialization. If the current position of the user is included in the selection area of a node (geometric or part of the hierarchical description), this one is selected. At any given moment, depending on the loaded data and the required nodes, the client sends requests to the best peer server that it has determined in order to receive the visualization data. The position of the neighbor peer is used to determine whether to have the required data in its cache. For this purpose, known LOD selection information and the position of the neighbor are used to know whether he has information in his cache. This information is weighted by the percentage of achievement measured (which corresponds to the response rate paid in the required time) as well as the percentage of loading determined by the neighboring peer (which corresponds to the percentage of nodes stored in the cache of the neighbor among those are perceptible given his point of view). The weighting is done by sorting the clients that are likely to have the required node. The remote peers that potentially have the information are sorted according to the percentage of loading and realization then among these and within an imposed limit they are sorted according to the TTS. Once the Upload of a peer server has been reached, it can no longer be used until the requests passed to it have been acknowledged (or until a reset timer is reached if it is not can not acquit the queries).

L'utilisation du fichier de description permet au client de converger plus vite vers la représentation optimale. Il est en mesure de générer des requêtes correspondant exactement à ses besoins et il est en mesure de les envoyer au pair qui peut lui fournir le meilleur service. Dans le cas d'une représentation arborescente avec une dépendance entre les noeuds, il est important de récupérer en premier les noeuds les plus hauts dans l'arbre (c'est-à-dire les noeuds parents). C'est à cet effet que l'on trie les pairs voisin en fonction du TTS de manière a effectuer la requête parmi ceux qui disposent de l'information a celui qui répondra le plus vite. 5.2 Connectivité entre les pairs Les pairs se connectent entre eux en fonction de leur proximité dans l'espace virtuel. Deux techniques peuvent être utilisées pour assurer la connectivité : On peut utiliser un ou plusieurs serveurs (dans ce cas chacun d'entre eux aura a sa charge une zone précise) pour assurer la connectivité. Tous les pairs doivent transmettre leur position courante au serveur auquel ils sont connectés. A intervalle régulier le serveur effectue une triangulation par exemple pour pouvoir déterminer quels sont les voisins de chaque pair (dans notre cas on effectue pour l'instant une triangulation de Delaunay en 2D ou un simple calcul de distance en 3D). Le serveur envoie ensuite à chacun des pairs qui sont connectés une liste de pairs auxquels ils doivent se connecter. Cette liste fait une taille d'au plus le nombre de pair voisins qu'a requis le pair considéré. Quand un pair reçoit ce type de message, il effectue une mise à jour de sa connectivité. C'est-à-dire qu'il se déconnecte des pairs qui ne sont pas dans la liste et il se connecte aux pairs auxquels il n'est pas déjà connecté. Si on utilise ce premier mode particulier d'initialisation, il est nécessaire que la liste de pair soit connexe de manière à pouvoir propager le message dans l'espace sauf si on utilise le pair de connectivité comme relais pour la transmission de cette information. Par connexe on entend qu'il existe au moins un chemin entre chacun des pairs de l'espace virtuel. On peut également utiliser un réseau de pairs dont la caractéristique est que les pairs sont connectés les uns avec les autres en fonction de leur position dans un même espace virtuel. Dans ce cas particulier la mise à jour de la connectivité pourra se faire en interrogeant le noeud (celui qui gère la connectivité) du réseau de pair pour savoir quels sont les voisins qui y sont connectés. On note que dans le cas d'un déplacement non limité dans un espace virtuel, la meilleure connectivité que l'on puisse utiliser sera une connectivité 3D. En effet, il est compréhensible qu'un utilisateur se déplaçant en altitude ait dans son cache des données très différentes de celles contenues dans le cache d'un utilisateur se déplaçant au niveau du sol. On présente, en relation avec la figure 1, un exemple de connectivité 3D. Les pairs (101, 102,...) sont connectés (1001, 1002, 1003, ...) en fonction de leur position dans l'espace virtuel. La connectivité est donc une connectivité 3D. 5.3 Transmission adaptée du modèle On présente, en relation avec la figure 2, l'apport principal de la technique de transmission adaptée et optimisée d'une structure de type arborescente en réseau. L'innovation repose sur la transmission d'une description de la scène pour optimiser les échanges sur le réseau. On suppose que le pair client (10) considéré est connecté à n pairs (2 dans l'exemple, 11 et 12) qui sont des voisins dans l'espace virtuel ou le serveur qui héberge la représentation complète. Régulièrement les voisins transmettent leur position courante au pair considéré. Using the description file allows the client to converge faster to the optimal representation. He is able to generate queries exactly matching his needs and is able to send them to the peer who can provide him with the best service. In the case of a tree representation with a dependency between the nodes, it is important to first recover the highest nodes in the tree (that is to say the parent nodes). It is for this purpose that the neighboring peers are sorted according to the TTS so as to make the request among those who have the information to the one who will answer the fastest. 5.2 Peer Connectivity Peers connect to each other based on their proximity to the virtual space. Two techniques can be used to provide connectivity: One or more servers can be used (in this case each of them will have a specific area to support) to ensure connectivity. All peers must transmit their current position to the server to which they are connected. At regular intervals the server performs a triangulation for example to be able to determine which are the neighbors of each pair (in this case we are currently doing a Delaunay triangulation in 2D or a simple distance calculation in 3D). The server then sends each of the peers that are connected a list of peers to which they must connect. This list is a size of at most the number of peer neighbors required by the peer. When a peer receives this type of message, it performs an update of its connectivity. That is, it disconnects peers that are not in the list and connects to peers to which it is not already connected. If this first particular mode of initialization is used, it is necessary that the peer list be connected so as to be able to propagate the message in the space except if the connectivity peer is used as relay for the transmission of this information. By related it is meant that there is at least one path between each of the pairs of the virtual space. One can also use a network of peers whose characteristic is that the peers are connected with each other according to their position in the same virtual space. In this particular case the update of the connectivity can be done by interrogating the node (the one that manages the connectivity) of the peer network to know which neighbors are connected to it. Note that in the case of unrestricted displacement in a virtual space, the best connectivity that can be used will be 3D connectivity. Indeed, it is understandable that a user moving at altitude has in his cache very different data from those contained in the cache of a user moving at ground level. In connection with FIG. 1, an example of 3D connectivity is presented. The peers (101, 102, ...) are connected (1001, 1002, 1003, ...) according to their position in the virtual space. Connectivity is therefore 3D connectivity. 5.3 Adapted transmission of the model In relation with FIG. 2, the main contribution of the adapted and optimized transmission technique of a network-type tree structure is presented. Innovation relies on the transmission of a description of the scene to optimize the exchanges on the network. It is assumed that the peer client (10) considered is connected to n peers (2 in the example, 11 and 12) which are neighbors in the virtual space or the server that hosts the complete representation. The neighbors regularly transmit their current position to the par concerned.

L'étape 0 permet au pair client 10 de déterminer quels sont les pairs serveurs qui vont lui fournir le fichier de description. Le fichier de description ou partie de celui-ci peut être transmis par n'importe quel pair serveur du moment que son upload est adapté. Parmi les pairs dont l'upload est adapté on choisit, par exemple, ceux dont le temps de réponse est le plus faible. Step 0 allows the client peer 10 to determine which peer servers will provide the description file. The description file or part of it can be transmitted by any peer server as long as its upload is adapted. Among the peers whose upload is adapted we choose, for example, those whose response time is the weakest.

L'étape 1 est une étape d'initialisation. Le client 10 demande (101) au pair serveur 11 qu'il a sélectionné de lui transmettre (102) en retour un fichier de description de l'arbre 1001 qui lui permettra de sélectionner les noeuds dont il aura besoin pour la visualisation. Les noeuds sont sélectionnés en fonction de la position de l'utilisateur dans la scène. La sélection des pairs serveurs pour la transmission du fichier de description tient compte de la taille du fichier de description à transmettre et de d'autres paramètres propres aux capacités des pairs serveurs ( TTS , Upload et pourcentage de réalisation). - L'étape 2 et l'étape 3 présentent des cas de sélection de noeuds. En fonction de la position 103 de l'utilisateur dans la scène 104 le client 10 demande (105, 106, 107, 108) les informations géométriques correspondant aux noeuds (1002, 1003) qu'il souhaite visualiser. Pour ce faire, il sélectionne (109, 110) les pairs serveurs 11, 12 les mieux adaptés compte tenu de leurs capacités respectives ( TTS , Upload et pourcentage de réalisation) et de l'importance des noeuds (leur taille, ou encore le volume de données à transmettre). L'étape 4 montre que si les données 1004 géométriques sont présentes dans le cache du client 10, aucun trafic réseau n'est généré. Le client 10 utilise les données qu'il a déjà chargé. On présente, en relation avec la figure 3, un cas particulier ou la connectivité est mise à jour. Les étapes décrites précédemment (figure 2) sont les mêmes, mais à l'instant t 1005 le pair client se déconnecte du pair serveur 12 pour se connecter au pair serveur 13. Ce cas se produit notamment quand le pair serveur 13 s'est rapproché du pair client 10 ou que le pair serveur 12 s'est déconnecté du réseau. Lorsque le fichier de description est progressif, les mêmes étapes sont répétées pour récupérer les parties manquantes du fichier de description en tenant compte de la possibilité de disposer de l'information de perceptibilité et de taille des parties de fichier de description manquantes. 5.4 Rappel du principe utilisé pour la visualisation On présente, en relation avec la figure 4, les données qui sont transmises sur le réseau pour que la visualisation puisse être effectuée. Dans un premier temps (40), après une procédure d'initialisation 401, on transmet, par l'intermédiaire du réseau 41 un arbre de sélection 402 qui correspond à la représentation hiérarchique sans les données géométriques. Seules sont transmises les données nécessaires à la sélection (index du noeud, index du noeud père, zone de sélection, centre de gravité du noeud). Une fois que l'arbre est reconstruit 42, le client peut demander 43 les informations dont il a besoin pour sa visualisation (représentations géométriques, images compressées ...). Le choix des noeuds à visualiser peut être effectuée au niveau du client grâce aux zones de sélection associées à chaque noeud. Si la position de l'utilisateur est incluse dans la zone de sélection d'un noeud, il est également sélectionné. Step 1 is an initialization step. The client 10 (101) asks the server par 11 that it has selected to transmit (102) back a description file of the tree 1001 which will allow him to select the nodes he will need for viewing. The nodes are selected according to the position of the user in the scene. The selection of the peer servers for the transmission of the description file takes into account the size of the description file to be transmitted and other parameters specific to the capabilities of the peer servers (TTS, Upload and percentage of completion). Step 2 and Step 3 present cases of selection of nodes. According to the position 103 of the user in the scene 104, the client 10 requests (105, 106, 107, 108) the geometrical information corresponding to the nodes (1002, 1003) that he wishes to display. To do this, he selects (109, 110) the best-matched servers 11, 12, taking into account their respective capacities (TTS, Upload and percentage of implementation) and the importance of the nodes (their size, or the volume data to be transmitted). Step 4 shows that if the geometric data 1004 is present in the client cache 10, no network traffic is generated. The client 10 uses the data it has already loaded. In connection with FIG. 3, a particular case is presented where the connectivity is updated. The steps described above (FIG. 2) are the same, but at the instant t 1005 the client peer disconnects from the server peer 12 to connect to the server peer 13. This case occurs especially when the peer server 13 has approached client peer 10 or the peer server 12 has disconnected from the network. When the description file is progressive, the same steps are repeated to recover the missing parts of the description file taking into account the possibility of having the perceptibility information and the size of the missing description file parts. 5.4 Reminder of the principle used for the visualization In relation to FIG. 4, the data transmitted on the network is presented so that the visualization can be performed. In a first step (40), after an initialization procedure 401, a selection tree 402 is transmitted via the network 41, which corresponds to the hierarchical representation without the geometric data. Only the data necessary for the selection are transmitted (index of the node, index of the father node, zone of selection, center of gravity of the node). Once the tree is rebuilt 42, the client can ask for the information he needs for his visualization (geometric representations, compressed images, etc.). The choice of the nodes to be visualized can be made at the level of the customer thanks to the selection zones associated with each node. If the user's position is included in the selection area of a node, it is also selected.

En fonction de la position de l'utilisateur, le pair peut sélectionner les informations que le pair serveur qu'il a choisi doit lui transmettre pour permettre la visualisation. On note qu'avec cette technique, il est possible de faire varier en fonction du point de vue les paramètres de sélection du LOD . Il est donc possible de faire de l'auto adaptation pour privilégier la fluidité du déplacement ou la qualité de la représentation, en fonction de la taille des données associées au LOD considéré. De même cette gestion de LOD peut être contrainte par le débit fournit par le réseau car plus la représentation est détaillée, plus la quantité de données à transmettre est importante. Depending on the position of the user, the peer may select the information that the peer server he has chosen to transmit to him for viewing. Note that with this technique, it is possible to vary depending on the point of view the LOD selection parameters. It is therefore possible to make self-adaptation to favor the fluidity of the displacement or the quality of the representation, according to the size of the data associated with the LOD considered. Similarly, this management of LOD can be constrained by the bit rate provided by the network because the more the representation is detailed, the greater the quantity of data to be transmitted is important.

Par la suite, on présente notamment le cas de la mise en oeuvre de l'invention dans le cadre d'une modélisation d'une ville en utilisant une représentation hiérarchique basée sur le PBTree . Il est clair cependant que l'invention ne se limite pas à cette application particulière, mais peut également être mise en oeuvre dans de nombreux autres domaines, et par exemple dans la visualisation en continu de flux multimédias scalables représentés par un arbre hiérarchique dans le cadre de réseaux pair à pair et plus généralement dans tous les cas où les objectifs listés par la suite sont intéressants. 5.5 Description d'un mode de réalisation 5.5.1 Description L'implémentation décrite ci-dessous correspond à une sélection du niveau de détail se basant sur la position du centre de gravité des noeuds dans la scène. A chacun des noeuds est associé une zone de sélection spécifique. La représentation 3D utilisée dans le cas présent est une ville. On utilise l'algorithme PBTree en tant que structure de description. On note par ailleurs que d'autres types de données peuvent être utilisés avec cette technique, comme le streaming basé point, ou les ondelettes par exemple. 5.5.2 Représentation 3D d'une ville La représentation 3D multi niveaux de détail utilisée dans cette implémentation est un PBTree . La figure 5 montre cette structure arborescente 50. Elle présente également la liste des noeuds actifs 51 (c'est-à-dire dont les contenus associés sont affichés sur le terminal client et qui sont susceptibles d'être raffinés).et fusionnables 52 pour un niveau de détail donné. Chaque noeud de ce PBTree stocke un modèle 2D de bâtiment à un niveau de détail donné. Les simplifications utilisées pour générer cette représentation multi niveaux de détails d'un ensemble de bâtiments sont au nombre de trois : Suppression d'un sommet de l'empreinte au sol. Fusion de deux bâtiments adjacents. Fusion de deux bâtiments non adjacents. La description du PBTree , ainsi que le processus de construction, et ses utilisations dans le cas d'un mode de navigation en survol a largement été décrite dans la partie implémentation du brevet [FR-05 02 4491: Procédé pour la gestion de la représentation d'au moins une scène 3D modélisée . L'implémentation dans le cadre de l'invention porte sur la sur la sélection des noeuds a transmettre en fonction de la position de l'utilisateur. 5.5.3 Génération du fichier de description de la structure arborescente La génération du fichier de description global est présentée en détail dans le brevet [FR-05 02 449]. Dans ce mode de réalisation particulier, on décrit le découpage de ce fichier de description global en un ensemble de sous arbres de description. Chaque sous-arbre peut faire l'objet d'un transfert séparé au pair qui le demande. Pour chacun des noeuds de l'arbre de description global, on rajoute la taille du message qui y est associé comme on l'a précisé précédemment. Cette taille permet de savoir si la requête que l'on compte faire en direction du pair considéré est compatible avec son upload . Si on transmet trop de requêtes a un pair (si la taille des messages qu'il va devoir envoyer dépasse son upload ), le pair ne pourra pas fournir le meilleur service possible. Les données souhaitées resteront dans la pile d'envois du pair pendant un temps non négligeable. Le fichier de description doit être progressif car suivant la taille de la structure hiérarchique que l'on souhaite décrire, il peut falloir un temps non négligeable pour le transmettre. En particulier, l'arbre de description du PBTree est une version simplifiée de ce dernier. Cet arbre ne contient que les informations nécessaires pour sélectionner le niveau de détail des bâtiments à afficher. Cet arbre est décomposé en une suite de sous-arbres permettant un envoi progressif de l'arbre de description depuis un serveur vers un client. 5.5.3.1 Principes de découpage de l'arbre de description en sous-arbre L'envoi progressif des sous-arbres s'effectue au gré des déplacements de l'utilisateur dans l'environnement urbain. La décomposition de l'arbre de description en sous-arbres s'effectue en fonction du nombre maximum de noeuds qui a été fixé pour tous les sous-arbres. Cette décomposition doit également respecter la structure d'arbre. Ainsi, l'ensemble des sous-arbres obtenus après décomposition doit également être un arbre. La figure 6 présente la décomposition d'un arbre de description en sous-arbres. Deux découpages sont présentés : un premier 60 avec quatre noeuds au maximum par sous-arbre 61, et un second 62 avec au plus six noeuds (63). L'arbre 61 représente la décomposition en sous-arbres de l'arbre 60. L'arbre 63 représente la décomposition en sous-arbres de l'arbre 61. Pour chaque partie d'arbre, on dispose de la taille de chacun des sous éléments de l'arbre, ainsi que de leur index. Il possible de manière optionnelle de déterminer quel est la zone de perceptibilité des fils grâce aux informations de sélection du LOD contenues dans la partie de l'arbre considérée. L'organisation des sous-arbres sous la forme d'un arbre permet implicitement d'ordonner le transfert progressif de l'arbre de description. Afin de recevoir le sous-arbre 614 (figure 6), il faudra avoir auparavant récupéré auprès du serveur les sous-arbres 613, 611 et 600. Le découpage d'un arbre en sous arbre doit respecter les contraintes suivantes : Les noeuds du premier niveau de l'arbre à découper doivent tous être compris dans le même sous-arbre. Ce sous-arbre constitue en fait la racine de l'arbre de sous-arbres, Tous les fils d'un noeud de l'arbre à découper doivent être compris dans le même sous-arbre. Cela implique que le nombre maximum de noeuds dans un sous-arbre doit être supérieur ou égal au nombre maximum de fils qu'un noeud de l'arbre à découper peut posséder. Cette contrainte a pour défaut d'engendrer le sous-remplissage de sous-arbres. C'est le cas notamment, du sous-arbre 621 dans le découpage utilisant six noeuds au maximum, Dans le cas du découpage du PBTree, la racine est une racine implicite. Celle-ci n'est donc pas incluse dans le premier sous-arbre. 5.5.3.2 Algorithmes de découpage de l'arbre de description en sous-arbres On décrit, en relation avec la figure 7, l'algorithme de découpage d'un arbre en sous-arbre, dans le cas d'une structure 70 contenant au maximum 5 noeuds par sous-arbre : - 71 : Sous-arbres construits après l'ajout des fils du noeud 2 ; 72 : Le noeud courant devient le noeud 3. Il y a alors suffisamment de place pour ajouter les fils du noeud 3. Mais pour respecter la contrainte que les sous arbre doivent en former un autre, un nouveau sous-arbre est créé ; 73 : Le noeud courant est le noeud 6 après avoir passé le noeud 5 sans fils. Subsequently, the case of the implementation of the invention is presented in the context of modeling a city using a hierarchical representation based on the PBTree. It is clear however that the invention is not limited to this particular application, but can also be implemented in many other fields, and for example in the continuous visualization of scalable multimedia streams represented by a hierarchical tree in the context peer-to-peer networks and more generally in all cases where the objectives listed below are interesting. 5.5 Description of an embodiment 5.5.1 Description The implementation described below corresponds to a selection of the level of detail based on the position of the center of gravity of the nodes in the scene. Each of the nodes is associated with a specific selection area. The 3D representation used in this case is a city. The PBTree algorithm is used as the description structure. Note also that other types of data can be used with this technique, such as point-based streaming, or wavelet for example. 5.5.2 3D Representation of a City The 3D multi-level representation of detail used in this implementation is a PBTree. FIG. 5 shows this tree structure 50. It also presents the list of active nodes 51 (that is to say whose associated contents are displayed on the client terminal and which are capable of being refined) and mergeable 52 for a particular level of detail. Each node of this PBTree stores a 2D building model at a particular level of detail. The simplifications used to generate this multi-level representation of details of a set of buildings are three in number: Removal of a vertex from the footprint. Fusion of two adjacent buildings. Fusion of two non-adjacent buildings. The description of the PBTree, as well as the construction process, and its uses in the case of an overflight navigation mode has largely been described in the implementation part of the patent [FR-05 02 4491: Method for the management of the representation at least one modeled 3D scene. The implementation in the context of the invention relates to the selection of the nodes to be transmitted according to the position of the user. 5.5.3 Generation of the description file of the tree structure The generation of the overall description file is presented in detail in the patent [FR-05 02 449]. In this particular embodiment, the division of this global description file into a set of sub-description trees is described. Each subtree can be transferred separately to the peer who requests it. For each of the nodes of the global description tree, the size of the message associated with it is added as previously specified. This size makes it possible to know if the request that one intends to make towards the peer considered is compatible with its upload. If we send too many requests to a peer (if the size of the messages it will have to send exceeds its upload), the peer will not be able to provide the best possible service. The desired data will remain in the peer send stack for a significant amount of time. The description file must be progressive because depending on the size of the hierarchical structure that one wishes to describe, it may take a significant amount of time to transmit it. In particular, the description tree of the PBTree is a simplified version of the latter. This tree contains only the information necessary to select the level of detail of the buildings to display. This tree is broken down into a series of sub-trees allowing a progressive sending of the description tree from a server to a client. 5.5.3.1 Principles of subdivision of the subtree description tree The progressive sending of the subtrees is done according to the user's movements in the urban environment. The decomposition of the description tree into subtrees is based on the maximum number of nodes that has been set for all subtrees. This decomposition must also respect the tree structure. Thus, all subtrees obtained after decomposition must also be a tree. Figure 6 shows the decomposition of a description tree into subtrees. Two cuts are presented: a first 60 with four nodes maximum per subtree 61, and a second 62 with at most six nodes (63). The shaft 61 represents the sub-tree decomposition of the shaft 60. The shaft 63 represents the sub-tree decomposition of the shaft 61. For each tree part, the size of each of the sub-trees is shown. elements of the tree, as well as their index. It is optionally possible to determine what is the area of son perceptibility through the selection information of the LOD contained in the part of the tree considered. The organization of subtrees in the form of a tree implicitly allows to order the progressive transfer of the description tree. In order to receive the sub-tree 614 (FIG. 6), the sub-trees 613, 611 and 600 must first have been recovered from the server. The division of a tree into a sub-tree must respect the following constraints: The nodes of the first tree level of the chopping tree must all be included in the same subtree. This subtree is actually the root of the tree of subtrees, All the threads of a node of the tree to be cut must be included in the same subtree. This implies that the maximum number of nodes in a subtree must be greater than or equal to the maximum number of threads that a node of the tree to be cut can have. This constraint fails to generate the under-filling of subtrees. This is the case, in particular, of the sub-tree 621 in the division using up to six nodes. In the case of the division of the PBTree, the root is an implicit root. This is not included in the first subtree. 5.5.3.2 Algorithms for splitting the description tree into subtrees In relation to FIG. 7, the algorithm for cutting a subtree tree is described, in the case of a structure 70 containing at least one sub-tree. maximum 5 nodes per subtree: - 71: Subtrees built after adding the wires of node 2; 72: The current node becomes the node 3. There is then enough room to add the threads of the node 3. But to respect the constraint that the subtrees must form another, a new subtree is created; 73: The current node is the node 6 after passing the node 5 without son.

Le sous-arbre courant est celui contenant le noeud 6. Les fils du noeud 6 y sont donc ajoutés. On remarque que la création d'un nouveau sous-arbre est motivée par : Le fait qu'un sous-arbre ait atteint le nombre maximum de noeud ; Un nombre trop important de fils pour que ceux-ci soient tous ajoutés à un sous-arbre sans dépasser le nombre maximum de noeuds. Une troisième cause de création de sous-arbres est visible sur l'exemple de la figure 7. Les noeuds 2 et 3 ne sont pas situés sur les mêmes niveaux. Afin de respecter l'arborescence lors du découpage, il faut créer un nouveau sous-arbre lors de l'ajout des fils noeuds du 3. The current subtree is the one containing the node 6. The threads of the node 6 are thus added thereto. Note that the creation of a new subtree is motivated by: The fact that a subtree has reached the maximum number of nodes; Too many threads so that they are all added to a subtree without exceeding the maximum number of nodes. A third cause of creation of subtrees is visible in the example of Figure 7. The nodes 2 and 3 are not located on the same levels. In order to respect the tree structure when cutting, a new subtree must be created when adding the 3 nodes.

La figure 8 présente l'algorithme de découpage d'un arbre (800) en sous-arbres. Cette figure illustre les conditions suivantes de création d'un nouveau sous-arbre : le fait qu'un sous-arbre ait atteint le nombre maximum de noeud ; un nombre trop important de fils pour que ceux-ci soient tous ajoutés à un 20 sous-arbre sans dépasser le nombre maximum de noeuds. Le découpage de l'arbre 800 comprend alors les étapes suivantes : Initialisation du découpage (80) : Remplissage du premier sous-arbre 800 avec tous les fils (0 et 1) de la racine et début du processus de balayage de noeud ; 25 - ajout (81) des fils du noeud courant 0 (2 et 3) au sous-arbre 801 en cours de construction ; ajout (82) des fils du noeud courant 802 (4, 5, 6, 7) au sous-arbre en cours de construction : le noeud 1 possède 4 fils. Or le sous-arbre en cours de construction 803 est plein. Un nouveau sous arbre est créé ; 83. Le noeud courant 804 est le 2. Il ne possède aucun fils, passage au noeud 3. Ajout des fils du noeud trois au sous-arbre courant 803. Or, celui-ci est plein : construction d'un nouveau sous-arbre. 84. Le noeud courant est le 4, sans fils donc passage au noeud 5. Le noeud 5 5 possède 3 fils. Le sous-arbre courant 805 n'est pas plein, mais il possède déjà deux noeuds. Création d'un nouveau sous-arbre. Ajout (85) des fils du noeud 6 86. Les noeuds 8, 9 et 10 sont sautés car ils n'ont pas de fils. Ajout des fils du noeud 11 : le sous-arbre en cours de construction est plein, création 10 d'un nouveau sous-arbre 87. Les noeuds 14 et 15 n'ont pas de fils. La construction de la liste de sous-arbres est terminée. 5.5.3.3 Noeud de description hiérarchique ( HDescNode ) Le noeud de description hiérarchique est initialement une extension du 15 noeud FootprintSet . Un tel type de noeud est par exemple présent dans la norme MPeg4 (norme ISO/IEC JTC11SC29/WG11). Il correspond à une description hiérarchique d'un ensemble de polygones 2D. Il peut cependant être utilisé pour d'autres modèles de données supportant la progressivité. Le noeud de description hiérarchique HierarchicalDescription (nommé 20 par la suite HDescNode ), dans le cas de son utilisation avec le FootprintSet , a pour but de déterminer les bâtiments du PBTree (représenté par le FootprintSetNode ) qui doivent être affichés. Ainsi le HDescNode effectue une partie du travail du FootprintSetNode : celle de sélection du niveau de détail des bâtiments. 25 La partie de rendu des bâtiments sélectionnés continue à être effectuée par le FootprintSetNode . Au sein du graphe de scène, il y a donc une communication entre le noeud HDescNode et le noeud FootprintSetNode afin de transmettre à ce dernier la liste des bâtiments à composer. Figure 8 shows the algorithm for cutting a tree (800) into subtrees. This figure illustrates the following conditions for creating a new subtree: the fact that a subtree has reached the maximum number of nodes; too many threads for all of them to be added to a subtree without exceeding the maximum number of nodes. The cutting of the shaft 800 then comprises the following steps: Initialization of the cutting (80): Filling the first sub-tree 800 with all the threads (0 and 1) of the root and beginning of the node scanning process; Adding (81) the son of the current node 0 (2 and 3) to the subtree 801 being constructed; adding (82) the son of the current node 802 (4, 5, 6, 7) to the subtree being built: the node 1 has 4 son. Now the subtree under construction 803 is full. A new subtree is created; 83. Current node 804 is 2. It does not have any wires, go to node 3. Adds the threads of node three to the current subtree 803. Now, this one is full: building a new subtree . 84. The current node is 4, without wires and therefore goes to node 5. Node 5 has 3 wires. The current 805 subtree is not full, but it already has two nodes. Create a new subtree. Adding (85) the threads of the node 6 86. The nodes 8, 9 and 10 are skipped because they have no son. Adding the threads of node 11: the subtree being built is full, creating a new subtree 87. The nodes 14 and 15 have no threads. The construction of the subtree list is complete. 5.5.3.3 Hierarchical description node (HDescNode) The hierarchical description node is initially an extension of the FootprintSet node. Such a type of node is for example present in the MPeg4 standard (ISO / IEC JTC11SC29 / WG11). It corresponds to a hierarchical description of a set of 2D polygons. However, it can be used for other data models that support progressivity. The hierarchical description node HierarchicalDescription (hereinafter referred to as HDescNode), in the case of its use with the FootprintSet, is intended to determine the PBTree's buildings (represented by the FootprintSetNode) to be displayed. Thus the HDescNode does some of the work of FootprintSetNode: that of selecting the level of detail of buildings. The rendering portion of the selected buildings continues to be performed by the FootprintSetNode. Within the scene graph, there is therefore a communication between the node HDescNode FootprintSetNode and node to transmit to the latter the list of buildings to compose.

On présente, en relation avec la figure 17, le graphe de scène correspondant à l'utilisation d'un HDescNode et d'un FootprintSetNode et la relation 170 entre ces deux noeuds. Afin de sélectionner le niveau de détail des bâtiments à afficher, le 5 HDescNode utilise un PBTree simplifié : celui-ci ne contient plus la géométrie des bâtiments, mais uniquement pour chaque noeud : La sphère englobant la boîte qui contient le bâtiment 2.5D ; Les erreurs métriques ; La taille du noeud du PBTree décrit (si le mode de communication est le 10 mode pair à pair). Cette description du PBTree peut donc être transmise rapidement à travers le réseau puisqu'elle est beaucoup plus petite. En parcourant l'arbre de description du PBTree et en utilisant la notion d'aura de perceptibilité d'un bâtiment, il devient possible de naviguer en mode client/serveur dans de grands environnements 15 urbains tel que la ville de Paris. 5.5.4 Sélection des noeuds à visualiser pour la ville Dans ce mode de réalisation particulier, c'est le pair qui effectue la sélection des noeuds à visualiser. Il transmet les requêtes au pair serveur qu'il a choisi pour qu'il lui envoie les données dont il a besoin pour visualiser la structure 20 hiérarchique. Le fichier de description que l'on propose ne contient pas les informations géométriques, le client doit donc les demander au pair serveur une fois qu'il a sélectionné un noeud. Le procédé général de sélection des noeuds est décrit dans le brevet [FR-05 02 4491. Dans ce mode de réalisation, nous optimisons ce procédé. 25 Une optimisation, selon l'invention, consiste à transmettre les auras des boites englobantes des différents noeuds de l'arbre en plus de l'aura de perceptibilité et du centre de gravité. Grâce a la pyramide de vue (cône de vision) on peut connaître les noeuds visible parmi ceux qui sont perceptible (si la boite englobante est incluse dans la pyramide de vue) On présente, en relation avec la figure 9, les différents noeuds perceptibles en n'utilisant que l'aura de perceptibilité comme critère de sélection. Cette figure permet de démontrer le lien existant entre l'arbre hiérarchique, la représentation visuelle et les zones de perceptibilité ; 900: Zone de perceptibilité de l'objet ; 901 : Zone de perceptibilité du noeud; 902 :Noeud de la représentation hiérarchique ; 903 :Noeud perceptible (qui doit être développé) ; 904 :Noeud visible si l'on regarde l'objet ; - 905 : Position de l'utilisateur dans la scène. La figure 10 présente les noeuds perceptibles si l'on tient compte du point de vue de l'utilisateur et que l'on dispose des auras incluant les boites englobantes des différents noeuds. Si un noeud est perceptible et que son aura de boite englobante entre en intersection avec le point de vue, il est sélectionné. Cette figure permet de démontrer le lien existant entre l'arbre hiérarchique, la représentation visuelle et les zones de perceptibilité en tenant compte du point de vue de l'utilisateur, avec une représentation 1007 pour laquelle rien n'est perceptible ; 1000: Zone de perceptibilité de l'objet ; - 1001 : Zone de perceptibilité du noeud ; 1002 :Noeud de la représentation hiérarchique ; 1003 :Noeud perceptible (qui doit être développé) ; 1004 :Noeud visible si l'on regarde l'objet ; 1005 : Position de l'utilisateur dans la scène ; - 1006: Point de vue de l'utilisateur. On constate que le nombre de noeuds perceptibles varie si on utilise le point de vue de l'utilisateur et l'aura incluant la boite englobante du noeud. Cette information permet de limiter le nombre de noeuds géométriques qui vont être demandés au serveur. In relation to FIG. 17, the scene graph corresponding to the use of an HDescNode and a FootprintSetNode and the relation 170 between these two nodes is presented. In order to select the level of detail of the buildings to display, the 5 HDescNode uses a simplified PBTree: it no longer contains the geometry of the buildings, but only for each node: The sphere encompassing the box that contains the building 2.5D; Metric errors; The size of the PBTree node describes (if the communication mode is the peer-to-peer mode). This description of the PBTree can therefore be transmitted quickly through the network since it is much smaller. By traversing the description tree of the PBTree and using the concept of aura of perceptibility of a building, it becomes possible to navigate in client / server mode in large urban environments such as the city of Paris. 5.5.4 Selection of the nodes to be visualized for the city In this particular embodiment, it is the peer which carries out the selection of the nodes to be visualized. It transmits the requests to the peer server it has chosen to send it the data it needs to view the hierarchical structure. The description file that we propose does not contain the geometric information, so the client must ask the peer server once it has selected a node. The general method of selecting the nodes is described in the patent [FR-05 02 4491. In this embodiment, we optimize this process. An optimization according to the invention consists in transmitting the auras of the bounding boxes of the various nodes of the tree in addition to the aura of perceptibility and the center of gravity. Thanks to the pyramid of sight (cone of vision) one can know the nodes visible among those which are perceptible (if the enclosing box is included in the pyramid of view) One presents, in relation with the figure 9, the various nodes perceptible in using only the aura of perceptibility as a selection criterion. This figure makes it possible to demonstrate the link existing between the hierarchical tree, the visual representation and the zones of perceptibility; 900: Area of perceptibility of the object; 901: Area of perceptibility of the node; 902: Node of the hierarchical representation; 903: Perceptible knot (to be developed); 904: Knot visible if we look at the object; - 905: User's position in the scene. Figure 10 shows the perceptible nodes taking into account the point of view of the user and that auras including the bounding boxes of the different nodes are available. If a node is noticeable and its bounding box aura intersects with the point of view, it is selected. This figure makes it possible to demonstrate the link existing between the hierarchical tree, the visual representation and the zones of perceptibility taking into account the point of view of the user, with a representation 1007 for which nothing is perceptible; 1000: Area of perceptibility of the object; - 1001: Area of perceptibility of the node; 1002: Node of the hierarchical representation; 1003: Perceptible knot (to be developed); 1004: Visible node when looking at the object; 1005: User's position in the scene; - 1006: User's point of view. It can be seen that the number of perceptible nodes varies if one uses the point of view of the user and the aura including the bounding box of the node. This information makes it possible to limit the number of geometric nodes that will be requested from the server.

Pour permettre une légère anticipation et qu'il y ait moins de raffinements visibles dus à une latence réseau, on n'utilise pas le point de vue réel. Il est décalé en arrière de manière a pouvoir déclarer comme perceptible des noeuds qui sont en retrait ou sur les côtés du point de vue, ce qui permet une anticipation pour les mouvements de rotation ou de recul. 5.5.5 Transmission de l'arbre de description entre pairs 5.5.5.1 Protocole de communication Afin de transmettre l'arbre de description sur le réseau en mode client-serveur, un protocole applicatif reposant sur TCP/UDP-IP est défini. Il repose sur des requêtes émises par le client (description du paquet de la requête en relation avec la figure 14), et des réponses transmises par le serveur (description du paquet de réponse en relation avec la figure 15). A son démarrage, le client réclame immédiatement le sous-arbre d'index 0 au serveur en utilisant une requête HDescRPck (figure 14). Le serveur lui répond sous la forme d'un paquet HDescPck contenant le sous-arbre de description d'index O. Le client lors de son parcours du sous-arbre sera amené selon ses besoins à récupérer d'autres sous-arbres. Il les réclamera au serveur en utilisant une requête HDescRPck (figure 14). Le serveur lui répondra par un paquet 20 HDescAPck (figure 15) contenant les sous-arbres demandés. Les informations (les champs) contenues dans ces paquets sont décrites dans les paragraphes suivants. La figure 18 présente une description détaillée du contenu du paquet HDescPck . Dans le cas de la description d'un PBT, les sous-arbres sont en fait des FPHDescSubTree. L'entête (181) est donc différent de 25 l'entête du HDescSubTree (qui en fait est vide). 5.5.5.2 Principe d'encodage et compression des paquets Dans le but de transmettre plus rapidement sur le réseau l'arbre de description hiérarchique, celui-ci est encodé de manière à le compresser. 30 Les descriptions suivantes présentent cet encodage en utilisant la syntaxe SDL. Certaines parties de l'encodage sont spécifiques à la structure décrite. Ces parties spécifiques étendent en conséquence la syntaxe de base. Actuellement, une seule structure est décrite : l'arbre de description hiérarchique, il s'agit du PBTree. 5.5.5.3 Champ HierarchicalDescriptionSpecificlnfo To allow a slight anticipation and that there is less visible refinements due to network latency, we do not use the real point of view. It is shifted backwards so as to be able to declare as noticeable nodes that are set back or on the sides of the point of view, which allows an anticipation for the movements of rotation or recoil. 5.5.5 Transmission of the peer description tree 5.5.5.1 Communication protocol In order to transmit the description tree on the network in client-server mode, an application protocol based on TCP / UDP-IP is defined. It is based on requests issued by the client (description of the request packet in relation to FIG. 14), and responses transmitted by the server (description of the response packet in relation to FIG. 15). When it starts, the client immediately requests the index subtree 0 from the server using an HDescRPck request (Figure 14). The server responds to it in the form of an HDescPck package containing the index description subtree O. The client during its subtree journey will be brought as needed to retrieve other subtrees. It will claim them to the server using an HDescRPck query (Figure 14). The server will respond with a HDescAPck packet (FIG. 15) containing the requested subtrees. The information (fields) contained in these packets are described in the following paragraphs. Figure 18 shows a detailed description of the contents of the HDescPck package. In the case of the description of a PBT, the subtrees are in fact FPHDescSubTree. The header (181) is therefore different from the header of the HDescSubTree (which in fact is empty). 5.5.5.2 Principle of Encoding and Packet Compression In order to transmit the hierarchical description tree faster on the network, it is encoded in such a way as to compress it. The following descriptions show this encoding using the SDL syntax. Some parts of the encoding are specific to the described structure. These specific parts accordingly extend the basic syntax. Currently, only one structure is described: the hierarchical description tree, this is PBTree. 5.5.5.3 HierarchicalDescriptionSpecificlnfo field

Les paramètres de compression sont spécifiques à chaque arbre de description. Ses paramètres sont les tous premiers éléments transmis auclient. Syntaxe : class HierarchicalDescriptionDecoderConfig extends AFXDecoderSpecificlnfo { int(8) type; unsigned int(5) rootChildrenRadiusNbBits; unsigned int(5) nbChildrenNbBits; unsigned int(5) nbSubTreesNbBits; float(32) acquisitionPrecision; float(32) minMetricError; float(32) maxMetricErrorEncodingFunction; Compression settings are specific to each description tree. Its parameters are the very first elements transmitted to the client. Syntax: class HierarchicalDescriptionDecoderConfig extends AFXDecoderSpecificlnfo {int (8) type; unsigned int (5) rootChildrenRadiusNbBits; unsigned int (5) nbChildrenNbBits; unsigned int (5) nbSubTreesNbBits; float (32) acquisitionPrecision; float (32) minMetricError; float (32) maxMetricErrorEncodingFunction;

switch(type) { 0: FPHDescDecoderConfig; } } Sémantique : type spécifie le type de structure décrit par la description hiérarchique. 25 Actuellement, une seule structure est décrite : il s'agit du PBTree. Le type associé est O. rootChildrenRadiusNbBits est le nombre de bits qui sont utilisés pour encoder le rayon des fils appartenant à la racine de l'arbre de description. nbSubTreesNbBits est le nombre de bits utilisés pour encoder le 30 nombre de sous-arbres contenus dans un HDescAPck. acquisitionPrecision est la précision utilisée lors de l'encodage des deltas entre le centre de la sphère englobante d'un père et le centre de la sphère englobante des fils du noeuds. Cette valeur doit être positive est strictement supérieure à 0. minMetricError est l'erreur métrique minimum supérieure à 0 trouvée dans l'arbre de description. Cette valeur est utilisée pour décoder l'erreur métrique d'un noeud. maxMetricErrorEncodingFunction est la plus grande valeur de la 5 fonction utilisée pour encoder l'erreur métrique. La fonction de décodage est la suivante : if (encodedMetricError = 0) metricError = minMetricError switch (type) {0: FPHDescDecoderConfig; }} Semantics: type specifies the type of structure described by the hierarchical description. Currently, only one structure is described: it is PBTree. The associated type is O. rootChildrenRadiusNbBits is the number of bits that are used to encode the radius of the children belonging to the root of the description tree. nbSubTreesNbBits is the number of bits used to encode the number of subtrees contained in a HDescAPck. acquisitionPrecision is the precision used when encoding deltas between the center of the enclosing sphere of a father and the center of the enclosing sphere of the nodes' threads. This value must be positive and strictly greater than 0. minMetricError is the minimum metric error greater than 0 found in the description tree. This value is used to decode the metric error of a node. maxMetricErrorEncodingFunction is the largest value of the function used to encode the metric error. The decoding function is as follows: if (encodedMetricError = 0) metricError = minMetricError

else encudedMetricError - maxMetricErrorEncodingFunction 8 ù metricError = e 255 ù 1 else encudedMetricError - maxMetricErrorEncodingFunction 8 ù metricError = e 255 ù 1

if (metricError < minMetricError) metricError =1.001 minMetricError 10 5.5.5.4 Champ FPHDescSpecificlnfo Dans le cas où le type de structure décrite est 0 (i.e. un PBTree), les paramètres HierarchicalDescriptionSpecificInfo sont complétés par les informations suivantes : Syntaxe : 15 class FPHDescDecoderConfig extends HierarchicalDescriptionDecoderConfig { 20 unsigned int(16) nbRootChildren; unsigned int(5) indexNbBits; unsigned int(5) nbNodesInSubTreeNbBits; unsigned int(5) nbNodesOnFirstLevelOfSubTreeNbBits; unsigned int(5) nbSubTreesChildrenNbBits unsigned unsigned int(5) nbNodesOnLastLevelNbBits int(8) networkType switch(networkType) { 25 0: // pas d'information supplémentaire 1: int(5) subTreeSizeNbBits int(5) geometryNodeSizeNbBits } 30 } Sémantique : nbRootChildren est le nombre de noeuds que possède la racine. Cette information est utilisée lors du décodage du premier sous-arbre afin de 32 déterminer combien de noeuds sont à rattacher à la racine de l'arbre de description. if (metricError <minMetricError) metricError = 1.001 minMetricError 10 5.5.5.4 FPHDescSpecificlnfo Field In the case where the described structure type is 0 (ie a PBTree), the HierarchicalDescriptionSpecificInfo parameters are supplemented by the following information: Syntax: 15 class FPHDescDecoderConfig extends HierarchicalDescriptionDecoderConfig {20 unsigned int (16) nbRootChildren; unsigned int (5) indexNbBits; unsigned int (5) nbNodesInSubTreeNbBits; unsigned int (5) nbNodesOnFirstLevelOfSubTreeNbBits; unsigned int (5) nbSubTreesChildrenNbBits unsigned unsigned int (5) int (8) networkType switch (networkType) {25 0: // no additional information nbRootChildren is the number of nodes that the root has. This information is used when decoding the first subtree to determine how many nodes are to be attached to the root of the description tree.

indexNbBits est le nombre de bits utilisés pour encoder les index des noeuds de l'arbre de description. nbNodesInSubTreeNbBits est le nombre de bits utilisés pour encoder le nombre de noeuds présents dans un sous-arbre (HDescSubTree). indexNbBits is the number of bits used to encode the indexes of the nodes of the description tree. nbNodesInSubTreeNbBits is the number of bits used to encode the number of nodes present in a subtree (HDescSubTree).

nbNodesOnFirstLevelOfSubTreeNbBits est le nombre de bits utilisés pour encoder le nombre de noeuds présents sur le premier niveau d'un sous-arbre. - nbSubTreesChildrenNbBits est le nombre de bits utilisés pour encoder le nombre de fils que possède un sous-arbre. nbNodesOnFirstLevelOfSubTreeNbBits is the number of bits used to encode the number of nodes present on the first level of a subtree. - nbSubTreesChildrenNbBits is the number of bits used to encode the number of threads that a subtree has.

nbNodesOnLastLevelNbBits est le nombre de bits utilisés pour encoder le nombre de noeuds présents sur le dernier niveau d'un sous-arbre. nbNodesOnLastLevelNbBits is the number of bits used to encode the number of nodes present on the last level of a subtree.

networkType est le type de communication réseau utilisé. networkType is the type of network communication used.

Actuellement, deux types de communication sont mis en oeuvre : Currently, two types of communication are implemented:

Type 0 : modèle client-serveur ;Type 0: client-server model;

Type 1 : modèle pair à pair.Type 1: peer-to-peer model.

Selon le mode de communication utilisé, des informations supplémentaires peuvent être ajoutées au flux : - nbTreeSizeNbBits est le nombre de bits utilisés pour encoder la taille d'un sous-arbre. Depending on the communication mode used, additional information can be added to the stream: - nbTreeSizeNbBits is the number of bits used to encode the size of a subtree.

geometryNodeSizeNbBits est le nombre de bits utilisés pour encoder la taille de la géométrie d'un noeud du PBTree. 5.5.5.5 Champ HierarchicalDescriptionAnswerPacket Syntaxe : class HierarchicalDescriptionPacket { unsigned int(HierarchicalDescriptionDecoderConfig.nbSubTreesNbBits nbSubTrees; for (i= 0; i < nbSubTrees; i++) { HierarchicalDescriptionSubTree subTree; } } Sémantique : nbSubTrees est le seul champ présent dans l'entête d'un paquet de réponse (HDescAPckHeader). Sa valeur correspond au nombre de sous-arbres présents dans le paquet. 5.5.5.6 Champ HierarchicalDescriptionSubTree Syntaxe : class HierarchicalDescriptionSubTree { switch(HierarchicalDescriptionDecoderConfig.type) { 0: FPHDescSubTree; Sémantique : Dans le cas général, l'entête d'un sous-arbre de description hiérarchique HDescSubTreeHeader est vide. Cet entête est spécialisé dans le cas de la 15 description d'un PBTree comme cela est décrit ci-dessous. 5.5.5.7 Champ FPHDescSubTree Syntaxe : class FPHDescSubTree extends HierarchicalDescriptionSubTree { 20 unsigned int(FPHDescDecoderConfig.nbNodesInSubTreeNbBits) nbNodesInSubTree; unsigned int(FPHDescDecoderConfig.nbNodesOnFirstLevelOfSubTreeNbBi ts) nbNodesOnFirstLevelOfSubTree; 25 unsigned int(FPHDescDecoderConfig.indexNbBits) indexParentFirstNodeInSubTree; unsigned int(FPHDescDecoderConfig.indexNbBits) indexFirstNodeInSubTree; int(FPHDescDecoderConfig.nbSubTreesChildrenNbBits) 30 nbSubTreesChildren for (i= 0; i < nbSubTreesChildren; i++) { int(FPHDescDecoderConfig.nbSubTreesNbBits) indexSubTreeChild int(FPHDescDecoderConfig.nbNodesOnLastLevelNbBits) 35 nbNodesOnLastLevel switch(FPHDescDecoderConfig.networkType) { 0: // pas d'information supplémentaire geometryNodeSizeNbBits is the number of bits used to encode the geometry size of a PBTree node. 5.5.5.5 HierarchicalDescriptionAnswerPacket field Syntax: class HierarchicalDescriptionPacket {unsigned int (HierarchicalDescriptionDecoderConfig.nbSubTreesNbBits nbSubTrees; for (i = 0; i <nbSubTrees; i ++) {HierarchicalDescriptionSubTree subTree;}} Semantics: nbSubTrees is the only field present in the header of a response packet (HDescAPckHeader) Its value is the number of subtrees in the package 5.5.5.6 HierarchicalDescriptionSubTree field Syntax: class HierarchicalDescriptionSubTree {switch (HierarchicalDescriptionDecoderConfig.type) {0: FPHDescSubTree; Semantics: In the general case, the header of a hierarchical description subtree HDescSubTreeHeader is empty This header is specialized in the case of describing a PBTree as described below 5.5.5.7 FPHDescSubTree field Syntax: class FPHDescSubTree extends HierarchicalDescriptionSubTree {20 unsigned int (FPHDescDecoderConfig.nbNodesInSubTr eeNbBits) nbNodesInSubTree; unsigned int (FPHDescDecoderConfig.nbNodesOnFirstLevelOfSubTreeNbBi ts) nbNodesOnFirstLevelOfSubTree; Unsigned int (FPHDescDecoderConfig.indexNbBits) indexParentFirstNodeInSubTree; unsigned int (FPHDescDecoderConfig.indexNbBits) indexFirstNodeInSubTree; int (FPHDescDecoderConfig.nbSubTreesChildrenNbBits) nbSubTreesChildren 30 for (i = 0; i <nbSubTreesChildren; i ++) {int (FPHDescDecoderConfig.nbSubTreesNbBits) indexSubTreeChild int (FPHDescDecoderConfig.nbNodesOnLastLevelNbBits) 35 nbNodesOnLastLevel switch (FPHDescDecoderConfig.networkType) {0: // no additional information

int(FPHDescDecoderConfig.subTreeSizeNbBits) subTreeChildSize 1: 40 } } int (FPHDescDecoderConfig.subTreeSizeNbBits) subTreeChildSize 1: 40}}

for (i= 0; i < nbNodeslnSubTree; i++) { HierarchicalDescriptionNodeMessage node; Sémantique : nbNodeslnSubTree indique le nombre de noeuds présents dans le sous-10 arbre. nbNodesOnFirstLevelOfSubTree indique le nombre de noeuds présents sur le premier niveau du sous-arbre. indexParentFirstNodelnSubTree est l'index du noeud père auquel le premier noeud du sous-arbre doit être rattaché. Lors du décodage des 15 noeuds suivants, ces noeuds seront ajoutés à ce noeud père jusqu'à ce que tous ses noeuds aient été décodés. Une fois ses noeuds décodés, les noeuds suivants seront rattachés au noeud père qui est le frère du noeud indexé par indexParentFirstNodelnSubTree . Le décodage du sous-arbre se déroule de même jusqu'à ce que le nombre de noeuds 20 nbNodesOnFirstLevelOfSubTree soit atteint. Les noeuds décodés ensuite ont leur parent présent dans le sous-arbre en cours de décodage. indexFirstNodelnSubTree est l'index du premier noeud contenu dans le sous-arbre. Les index des autres noeuds contenus dans le sous-arbre sont obtenus en incrémentant l'index courant à chaque noeud décodé. 25 - nbSubTreesChildren est le nombre de sous-arbres fils que possède ce sous-arbre. indexSubTreeChild est l'index du sous-arbre fils. Cet index est utilisé par le client pour demander au serveur de lui fournir les fils du sous-arbre en cours de décodage. 30 - nbNodesOnLastLevel est le nombre de noeuds du dernier niveau du sous-arbre en cours de décodage qui ont leurs fils situés dans le sous-arbre ayant pour index indexSubTreeChild . 34 subTreeChildSize est la taille en octets du sous-arbre ayant pour index indexSubTreeChild . 5.5.5.8 Champ HierarchicalDescriptionNodeMessage for (i = 0; i <nbNodeslnSubTree; i ++) {HierarchicalDescriptionNodeMessage node; Semantics: nbNodeslnSubTree indicates the number of nodes present in the subtree. nbNodesOnFirstLevelOfSubTree indicates the number of nodes present on the first level of the subtree. indexParentFirstNodelnSubTree is the index of the parent node to which the first node of the subtree should be attached. When decoding the next 15 nodes, these nodes will be added to this parent node until all its nodes have been decoded. Once its nodes are decoded, the following nodes will be attached to the parent node which is the index node of the node indexed by indexParentFirstNodelnSubTree. The decoding of the subtree proceeds in the same way until the number of nodes 20 nbNodesOnFirstLevelOfSubTree is reached. The decoded nodes then have their parent present in the subtree being decoded. indexFirstNodelnSubTree is the index of the first node contained in the subtree. The indexes of the other nodes contained in the subtree are obtained by incrementing the current index at each decoded node. 25 - nbSubTreesChildren is the number of child subtrees owned by this subtree. indexSubTreeChild is the index of the child subtree. This index is used by the client to request the server to supply the subtree threads being decoded. 30 - nbNodesOnLastLevel is the number of nodes in the last level of the subtree being decoded that have their children located in the subtree with indexSubTreeChild as their index. 34 subTreeChildSize is the size in bytes of the subtree whose index is indexSubTreeChild. 5.5.5.8 HierarchicalDescriptionNodeMessage field

Syntaxe : class HierarchicalDescriptionNodeMessage { unsigned int(HierarchicalDescriptionDecoderConfig.nbChildrenNbBits nbChildren; if (nbChildren > 0) { unsigned int(8) encodedMetricError; } Syntax: class HierarchicalDescriptionNodeMessage {unsigned int (HierarchicalDescriptionDecoderConfig.nbChildrenNbBits nbChildren; if (nbChildren> 0) {unsigned int (8) encodedMetricError;}

int(l) isChildOfRoot; variable temporaire non lue. if (isChildOfRoot) { float(32) gcX; float(32) gcY; float(32) gcZ; unsigned int(HierarchicalDescriptionDecoderConfig.rootChildrenRa diusNbBits) radius; } else { unsigned int(5) nbBitsDelta; int(l) isDeltaXNeg; unsigned int(nbBitsDelta) deltaX; int(l) isDeltaYNeg; unsigned int(nbBitsDelta) deltaY; int(l) isDeltaYNeg; unsigned int(nbBitsDelta) deltaZ; int(l) isDeltaRadiusNeg; unsigned int(nbBitsDelta) deltaRadius; } } Sémantique : nbChildren est le nombre de fils que possède ce noeud. encodedMetricError est la valeur encodée de l'erreur métrique pour ce noeud de description hiérarchique. Si le noeud ne possède pas de fils (i.e. c'est une feuille de l'arbre de description), son erreur métrique est nulle. Il n'est donc pas nécessaire de la transmettre. isChildOfRoot est une variable booléenne qui n'est pas lue dans le flux. Elle est utilisée pour savoir si le noeud est un fils de la racine ou non. Si le noeud est un fils de la racine, les coordonnées complètes du centre de la sphère englobante sont transmises. Sinon, elles sont déterminées en utilisant la différence entre celle du noeud à décoder et celle du noeud père. Il en est de même pour le rayon. gcX , gcY , gcZ sont les coordonnées du centre de la sphère englobante. radius est le rayon de la sphère englobante. nbBitsDelta est le nombre qu'il faut utiliser pour les lire les valeurs deltaX , deltaY , deltaZ et deltaRadius . - isDeltaNegX indique si la différence entre l'abscisse du centre de la sphère englobante du noeud père et l'abscisse du centre de la sphère englobante du noeud en cours de décodage est positive ou négative. deltaX est la valeur absolue de la différence entre l'abscisse du centre de la sphère englobante du noeud père et l'abscisse du centre de la sphère englobante du noeud en cours de décodage. Si isDeltaNegX vaut 1, deltaX doit être multiplié par -1. L'opération pour décoder l'abscisse est la suivante : if (isDeltaXNeg) deltaX = deltaX • -1 node.gcX = parentNode.gcX + HierarchilcalDescriptionDecoderConfig.acquisition Pr ecision deltaX - isDeltaYNeg , isDeltaZNeg , deltaY et deltaZ ont la même signification que isDeltaXNeg et deltaX , mais pour l'ordonnée et l'altitude. deltaRadius est la différence entre le rayon de la sphère du noeud père et le rayon du noeud en cours de décodage. L'opération pour décoder le 25 rayon du noeud courant est la suivante : radius = parentNode.radius + HierarchicalDescriptionDecoderConfig.acquisition Pr ecision deltaRadius 5.5.5.9 Champ FPDescNodeMessage Syntaxe : class FPHDescSubTree extends HierarchicalDescriptionSubTree { switch(FPHDescDecoderConfig.networkType) { 0: // pas d'information supplémentaire 1: int(8) geometryNodeSize } } Sémantique : int (l) isChildOfRoot; temporary variable not read. if (isChildOfRoot) {float (32) gcX; float (32) gcY; float (32) gcZ; unsigned int (HierarchicalDescriptionDecoderConfig.rootChildrenRa diusNbBits) radius; } else {unsigned int (5) nbBitsDelta; int (l) isDeltaXNeg; unsigned int (nbBitsDelta) deltaX; int (l) isDeltaYNeg; unsigned int (nbBitsDelta) deltaY; int (l) isDeltaYNeg; unsigned int (nbBitsDelta) deltaZ; int (l) isDeltaRadiusNeg; unsigned int (nbBitsDelta) deltaRadius; }} Semantics: nbChildren is the number of threads that this node has. encodedMetricError is the encoded value of the metric error for this hierarchical description node. If the node does not have a child (i.e. is a leaf of the description tree), its metric error is zero. It is not necessary to transmit it. isChildOfRoot is a Boolean variable that is not read in the stream. It is used to know if the node is a child of the root or not. If the node is a child of the root, the complete coordinates of the center of the enclosing sphere are transmitted. Otherwise, they are determined using the difference between that of the node to be decoded and that of the parent node. It is the same for the radius. gcX, gcY, gcZ are the coordinates of the center of the bounding sphere. radius is the radius of the enclosing sphere. nbBitsDelta is the number to use to read the deltaX, deltaY, deltaZ and deltaRadius values. - isDeltaNegX indicates whether the difference between the center abscissa of the enclosing sphere of the parent node and the abscissa of the center of the bounding sphere of the node being decoded is positive or negative. deltaX is the absolute value of the difference between the center abscissa of the enclosing sphere of the parent node and the abscissa of the center of the bounding sphere of the node being decoded. If isDeltaNegX is 1, deltaX must be multiplied by -1. The operation to decode the abscissa is as follows: if (isDeltaXNeg) deltaX = deltaX • -1 node.gcX = parentNode.gcX + HierarchilcalDescriptionDecoderConfig.acquisition Precision deltaX - isDeltaYNeg, isDeltaZNeg, deltaY and deltaZ have the same meaning as isDeltaXNeg and deltaX, but for the ordinate and altitude. deltaRadius is the difference between the radius of the sphere of the father node and the radius of the node being decoded. The operation to decode the radius of the current node is: radius = parentNode.radius + HierarchicalDescriptionDecoderConfig.acquisition deltaRadius Precision 5.5.5.9 FPDescNodeMessage Field Syntax: class FPHDescSubTree extends HierarchicalDescriptionSubTree {switch (FPHDescDecoderConfig.networkType) {0: // no additional information 1: int (8) geometryNodeSize}} Semantics:

geometryNodeSize est la taille en octet de la géométrie du noeud du PBTree décrit par le noeud de description hiérarchique. 5.5.5.10 Reconstruction de l'arbre reçu On décrit en relation avec la figure 16, une méthode de reconstruction d'un sous-arbre lors de son décodage par un pair client. geometryNodeSize is the byte size of the PBTree node geometry described by the hierarchical description node. 5.5.5.10 Reconstruction of the received tree With respect to FIG. 16, a method of reconstructing a subtree during decoding by a client peer is described.

Le pair client dispose d'un arbre de description 160. Il reçoit un sous arbre 161, contenant une liste de noeuds 162. The client peer has a description tree 160. It receives a subtree 161, containing a list of nodes 162.

Le nombre d'étapes nécessaires à la reconstruction dépend du nombre de The number of steps required for reconstruction depends on the number of

noeuds du sous arbre reçu (dans cet exemple, il y en a sept). Pour chaque noeud de la liste de noeud 162, le pair client ajoute ce noeud à l'arbre de description en nodes of the subtree received (in this example, there are seven). For each node in the node list 162, the client peer adds this node to the description tree in

fonction du niveau du noeud dans l'arbre. function of the level of the node in the tree.

5.5.6 Sélection des pairs serveurs5.5.6 Peer server selection

La sélection des pairs serveurs se fait à chaque parcours de l'arbre. Les requêtes sont transmises en fonction de l'importance des noeuds à chacun des pairs serveurs connectés (par rapport a la position du noeud dans la hiérarchie des niveaux de détail). La figure 11 présente une possibilité d'implémentation pour la répartition des requêtes entre les pairs connectés et le serveur central. The selection of the peer servers is done at each route of the tree. Queries are transmitted based on the importance of the nodes to each of the connected peers (relative to the position of the node in the hierarchy of detail levels). Figure 11 shows an implementation possibility for the distribution of requests between the connected peers and the central server.

Ce mode particulier de réalisation peut par exemple s'appliquer dans le cas ou le fichier de description n'est pas progressif. This particular embodiment can for example apply in the case where the description file is not progressive.

Le pourcentage de réalisation de la figure 11 représente le taux de requêtes non acquittées dans l'intervalle de temps imparti. Le pourcentage de réalisation doit régulièrement être remis à jour. The embodiment percentage of FIG. 11 represents the rate of unacknowledged requests in the time interval. The percentage of realization must regularly be updated.

Le pourcentage de chargement est déterminé par le pair distant et est transmis au cours d'un envoi de position. Pendant le parcours de son arbre, chaque pair détermine le pourcentage de noeuds qu'il a chargé compte tenu de sa position. Le pourcentage de chargement est maximal si toutes les données nécessaires à la visualisation compte tenu de la position courante sont contenues dans le cache du pair considéré. L'upload de chaque pair peut être fixé manuellement, dans ce cas il sera transmis dans un message d'initialisation. Il est aussi envisageable de le mesurer régulièrement. L'upload sera ajusté en fonction de l'intervalle entre chaque parcours (compte tenu que c'est un débit par seconde que l'on mesure). Le pair client charge (10) la description de la scène, puis effectue (11) le tri des noeuds de l'arbre par priorité. En cas de nouvelle position 12, le pair client récupère (13) la liste des pairs connectés au même point d'intérêt puis trie (14) cette liste en fonction de la taille, du pourcentage de chargement de réalisation, du TTS. Le pair client crée (15) ensuite la liste des noeuds à charger pour les pairs serveur ainsi que pour le serveur central. Pour chaque noeud de la liste de noeud, le pair client effectue (16) un test d'intersection du noeud considéré avec son aura de perception. S'il n'y a pas d'intersection (17), on passe au noeud suivant. S'il y a intersection (18), le pair client inspecte son cache (19) pour savoir si le noeud a déjà été chargé. Si oui (20), on passe au noeud suivant. Si non (21), il vérifie s'il est à la fin de sa liste de pair connecté (22). Si non (23) il passe les pairs considérés en revue : il effectue (24) un test d'intersection du pair serveur considéré avec son aura de perception. S'il n'y a pas d'intersection (25), on passe au pair suivant. S'il y a intersection (26), le pair client vérifie la capacité du pair serveur considéré eut égard à la taille des données à télécharger, ainsi qu'au TTS , à l'Upload . Si le pair serveur est éligible, (27), on ajoute (28) le noeud dans la liste des noeuds requis via ce pair et on passe (29) au noeud suivant. Si aucun pair (30) ne peut fournir le noeud requis, on ajoute (31) le noeud dans la liste des noeuds requis au serveur central. The loading percentage is determined by the remote peer and is transmitted during a position send. During the course of his tree, each peer determines the percentage of nodes he has loaded given his position. The percentage of loading is maximum if all the data necessary for the visualization taking into account the current position are contained in the cache of the peer considered. The upload of each peer can be set manually, in this case it will be transmitted in an initialization message. It is also possible to measure it regularly. The upload will be adjusted according to the interval between each course (considering that it is a flow per second that we measure). The client peer loads (10) the description of the scene, then performs (11) sorting the nodes of the tree by priority. In the case of a new position 12, the peer client retrieves (13) the list of peers connected to the same point of interest and then sorts (14) this list according to the size, the percentage of implementation loading, the TTS. The client peer then creates (15) the list of nodes to be loaded for the peer server as well as for the central server. For each node of the node list, the client peer performs (16) an intersection test of the considered node with its perception aura. If there is no intersection (17), move on to the next node. If there is an intersection (18), the peer client inspects its cache (19) to see if the node has already been loaded. If yes (20), go to the next node. If not (21), it checks whether it is at the end of its connected peer list (22). If not (23) it passes the considered peers: it performs (24) an intersection test of the considered server peer with its aura of perception. If there is no intersection (25), we go on to the next par. If there is an intersection (26), the client peer verifies the capacity of the peer server considered with regard to the size of the data to be downloaded, as well as to the TTS, to the Upload. If the peer server is eligible, (27), add the node (28) to the list of required nodes via this peer and pass (29) to the next node. If no peer (30) can provide the required node, add (31) the node in the list of required nodes to the central server.

Lorsque cette liste de noeuds a été intégralement parcourue (32), les messages de récupération des données géométriques sont envoyées (33) aux pairs et au serveur central. 5.6 Structure des pairs La structure d'un pair client est illustrée schématiquement par la figure 12. Il comprend une mémoire 121, et une unité de traitement 120 équipée d'un microprocesseur, qui est piloté par un programme d'ordinateur (ou application) 122. L'unité de traitement 120 reçoit en entrée, via un module d'interface d'entrée réseau 123, des noeuds de constitution des arbres hiérarchiques et/ou des données de visualisation et/ou des réponses 124, que le microprocesseur traite, selon les instructions du programme 122, pour générer le sous-arbre hiérarchique et/ou effectuer le classement des pairs serveur et/ou réaliser la représentation des données et de visualisation et/ou générer de nouvelles requêtes à destination des pairs serveur 1212, qui sont transmises via un module d'interface de sortie réseau 125. La structure d'un pair serveur est illustrée schématiquement par la figure 13. Il comprend une mémoire 131, et une unité de traitement 130 équipée d'un microprocesseur, qui est piloté par un programme d'ordinateur (ou application) 132. L'unité de traitement 130 reçoit en entrée, via un module d'interface d'entrée réseau 133, des requêtes d'obtention d'arbres hiérarchiques et/ou des requêtes d'obtention de données de visualisation 134, que le microprocesseur traite, selon les instructions du programme 132, pour générer des envois de noeuds des arbres hiérarchiques et/ou des réponses et/ou des données de visualisation 136, qui sont transmises via un module d'interface de sortie réseau 135. 25 When this list of nodes has been completely traversed (32), the geometric data recovery messages are sent (33) to the peers and to the central server. 5.6 Peer Structure The structure of a client peer is illustrated schematically in FIG. 12. It comprises a memory 121, and a processing unit 120 equipped with a microprocessor, which is controlled by a computer program (or application). 122. The processing unit 120 receives as input, via a network input interface module 123, hierarchical tree constitution nodes and / or display data and / or responses 124, which the microprocessor processes, according to the instructions of the program 122, to generate the hierarchical subtree and / or perform the ranking of the peer server and / or perform the data representation and visualization and / or generate new requests to the peer server 1212, which are transmitted via a network output interface module 125. The structure of a server peer is illustrated schematically in FIG. 13. It comprises a memory 131, and a processing unit 130 eq. The processor unit 130 receives, via a network input interface module 133, requests for obtaining data from a microprocessor, which is controlled by a computer (or application) program 132. hierarchical trees and / or requests for obtaining display data 134, which the microprocessor processes, according to the instructions of the program 132, to generate node sends of the hierarchical trees and / or responses and / or display data 136 , which are transmitted via a network output interface module 135. 25

Claims

A method of selecting at least one peer server for transmitting viewing data of content to at least one peer client within a peer network, said data being organized as nodes a hierarchical tree comprising at least one parent node and at least one child node, a displayable element being associated with each of said nodes, characterized in that it comprises a selection phase of at least one of said peer servers comprising at least a part of said display data and / or at least a part of said hierarchical tree, said selection phase taking account of at least one piece of information representative of a data size of at least one of said viewable elements.

2. Selection method according to claim 1 characterized in that said selection phase comprises a step of identifying a set of neighboring pairs comprising at least a portion of said display data and / or at least a portion of said hierarchical tree.

3. Selection method according to claim 2, characterized in that said selection phase comprises the following steps: determination, by said at least one client peer, of a current virtual browsing space, represented by a visualization subtree current of said hierarchical tree; selecting, by said at least one client peer, at least one neighboring peer server present within said current browsing virtual space, forming said set of neighboring peers; transmission, to said peer client, by at least one of said neighboring peer servers, of at least one display node of said current display subtree, following at least one request from said client peer; associating at least one of said neighboring peer servers, said associated server pair, with each of said nodes of said visualization subtree in conjunction with the viewing nodes contained in each of said peer servers; classifying, by said client pair, said associated pairs, according to said data size of said viewable elements of said transmitted display nodes, for each of said nodes; transmission, by said associated pairs, of at least one display data of said viewable elements following at least one transmission request sent by said client pair, according to said classification.

4. Selection method according to claim 3, characterized in that said classifying step also takes account of at least one of the parameters belonging to the group comprising at least: a quantity of bandwidth available for transmission; a time of service; download time; A level of detail of said at least one display node; the data present on said peer servers; the percentage of loading; the acquittal rate; the position of said peer servers. 20

5. Selection method according to any one of claims 2 to 4, characterized in that it implements at least one peer, said pair of connectivity, managing the access of a peer client to a peer network, and in that said step of determining a current browsing virtual space comprises the following substeps: connecting said client peer to at least one of said connectivity peers, so as to enable said peer client to access said network peers; interrogating, by said peer client, at least one peer whose identifier is provided by at least one of said connectivity peers so as to obtain said viewing subtree; 30

6. Data signal exchanged between at least one peer server and at least one peer client, in a selection method according to any one of claims 1 to 5, characterized in that it comprises at least one information field of at least one information representative of a data size of at least one of said viewable elements.

7. Computer program product downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor, characterized in that it comprises program code instructions for the execution of the method The selection method according to at least one of claims 1 to 5 when executed on a computer.

8. Terminal comprising a client pair for selecting at least one peer server for the transmission of data for viewing content within a peer network, said data being organized in the form of nodes of a hierarchical tree comprising at least one parent node and at least one child node, a displayable element being associated with each of said nodes, characterized in that it comprises means for selecting at least one of said peer servers comprising at least a part of said data and / or at least a portion of said hierarchical tree, said selection phase taking account of at least one information representative of a data size of at least one of said viewable elements.

A server comprising a peer server for transmitting viewing data of a content to a peer client within a peer network, said data being organized as nodes of a hierarchical tree comprising at least one parent node and at least one child node, a displayable element being associated with each of said nodes, characterized in that it comprises means for transmitting, at least 30, a display datum of said viewable elements as a result of leasta transmission request transmitted by said client pair, according to a classification of said display data according to information representative of a data size of at least one of said displayable elements.