FR3084190A1 - Procede mis en œuvre par ordinateur pour la creation de contenus comprenant des images de synthese - Google Patents

Abstract

L'invention concerne un procédé mis en œuvre par ordinateur pour la création de manière collaborative et dans un processus unifié temps-réel, 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 œuvre grâce à l'action combinée d'une pluralité de terminaux et d'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.

Description

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 œuvre par ordinateur pour la création de manière collaborative et dans un processus 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

II 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.

II 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 voir 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 macromodifications, comme par exemple décider de modifier l’apparence du personnage principal de l’histoire.

Les macro-modifications sont moins fréquentes que les micromodifications 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. II 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 des ces contenus.

Pour résoudre les problème énoncés ci-dessus, nous proposons un procédé unifié et temps-réel mis en œuvre 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 œuvre 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 œuvre 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 œuvre 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 œuvre 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 du projet entre le serveur central et lesdits terminaux de sorte que chaque terminal mettant en œuvre les étapes de production du procédé reçoivent 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. 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 en outre des étapes de gestion de contrôle d’accès pour interdire ou autoriser la mise en œuvre 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 œuvre 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 œuvre d’étapes de production par un premier terminal, lorsqu’un deuxième résultat de la mise en œuvre 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.

L’invention concerne aussi un dispositif serveur comprenant une interface réseau, une mémoire de stockage et un processeur pour mettre en œuvre 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 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 œuvre 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 ;

3. 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 cameras 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) ;

4. 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. A 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. II 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. II 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 œuvre 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 architecture 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.

Dans une version préférée de l’invention, il est possible de combiner plusieurs processeurs graphiques (GPU) pour alimenter la solution en ressources de calcul et ainsi en améliorer les performances, en particulier pour des projets volumineux et/ou complexes. Cette partie sera décrite en détail dans la partie suivante dédiée à la fonction collaborative du procédé.

Le procédé étant adapté à la création de contenu d’animation linéaire, il tire parti de cette propriété pour optimiser ses performances. En effet quand le film est joué (play-back en anglais), les données constituant ce film sont connues ; il est donc possible d’utiliser des algorithmes dits prédictifs dont la fonction est de faire en sorte que la fréquence d'affichage des images souhaitée par l’utilisateur du procédé soit maintenue constante pendant la phase de jeu ou le playback. Ces algorithmes analysent en aval de la partie du film qui est joué, les parties du film qui devront être jouées dans le futur, ce qui leur permet d’optimiser l’usage des ressources du dispositif informatique sur lequel le film est calculé dans le temps en respectant des contraintes comme la quantité de mémoire disponible, la fréquence de calcul et la résolution des images souhaitées, etc. Rappelons en effet que le film étant calculé à la volée, et les ressources du dispositif informatique sur lequel la solution est exécutée étant limitées (capacité des unités de traitement et capacité de stockage en mémoire), il convient d’utiliser ces ressources aux mieux afin de garantir le maintien d’une fréquence de calcul des images au minimum constant au fil du temps, par exemple 24, 25, 30, 60, 90 images par seconde.

Le procédé comprend deux types possibles de mode de jeu (play-back) :

- Un mode dit de priorité à la qualité : dans une version préférée de l’invention, le procédé calcule les scènes virtuelles en veillant à respecter s’il le peut la fréquence de rafraîchissement spécifiée par l’utilisateur dans les paramètres du projet. Autrement dit, si la complexité du projet ne le permet pas, la fréquence de calcul peut être inférieure à la fréquence de calcul souhaitée par l’utilisateur, mais la qualité des images calculées elle n’est pas affectée.

- Un mode dit de priorité à la fréquence de calcul des images : dans une autre version préférée de l’invention, dans le cas où la complexité du projet dépasse les capacités du système informatique sur lequel le procédé est exécuté, la fréquence de calcul des images est maintenue constante au détriment de la qualité des images. Dans ce mode, le procédé choisit selon des algorithmes conçus à cet effet, d’altérer certains éléments du projet comme par exemple la complexité géométrique des modèles 3D pour les simplifier de sorte que la fréquence de rafraîchissement des images soit maintenue constante. Cette méthode est similaire dans le principe aux méthodes de compression vidéo. La bande passante des réseaux utilisés dans la diffusion des vidéos (en streaming par exemple) n’étant pas suffisante pour transmettre en temps-réel les données brutes de la vidéo, ces données sont compressées ce qui dans le cas de méthodes de compression dites lossy en anglais, provoque une dégradation de la qualité des images d’origine. Le principe décrit dans le cas des projets d’animation 3D est le même. II est possible d’altérer certains aspects du projet comme le nombre de sources de lumière utilisées dans une scène 3D, le fait que ces sources portent des ombres ou pas, la représentation des modèles 3D dans un format plus compact qui celui utilisé par défaut, etc. pour réduire la complexité des images à calculer afin de maintenir la fréquence de calcul souhaitée, mais en contrepartie, les images produites n’ont pas nécessairement la même qualité visuelle que celle produite dans le mode de jeu précédent qui donne la priorité à la qualité de 1‘image sur la fréquence de rafraîchissement.

La possibilité de jouer les contenus d’animation 3D en temps-réel est nécessaire pour des médias comme la réalité-virtuelle et réalité augmentée. Quel que soit le mode de jeu mis en œuvre, les contenus d’animation 3D conçus par l’intermédiaire du procédé, peuvent être joués sur n’importe quel dispositif informatique disposant soit d’un écran intégré ou déporté que ce soit un ordinateur portable ou de bureau, un smartphone ou un tablette, soit une ou plusieurs unités centrales et/ou graphiques de traitement (CPU et GPU) connectées d’un centre de calcul, soit n’importe quel autre système conçu pour la réalité virtuelle ou augmentée spécifiquement.

La combinaison de l’usage de processeurs graphiques et de l’usage d’algorithmes de playback ou de jeu dit prédictifs participe à la fonction du procédé qui est d’accélérer par une combinaison d’un ensemble de moyens organisés de façon innovante, le processus de création de contenus d’animation 3D temps-réel.

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

A 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 œuvre sur un serveur qui centralise les données, tandis qu’une autre partie du procédé est mise en œuvre 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 œuvre 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 Τ_Ί.

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 C₂, C₃,..., 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, C₂, C₃,..., 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 œuvre sur le terminal de l’utilisateur, par opposition à l’application serveur, correspondant aux étapes mises en œuvre 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 P_c 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 P_c soit identique à P_s.

L’application client peut alors faire des modifications au projet. Le procédé laisse la possibilité à la personne qui en fait l’usage d’exporter les données du projet dans un format de son choix, afin qu’elles puissent être utilisées si nécessaire dans des systèmes indépendants du procédé.

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.

Dans un programme informatique classique d’un pipeline de production de l’art antérieur, non collaboratif, lorsque l’utilisateur d’un programme quitte l’application, il perd l’historique des changements qui ont été apportés à un document depuis son ouverture dans l’application. Cet historique permet notamment à l’utilisateur de revenir en arrière ou en avant par un système d’undo-redo (défaire-refaire). Par ailleurs l’opération de sauvegarde ne sauve qu’un état du document à l’instant 't' : l’historique des modifications apportées au document depuis sa dernière sauvegarde n’est donc généralement pas sauvé. Aussi, toutes les étapes qui ont conduit par exemple à la création d’une version 2 d’un fichier à partir de sa version 1 sont définitivement perdues une fois que l’utilisateur quitte l’application. A contrario, dans le procédé selon l’invention, l’étape dite d’historique, mise en œuvre en partie sur le terminal utilisateur, par la transmission des informations de modifications effectuées, et en partie sur le serveur, par l’enregistrement des ces modifications, l’intégralité de l’historique des modifications faites au projet est préservée depuis la création du projet sur le serveur. Il est alors possible pour un utilisateur de quitter l’application puis de la relancer et de là, de défaire des modifications antérieures à la dernière utilisation du programme. L’utilisateur peut aussi remonter dans le temps depuis n’importe quelle session de travail jusqu’à la toute première étape du projet, qui était la création du projet lui même.

Il est également possible d’avoir la liste complète de toutes les modifications qui ont été faites au projet entre deux périodes de temps.

L’invention exploite cette possibilité en proposant à l'utilisateur au moins deux fonctions majeures qui sont exposées au travers d’une interface graphique spécifiquement conçue pour lui permettre d'exploiter les données obtenues par l’étape d’historique du procédé :

- Une barre de temps : l’historique du projet depuis sa création est présenté à l’utilisateur du procédé sous la forme d’une barre de temps ou timeline. L’utilisateur grâce à un curseur qui se déplace sur cette barre de temps a la possibilité de revenir à des états antérieurs ou de retourner à des états postérieurs du projet. En résumé, il est possible de se déplacer dans le temps. Lorsque l’utilisateur se déplace dans le temps, le contenu du projet local est adapté pour refléter l’état du projet tel qu’il était à l’époque choisie.

- Créer et fusionner des branches de travail : le travail collaboratif permet à tous les utilisateurs du procédé de travailler sur le même document en même temps. Il n’existe donc jamais qu’une et une seule version de ce document ou projet. Il peut cependant arriver que deux utilisateurs veuillent travailler sur deux versions différentes du même projet ; l’interface mentionnée ci-dessus le permet à travers un mécanisme qui permet de créer une version parallèle à la version principale du projet. Cette version parallèle est appelée une ‘branche’ pour reprendre la terminologie utilisée dans les logiciels de contrôle de révision. On dit dans ce cas qu’une nouvelle branche a été ajoutée au projet. La création de cette branche apparaît visuellement dans l’interface sous la forme d’une seconde barre de temps qui émerge de la première à l’endroit où la branche a été créée depuis la barre de temps représentant la version principale du projet. II est alors possible à deux utilisateurs de travailler sur deux versions du projet (V1 la version principale et V2) sans que les modifications faites par le premier utilisateur à V1 soient visibles au second utilisateur lorsque celui-ci travaille sur V2 (et vice versa). II reste néanmoins possible d’apporter ultérieurement les modifications de la version V2 à la version principale V1 par une opération dite de ‘merge’en anglais ; il s’agit en réalité de fusionner les deux versions pour qu’elles n’en fassent de nouveau plus qu’une. Le procédé ne se limite pas à deux branches ou deux versions ; il est possible d'en créer autant que nécessaire.

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 euxmê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). II 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. II 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éconnection 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 œuvre sur ordinateur tel que décrit ci-après.

1. Lancer l’application client : un utilisateur LI1 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.

2. 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.

3. 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 11.11 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 LI1 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.

4. 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 doubleclic 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 ‘nev/ 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é.

5. 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 11.

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 glisserdé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.

6. 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.

7. 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.

8. 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.

9. 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 C₂.

En activant la fonction de partage de projet, en référence à la figure 9, l’utilisateur LU 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 LU 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 LU 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 LU 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 LU qui pourtant n'a rien fait.

Le premier utilisateur LU 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.

10. Gérer différentes versions d’un projet grâce à l’historique, en référence à la figure 15 : les utilisateurs U2 et LU 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 110, le deuxième utilisateur U2 peut créer une deuxième version P’ du projet ci-après appelée branche 111. Toutes les modifications réalisées par le premier utilisateur LU 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 LU. En regardant l’éditeur de l’historique il est possible de voir que les utilisateurs LU 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 LI1 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 115.

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 LI1 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). II 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 LU, U2, ... partageant une même partie d’application serveur, autrement dit partageant un même ensemble d’étapes du procédé mis en œuvre 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 œuvre depuis un terminal, cette application se connecte tout d’abord au serveur qui met en œuvre 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 œuvre 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 C_n a amené l’objet à l’état R_n.

Le procédé selon l’invention met en œuvre 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 œuvre.

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 œuvre 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 œuvre d’une étape de production telle que décrit précédemment.

Pour résoudre ce conflit le procédé met en œuvre 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 1105 et un ou plusieurs terminaux 1100.

Un terminal 1100 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 1102.

L’application client 1101 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 1105 par un réseau local ou distant de type LAN ou WAN 1106. 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 1103 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 T 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 mécanisme 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 1110 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 1111, et un ordinateur muni d’un clavier et d’une souris 1112.

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 1113.

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

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. II 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 1114 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 mécanisme 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 1105.

Claims (8)

1. REVENDICATIONS

   1. Procédé unifié et temps-réel mis en œuvre 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 œuvre 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 œuvre 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 œuvre 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 œuvre 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é.
2. 2. Procédé mis en œuvre par ordinateur selon la revendication 1, caractérisé en ce qu’il comprend une étape de synchronisation du projet entre le serveur central et lesdits terminaux de sorte que chaque terminal mettant en œuvre les étapes de production du procédé reçoivent tout ou partie des données de projet à jour en fonction de toutes les modifications et créations apportées par l’ensemble des terminaux et du serveur.
3. 3. Procédé mis en œuvre par ordinateur selon la revendication 1 ou 2, caractérisé en ce qu’il comprend en outre des étapes de gestion de contrôle d’accès pour interdire ou autoriser la mise en œuvre de tout ou partie des étapes de production et de gestion à un terminal connecté au serveur.
4. 4. Procédé mis en œuvre par ordinateur selon l’une quelconque des revendications 1 à 3, caractérisé en ce que l’étape de résolution de conflits comprend une liste d’exclusion d’un premier résultat de la mise en œuvre d’étapes de production par un premier terminal, lorsqu’un second résultat de la mise en œuvre d’étapes de production par un second terminal a provoqué la détection d’un conflit, l’événement antérieur étant exclu si au moins 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.
5. 5. Dispositif serveur comprenant une interface réseau, une mémoire de stockage et un processeur pour mettre en œuvre au moins les étapes de gestion et/ou les étapes de diffusion et de distribution du contenu d’animation du procédé selon l’une quelconque des revendications 1 à 4.
6. 6. 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é selon l’une quelconque des revendications 1 à 4, et comprenant une interface réseau pour communiquer avec ledit dispositif serveur selon la revendication 5.
7. 7. Système informatique comprenant un dispositif serveur selon la revendication 5 et un ou plusieurs terminaux informatiques selon la revendication 6.
8. 8. Support de stockage lisible par un ordinateur ayant enregistré sur lui des instructions qui commandent un dispositif serveur et/ou un terminal informatique pour exécuter un procédé selon l’une quelconque des revendications 1 à 4.