Procédé mis en œuvre par ordinateur pour la création de contenus comprenant des images de synthèse

La présente invention se rapporte à un procédé mis en oeuvre par ordinateur pour la création de manière collaborative et dans un processus, aussi appelé pipeline, unifié et temps-réel, de séquences animées et sonores numériques comprenant des images de synthèse.

Dans le domaine de la création audio-visuelle, on oppose généralement le terme 2D, associé à l'animation traditionnelle par exemple réalisée par une succession d’images dessinées à la main ou à la vidéo, au terme 3D, correspondant à la création de séquences animées ou d'images fixes dont la création est le résultat de calculs généralement réalisés par un ordinateur. C'est pour cette raison que les images produites en 3D sont qualifiées d'images de synthèse.

Les séquences animées 3D peuvent être de deux types : précalculées ou temps-réel. Dans le cas des séquences précalculées les animations 3D sont calculées à l'avance et les contenus créés sont ensuite sauvegardés dans un fichier vidéo ou sous la forme d'une séquence d'images numériques. Une fois calculées, le contenu des images ne peut plus être modifié. Les séquences temps-réel sont calculées au moment de l’affichage, généralement par des processeurs dédiés dits GPU ou cartes graphiques spécialement conçus pour calculer des images de synthèse à très grande vitesse

Il est bien connu dans l’état de la technique qu’une fréquence de génération de ces séquences animées 2D ou 3D, précalculées ou temps-réel, est généralement d’au moins 24 images par seconde quelle que soit la taille de l’image, le nombre de sorties et la qualité sonore générée.

La réalisation de contenus en image de synthèse répond pour l’homme du métier à un ensemble de tâches distinctes dont les étapes principales sont, par ordre de réalisation habituelle, en référence à la figure 1 :

E1. Une étape de création de modèles 3D (un humain, un animal, un objet éventuellement articulé), étape aussi appelée modélisation ou en anglais surfacing. L’apparence du modèle comme la couleur de sa surface ou un aspect mat ou brillant par exemple, est aussi définie au cours de cette étape. Ces modèles sont appelés des assets.

E2. Une étape dite de layout (ce terme n’ayant pas d’équivalent francophone pour l’homme du métier). Au cours de cette étape on assemble et arrange les objets créés à l’étape précédente pour former des ensembles plus complexes. Autrement dit, on met en place des « scènes », au sens cinématographique, comprenant par exemple des décors et des personnages positionnés pour répondre aux besoins de l'histoire et à des considérations esthétiques. Plusieurs angles de vue sont sélectionnés pour filmer ces décors virtuels et les personnages 3D éventuels qui s’y trouveront.

E3. Une étape dite d’animation. Elle consiste à animer les éléments mis en place lors du layout au moyen de différentes méthodes.

E4. Une étape d’éclairage. Pour être visibles, les éléments composants les scènes issues du layout, filmés sous les angles de vue choisis à l’étape du layout, doivent être éclairés.

E5. Une étape de montage, au cours de laquelle les différentes scènes virtuelles filmées et animées depuis les différents angles de vue sont mises bout à bout pour former ce qui constitue le film.

Un procédé habituel de réalisation de contenu d’animation en images de synthèse, appelé pipeline de production, comprend aussi généralement, avant l’étape de montage E5, une étape de rendu, au cours de laquelle on applique des effets de matière et de texture aux éléments des scènes représentées afin de leur donner un aspect visuel conforment aux critères artistiques voulus.

Il existe d’autres étapes que nous n’avons pas décrites ici car elles ne sont pas strictement nécessaires à la réalisation d’un contenu d’animation linéaire. On peut citer par exemple l'étape dite des effets qui permet de créer des effets d’explosion, de fumée, de liquide, de feu, ou de simuler le mouvement des vêtements, etc., l’étape du compositing qui consiste à mélanger plusieurs sources d’image pour n’en former qu’une, et celle de l’étalonnage ( grading en anglais) qui consiste à modifier l’équilibre des couleurs d’une image pour en modifier son apparence. Par ailleurs, la réalisation d’un contenu narratif linéaire en animation est souvent précédée de la description de ce contenu sous une forme écrite (communément référencée sous le terme de script ou de scénario ou screenplay en anglais) et d’un storyboard, qui est une représentation de ce script sous la forme d’une succession d’images dessinées.

L’ensemble de ces étapes de travail constitue un procédé de production communément appelée pipeline de production.

Un tel pipeline de production est réalisé de manière séquentielle, linéaire et fragmentée. Or, chaque étape de ce pipeline requiert des outils informatiques, aussi appelés solutions logicielles, spécialisés et généralement indépendants les uns des autres ; de plus de tels projets impliquent généralement un grand nombre de personnes travaillant simultanément sur tous ces outils disparates.

En outre, les pipelines de production connus pour la réalisation de projet d’animation 3D professionnels pour des animations linéaires précalculées, tel qu’un film d’animation, ne sont généralement pas adaptés à la conception de contenus d'animation temps-réel linéaires ou nécessitant peu d'interactions pour des médias comme la réalité augmentée ou la réalité virtuelle.

Le processus de production de contenus d’animation (auquel on se référera plus généralement comme étant une animation 3D) est avant tout un processus créatif. Un tel processus créatif requiert qu’il soit possible par des itérations successives de tester, préférentiellement rapidement et souvent, des idées sur tous les aspects du médium.

Par exemple produire un contenu d’animation 3D linéaire, requiert qu’il soit possible à n’importe quel moment du processus de création, de faire des modifications aux étapes de la modélisation, du layout, de l’animation, de l’éclairage ou du montage car les résultats produits à chacune de ces étapes ont une incidence sur le résultat final ; autrement dit sur le contenu produit en fin de chaîne.

Un projet de long métrage d’animation 3D pour le cinéma par exemple est le résultat de dizaines voire de centaines de milliers de modifications faites par l’ensemble des personnes contribuant à sa réalisation.

Certaines de ces modifications sont mineures, dites micro-modifications, comme par exemple des ajustements de petite amplitude sur la couleur d’un objet, sur la longueur d’un plan dans un montage, ou majeures, dites macro modifications, comme par exemple décider de modifier l’apparence du personnage principal de l’histoire.

Les macro-modifications sont moins fréquentes que les micro- modifications mais elles sont plus visibles et ont un impact plus important sur le processus de création. Or, au regard de ces critères, les pipelines de production de l’art antérieur posent de nombreux problèmes parmi lesquels :

1. Parce qu’ils sont linéaires, une modification réalisée en amont de la chaîne de production, requiert de passer par toutes les étapes qui se trouvent en aval de l’étape où la modification est faite, avant de pouvoir être jugée dans le contexte du contenu final (en sortie de l’étape du montage). Le processus est similaire à celui d’un effet de domino ou de cascade : une modification en amont déclenche toute une série d’événements en aval jusqu’à atteindre la dernière étape de la chaîne. 2. Les outils utilisés aux différentes étapes de la production ne produisant pas de résultats en temps-réel et ne communiquant pas les uns avec les autres (de par la nature fragmentée du pipeline de production), les modifications apportées provoquent des pertes importantes de temps de production. Il n’est pas rare qu’une modification prenne plusieurs minutes, plusieurs heures, voire parfois plusieurs jours avant qu’elle ne puisse produire un résultat visible, notamment en fonction de sa position dans la chaîne de production.

Aussi un des problèmes bien connus est d'optimiser le processus de création de contenus d’animation 3D, principalement linéaires, qu’ils soient temps-réel ou précalculés, en assurant notamment qu’un grand nombre de personnes puissent travailler simultanément sur la production de ces contenus.

Pour résoudre les problème énoncés ci-dessus, nous proposons un procédé de pipeline unifié collaboratif et temps-réel mis en oeuvre par ordinateur pour la création de manière collaborative, de contenus d’animation, caractérisé en ce qu’il comprend d'une part des étapes de production et de diffusion de contenus d’animation en images de synthèse destinées à être mises en oeuvre par une pluralité de terminaux en coopération avec un serveur central, et d'autre part des étapes de gestion de ces contenus d’animation adaptées pour permettre au serveur central de centraliser et gérer l’ensemble des données produites au stade des étapes de production ;

lesdites étapes de production dudit procédé unifié temps-réel comprenant :

- une étape de création d’un projet de contenu d’animation ;

- une étape de création d’une ou plusieurs scènes 3D et d’une ou plusieurs séquences 3D dans ledit projet créé ;

- une étape d’ouverture et d’édition d’au moins une scène 3D ;

- une étape d’ouverture et d’édition d’au moins une séquence 3D créée pour monter ledit contenu en images de synthèse ;

- des étapes de diffusion du contenu d’animation ;

lesdites étapes de gestion comprenant :

- une étape de gestion d’un historique de production, adaptée pour assurer la transmission et l’enregistrement du résultat de la mise en oeuvre d’étapes de production par un terminal au serveur central ; - une étape de mise à jour du projet stocké sur ledit serveur en fonction desdits résultats de la mise en oeuvre d’étapes de production par un terminal transmis lors de l’étape de gestion de l’historique de production ;

- une étape de détection de conflits adaptée pour être mise en oeuvre sur le serveur de sorte à détecter lorsqu’au moins deux étapes de production ont créé, modifié ou supprimé, directement ou via une autre donnée liée, simultanément au moins une même donnée stockée sur le serveur central ;

- une étape de résolution de conflits, lorsqu’un conflit est détecté à l’étape précédente, apte à déterminer la ou les créations, modifications ou suppressions à appliquer à ladite au moins une donnée pour laquelle un conflit est détecté.

Ainsi, on obtient un procédé simple, unifié, collaboratif et connecté apte à gérer au sein d’un même applicatif la création et la diffusion de contenus d’animation comprenant des images de synthèse, adapté aux rendus précalculés ou temps-réel.

Avantageusement et de manière non limitative, le procédé comprend une étape de synchronisation temps-réel du projet entre le serveur central et lesdits terminaux de sorte que chaque terminal mettant en oeuvre les étapes de production du procédé reçoive tout ou partie des données du projet à jour en fonction de toutes les modifications et créations apportées par l’ensemble des terminaux et du serveur, ladite étape de synchronisation étant adaptée pour être mise en oeuvre par le serveur lors d’un fonctionnement en mode de travail collaboratif et/ou par lesdits terminaux lorsqu'ils se connectent au serveur. Ainsi, on peut s’assurer que toute personne utilisatrice travaillant depuis un terminal distant du serveur possède en permanence la dernière version du projet de contenu en cours, et ce même lorsqu’un grand nombre d’utilisateurs travaillent en simultané sur le projet.

Avantageusement et de manière non limitative, le procédé comprend pour lesdites étapes de mise-à-jour et de synchronisation du projet entre le serveur central et lesdits terminaux une pluralité de modules de synchronisation des données, ladite pluralité de modules comprenant :

- un module temps-réel de mise à jour adapté pour mettre en oeuvre une fonction d'encodage cryptographique générant une clef de hachage en fonction desdites données du projet, ledit module temps-réel de mise à jour étant adapté pour déterminer si des données du projet importées doivent être enregistrées par lesdits terminaux et le serveur ;

- un module temps-réel d’optimisation apte à détecter des changements d’états transitoires de données du projet, et étant adapté pour compresser ladite liste de l’historique de création des projets de sorte à réduire la quantité de données transférées et stockées par lesdits terminaux et le serveur ;

- un module temps-réel de contrôle exploitant ladite clef de hachage de sorte à contrôler l’intégrité des données transmises entre lesdits terminaux et le serveur,

- un module temps-réel d’apprentissage, apte à analyser les données de l’historique de création des projets, et à définir un ordre de priorité, selon lequel ledit serveur transmet et met à jour, les données auxdits terminaux ;

- un module temps-réel de versionnage, apte à préserver l’historique de création des projets sous la forme d’une série de sauvegardes d’état total du projet et de révisions intermédiaires relatives à ces états ; ladite fréquence des sauvegardes des états total étant fonction de données d’apprentissage dudit module temps-réel d’apprentissage ;

- un module temps-réel de marquage apte à autoriser un utilisateur d’un terminal à marquer par au moins une balise une étape clef de l'évolution du projet, ledit module de marquage permettant de rétablir ledit projet à son état à l’instant de marquage.

Ainsi, les étapes de mises à jour et de synchronisation sont fiables, robustes et rapides.

Avantageusement et de manière non limitative, le procédé comprend en outre des étapes de gestion de contrôle d’accès pour interdire ou autoriser la mise en oeuvre de tout ou partie des étapes de production et de gestion à un terminal connecté au serveur. Ainsi, on peut segmenter les droits de mise en oeuvre du procédé afin de limiter les interactions lors d’un travail collaboratif impliquant de nombreuses personnes. Le contrôle d’accès permet en outre de limiter les risques de modification ou de suppression de contenu par exemple accidentelle.

Avantageusement et de manière non limitative, l’étape de résolution de conflits comprend l’exclusion du projet d’un premier résultat de la mise en oeuvre d’étapes de production par un premier terminal, lorsqu’un deuxième résultat de la mise en oeuvre d’étapes de production par un deuxième terminal a généré la détection d’un conflit, l’événement antérieur étant exclu si l’un des critères suivants est rempli :

- le premier résultat supprime un objet qui a été supprimé, modifié, ajouté ou référencé par le second résultat ;

- le premier résultat ajoute un objet qui a été supprimé, ajouté ou modifié par le second résultat ;

- le premier résultat modifie une propriété d’un objet qui a été supprimé par le second résultat ;

- le premier résultat modifie une propriété unique d’un objet qui a aussi été modifié par le second résultat ;

- le premier résultat ajoute une référence à un objet qui a été supprimé par le second résultat ; - le premier résultat ajoute une référence à un objet ou une valeur pour une propriété d’un objet pouvant avoir plusieurs valeurs, qui a été ajoutée, supprimée ou changée par le second résultat ;

- le premier résultat supprime une référence à un objet ou une valeur d’un objet pouvant recevoir plusieurs valeurs pour la même propriété ayant été ajoutée, supprimée ou changée par le second résultat ;

- le premier résultat déplace une référence à un objet ou une valeur d’une propriété pouvant recevoir plusieurs valeurs ayant été ajoutée, supprimée ou déplacée dans une même propriété par le second résultat.

Avantageusement et de manière non limitative, le procédé comprend un module d’apprentissage automatique adapté pour optimiser la séquence de chargement des données dans la mémoire desdits terminaux afin de restituer en image animées et sonore le contenu du projet en temps-réel sur lesdits terminaux, en fonction des données de l’historique de création du projet, des données du projet et de méta-données générées par lesdits terminaux. Ainsi, on peut optimiser la bande passante utilisée entre les terminaux et le serveur ainsi que la mémoire occupée et le temps de calcul nécessaire tant côté terminal que côté serveur.

Avantageusement et de manière non limitative, lesdites étapes de production et de diffusion du contenu d’animation, comprennent une étape d’affichage en temps-réel dudit contenu d’animation sur un dispositif de réalité augmentée, tel qu’un smartphone ou une tablette, connecté audit serveur.

En particulier le procédé met en oeuvre une étape de création d’une caméra virtuelle adaptée pour un dispositif de réalité augmentée, ladite étape de création d’une caméra virtuelle étant mise en oeuvre après ladite étape d’ouverture et d’édition d’au moins une scène 3D.

L’invention concerne aussi un dispositif serveur comprenant une interface réseau, une mémoire de stockage et un processeur pour mettre en oeuvre au moins les étapes de gestion et/ou les étapes de production et de diffusion du contenu d’animation du procédé tel que décrit précédemment.

L’invention concerne aussi un ensemble de réalité augmentée, comprenant un dispositif serveur tel que décrit précédemment et un dispositif de réalité augmentée, tel qu’un smartphone ou une tablette, ledit dispositif serveur mettant en oeuvre les étapes de production et de de diffusion du contenu d’animation du procédé tel que décrit précédemment.

L’invention concerne aussi un terminal informatique pour commander une interface homme-machine adaptée pour exécuter et/ou réaliser au moins les étapes de production du procédé décrit précédemment, et comprenant une interface réseau pour communiquer avec ledit dispositif serveur décrit précédemment.

L’invention concerne aussi un système informatique comprenant un dispositif serveur tel que décrit précédemment et un ou plusieurs terminaux informatiques tels que décrits précédemment.

L’invention concerne aussi un support de stockage lisible par un ordinateur, par exemple un disque dur, un support de stockage de masse, un disque optique, ou tout autre moyen adapté, ayant enregistré sur lui des instructions qui commandent un dispositif serveur et/ou un terminal informatique pour exécuter un procédé tel que décrit précédemment.

D’autres particularités et avantages de l’invention ressortiront à la lecture de la description faite ci-après d’un mode de réalisation particulier de l’invention, donné à titre indicatif mais non limitatif, en référence aux dessins annexés sur lesquels :

- les figures 1 et 2 sont des vues schématiques d’un pipeline de production de l’art antérieur ;

- la figure 3 est une vue schématique des interactions entre des étapes de production d’un procédé selon un mode de réalisation de l’invention ;

- la figure 4 est une représentation graphique d’un projet de contenu d’animation en images de synthèse ;

- la figure 5 est une représentation d’une scène 3D connue de l’art antérieur représentée dans sa forme la plus classique par une série d’objets ou de modèles 3D, dits assets, comprenant chacun des propriétés permettant d’en modifier l’apparence ; - la figure 6 est une vue schématique de l’organisation des données d’un projet de contenu d’un procédé selon un mode de réalisation de l’invention ;

- les figures 7 à 16 sont des vues simplifiées d’interfaces utilisateur de la mise en oeuvre du procédé sur un ordinateur selon un mode de réalisation de l’invention ;

- la figure 17 est une vue schématique d’une étape de synchronisation selon un mode de réalisation de l’invention ;

- la figure 18 est une vue schématique d’un groupe d’étapes de diffusion et de distribution selon un mode de réalisation du procédé ;

- la figure 19 est une vue schématique d’un groupe d’étapes de diffusion et de distribution selon un autre mode de réalisation du procédé.

L’invention porte sur la conception d’un procédé dédié à la création, la production, la distribution et la diffusion de contenus d’animation linéaires ou plus généralement la création et la distribution de séquences animées et sonores en utilisant une variété de sources sonores et graphiques qui peuvent être combinées ensemble comme par exemple, des images de synthèse, aussi appelé contenu 3D, principalement, mais aussi des images numériques et des vidéos, dit contenu 2D, dans un processus, ou pipeline, qui soit à la fois unifié, temps-réel, collaboratif et connecté à d’autres méthodes de création de contenus d’animation temps-réel, notamment pour de la réalité augmentée.

Les séquences animées et sonores générées par cette invention peuvent être soit précalculées et sauvées dans des fichiers vidéo par exemple, soit calculées à la volée ce qui permet de les exploiter sur des systèmes de type réalité augmentée ou virtuelle ou n’importe quel autre système d’affichage ou de diffusion (comme par exemple le streaming) existant ou à venir pour lequel des séquences sonores et animées en images de synthèse doivent être calculées à la volée, en temps-réel (visualisation 3D temps-réel).

Le procédé mis en oeuvre par ordinateur selon l’invention comprend une pluralité d’étapes de production conduisant à la fabrication de contenus, pouvant être mises en oeuvre parallèlement et indépendamment les unes des autres. Le procédé selon l’invention est aussi appelé Pipeline Unifié Collaboratif ou en anglais Collaborative Unified Pipeline, auquel nous ferons référence dans la suite de ce document par l’acronyme CUP.

Dans la suite de la description on se référera à l’utilisateur du procédé comme toute personne, ou tout groupe de personnes, agissant sur le procédé mis en oeuvre par ordinateur selon l’invention, par l’intermédiaire d’un ordinateur ou de tout dispositif apte à communiquer avec l’ordinateur mettant en oeuvre tout ou partie du procédé.

Les différentes étapes de production, que l’on peut aussi appeler fonctions, sont décrites dans un premier temps séparément les unes des autres, puis présentées dans le cadre d'un mode de réalisation détaillé.

Le procédé selon l’invention comprend deux groupes d’étapes de production principaux : des étapes de création et d’édition et des étapes de diffusion.

Le premier groupe d’étapes de production est généralement mis en oeuvre sur les terminaux utilisateurs, tandis que le deuxième groupe d’étapes est dans ce mode de réalisation mis en oeuvre sur le serveur.

Le procédé comprend en outre un troisième groupe d’étapes appelé étapes de gestion, ces étapes étant conjointement mises en oeuvre par les terminaux et le serveur, ces étapes comprenant notamment les étapes d’historique et de résolution de conflit, qui seront décrites plus loin.

Le premier groupe d’étapes de production dites fonctions de création et d’édition comprend l’ensemble des étapes E1 -E5 de la production d’un contenu d’animation 3D, en référence à la figure 1 , depuis l’étape de la modélisation E1 jusqu’à l’étape finale du montage E5 telles que nous les avons décrites dans l’état antérieur de la technique.

Aussi le procédé selon l’invention mis en oeuvre par ordinateur permet de créer un contenu d’animation 3D temps-réel du début jusqu’à la fin, ce premier groupe d’étapes comprenant cinq étapes :

1. Créer ou ouvrir un projet de contenu d’animation ;

2. Création de nouvelles scènes 3D qui peuvent cependant contenir une mixité d’autres sources (comme des images numériques, des vidéos, etc.), et création de nouvelles séquences ; Ouverture et édition de scènes 3D créées à l’étape précédente. Dans cette étape l’utilisateur du procédé peut modéliser sur place ou importer des modèles 3D créés avec d’autres solutions, choisir des angles de vue (par l’intermédiaire de caméras virtuelles qui sont placées dans la scène), ajouter des lumières, et animer tous les objets de la scène (les modèles, les caméras, les sources de lumière, etc.) et toutes les propriétés de ces objets (comme par exemple la couleur d’un objet 3D). Une scène peut également contenir plusieurs versions de l’animation (ou take d’animation dans la terminologie de l’homme du métier) ;

Ouverture et édition des séquences créées à l’étape 1.2. Dans cette étape, l’utilisateur du procédé peut éditer le contenu d’une séquence. Le processus consiste à mettre un ensemble de plans bout à bout comme dans n’importe quelle solution de montage vidéo. À la différence des logiciels de montage vidéo, l’invention utilise en guise de plan non pas des vidéos mais les scènes 3D créées à l’étape précédente 1.3. Pour chaque scène utilisée dans le montage de la séquence, l’utilisateur doit au minimum spécifier la caméra ou l’angle de vue depuis lequel cette scène sera calculée.

Comme pour tout outil de montage cependant, l’ordre et la longueur des plans qui composent le montage peuvent être également changés. En résumé, un plan dans ce système est défini au minimum par une scène 3D, la version de l’animation qui doit être utilisée pour cette scène quand elle jouée, un angle de vue depuis lequel cette scène est filmée quand elle est jouée dans le montage, et les informations de montage habituelles comme la position du plan dans le montage, sa durée, et son point d’entrée et de sortie.

4.1. Il est possible de créer une séquence à partir d’un enchaînement de plans utilisant une seule et même scène 3D filmée depuis des angles de vue différents.

4.2. Il est également possible d’utiliser plusieurs scènes 3D dans la même séquence. La possibilité de mixer différentes scènes dans une seule et même séquence est une caractéristique de l’invention ; 5. Jouer le contenu en jouant les séquences créées et éditées à l’étape 4 précédente.

5.1 . Dans un premier mode de réalisation de l’invention, le contenu du projet est calculé en 2D pour être projeté sur l’écran de l’ordinateur sur lequel le système est exécuté (il peut également s’agir de l’écran d’une tablette ou d’un smartphone ou de n’importe quel dispositif de projection connecté à l’ordinateur).

5.2. Dans un deuxième mode de réalisation de l’invention, non exclusif du premier, ces contenus sont calculés pour être diffusés sur des systèmes de réalité virtuelle et augmentée.

5.3. Dans une troisième mode de réalisation de l’invention qui est décrit en détail dans la suite du document, le contenu peut être calculé à la volée sur un ou plusieurs processeurs et le résultat, la sortie vidéo et audio, diffusé (ou streamé selon un néologisme issu de l’anglais fréquemment employé par l’homme du métier) vers un autre dispositif électronique/informatique.

Notons que les scènes, les séquences, et le contenu finalisé constitué par l’ensemble des séquences, sont joués en temps-réel et peuvent être calculés comme nous venons de l’indiquer pour s’adapter aux contraintes de n’importe quel système d’affichage que ce soit un écran d’ordinateur, de smartphone ou de tablette, un système de réalité virtuelle ou augmentée, ou tout autre dispositif adapté.

Comme il s’agit de scènes 3D filmées depuis un angle de vue choisi par l’utilisateur du système, celles-ci sont calculées à la volée. Le fait que les images ne soient pas précalculées comme dans le cas des vidéos est un élément clef de l’invention, puisque cela permet à l’utilisateur du système de modifier n’importe quel élément du projet à n’importe quelle étape de la fabrication et de la diffusion du contenu, par exemple la position d’un objet dans une scène, la position d’une caméra, la position et l’intensité d’une source de lumière, l’animation d’un personnage, le montage d’une séquence, en utilisant n’importe quel système d’affichage et de pouvoir voir le résultat de ses changements en temps-réel. Toutes ces étapes peuvent être exécutées par le seul procédé mis en oeuvre par ordinateur selon l’invention qui, associé à un système de succession d’affichage d’écrans d’interface homme-machine, permet à l’utilisateur de passer d’une étape à une autre de manière fluide.

Autrement dit, ce système d’écran ou de navigation a été conçu pour réunir l'ensemble des étapes de la fabrication d’un contenu d'animation 3D dans un seul et même procédé, autrement dit dans une seule et même solution, afin de permettre à l’utilisateur de travailler sur n’importe quel aspect du film (le layout, le montage, l’éclairage, l’animation, etc.) en parallèle et avec un retour temps-réel (prochain point).

En effet, le procédé selon l’invention est un procédé temps-réel. Pour ce faire, le procédé s’appuie sur deux éléments :

La solution du pipeline unifié décrite ci-dessus (1 ) tire parti des capacités des processeurs graphiques (GPU) qui ont été conçus pour accélérer des tâches comme le calcul des images de synthèse ou le calcul des déformations d’objets 3D animés dont le traitement informatique se prête bien à des architectures de calcul de type massivement parallèle. L’usage de processeurs graphiques (GPU) n’exclut pas dans la solution l’usage d’unités centrales de traitement (CPU). Les ressources de traitement informatique requises par la solution sont bien supérieures à celles exigées par une solution logicielle conçue pour l’édition de texte (la solution rentre dans la catégorie nommée « data-intensive computing » en anglais). Il est donc préférable de pouvoir exploiter toutes les ressources disponibles du dispositif informatique/électronique sur lequel la solution est exécutée, ce qui implique de combiner les capacités de calcul du ou des CPU et GPU disponibles sur le dispositif informatique où la solution est mise en pratique.

Le procédé selon l’invention est adapté de sorte à permettre un fonctionnement de mise en oeuvre collaboratif.

À cet effet le procédé selon l’invention permet à plusieurs utilisateurs de travailler en même temps sur le même contenu/projet/film d’animation 3D et de voir en temps-réel les changements réalisés par l’ensemble de ces utilisateurs.

Le procédé permet donc de faire du travail collaboratif simultané à distance. Aussi, le procédé est partiellement mis en oeuvre sur un serveur qui centralise les données, tandis qu’une autre partie du procédé est mise en oeuvre sur des terminaux, par exemple des ordinateurs de bureau, des tablettes ou des smartphones. La partie centralisée du procédé étant commune pour la mise en oeuvre du procédé par l’ensemble des terminaux d’un même projet de contenu d’animation 3D.

Dans une version préférée de l’invention, les utilisateurs ont accès aux données du projet grâce à une solution logicielle (ci-après nommé application client) exécutée sur leur terminal, autrement dit sur leur dispositif informatique dont l’utilisateur se sert pour travailler.

Le terminal est une unité de traitement informatique complète qui dispose d’une ou de plusieurs unités centrales et graphiques de traitement ainsi que d’un ou de plusieurs dispositifs de sortie vidéo et audio qui permettent d’afficher des images et de jouer des sons sur une variété de dispositifs (écran d’ordinateur, casque de réalité virtuelle, haut-parleur, casque audio, etc.).

Au démarrage de l’application, le programme informatique (application client) exécuté sur le terminal, se connecte à une application distante (ci-après nommé application serveur), qui est elle-même exécutée sur le serveur du réseau auquel le terminal est connecté (ci-après nommé serveur S).

Pour permettre aux applications client et serveur de traiter les données qu’ils envoient et qu’ils reçoivent, les données du projet sont encapsulées selon un protocole spécifique à l’invention.

Pour le transit des données encapsulées sur le réseau, n’importe quel protocole standard peut être utilisé (comme par exemple TCP/IP qui est le protocole utilisé pour les échanges de données sur Internet). Dans une version préférée de l’invention, le terminal et le serveur forment un réseau local (nommé LAN for Local Area Network en anglais).

Dans une autre version de l’invention, le terminal et le serveur appartiennent à des réseaux différents mais peuvent néanmoins communiquer grâce à une connexion de type Internet par exemple. Ils forment dans ce cas un réseau dit étendu ou WAN (pour Wide Area Network en anglais). Une session de travail est créée dès lors qu’au moins un client est connecté au serveur ; le nombre d’applications client se connectant au serveur dans une session de travail n’a pas de limite supérieure.

Cette division permet à l’application client Ci d’envoyer à l’application serveur toutes les modifications faites à un projet P depuis le terminal T 1.

Quand elle reçoit une modification, l’application serveur S exécute deux tâches : 1 ) elle applique cette modification à sa propre version du projet 2) elle diffuse cette modification à l’ensemble des clients avec lesquels elle partage une connexion C2, C3, ... , CN à l’exception du client d’où provient la modification, ce qui permet à ces applications client de l’appliquer à leur propre version du projet.

Toutes les versions du projet, que ce soit celles maintenues par les différentes applications client Ci , C2, C3,..., CN OU celle maintenue par l’application serveur S sont alors à jour ou synchronisées.

Tous les utilisateurs du procédé qui sont distants les uns des autres et travaillent sur des terminaux différents ont donc en permanence la même“vue" sur le projet P.

Dans la présente description on entend par application client, l’ensemble des étapes du procédé mises en oeuvre sur le terminal de l’utilisateur, par opposition à l’application serveur, correspondant aux étapes mises en oeuvre sur le serveur central S.

Dans cette version de l’invention, il existe autant de copies (locales) du projet P que de terminaux, en plus de la copie du projet se trouvant sur le serveur ; dans une session de travail, toutes ces copies sont identiques.

Lorsqu’une nouvelle application client est lancée et que la version du projet Pc qui se trouve sur le disque du terminal n’est pas la même que la version P _s qui se trouve sur le serveur, l’application serveur procède alors à une étape de synchronisation, au cours de laquelle elle envoie à l’application client toutes les modifications nécessaires à la mise à jour du projet P _s de sorte qu’à la fin du processus, le projet Pc soit identique à Ps.

Le procédé mis en oeuvre comprend en outre une fonction d’historique, une fonction connectée et des fonctions de distribution. La fonction d’historique est mise en oeuvre de sorte que toutes les modifications apportées au projet, par tous les utilisateurs agissant sur leurs terminaux distants, simultanément ou non, depuis sa création sont sauvegardées sur le serveur S, puisqu’à chaque fois qu’un utilisateur effectue une modification, qu’il s’agisse d’un changement mineur ou majeur, cette modification est envoyée au serveur qui l’enregistre localement avant qu’il ne la diffuse à son tour selon le procédé qui vient d’être expliqué. L’utilisateur du procédé n’a donc pas besoin techniquement d’enregistrer les modifications apportées pour préserver ses changements.

Les données de l’historique des changements d’un projet sont sauvegardées dans la mémoire de l’application serveur mais également sur l'espace de stockage, par exemple dans un disque dur, qui lui est associé.

Les données de l’historique peuvent être divisées en deux grandes catégories.

Le premier type de données est représenté par toutes les assets importées ou créées dans le projet par les utilisateurs. Une asset étant un terme anglophone bien connu de l’homme du métier et comprenant notamment des modèles 3D, des images ou textures, des sons, des vidéos, des matériaux, etc.

Dans le procédé selon l’invention, ces données sont décrites comme des blobs (acronyme de Binary Large Objects) pouvant aller de quelques kilooctets à plus d’un millier de mégaoctets (gigaoctet).

Ces blobs sont stockés sur l’espace de stockage du serveur sous la forme de données binaires.

Le deuxième type de données est représenté par des objets auxquels sont rattachés des propriétés.

Un objet est défini comme un ensemble de paires clef-valeur dite propriété. Chaque propriété contient soit une valeur, soit une référence (vers un blob ou un autre objet), soit multivaluée (liste de valeur ou de références).

Ainsi par exemple un objet de type“objet 3D” référence un blob contenant les informations de maillage d’un modèle 3D et des propriétés comme la position de cet objet dans une scène 3D, ainsi que des références vers les matériaux qui lui sont assignés. Un matériau est un autre exemple d’objet qui contient des informations sur l’apparence d’un modèle 3D comme sa couleur ou sa brillance, chacune de ces propriétés pouvant contenir soit une valeur constante soit une référence à des blobs de type texture.

La quantité de mémoire nécessaire au stockage de ce type d’information sur le disque du serveur est relativement négligeable en comparaison de la taille des blobs.

Ces deux types de données diffèrent par leur taille mais également par leur fréquence d’édition. Les données de type blob sont plus rarement ajoutées au projet que les données du second type dont l’édition est par contre beaucoup plus fréquente. Changer la couleur d’un objet par exemple peut se faire dans un processus itératif en temps-réel, entraînant des dizaines voire des centaines de changements par seconde. Ces données peuvent être vues comme représentant l’historique de création du projet.

Voici par exemple une séquence possible de changement de ce type : 1.Créer une nouvelle scène

2. Renommer la scène en“SCN_1”

3. Ajouter un objet 3D importé dans SCN_1

4. Changer la position de cet objet

5. Changer le couleur de cet objet (rouge)

6. Changer la couleur de cet objet (vert)

7. Changer la couleur de cet objet (bleu)

8. Ajouter une texture de couleur à cet objet.

À ce stade de la création du projet, le projet est donc constitué d’un historique d’édition comprenant les étapes 1 -8 et de deux blobs sauvegardés à la fois sur le disque dur du serveur mais également sur celui de l’application client dans ce que nous appelons dans l’invention un blob store (entrepôt de blobs).

Grâce à ces informations il est possible par exemple de mettre à jour le projet d’un second utilisateur U2 se connectant au serveur après que les changements réalisés par U1 aient été enregistrés.

En appliquant les tâches d’édition de l'historique sur le projet du second utilisateur U2, son projet peut être mis à jour. Par exemple :

1. Une nouvelle scène est créée dans la copie locale du projet de U2, 2. Cette scène est renommée SCN_1

3. L’objet 3D est importé depuis le blob store du serveur, sauvegardé dans le blob store de l’application client et ajouté à la scène.

4. La position de l’objet est changée,

5. La couleur de l’objet est changée (rouge),

6. La couleur de l’objet est changée (vert),

7. La couleur de l’objet est changée (bleu),

8. La texture est importée depuis le blob store du serveur, sauvegardée dans le blob store de l’application client et ajoutée à la scène

Le procédé selon l’invention comprend des modules adaptés à la fonction collaborative et à la génération de l'historique de la solution qui en découle. Ces modules sont les suivants :

- gestion des mises à jour : on distingue 1 ) les mises à jour dans la cadre d’une session de travail collaboratif en temps-réel (c’est à dire lorsque plusieurs applications client sont déjà connectées au serveur) et 2) des mises à jour réalisées lorsqu’une application se connecte au serveur après un temps de déconnexion :

1 . Les changements provenant d’une application client sont envoyés à l’application serveur qui les sauve localement (dans un processus décrit ci-dessous) puis les renvoie aux autres applications clients connectées qui exécutent alors ces changements localement. Nous sommes dans une logique de“push” : le serveur pousse les changements.

2. Lorsqu’une application client se connecte au serveur après un temps de déconnexion (ou pour la première fois), elle obtient du serveur un état du projet (via un module décrit ci-dessous) qui lui permet d'établir la liste de tous les blobs ayant été ajoutés à ce projet depuis sa dernière connexion. L’application client est alors en mesure d'établir les blobs manquants en comparant cette liste avec la liste des blobs déjà présents dans son blob store local. Seuls les blobs manquants sont ainsi renvoyés par l’application serveur à l’application client. Nous sommes dans une logique de“pull” : c’est le client qui demande la liste des données dont il a besoin pour se mettre à jour. - gestion des blobs : lorsque des données de type binaires sont ajoutées au projet, il arrive parfois à un utilisateur de les ajouter plusieurs fois de suite. En effet les données binaires sont parfois associées sous forme de « bundles » ou paquet.

À titre d’exemple un bundle B1 comprenant des informations de maillage décrivant un modèle 3D et trois textures (T1 T2 et T3). Dans une étape de travail ultérieure, il se peut que l’utilisateur importe dans le projet une nouvelle version du“bundle” B1 que nous appellerons B2.

Dans ce nouveau bundle B2, seule la texture T3 est différente des fichiers contenus dans le bundle B1. Il est donc relativement inefficace de réimporter dans le projet les informations de maillage de l’objet 3D ainsi que les textures T1 et T2, seul T3 devant faire l’objet d’une mise à jour. L’espace de stockage et l’utilisation de la bande passante nécessaire pour transférer les informations binaires vers le serveur, puis depuis le serveur vers les applications client étant coûteux et limités, il est nécessaire de ne faire transiter et de ne stocker que les données nouvelles.

Le procédé selon l’invention comprend donc un module permettant de calculer sur la base des informations que le blob contient une signature unique. Dans le mode de réalisation principal de l’invention, nous utilisons une clef de type sha ou valeur de hachage, c’est à dire une clef obtenue par une fonction de hachage cryptographique qui génère une empreinte unique à chaque blob du projet.

La fonction qui génère cette valeur de hachage utilise en entrée les données binaires des blobs.

Lorsque le sha pour un blob est calculé, le procédé compare la valeur de hachage obtenue avec celles de chacune des blobs contenus dans le blob store :

• Si le procédé trouve un sha dans le blob store avec la même clef, il en est déduit que le blob existe déjà dans le projet, et qu’il n’est donc pas nécessaire de l’importer.

• Si le sha n’existe pas encore, alors le blob est importé. Selon certains modes de réalisation de l’invention, la capacité du stockage et de trafic internet du côté serveur sont limités. L’utilisateur doit donc faire bon usage de cette capacité de stockage et de bande passante et le système doit par conséquent l’informer de l’impact qu’une opération d’import peut avoir sur l’utilisation du quota d’espace disque et de trafic qui lui est réservé.

Ainsi selon un mode de réalisation particulier du procédé selon l’invention, lorsque l’utilisateur importe des blobs dans le projet, l’application client procède de la sorte :

1.Tous les blobs contenus dans un bundle (le paquet importé) sont lus en mémoire et une valeur de hachage est calculée pour chaque blob du bundle. Si le blob existe dans le blob store il est ignoré. Si le blob n’existe pas, sa taille est ajoutée à la taille totale des données que l’utilisateur souhaite importer.

2. Une fois que tous les blobs d’un bundle ont été analysés selon le processus décrit ci-dessus, on obtient la taille totale des données à importer dans le projet et donc à stocker sur le serveur. Ce chiffre peut ainsi être présenté à l’utilisateur à travers une interface utilisateur. Si l’utilisateur réalise que la quantité de données à importer dépasse la capacité de stockage restante sur le serveur ou qu’elle est trop importante (du fait d’une erreur de manipulation par exemple) il peut décider d’annuler le processus d’import ou d’augmenter la taille de stockage sur le serveur. Dans le cas contraire, il peut confirmer l’import. Si l’import est confirmé par l’utilisateur, les données sont alors transférées vers le serveur et deviennent alors accessibles aux autres utilisateurs du projet.

Ce module d’import en deux étapes a été créé dans le contexte de la mise au point des fonctions collaboratives du procédé selon l’invention et lui est spécifique. - gestion de l’historique de création : dans l’exemple donné ci-dessus, plusieurs étapes de l’historique représentent des modifications successives et potentiellement très rapides, par exemple de l’ordre de quelques millisecondes, d’une propriété du projet ou de l’application client. Par exemple, dans les étapes du projet U2 exposé précédemment, les étapes 5, 6 et 7, les trois changements consécutifs réalisés sur la couleur d’un objet, sont très rapides. Lorsque des modifications sont faites sur une propriété d’un objet de manière rapide, l’intention de l’utilisateur est de passer de l’état Eo dans lequel se trouve cette propriété avant qu’elle ne soit changée, à l’état Ei à l’étape 5, puis à l’état E2 à l’étape 6, puis enfin à l’état E3 à l’étape 7.

Ces modifications étant réalisées en temps-réel (elles ne demandent que quelques millisecondes pour être exécutées), elles n’apparaissent à l’utilisateur que comme une succession continue, ou un flux constant de changements. L’utilisateur arrête le processus itératif à l’état E3. Il est donc possible de considérer que l’intention de l’utilisateur est de passer de Eo à E3 et que les états E1 et E2 ne sont que des états intermédiaires dit transitoires, par lesquels l’utilisateur passe avant de s’arrêter sur l’état final souhaité (E3). Un état est dit transitoire lorsque sa durée de vie est très brève (quelques millisecondes seulement). Le procédé met en oeuvre les étapes suivantes :

• Envoi des révisions en temps-réel par le serveur aux applications client dans une session d'édition collaborative : lorsqu’un utilisateur U1 déplace un objet dans une scène S1 , et qu’un autre utilisateur U2 édite le contenu de la même scène S1 en même temps, U2 voit l’objet se déplacer comme il se déplace dans la scène de l’utilisateur U1. Cela est possible car toutes les révisions qu’elles soient transitoires ou non sont envoyées au serveur qui les renvoie sans attendre à l’ensemble des applications clients utilisées pour éditer le contenu du projet.

• Sauvegarde des révisions dans l’historique de création du projet : lorsque l’utilisateur arrête de modifier une propriété du système (ce qui se produit lorsque la modification suivante concerne une autre propriété du système ou lorsque la propriété concernée arrête d’être modifiée pendant un temps donné), l’application serveur compresse la liste de révisions pour en supprimer les états transitoires et la remplacer par une révision faisant passer la propriété de l’état Eo directement à l’état E3, selon notre exemple, et c’est le résultat de cette compression qui est sauvé dans l’historique de création du projet. En termes généraux, lorsqu’une propriété du système passe d’un état EN à un état EN _+P OÙ P est le nombre d’états transitoires, la partie du procédé en charge de la gestion de l’historique ne préserve pas dans l’historique les P états transitoires mais une seule modification permettant de passer de l’état EN à l’état E N ₊ P directement. Cette méthode de compression, peut être mise en oeuvre par le procédé selon l’invention, soit sur l’application client soit sur l’application serveur.

- gestion par l’application serveur des blobs corrompus : il arrive parfois que certains blobs transmis par le réseau depuis les applications clients vers le serveur n’arrivent au serveur que de façon partielle ou modifiées. Les raisons pour lesquelles un blob peut être corrompu sont multiples : l’application client qui envoie les données s’arrête inopinément, coupure internet, attaque informatique, etc. Pour remédier à ce problème, le procédé met en oeuvre les étapes suivantes :

• Étape 1 : l’application client calcule la valeur de hachage H B d’un blob B et envoie une requête à l’application serveur lui signifiant qu’elle s’apprête à lui envoyer un blob avec une valeur de hachage H B. Immédiatement après, l’application client commence à envoyer les données du blob B en relation avec cette requête.

• Étape 2 : lorsque le serveur cesse de recevoir les données associées au blob B, il considère que les données ont été transmises en intégralité. Il calcule alors la valeur de hachage du blob côté serveur H’B en utilisant le même algorithme que celui utilisé par l’application client. Si la valeur de hachage H’B est égale à celle envoyée par l’application client (H B), le serveur a la garantie que les données du blob B sont complètes et intègres et le processus s’arrête à cette étape. Si la valeur est différente, le serveur passe à l’étape 3.

• Étape 3 : dès que l’application serveur rétablit une connexion avec l’application client, elle lui envoie une requête lui demandant de renvoyer les données pour le blob dont les données sont incomplètes.

L’application serveur envoie la même requête à toutes les applications client partageant le même projet, dans l’hypothèse où l’une des applications client serait en possession du même blob et où l’application client qui a envoyé le blob initialement, serait indisponible. L’application serveur répète l’étape 3 jusqu’à ce qu’il obtienne une copie complète des données du blob. Par ailleurs, le serveur n’envoie pas les données relatives au blob B aux autres applications clients tant que la copie sauvegardée côté serveur n’est pas complète.

Ce module qui reprend la valeur de hachage utilisée pour la gestion du blob store, est important car il garantit la fiabilité de la fonction collaborative du procédé selon l’invention. Par ailleurs le cas précédent décrit le module lorsque les données transitent de l’application client vers l’application serveur, mais le même module est exploité lorsque des données sont transmises (dans le cas d’une mise à jour par exemple) depuis l’application serveur vers n’importe quelle application client.

-“Priorisation" des blobs : selon un mode de réalisation du procédé selon l’invention, les blobs sont transmis depuis l’application serveur vers les applications clients en fonction de critères déterminés par les applications client. Plusieurs cas de figures peuvent se présenter :

• La bande passante de l’application est peu sollicitée : dans ce cas, les blobs sont envoyés par l’application serveur à l’application client dans l’ordre où les blobs sont arrivés sur le serveur donc sans“Policy” ou stratégie particulière.

• Après quelques heures ou quelques jours de travail sur un projet, il n’est pas rare que l’état du projet ait considérablement changé. Un utilisateur qui se reconnecte au projet après un long moment d’absence doit attendre que tous les nouveaux blobs du projet soient transférés depuis le serveur sur son terminal avant de pouvoir reprendre le travail. Il est cependant rare que l’utilisateur ait besoin d’accéder à toutes les nouveaux blobs dès l’ouverture de la session. Le procédé exploite cette observation de la manière suivante : l’application client détecte la partie du projet sur laquelle l’utilisateur travaille en premier comme par exemple une scène particulière du projet et transmet cette information à l’application serveur qui va envoyer les blobs contenus dans cette scène avant les autres. Ce processus de hiérarchisation ou de priorisation envoie les informations“utiles” en premier à l’utilisateur ce qui permet de réduire le temps d’attente et d’améliorer son expérience. Il est particulièrement utile pour les applications client dont la bande passante et l’espace de stockage sont limités comme par exemple l’application client de réalité augmentée sur téléphone portable. Dans l’exemple mentionné ci-dessus la métrique utilisée pour déterminer l’ordre des blobs à envoyer en priorité par le serveur au client est simple (elle se base sur la partie du projet sur laquelle l’utilisateur travaille) mais elle peut prendre des formes beaucoup plus complexes notamment lorsqu’elle est basée sur un processus d’apprentissage. En effet selon un mode de réalisation du procédé selon l’invention, et en conséquence de la fonction collaborative de l’invention, l’application serveur est en mesure de connaître et donc d’apprendre sur la base de l’historique de création du projet les habitudes de travail de chaque utilisateur travaillant sur le projet, et de manière générale l’implication de chaque utilisateur du système dans différents projets. Ce processus d’apprentissage à base de machine learning fournit une matrice de décision permettant à l’application serveur d’adopter en temps-réel une stratégie pour la hiérarchisation de la livraison des blobs la mieux adaptée possible à chaque utilisateur et à chaque application client. L’application serveur maintient donc une liste de priorités d’envoi des blobs par utilisateur pour chaque application client (ordinateur de bureau, application de réalité augmentée sur smartphone, etc.). Si le résultat du processus d’apprentissage sur la base de machine learning indique par exemple qu’un utilisateur travaille plus particulièrement sur une des assets du projet plutôt qu’une autre, toutes les données en relation avec cette asset auront leur priorité dans la liste d’envoi des blobs augmentée. Lorsque les priorités de tous les blobs en attente sur le serveur pour une application client particulière ont été mises à jour, alors le serveur les envoie à l’application client dans l’ordre décroissant de priorité. Ce processus s’opère en temps-réel (les priorités pour chaque application client et chaque utilisateur du système sont continuellement mises à jour) et la liste des priorités peut changer pendant l’envoi des blobs (du fait d’une nouvelle information communiquée au serveur par le client).

• Module de stockage des états intermédiaires (tag / snaoshot) et de l’historique de création : lorsqu’un utilisateur lance une application client et charge les données d’un projet qui a fait l’objet de modifications depuis sa dernière connexion, l’application serveur détermine en comparant son historique de création avec celui de l’application client, l’état E _c dans lequel se trouve le projet sur l’application client. À partir de l’état Es dans lequel se trouve le projet sur le serveur (avec Es >= à Ec), il en déduit alors la section de l’historique H devant être exécutée sur l’application client pour mettre le projet à jour. Autrement dit : H = Es - Ec. Ce module devient cependant inefficace au fur et à mesure que l’historique de création du projet grossit.

À titre d’exemple, Un groupe d’utilisateurs travaille sur un projet pendant une période relativement longue, par exemple plusieurs semaines ou plusieurs mois. Le projet est complexe : l’historique comprend des dizaines voire des centaines de milliers de changements d’état appelés révisions et le blob store comprend plusieurs dizaines de gigaoctet de données. Dans le cas où un utilisateur U rejoint le projet, suivant la logique décrite ci-dessus, le serveur devra envoyer tous les blobs (y compris ceux qui ne sont potentiellement plus utilisés dans la version la plus récente du projet) et l’intégralité du contenu de l’historique du projet au nouvel utilisateur ; afin de mettre le projet sur le système de l’utilisateur dans l’état Es, toutes les révisions depuis la création du projet seront alors exécutées sur l’application client, ce qui peut prendre beaucoup de temps pour un projet avec un historique important comme c’est le cas dans notre exemple. Selon un mode de réalisation du procédé selon l’invention, l’application serveur sauve automatiquement et régulièrement un état total du projet. Cet état total peut être vu comme une version ou image {snapshot e n anglais) du projet à l’instant t. Le fait qu’il existe une sauvegarde de l’état total du projet à l’instant t est également préservé dans l’historique de création du projet. Grâce à cette méthode, le serveur n’a plus qu’à envoyer au nouvel utilisateur U, les données relatives à la dernière sauvegarde de l’état total du projet Eïotai puis toutes les modifications réalisées sur le projet depuis le moment où E Total a été généré. Dans l’historique du projet, les modifications réalisées à un propriété du projet sont toujours définies dans l’historique de création, comme relatives à l’état dans lequel se trouve cette propriété dans la dernière sauvegarde de l’état total du projet. Le serveur procède à la sauvegarde totale du projet lorsque le nombre de révisions depuis la dernière sauvegarde de l'état total dépasse la valeur Q R fixée par le système.

• Gestion de l’historique par l’utilisateur côté client : grâce au module décrit ci-dessus, il existe sur le serveur une série de sauvegardes dites d’état total (des images du projet prises à intervalle plus ou moins réguliers). Selon un mode de réalisation du procédé selon l’invention, cette suite de sauvegardes d’état total du projet et l’historique des modifications réalisées entre chaque sauvegarde d’état total est exposée dans l’interface utilisateur de l’application client sous la forme d’une ligne de temps représentant l’intégralité de l’historique du projet depuis sa création. En se déplaçant sur cette ligne, l’utilisateur peut faire en sorte que le projet soit restauré dans un état antérieur. Pour se faire, le même module que celui précédemment décrit est utilisé. L'application serveur envoie les informations de mise à jour de l’application client en utilisant la sauvegarde de l’état total du projet T Total la plus immédiatement antérieure au moment ÏRestaure de restauration désiré, puis envoie les modifications additionnelles depuis le moment où cette sauvegarde a été réalisée jusqu’au moment de restauration désiré (T Restaure). Le projet est alors restauré dans l’état où il était à l’instant ÏRestaure . À travers la même interface utilisateur, l’utilisateur peut laisser dans l’historique de création des balises ou tags en anglais lui permettant de marquer dans l’historique de création du projet des étapes jugées clef de son évolution. Ces balises ou tags permettent de rapidement rétablir des versions antérieures du projet et notamment d’établir des comparaisons visuelles ou autres entre différents états du projet de manière simple et rapide. Selon un mode de réalisation du procédé selon l’invention il existe une balise spéciale générée automatiquement plutôt que par l’utilisateur : cette balise spéciale est ajoutée lorsque le projet n’a pas été modifié par aucune des applications client après un laps de temps QT. En effet nous considérons dans ce cas, qu’une absence de changement pendant un laps de temps long indique que le projet est potentiellement dans un état satisfaisant ou stable pour les utilisateurs du procédé selon l’invention et que cet état mérite donc d'être préservé.

Le procédé selon l’invention comprend donc un ensemble de modules collaborant les uns avec les autres, dans le mode de réalisation principal selon un fonctionnement interdépendant, bâtis sur des concepts communs comme par exemple le calcul de la valeur de hachage et exploitant la fonction collaborative de l’invention. Le procédé comprend notamment :

• Un module A temps-réel de synchronisation des données du projet sur les applications clients mis en oeuvre soit par le serveur dans le cas d’une session de travail collaboratif (push) soit par les applications client lorsqu'ils se connectent au serveur (pull),

• Un module B temps-réel qui à partir d’une valeur de hachage calculée sur les données binaires des blobs grâce à une fonction d’encodage cryptographique, permet de décider si des blobs importés doivent être ajouté ou non au blob store,

• Un module C temps-réel différenciant les changements d’états transitoires des autres changements d’état, permettant de compresser la liste de l'historique de création des projets de manière significative, et réduisant l’impact sur la quantité de données stockées sur les espaces de stockage, en mémoire et transitant sur le réseau,

• Un module D temps-réel exploitant la clef de hachage garantissant l’intégrité des données transmises entre les applications client et l’application serveur, • Un module E temps-réel exploitant dans un algorithme d’apprentissage

(machine learning) les données de l’historique de création des projets pour hiérarchiser l’ordre dans lequel l’application serveur délivre dans le cadre de mise à jour, les blobs aux différents utilisateurs et différentes applications client connectés au projet,

• Un module F temps-réel préservant l’historique de création des projets sous la forme d’une série de sauvegardes d’état total du projet et de révisions intermédiaires relatives à ces états. La fréquence des sauvegardes des états total étant déterminée par un algorithme basé sur un module d’apprentissage (machine learning) en temps-réel exploitant les données de l’historique,

• Un module G temps-réel permettant à l’utilisateur du procédé à travers une interface utilisateur de l’application client de marquer par des balises les moments clefs de l'évolution du projet et de revenir dans le temps en utilisant ou non ces balises pour facilement rétablir le projet dans des états antérieurs, à partir desquels des comparaisons entre différents états du projet peuvent être présentées à l’utilisateur à des fins comparatives.

Module d’optimisation de la gestion et du processus de visionnage des contenus par système d’apprentissage exploitant entre autres les données de l’historique.

Une des fonctions du procédé selon l’invention est de visionner en temps- réel ou en différé un contenu d’animation 3D constitué par un ensemble de plans ou clips organisés sous forme de séquences, comme décrit ci-dessus. L’objectif est de permettre aux utilisateurs du procédé, côté application client, de créer les contenus les plus complexes possibles tout en maintenant les meilleures performances de visionnage, c’est à dire avec une fréquence d’affichage des images et du son supérieure ou égale à 30 images par seconde pour une définition d’image supérieure ou égale au standard de format d’image dit Full HD. Dans ce contexte, le dispositif met en place un module permettant d’optimiser le processus par lequel les données formant le contenu à visionner sont transformées en images animées et sonores. L’usage collaboratif du dispositif unifié génère de grandes quantités d’information sur 1 ) l’usage du dispositif lui-même et 2) les contenus fabriqués par les utilisateurs du dispositif. Ces informations collectées par l’application serveur comprennent 1 ) l’historique de création du projet, 2) les méta-données connexes à l’usage du dispositif et à l’édition du projet 3) l'intégralité des données dont le projet est constitué. L’historique de création a déjà été présenté ci-dessus. Les méta-données peuvent inclure des métriques comme par exemple la taille mémoire nécessaire pour le chargement d’une scène 3D donnée, le temps qu’il a fallu pour charger cette scène, la fréquence d’utilisation d’une scène ou d’une asset donnée (combien de fois a-t-elle été éditée par les utilisateurs du système, combien de fois la scène apparaît-elle dans les séquences du contenu d’animation final), etc. Les utilisateurs du dispositif visionnent également fréquemment les différentes scènes et séquences constituant le projet ; ainsi durant ces visionnages, il est possible de collecter des informations sur le temps de calcul de chaque image pour chaque scène, sur l’usage de la mémoire qui peut varier en fonction de ce qui est visible à l’écran, etc.

Soulignons que c’est caractère collaboratif et unifié du dispositif qui permet 1 ) de générer des informations nouvelles et 2) de les centraliser dans le cloud, et que c’est grâce à cela que ce module d’optimisation peut être mis en oeuvre. Les dispositifs actuels qui ne sont ni collaboratifs ni unifiés n’ont accès qu’à certaines de ces données et de façon non-centralisée et de fait, n’ont pas la possibilité de mettre en oeuvre le même procédé.

Ces données peuvent varier en fonction de l’application client utilisée (celle pour smartphone ou ordinateur de bureau par exemple) et des caractéristiques du GPU et du CPU du système sur lequel l’application client est exécutée (quantité mémoire, nombre de coeurs, etc.). Notons finalement que lorsque le contenu final du projet est joué par le procédé (où les scènes 3D sont affichées à l’écran avec le son selon les informations de montage définies dans les étapes mises en oeuvre par le procédé pour éditer des séquences), le processus par lequel ce contenu est calculé pour être restitué est prédictif puisqu’il est, dans le cas le plus commun de l’usage du procédé, linéaire (en opposition à des contenus dits interactifs, dont les contenus changent lorsqu’ils sont joués comme par exemple dans le cas d’un jeu vidéo). Selon un mode de réalisation du procédé selon l’invention, un algorithme à base d’apprentissage (machine learning) exploite l’intégralité des informations dont il dispose sur le projet (l’historique de création, les métadonnées collectées au fil du temps par configuration hardware utilisée, ainsi que les données du projet), pour planifier ( scheduler ) et optimiser l’usage des ressources du système sur lequel l’application client est exécutée, afin de garantir au mieux que le contenu du projet soit joué dans les conditions requises (résolution de l’image, nombre d’images par seconde, etc.). Ce module de planification de d’optimisation des ressources définit la partie du procédé selon l’invention est ici appelé moteur de film, auquel on se référera par la suite sous le terme de movie engine. À titre d’exemple, le procédé au cours d’une étape de collecte d’informations a détecté qu’une scène S3 requiert 3 secondes pour être chargée et 5 Go de mémoire sur le GPU ; cette scène apparaît 10 secondes après le début de la séquence d’animation (une séquence Q1 composée de 10 plans faisant référence à 3 scènes différentes S1 , S2 et S3) : le procédé est donc apte à planifier le chargement de la scène au moins 3 secondes avant qu’il soit nécessaire de l’afficher à l’écran et qu’au moins 5 Go de mémoire sur le GPU soit libre au moment où le processus de chargement commence, quitte à supprimer de la mémoire des données dont le procédé n’a pas immédiatement besoin si nécessaire. Le procédé comprend donc un movie engine dont le fonctionnement selon le mode de réalisation principal de l’invention est le suivant :

• L’application serveur collecte les informations suivantes :

• Les métadonnées envoyées par les différentes applications client utilisées pour l’édition du contenu du projet,

• L’historique de création du projet

• Les données du projet.

• Le serveur traite et réorganise ces informations dans des paquets d’informations pertinentes pour le movie engine qui sont ensuite envoyés aux applications client (sur le même principe que l’envoi des blobs),

• Ces paquets d’informations fournissent les données d’entrée au movie engine dont la tâche est d’optimiser la réponse au problème suivant : “quelles données charger et quand les charger sur la base de la configuration hardware sur laquelle l’application client est exécutée, de manière à garantir un visionnage en temps-réel sans interruption.

• Le movie engine affine de manière sensiblement permanente, et de manière préférée à une fréquence supérieure à la fréquence des événements utilisateurs sur les terminaux, en temps-réel, la réponse à ce problème sur la base des informations qui sont lui sont envoyées en continu par l’application serveur. Le movie engine explore différentes stratégies en adaptant les paramètres du problème afin d’optimiser sa réponse dans un processus d’auto apprentissage continu. Ainsi alors qu’une configuration S1 semble plus performante à un utilisateur du système qu’une configuration S2, le movie engine peut découvrir dans le cadre de ce processus d’apprentissage que S2 moyennant des modifications à des paramètres spécifiques du système est en réalité plus performante que S1. Par exemple, une stratégie peut consister à privilégier le chargement et le déchargement des données depuis l’espace de stockage du client dans et de la mémoire du GPU le plus vite possible plutôt que de préserver un maximum de données dans la mémoire du GPU le plus longtemps possible.

· Le movie engine possède des stratégies alternatives pour contourner des limitations du système si le processus de planification n’est pas suffisant pour garantir un visionnage sans interruption. Il peut selon un mode de réalisation du procédé selon l’invention :

• Précalculer avant le démarrage du visionnage du contenu (et mettre dans un tampon c’est à dire un espace mémoire réservé) des parties du contenu avant qu’elles ne soient jouées, lorsqu’il a été détecté que malgré toutes les optimisations possibles, ces parties du projet ne peuvent par exemple par être jouées en temps-réel dans les conditions de visionnage requises. · Planifier le calcul du projet en parallèle sur plusieurs GPUs lorsqu’un seul GPU n’est pas suffisant et recomposer les images calculées par ces GPUs dans un flux vidéo continu. Ces différentes options font partie des paramètres que le movie engine peut modifier dans son algorithme d’apprentissage afin d’offrir la meilleure réponse possible en fonction des contraintes du système (configuration hardware) et du projet.

Le procédé selon l’invention est en outre un procédé connecté. En effet, la nature collaborative du projet requiert que la version du projet qui se trouve sur le serveur S auquel les applications client sont connectées, soit la version de référence du projet. Le fait de disposer de l’ensemble des données du projet (y compris de son historique) sur le serveur, permet de développer un ensemble d’application satellites qui peuvent soit accéder aux données du projet depuis le serveur, soit s’interfacer directement avec l’application client.

Ces applications satellite peuvent être considérées comme un autre type d’application client.

À cet effet le procédé selon l’invention comprend une étape de connexion d’une application satellite au serveur. Dans un mode de réalisation principale de l’invention une solution logicielle est exécutée sur un smartphone ou une tablette équipée de fonctionnalité de réalité augmentée. Aussi à titre d’exemple, une application satellite au serveur S lit les données du projet P sur le serveur S et affiche les différentes scènes du projet sur l’application du smartphone. L’utilisateur de l’application peut alors sélectionner l’une des scènes du projet, puis à l’aide du système de réalité augmentée, déposer le contenu de cette scène virtuelle Sv sur n’importe quelle surface du monde réel dont le téléphone est capable de connaître la position et l’orientation dans l’espace 3D (il s’agit souvent dans le cas le plus simple d’une surface horizontale ou verticale, comme la surface d’une table ou celle d’un mur). La scène virtuelle 3D Sv est alors ajoutée au flux vidéo provenant de la caméra du téléphone en surimpression. La finalité de ce dispositif est de permettre à l’utilisateur de jouer la scène 3D Sv et de pouvoir la filmer en réalité augmentée.

Pour se faire l’application propose une fonction d’enregistrement de la caméra. Lorsque l’utilisateur de l’application enclenche cette fonction d’enregistrement, les déplacements de la caméra dans l’espace 3D (qui sont fournis par le système de réalité augmentée) et les images du flux vidéo créées sont conservées dans la mémoire du smartphone. Une fois l’enregistrement terminé, les mouvements de la caméra, les images de la vidéo et toutes les autres données auxiliaires créées par le système de réalité augmentée (comme par exemple les points dit de tracking qui sont des points de la scène réelle utilisés par le système de réalité augmentée pour calculer la position et la rotation du smartphone dans l’espace) sont sauvés dans le projet P sur le serveur.

Cette méthode d’acquisition permet notamment à l’utilisateur de créer des caméras virtuelles animées pour un projet de contenu d’animation 3D au moyen d’un dispositif grand public (les smartphones ou les tablettes).

Le procédé mis en oeuvre par ordinateur comprend aussi selon un mode de réalisation particulier, une étape de connexion d’une application temps-réel à l’application client. Dans ce mode de réalisation particulier, il est possible d’associer un système de capture de mouvement permettant d'enregistrer les positions et rotations d'objets ou de membres d'êtres vivants (corps et visage), pour en contrôler une contrepartie virtuelle sur ordinateur (caméra, modèle 3D, ou avatar). Cette méthode permet d’enregistrer directement les données capturées sur le serveur S dans le projet P ; elles sont alors immédiatement accessibles à toutes les applications client connectées au serveur.

Ces différents modes de réalisation de l’invention exploitent deux modes de connexion, l’une où l’application satellite accède aux données du projet P sur le serveur S via une connexion réseau de type Internet. L’autre dans laquelle une application satellite communique directement avec une application client (par un système de streaming par exemple) laissant la responsabilité à l’application client de communiquer avec le serveur pour accéder aux données du projet sur le serveur.

Le procédé selon l’invention comprend en outre un deuxième groupe d’étapes de production dites étapes de diffusion.

Ces étapes de diffusion comprennent dans un mode de réalisation une étape de calcul et de diffusion ( streaming ) local.

Aussi selon ce mode de réalisation, l’utilisateur de l’application client C qui utilise pour exécuter cette application un dispositif informatique de type ordinateur de bureau ou portable équipé d’une ou plusieurs unités centrales de traitement (CPU) et d’une ou plusieurs unités graphiques de traitement (GPU) peut calculer les séquences animées sonores à la volée (en temps-réel), localement, en utilisant les ressources de ces différentes unités de traitement.

Les sorties vidéo et audio créées peuvent être redirigées vers n’importe quel dispositif de visionnage connecté à l’ordinateur comme un écran 2D et des haut-parleurs ou un casque de réalité virtuelle.

Dans le cas d’un système de visionnage dynamique comme par exemple un système de réalité virtuelle ou augmentée où l’utilisateur du système de visionnage contrôle la caméra, les informations concernant la position et la rotation de la caméra fournies par le système de visionnage sont prises en compte dans la création du flux vidéo et audio créant une boucle de rétroaction: le système de réalité augmentée ou virtuelle par exemple fournit les informations 3D sur la position et la rotation de la caméra réelle (du smartphone ou du casque de réalité virtuelle) qui permettent de calculer sur l’ordinateur auquel il est connecté le flux vidéo et audio correspondant, ces flux étant eux- mêmes connectés aux entrées vidéo et audio respectives du système de réalité virtuelle ou augmentée.

Selon un deuxième mode de réalisation de l’invention, le calcul et streaming est réalisé à distance depuis le serveur S.

Aussi dans ce deuxième mode de réalisation, le même procédé que celui décrit ci-dessus est utilisé mais cette fois-ci le flux vidéo et audio est calculé sur le serveur soit hors ligne ( offline ) soit en temps-réel.

Dans le mode hors-ligne les flux audio et vidéo peuvent être sauvés dans une vidéo. Dans le mode temps-réel, les flux vidéo et audio sont calculés à la volée, dynamiquement et sont diffusés (streaming) vers un autre dispositif informatique ou électronique connecté au serveur par un réseau de type LAN (local) ou WAN (Internet par exemple).

Dans cette version de l’invention, il est possible de calculer une version finalisée du projet que ce soit dans la forme hors ligne (offline) ou temps-réel sur autant d’unités de traitement (CPU et GPU) que l’infrastructure du centre de calcul auquel le serveur est localement connecté le permet (notons que dans la mesure où les données du projet P qui sont sur le serveur S sont sur le réseau local auquel sont également connectés les unités de traitement, l’accès à ces données est rapide). Il est également possible d’utiliser n’importe quelle solution de calcul d’images de synthèse 3D pour créer les images finalisées de ce contenu.

Dans la version hors ligne ( offline ), un utilisateur peut adapter la vitesse avec laquelle une version finalisée du film est calculée en augmentant le nombre d’unités de traitements dédiées à cette tâche.

Dans la version temps-réel, un utilisateur du procédé peut accéder à distance, à des ressources de calcul beaucoup plus importantes que celles dont il dispose sur son ordinateur local (ou le dispositif électronique qu’il utilise pour visualiser le contenu comme un smartphone ou une tablette) afin d’obtenir une version finalisée du contenu en temps-réel de qualité bien supérieure à la version qu’il pourrait obtenir en exploitant les ressources de son propre ordinateur.

Ce dernier mode de réalisation de l’invention permet aux ressources de calcul (les GPU et les CPU utilisés dans le calcul du contenu) d’être physiquement séparées du dispositif de visualisation de ce contenu. Ce dispositif est différent du cas de la diffusion d’une vidéo par streaming depuis un serveur vers par exemple un smartphone via Internet, où le contenu de la vidéo est pré-calculé. Dans le cas de l’invention il s’agit de calculer le contenu du projet d’animation à la volée, au moment même ou il est diffusé (streamé) vers ce smartphone.

Un protocole adapté au streaming de contenu temps-réel comme par exemple RTSP ( Real-Time Streaming Protocol en anglais) est dans ce cas requis. Le contenu du projet est calculé live, de façon dynamique à la demande. Par dynamique, il est entendu que le contenu du projet peut être changé au moment même de sa diffusion (ce qui n’est bien entendu pas le cas pour une vidéo). Cela est notamment nécessaire lorsque l’utilisateur du procédé contrôle la caméra comme dans le cas de la réalité virtuelle et augmentée. Il s’agit de la même boucle de rétroaction que celle décrite ci-dessus mais dans cette version de l’invention, le système de réalité virtuelle ou augmentée et le serveur S sont connectés par un réseau LAN ou WAN (Internet par exemple).

Les données sur la position et la rotation de la caméra créées par le dispositif de réalité virtuelle ou augmentée sont donc envoyées au serveur S via ce réseau (entrée) ; ces informations sont ensuite utilisées pour calculer en direct à la volée, un flux vidéo et audio sur le serveur S qui est renvoyé (sortie) au dispositif par le réseau d’où les informations sur la caméra sont venues.

La possibilité de modifier dynamiquement le contenu d’animation alors qu’il est diffusé/streamé, permet également d’adapter le contenu en fonction par exemple des préférences de chaque personne qui le regarde.

Dans le mode de réalisation principal de l’invention, il est assigné une ou plusieurs unités de traitement (nommée ci-après groupe de calcul) à chaque personne regardant une version du contenu d’animation de sorte que chaque groupe de calcul puisse créer une version différente de ce contenu à partir du même projet S. Cette solution est similaire au concept de multi-casting asynchrone dans l’industrie du broadcasting ou streaming sauf que dans le cas décrit ici, chaque flux vidéo et audio généré et diffusé vers chaque client connecté au serveur de streaming est unique.

Aussi il est possible de sélectionner dynamiquement des objets de la scène au fur et à mesure que le film est visionné, pour pouvoir interagir avec eux.

Lorsqu’un film d’animation 3D est pré-calculé les informations concernant la composition de la scène sont perdues puisque les pixels comme déjà indiqué ci-dessus, n’ont aucune notion des modèles 3D qu’ils représentent.

Cette information peut être sauvée au niveau des pixels sous forme de métadonnée, les transformant ainsi en‘pixels intelligents’.

Lorsque le contenu du projet d’animation est calculé à la volée, puis diffusé en flux tendu, toutes les informations sur le contenu du projet sont connues puisqu’elles existent sur le serveur S. Il suffit donc par exemple à l’utilisateur du procédé d’indiquer à l’aide de la souris ou d’un écran tactile l’objet qu’il souhaite sélectionner ; les informations sur la position du curseur à l’écran sont ensuite envoyées au serveur qui en déduit par un ensemble de calculs simples, le modèle 3D que l’utilisateur a sélectionné.

Il est alors possible de lui renvoyer des informations supplémentaires sur ce modèle ou de lui offrir un ensemble de services associés à cet objet (comme par exemple l’imprimer en 3D, le commander par Internet, etc.). Il est également possible de connaître l’intégralité de l’historique de fabrication de ce modèle (qui l’a créé, qui l’a modifié, etc.) Le procédé selon l’invention répond ainsi aux problèmes techniques liés au caractère fragmenté des pipelines de production non temps-réel, à l’absence de solution collaborative, et à la déconnexion du processus de production du processus de diffusion des contenus d’animation 3D (qu’ils soient temps-réel ou non).

Le procédé selon l’invention résout l’ensemble de ces problèmes techniques dans un procédé global et dédié plus particulièrement à la création de contenus d’animation linéaires 3D temps-réel pour les médias traditionnels (télévision et cinéma) et les nouveaux médias (réalité virtuelle et augmentée).

Le présent procédé selon l’invention est conçu spécifiquement pour la création de contenus d’animation linéaires ou plus généralement de contenus narratifs 3D qui peuvent contenir des éléments d’interactivité mais qui se distinguent en tout cas clairement d’un jeu vidéo. Dans ce procédé, un ou plusieurs utilisateurs peuvent dans un processus unifié, travailler en temps-réel et en parallèle sur n’importe quel aspect d’un contenu d’animation 3D (et/ou mélangeant une variété de sources visuelles et sonores comme par exemple des vidéos, des images numériques, des sources audio préenregistrées ou générées procéduralement, etc.) en mode collaboratif simultané et à distance en utilisant une variété de dispositifs électroniques et/ou informatiques comme par exemple un smartphone, une tablette, un ordinateur portable ou de bureau, un casque ou n’importe quel autre système de réalité virtuelle ou augmentée, et de diffuser ces contenus grâce à une variété de procédés comme par exemple la publication d’une vidéo du contenu sur une plateforme de distribution vidéo ou le streaming d’un flux vidéo live dynamique (c’est à dire généré à la volée, ou créé dynamiquement à la demande) depuis un serveur vers n’importe quel dispositif d’affichage interactif ou non (casque de réalité virtuel, écran de smartphone ou de tablette, écran d’ordinateur, etc.).

Selon un mode de réalisation détaillé de l’invention décrit en référence aux figures 7 à 16, le procédé selon l’invention, autrement dit le pipeline collaboratif unifié (CUP), peut-être mis en oeuvre sur ordinateur tel que décrit ci-après.

1. Lancer l’application client : un utilisateur U1 lance l’application client sur un ordinateur de bureau équipé d’un CPU et d’un GPU. Cet ordinateur (aussi appelé terminal) est relié par un réseau distant de type WAN à un serveur situé dans un centre de calcul ou une plateforme cloud, tel que représenté figure 16.

Pour s’identifier sur le serveur S (sur lequel se trouve l’application serveur), U1 doit fournir un identifiant utilisateur ( username en anglais) et un mot de passe, figure 7, validé par l’application serveur.

Création/ouverture d’un projet : une fois connecté, un autre écran, figure 8 est offert à U1 qui lui permet soit de créer un nouveau projet de contenu soit d’ouvrir un projet existant. L’utilisateur U1 a la possibilité de personnaliser l’icône du projet P par un glisser-déplacer ( drag-and-drop en anglais) d’une image stockée sur le disque local de l’ordinateur sur l’icône du projet 23.

Dans le cas d’un projet existant, l’utilisateur U1 peut cliquer une fois sur l’icône du projet P pour un aperçu du contenu du projet sous la forme d’une petite vidéo ou teaser 24 par exemple de trente secondes maximum, pré-calculée ou calculée à la volée. Un double-clic sur l’icône du projet P provoque son ouverture.

Création/ouverture de scènes virtuelles 3D ou de séquences animées et sonores : l’ouverture du projet provoque la synchronisation des données sur le disque local du terminal depuis le serveur. Lorsque la version locale du projet est à jour (identique en tout point à la version sauvegardée sur le serveur), un autre écran ci-après nommé l’éditeur de projet est affiché, figure 1 1. Il est divisé verticalement en deux grands espaces : à gauche une liste de scènes 3D virtuelles 51 et à droite une liste des séquences composant le film 52.

Chaque espace comporte une icône qui permet de créer soit une nouvelle scène 54 soit une nouvelle séquence 57.

Les scènes et les séquences sont affichées comme une suite de cartes 55 comportant une image de la scène ou de la séquence choisie par l’utilisateur U1 ou de manière aléatoire (vignette ou snapshot) et le nom de la scène ou séquence qui peut être édité. Les scènes peuvent être dupliquées et supprimées. Un double-clic sur la carte d’une scène, ouvre la scène en édition. Edition de la scène animée : lorsque l’utilisateur U1 ouvre une scène, un nouvel écran lui est présenté, figure 12. Cet écran (ci-après nommé l’éditeur de scène) propose un espace de travail à partir duquel l’utilisateur peut éditer tous les aspects d’une scène virtuelle 3D comme par exemple importer ou modéliser sur place des modèles 3D, importer ou créer des animations, importer des caméras ou créer de nouveaux angles de vue à partir desquels la scène peut être filmée (en disposant des caméras virtuelles dans la scène 3D), importer ou créer des sources de lumière, des vidéos, des images numériques, des sons, etc.

L’éditeur de scène présente une barre de temps qui permet à l’utilisateur du procédé de se déplacer dans le temps de la scène. Le contenu de la scène est visible grâce à une sorte de fenêtre ouverte sur la scène 3D, calculée en temps-réel à la volée, qui s’appelle le viewport en anglais 71. Lorsque l’utilisateur clique sur l’icône de la caméra dans la barre des outils, une fenêtre s’affiche à l’écran comprenant la liste, présentée sous la forme de cartes, de toutes les caméras déjà créées dans la scène 82. Chaque carte comprend le nom de la caméra et une petite image qui représente une image de la scène prise depuis cette caméra. Un double- clic sur l’une de ces cartes permet de voir dans le viewport, la scène 3D filmée depuis la caméra sélectionnée.

La caméra peut être animée. Pour créer une nouvelle caméra, il faut se déplacer librement dans la scène 3D, puis lorsqu’un point de vue convient, cliquer sur le bouton‘ ne\ri de la fenêtre des caméras 82 ce qui a pour effet 1 ) d’ajouter une carte à la liste des caméras, 2) de créer une nouvelle caméra positionnée dans l’espace 3D de la scène à l’endroit souhaité. Edition d’une séquence sonore et visuelle : une fois que l’utilisateur a créé une ou plusieurs scènes, il peut revenir à l’éditeur de projet, figure 1 1.

Par un double-clic sur la carte représentant une séquence 58, l’utilisateur ouvre un nouvel écran nommé ci-après l’éditeur de séquence, figure 13. Cet écran permet à l’utilisateur d’éditer le contenu d’une séquence. Cet écran est séparé en trois grandes sections : - une fenêtre 3D ou viewport en anglais qui est la terminologie habituelle pour l’homme du métier, permet à l’utilisateur de voir le résultat de son montage 91 ,

- une liste de toutes les scènes 3D qui peuvent être utilisées dans le montage de la séquence 92 et

- une barre de temps ou timeline en anglais qui est la terminologie habituelle pour l’homme du métier, c’est à dire l’espace où l’utilisateur va créer son montage en y mettant bout à bout des plans 93. La création d’un plan sur la timeline s’opère par une opération de glisser- déplacer d’une carte représentant une scène 3D (ci-après SCN) depuis la section listant l’ensemble des scènes 3D du projet, sur la timeline.

Par défaut, le plan ainsi créé sur la timeline a la même durée que la durée de la scène SCN. Cependant, cette durée peut être ajustée comme dans n’importe quel outil de montage.

Enfin il est nécessaire une fois que le plan a été créé de préciser l’angle de vue depuis lequel la scène 3D SCN doit être filmée ainsi que la version de l’animation désirée pour ce plan. En cliquant sur le plan, comme par exemple à la référence 101 , une fenêtre s’affiche à l’écran 97.

Cette fenêtre comprend la liste des caméras et des animations de la scène 3D SCN. Il suffit alors à l’utilisateur de choisir la caméra et la version de l’animation qu’il souhaite utiliser pour ce plan en cliquant sur l’icône de la caméra et de l’animation représentant son choix.

D’autres éléments comme des sources audio peuvent être également ajoutés à cette timeline afin d’ajouter le son à l’image. Le viewport comprend certains contrôles 99 qui permettent à l’utilisateur de jouer la séquence pour vérifier le résultat de son montage.

Regarder la séquence en réalité virtuelle : en actionnant la fonction de réalité virtuelle 100 dans l’éditeur de séquence, il est possible de regarder la séquence non pas seulement sur l’écran de l’ordinateur mais également sur un casque de réalité virtuelle connecté à l’ordinateur de l’utilisateur. Jouer le film dans son intégralité : en actionnant la fonction du visionnage du film, figure 14 depuis l’éditeur de projet 53, l’utilisateur a la possibilité de jouer l’intégralité du film c’est à dire les séquences mises bout à bout. Les séquences sont jouées dans le même ordre que l’ordre dans lequel elles sont rangées dans l’éditeur de projet 52.

Création d’une caméra virtuelle en réalité augmentée : l’utilisateur lance une application satellite, en référence à la figure 19, sur un smartphone équipé de la fonction de réalité augmentée, ou de tout autre dispositif adapté.

L’application se connecte au serveur S pour y lire les données du projet P 1207, 1208. Apparaissent alors sur l’écran du smartphone la liste des scènes sous forme de cartes identiques à celles utilisées pour l’éditeur de projet 1205.

Via l’écran tactile du smartphone, l’utilisateur sélectionne une scène SCN dont il peut alors déposer le contenu sur une surface du monde réel pour l’y fixer. La scène virtuelle 3D est alors filmée par le téléphone comme si celle-ci faisant partie du monde réel.

En actionnant la fonction d’enregistrement 1201 , il est alors possible d’enregistrer les mouvements du smartphone dans l’espace réel 3D tout en se déplaçant autour de la scène virtuelle.

Une fois l’enregistrement terminé, le smartphone sauve les informations du mouvement de caméra qui vient d’être créé sur le serveur S en ajoutant une nouvelle caméra animée à la scène SCN du projet.

Ce mouvement de caméra est alors disponible dans le projet P dans l’application client depuis l’éditeur de scène ou l’éditeur de séquence.

Travail collaboratif : un autre utilisateur du procédé ci-après nommé utilisateur U2 se connecte au serveur S en lançant sur son propre ordinateur l’application client C2.

En activant la fonction de partage de projet, en référence à la figure 9, l’utilisateur U1 peut donner au second utilisateur U2 l’accès au projet P. L’utilisateur U2 a dès lors accès à toutes les données de ce projet et peut en modifier le contenu à sa guise. A chaque fois que l’utilisateur U1 ou l’utilisateur U2 édite le contenu de ce projet, les modifications sont immédiatement reflétées ou visibles sur l’écran de l’autre utilisateur.

Par exemple, l’utilisateur U1 créé une nouvelle scène depuis l’éditeur de projet. Cette scène apparaît sous la forme d’une nouvelle carte dans l’interface des deux utilisateurs bien que ce soit l’utilisateur U1 qui ait modifié le projet. Le deuxième utilisateur U2 qui a donc maintenant également accès à cette nouvelle scène décide de l'ouvrir pour y importer un modèle 3D. Le modèle est alors visible et disponible à la fois dans le projet du deuxième utilisateur U2 qui vient de l'importer mais également dans le projet du premier utilisateur U1 qui pourtant n'a rien fait.

Le premier utilisateur U1 décide de changer la couleur de cet objet. Ce changement de couleur est également appliqué au modèle du projet du deuxième utilisateur U2. Ce principe s’applique à tous les aspects du projet quel que soit le nombre d’utilisateurs connectés au serveur S.

Gérer différentes versions d’un projet grâce à l’historique, en référence à la figure 15 : les utilisateurs U2 et U1 peuvent explorer des versions différentes d’un même projet P.

En accédant à l’écran ci-après nommé éditeur de l’historique depuis l’application client 1 10, le deuxième utilisateur U2 peut créer une deuxième version P’ du projet ci-après appelée branche 1 1 1. Toutes les modifications réalisées par le premier utilisateur U1 au projet P ne seront plus visibles au deuxième utilisateur U2 tant que celui-ci travaillera sur le projet P’.

Réciproquement les modifications faites par le deuxième utilisateur U2 sur

P’ ne seront pas visibles par U1. En regardant l’éditeur de l’historique il est possible de voir que les utilisateurs U1 et U2 travaillent sur deux branches différentes, ces branches étant représentées de façon visuelle de manière explicite, tel que représenté figure 15.

Les utilisateurs U2 et U1 travaillent ainsi quelque temps mais réalisent plus tard que travailler sur deux versions du projet n’est plus nécessaire. Cependant, ils veulent intégrer les modifications qui ont été faites à la deuxième version du projet P’ dans le projet P. Cette opération peut être réalisée en sélectionnant les deux branches de projets P et P’ puis en effectuant une opération dite de fusion, merge en anglais qui est le terme consacré pour l’homme du métier, qui consiste à prendre les modifications faites au deuxième projet P’ et à les intégrer à la version principale du projet P ; les deux projets ont été fusionnés et les modifications faites aux deux projets depuis la création de la branche P’ ont été consolidées dans une seule et même version, la version principale P.

Cette opération de merge est également représentée de façon explicite dans l’éditeur de l’historique 1 15.

11. Jouer le film en réalité augmentée : une personne lance une application satellite sur un smartphone équipé de la fonction de réalité augmentée. Cette personne ne veut pas éditer le contenu d’un projet mais le regarder, comme spectateur. Cette application se connecte au serveur S et fournit à ce spectateur une liste de tous les projets disponibles. Grâce à l’écran tactile du smartphone, il sélectionne un projet, puis sélectionne grâce à l’interface graphique fournie par l’application de réalité augmentée une surface du monde réel sur laquelle le film en image de synthèse sera joué ; comme par exemple la surface d’une table.

12. Calculer le film à distance sur le serveur avec création dynamique de contenu, en référence à la figure 18 : l’utilisateur U1 souhaite montrer le résultat de son travail sur une tablette qui n’a cependant pas la capacité de traitement nécessaire pour le calculer à la volée en temps-réel. La page Web d’un navigateur Internet lui permet de voir la liste des projets disponibles. Sélectionner un de ces projets à l’aide de la souris, ou d’un écran tactile ou de tout autre dispositif adapté, déclenche deux choses :

12.1. D’une part une application ou un service permettant de recevoir un flux vidéo temps-réel ; basé sur un protocole de diffusion temps-réel de type RTSP et de l’afficher, est lancé sur la tablette. Il peut aussi s’agir de la page web depuis laquelle l’utilisateur accède à la liste des projets, puisque la balise dite video en HTML5 permet de recevoir et d’afficher dans une page web des flux vidéo temps-réel.

12.2. D’autre part un serveur de streaming est lancé sur le serveur S. Il s’agit d’une application qui va calculer une version finalisée du projet sur autant d’unités de traitement (GPU et CPU) que souhaité par l’utilisateur, comme paramètre du service, puis diffuser/streamer le résultat de ce calcul en flux tendu vers la tablette de l’utilisateur. Le contenu de ce flux entrant sera alors affiché sur l’écran de la tablette grâce au processus lancé à l’étape précédente (a). L’utilisateur peut interagir avec le contenu du film regardé. Il est par exemple possible de sélectionner un objet à l’écran à l’aide de la souris ou de l’écran tactile. L’objet est représenté comme un ensemble de pixels à l’écran, mais l’application de streaming peut connaître le modèle ou les modèles 3D représentés par ces pixels. Le modèle 3D sélectionné peut donc apparaître à l’écran entouré d’un contour (pour indiquer qu’il est sélectionné) puis tout un ensemble de services associés à cet objet peuvent lui être présentés.

A titre d’exemple notamment :

1. Il est possible de personnaliser le modèle 3D. Des versions alternatives au modèle sélectionné sont proposées à l’utilisateur qui peut choisir celui qu’il préfère. Le visionnage du film continue mais avec la version du modèle choisie par l’utilisateur ;

2. Des informations sur ce que représente le modèle peuvent être affichées à l’écran ;

3. L’utilisateur peut commander une impression 3D du modèle sélectionné.

Le broadcaster, c’est à dire le service en charge de diffuser le contenu vers la tablette, smartphone, etc. d’un ou plusieurs utilisateurs du service, peut aussi modifier le contenu du projet pendant qu’il est calculé et diffusé. Dans le cas de la retransmission d’un événement sportif en direct, à titre d’exemple, il est possible d’adapter le contenu de l’animation en fonction de l’actualité de cet événement. Dans ce cas les modifications sont opérées non pas par l’utilisateur du service mais par l’opérateur du service (le broadcaster). Il est possible de créer autant de versions personnalisées que d’utilisateurs connectés au service.

Afin de gérer le travail collaboratif de plusieurs utilisateurs U1 , U2, ... partageant une même partie d’application serveur, autrement dit partageant un même ensemble d’étapes du procédé mis en oeuvre par ordinateur, le procédé comprend aussi des étapes de gestion de droits d’accès. A cet effet le serveur comprend des étapes d’authentification utilisateur. Lorsqu’une application client est mise en oeuvre depuis un terminal, cette application se connecte tout d’abord au serveur qui met en oeuvre l’étape préalable d’authentification.

Cette étape d’authentification attribue alors un jeton numérique d’authentification, qui comprend des données d’authentification, hachées, cryptées ou encodées selon toute technique adaptée connue de l’homme du métier, et des données de droit d’accès, qui auront été préalablement définis dans une base de données du serveur.

De cette manière on peut s’assurer qu’un utilisateur ne pourra agir sur le procédé que pour un ensemble d’étapes de production qui lui sont autorisées. De manière classique, on peut prévoir des autorisations du type administrateur, donnant le droit de mettre en oeuvre des étapes de production et des étapes de gestion, une autorisation du type producteur, donnant par exemple des droits pour l’ensemble des étapes de productions, et des autorisations ciblées, par exemple une autorisation d’animateur ne permettant que l’accès en modification et création à l’étape d’animation du contenu produit.

Les données du contenu d’animation produit sont toutes stockées sur le serveur central.

Les données du contenu d’animation du type assets, tel que défini précédemment, sont stockées sous la forme d’objets binaires de grande taille, connus sous le terme anglais de Binary Large Objects, généralement abrégés par l'acronyme BLOB.

Ces données stockées sont organisées sous forme de groupes de données, connus dans le domaine technique sous l’appellation de Pool de données.

Toutefois le mode de stockage de données n’est pas limité à ce mode de stockage et de référencement. Toute autre solution technique de stockage sur serveur pouvant être adaptée à l'invention.

Chaque donnée est associée à un état R _n sur le serveur. Cet état est associé à des modifications, de sorte qu’à l’état précédent une même donnée était à un état R _n -i qui suite à une modification enregistrée dite Cn a amené l’objet à l’état R _n .

Le procédé selon l’invention met en oeuvre une étape de gestion des conflits d’édition et de création.

Cette étape de gestion est subdivisée en deux sous-étapes : une étape de détection de conflits et une étape de résolution des conflits. L’étape de détection de conflits est liée à l’étape d’historique en ce qu’elle détecte quelles actions concomitantes de l’historique agissent sur des données similaires stockées dans le serveur central.

Lorsque deux, ou plus, actions d’édition, de modification ou de création, réalisées par des étapes de productions, sont enregistrées par l’étape d’historique sur le serveur, et se référant à des données identiques, ou liées, alors l’étape de résolution de conflits est mise en oeuvre.

Cette étape de résolution de conflits vise à donner la priorité aux modifications, créations ou suppression les plus tardives.

Par conséquent, à titre d’exemple, lorsqu’un objet est dans un état R _n sur le serveur, par extension on peut parler aussi d’état R _n du serveur pour l’objet en question.

Un premier utilisateur U1 sur un premier terminal effectue une modification amenant à changer un état via une action f amenant le serveur vers un état R _P (que l’on écrit Rp = Rn->p), événement enregistré dans l’historique.

Un deuxième utilisateur, travaillant simultanément sur le même projet et sur un même objet, ou sur un objet lié, commande au serveur un changement d’état vers Rf= Rn->f, enregistré aussi dans l’historique.

Dans cette situation, le procédé de détection de conflit détecte que deux états concomitants sont exclusifs l’un de l’autre.

A cet effet, le procédé met alors en oeuvre l’étape de résolution de conflit pour déterminer quel état doit prendre le serveur, Rp, Rf ou un état différent.

Comme indiqué l’historique créé une relation d’ordre temporelle entre les événements. Dans cette situation, l’événement p est enregistré comme antérieur à l’événement f.

On entend par événement p ou f, le résultat de la mise en oeuvre d’une étape de production telle que décrit précédemment.

Pour résoudre ce conflit le procédé met en oeuvre une étape de détermination de l’exclusion de l’événement p.

Aussi, l’événement p est exclu s’il répond à l’un des critères suivants :

- l’événement p supprime un objet qui a été supprimé, modifié, ajouté ou référencé par l’événement f ; - l’événement p ajoute un objet qui a été supprimé, ajouté ou modifié par l’événement f ;

- l’événement p modifie une propriété d’un objet qui a été supprimé par l’événement f ;

- l’événement p modifie une propriété unique d’un objet qui a aussi été modifié par l’événement f ;

- l’événement p ajoute une référence à un objet qui a été supprimé par l’événement f ;

- l’événement p ajoute une référence à un objet ou une valeur pour une propriété d’un objet pouvant avoir plusieurs valeurs, qui a été ajoutée, supprimée ou changée par l’événement f ;

- l’événement p supprime une référence à un objet ou une valeur d’un objet pouvant recevoir plusieurs valeurs pour la même propriété ayant été ajoutée, supprimée ou changée par l’événement f ;

- l’événement p déplace une référence à un objet ou une valeur d’une propriété pouvant recevoir plusieurs valeurs ayant été ajoutée, supprimée ou déplacée dans une même propriété par l’événement f.

Si l’événement p entre dans l’un de ces cas il est alors ignoré, et le projet est mis à jour selon le dernier événement f. Sinon l’événement p est conservé avec l’événement f.

Les terminaux reçoivent alors du serveur une indication de mise à jour du projet, synchronisant les données locales sur les terminaux avec l’état du serveur suivant la résolution du conflit.

Ainsi, on peut résoudre de manière simple et efficace les conflits d’édition ayant un impact sur le procédé de production de contenus, en temps-réel, tout en assurant que ces modifications soient mises à jour directement à toutes les étapes de production, et répercutées en temps-réel sur tous les terminaux utilisateur.

L’invention concerne aussi un système informatique tel que représenté figure 16 comprenant un serveur 1 105 et un ou plusieurs terminaux 1 100.

Un terminal 1 100 comprend un dispositif informatique composé de systèmes d’affichage, d’unités de traitement de type CPU et GPU ou autre, et de capacité de stockage permettant de sauvegarder localement une version du projet P 1 102.

L’application client 1 101 selon l’invention, qui permet d’éditer le contenu de ce projet est exécutée sur ce dispositif.

Le terminal est connecté au serveur S 1 105 par un réseau local ou distant de type LAN ou WAN 1 106. Dans le cas d’une connexion distante de type WAN le serveur est dit dans le nuage (ou dans le cloud). Le serveur S est lui-même composé d’unités de traitement (de type CPU et GPU) et de capacité de stockage 1 103 utilisée pour sauver sur le serveur une version du projet P. L’application-serveur décrite dans cette innovation est exécutée sur ce serveur 1104. Plusieurs terminaux sont connectés au serveur via le réseau utilisateur 1 , utilisateur 2,..., utilisateur N.

La figure 17 représente schématiquement la manière par laquelle on synchronise une pluralité de projets de contenus différents avec une pluralité de terminaux différents.

Dans la première étape une modification faite au projet P par un utilisateur sur le terminal TA est d’abord sauvée localement 1’ puis diffusée au serveur 1 . Dans la deuxième étape, le serveur enregistre cette modification dans sa propre version du projet 2.

Dans la troisième et dernière étape, le serveur diffuse la modification à tous les terminaux sauf à celui d’où elle provient 3 qui l’appliquent à leur tour et l’enregistrent localement 3’.

A la fin de cette étape, toutes les versions du projet qui existent sur tous les terminaux et sur le serveur sont identiques, autrement dit les projets sont synchronisés.

La figure 18 est une représentation du module par lequel le contenu d’un projet peut être calculé à la volée et diffusé en flux tendu vers autant de dispositifs d’affichage (interactifs) que nécessaire.

Dans la figure trois types de dispositifs d’affichage interactifs sont représentés : un casque de réalité virtuelle 1 1 10 et les contrôleurs qui lui sont associés, une tablette ou un smartphone équipé de fonctions de réalité augmentée et d’écrans tactiles 11 1 1 , et un ordinateur muni d’un clavier et d’une souris 1 112. Les informations générées par ces différents dispositifs (comme par exemple la position du casque de réalité virtuelle ou du smartphone dans l’espace 3D du monde réel) sont envoyées au serveur auquel ils sont connectés 1 1 13.

Ces serveurs sont différents du serveur S de projet : ce sont des serveurs dit de streaming 1 1 15.

Ils sont connectés au serveur S via un réseau local (LAN) ce qui leur permet d’accéder aux données du projet rapidement. Il existe un serveur de streaming par dispositif d’affichage ou de visionnage. Cela permet à chaque serveur de streaming équipé de ses propres unités de traitement CPU et GPU, de calculer un flux vidéo et audio unique 1 1 14 qui répond aux entrées du système de visionnage. Chaque flux est donc potentiellement unique.

La figure 19 représente quant à elle le module permettant à un système équipé de fonctions de réalité augmentée comme un smartphone ou une tablette de se connecter au serveur S grâce à une solution logicielle exécutée sur ce système afin d’accéder aux données du projet comme par exemple, dans ce cas, les scènes 3D du projet P.

Dans l’exemple illustré par cette figure 19, dans l’étape 1 , les scènes 3D sont affichées sur l’écran du smartphone sous forme de cartes 1205.

A l’étape 2, l’application permet alors de jouer et de filmer ces scènes 3D en réalité augmentée.

A l’étape 3, une fois la scène filmée, toutes les données capturées par le système de réalité augmentée comme par exemple le mouvement de la caméra ou la vidéo sont ensuite sauvegardées sur le serveur S 1 105.