TITRE : Procédé de calcul de visibilité d’objets au sein d’une scène 3D.

DOMAINE TECHNIQUE DE L’INVENTION

[0001] L’invention a pour objet un procédé de calcul de visibilité d’objets au sein d’une scène en trois dimensions aussi appelée scène 3D.

[0002] Le domaine technique de l’invention est celui de du rendu 3D (ou 2D, pour deux dimensions) et de la détection de visibilité d’objets dans les applications utilisant des moteurs de rendu graphique comme les jeux vidéo, les mondes virtuels, la réalité virtuelle, la réalité augmentée...

ARRIERE-PLAN TECHNOLOGIQUE DE L’INVENTION

[0003] Dans le domaine de la technique on utilise des moteurs graphiques, comme Unity, Unreal et d’autres, pour produire des images à afficher sur un écran. Ces images sont produites à partir d’une scène composée d’objets. D’un point de vue macroscopique, pour un utilisateur final, ces objets sont des bâtiments, des véhicules, des planètes, des objets du quotidien.... Du point de vue du moteur de rendu graphiques il s’agit d’une liste de forme géométrique ayant des coordonnées dans l’espace, des propriétés de surface, des règles de mouvement dans le temps, ...

[0004] Plus techniquement, un moteur de rendu 3D a pour objet de dessiner en temps réel sur un plan de rendu appelé « viewport », une pluralité d’objets composant une scène. Ces objets sont définis dans l’espace de coordonnées (x,y,z).

[0005] Pour cela, avec référence à la figure 1 , un objet 100 est projeté sur un viewport 110 depuis le point de vue d’une caméra 120, elle aussi définie dans l’espace de coordonnées (x,y,z).

[0006] Un moteur de rendu utilise plusieurs techniques afin de projeter et dessiner correctement la scène sur le plan de rendu. Ces techniques sont combinées au sein d’un « render pipeline » aussi appelé pipeline graphique. Le pipeline graphique comporte une notion de visibilité afin calculer pour chaque pixel quel objet doit être dessiné et rendre sa couleur.

[0007] On comprend donc aisément qu’à partir d’un point d’observation données certains objets sont plus ou moins visibles, certains pouvant en masquer d’autres. [0008] Dans le rendu d’une scène en 3 dimensions, on a parfois besoin de connaître la visibilité d’un élément au sein de cette scène. En effet celui-ci peut être caché par un autre, dans une zone d’ombre, partiellement visible, ou encore derrière un autre objet semi-transparent.

[0009] Ce besoin est actuellement satisfait de manière imprécise ou partielle.

[0010] Une solution est d’utiliser la technique dite du zbuffer. Cette technique permet de déterminer la visibilité d’un objet au moment où il est lui-même dessiné, d’autres éléments pouvant le recouvrir par la suite. Cette technique permet donc uniquement de prendre en compte le positionnement et l’orientation de l’objet par rapport à un observateur, on parle aussi de caméra, au moment du rendu de l’objet.

[0011] Une autre solution est l’utilisation de « raycasts ». Cependant cette solution ne permet pas de connaître la visibilité d’un objet derrière un autre semi-transparent ou d’un objet dans une zone d’ombre.

[0012] Il n’existe donc pas de solution permettant un calcul de visibilité derrière des objets transparents avec prise en compte de l’éclairage de la scène et des ombres.

RESUME DE L’INVENTION

[0013] Notre invention répond à ce besoin en décrivant une technique de calcul de visibilité très précise d’un objet au sein d’une scène.

[0014] L’invention s’appuie sur un deuxième rendu en plus du rendu principal. Le rendu principal est celui attendu par l’utilisateur de l’application qui met en oeuvre le moteur de rendu.

[0015] Pour cela on ajoute une deuxième caméra dans la scène. Cette deuxième caméra suit à tout instant la position et les caractéristiques de la caméra principale (position, échelle, options de filtre, plans de coupe, etc...).

[0016] Contrairement à la caméra principale qui sert à rendre la scène et à l’afficher au joueur, la deuxième caméra réalise un rendu uniquement pour vérifier la visibilité de certains objets dans la scène. La fréquence de ces rendus peut être différente de celles de la caméra principale afin de ne pas perturber les performances de l’application.

[0017] On modifie le pipeline graphique associé à cette deuxième caméra afin de pouvoir réaliser les calculs de visibilité selon l’invention. [0018] L’invention offre une solution aux problèmes évoqués précédemment, en permettant de prendre en compte tous les aspects de la scène.

[0019] Un aspect de l’invention concerne un procédé de calcul d’un score de visibilité dans une scène en trois dimensions, la scène étant composée d’une pluralité d’objets caractérisé en ce que le procédé comporte les étapes suivantes mise en oeuvre par une caméra dédiée clone d’une caméra principale, la caméra dédiée étant associé à un pipeline graphique dédié :

Sélection d’un ensemble d’au moins un objet parmi la pluralité d’objets de la scène ;

Pour chaque objet de l’ensemble sélectionné découpage de l’objet en zones à tester ;

Sélection d’un canal de « stencil buffer » pour enregistrer un masque de visibilité pour les objets de l’ensemble sélectionné, le masque de visibilité étant produit par association d’un shader personnalisé aux objets de l’ensemble sélectionné le dit shader personnalisé écrivant dans le canal de « stencil buffer » une valeur prédéterminée ;

Utilisation, via un crochet du pipeline dédié, du contenu du canal du stencil buffer pour altérer l’image en la rendant opaque là où la valeur du stencil buffer n’est pas la valeur prédéterminée et transparente ailleurs;

Rendu des objets transparents ;

Pour chaque objet de l’ensemble sélectionné :

Calcul d’un score de visibilité basé sur les valeurs d’alpha des point centraux des zones à tester.

[0020] Outre les caractéristiques qui viennent d’être évoquées dans le paragraphe précédent, le procédé selon un aspect de l’invention peut présenter une ou plusieurs caractéristiques complémentaires parmi les suivantes, considérées individuellement ou selon toutes les combinaisons techniquement possibles :

La valeur prédéterminée est différente d’une valeur par défaut utilisée par le pipeline dédié ; Pour un moteur de rendu donnée, le pipeline dédié est le pipeline le moins gourmand en ressource de calcul ;

La fréquence de calcul de la caméra dédiée est inférieure à la fréquence de calcul de la caméra principale ; - On maintient des étapes de calcul d’éclairage dans le pipeline dédié pour mesurer une déviance de couleur par rapport à un éclairage ambiant de la scène, ladite déviance étant utilisée pour modifier le score de visibilité.

[0021] L’invention et ses différentes applications seront mieux comprises à la lecture de la description qui suit et à l’examen des figures qui l’accompagnent. BREVE DESCRIPTION DES FIGURES

[0022] Les figures sont présentées à titre indicatif et nullement limitatif de l’invention.

[0023] [Fig. 1 ] montre une illustration simplifiée du fonctionnement d’un moteur de rendu graphique. [0024] [Fig. 2] une illustration d’étapes du procédé selon l’invention.

[0025] [Fig. 3] une illustration d’une scène rendue par la caméra principale.

[0026] [Fig. 4] une image à la fin du rendu des objets opaques par le pipeline dédié.

[0027] [Fig. 5] un état du stencil buffer correspondant à la fin du rendu des objets opaques. [0028] [Fig. 6] le résultat de l’utilisation du stencil buffer selon l’invention.

[0029] [Fig. 7] des zones à tester dans un objet sélectionné en sortie du pipeline dédié.

DESCRIPTION DETAILLEE

[0030] Dans cette description, les actions de traitement sont réalisées par des microprocesseurs qui utilisent de la mémoire. Ces microprocesseurs sont soit des microprocesseurs généralistes aussi appelés CPU, soit des microprocesseurs graphiques aussi appelés GPU.

[0031] Dans la pratique l’invention est mise en oeuvre par un ordinateur, une console de jeu, un téléphone intelligent et plus généralement tout dispositif capable de mettre en oeuvre un moteur de rendu graphique. [0032] Les figures sont présentées à titre indicatif et nullement limitatif de l’invention.

[0033] Sauf précision contraire, un même élément apparaissant sur des figures différentes présente une référence unique.

[0034] [Fig. 2] montre une étape 200 de déclaration d’une caméra dédiée. Cette caméra est un clone de la caméra principale. On utilise des interfaces de programmation du moteur de rendu pour déclarer et instancier cette caméra dédiée.

[0035] [Fig. 2] montre une étape 210 de sélection d’au moins un objet parmi une pluralité d’objet de la scène. On rappelle qu’une scène est composé d’une pluralité d’objets 3D, chaque objet ayant un identifiant. L’étape de sélection produit, dans une zone mémoire d’un dispositif mettant en oeuvre le procédé selon l’invention, une liste d’identifiants comportant au moins un identifiant.

[0036] [Fig. 2] montre une étape 220 de découpage des objets sélectionnés en zone à tester.

[0037] [Fig. 2] montre une étape 230 dans laquelle on associe à chaque objet sélectionné un nuanceur personnalisé. Un nuanceur est plus communément désigné par la terminologie anglaise shader. Ce shader personnalisé est configuré pour écrire dans un canal du stencil une valeur prédéterminée. Cette valeur prédéterminée est différente de la valeur écrite par défaut par le pipeline graphique associé à la caméra dédié. Il est ainsi possible de conserver une empreinte du rendu des objets sélectionnés.

[0038] [Fig. 2] montre une étape 240 d’utilisation du stencil buffer. Cette étape est mise en oeuvre en utilisant des crochets, aussi appelé hooks, exposé par le pipeline graphique. Le crochet utilisé dans cette étape correspond à la fin du traitement des objets opaques de la scène. Dans cette étape on utilise le contenu du canal du stencil buffer pour altérer l’image. On rend l’image opaque là où la valeur du stencil buffer n’est pas la valeur prédéterminée utilisée dans le shader personnalisé et transparente ailleurs.

[0039] [Fig 3] montre un rendu d’une scène comportant 3 objets :

Un premier objet 310 en arrière-plan. Le premier objet est un objet sélectionné ; Un deuxième objet 320 en plan intermédiaire qui recouvre partiellement le premier objet ;

Un troisième objet 330 au premier plan, le troisième objet :

Est transparent, - Recouvre le deuxième objet,

Recouvre partiellement le premier objet.

[0040] [Fig. 4] montre un viewport 300 de la caméra secondaire, dans lequel des objets opaques d’une scène ont été rendus.

[0041] [Fig. 5] montre l’état du stencil buffer correspondant à la [Fig. 4] [Fig. 5] montre que le stencil buffer comporte une empreinte de la partie visible du premier objet de la scène.

[0042] [Fig. 6] montre une étape 250 de rendu des objets transparents. [Fig. 6] montre le premier objet découpé par le deuxième objet et divisé en deux zones par le troisième objet. [0043] A la fin de l’étape 250 de rendu des objets transparents le pipeline dédié a terminé son travail de rendu et une image rendue est disponible.

[0044] [Fig. 6] montre l’état du viewport de la caméra dédiée après le rendu des objets transparents.

[0045] [Fig. 2] montre une étape 260 de calcul du score. Pour un objet ce calcul se fait de la façon suivante :

Pour chaque zone à tester, on détermine les coordonnées du centre de la zone à tester dans l’image rendue ;

Pour chaque centre calculé on lit la valeur de l’alpha du pixel correspondant et on utilise la règle suivante : - Si alpha = 0. L’objet est totalement visible à ce point ;

Si alpha = 1. L’objet n’est pas visible à ce point ;

Si alpha est compris entre 0 et 1 , l’objet est partiellement visible à ce point. [0046] Contrairement à un Raycast standard, on a, avec l’invention, pour chaque pixel testé une valeur comprise entre 0 et 1. Cela est illustré par la [Fig. 7]

[0047] La visibilité de l’objet peut être donc déterminée de manière précise en agrégeant les mesures d’alpha. Une simple somme suffit : si la somme vaut 0 alors l’objet est totalement visible. Si la somme vaut le nombre de zones à tester alors l’objet est totalement invisible.

[0048] Il est aussi possible d’utiliser les couches rgb du pixel testé pour déterminer la déviance de couleur par rapport à la couleur originale. Cela permet d’affiner le score de visibilité. Pour arriver à ce résultat il suffit de conserver les étapes de Lightning (autrement dit d’éclairage) dans le pipeline dédié de rendu, pour déterminer la déviance de couleur par rapport à l’éclairage ambiant de la scène

[0049] Dans une variante préférée la note de visibilité est intégrée sur une période de temps prédéterminé. Cette période dépend de la nature de l’objet. L’objet peut par exemple comporter du texte ou des symboles. La période est alors le temps suffisant pour permettre de lire le texte ou les symboles. Dans une autre variante cette période est comprise entre 0.5 secondes et 3 secondes.

[0050] Dans l’invention le pipeline dédiée traite d’abord les objets opaques, puis les objets transparents. Dans une variante préférée, le pipeline dédié est le plus simple proposé par le moteur de rendu qui respecte la condition précédente. Cela permet de limiter les ressources de traitement consommées par l’invention.