EP3824440A1 - Method implemented by computer for the creation of contents comprising synthesis images - Google Patents

Abstract

The invention relates to a method implemented by computer for the creation in a collaborative manner and in a real-time unified process, of animation contents, characterized in that it comprises on the one hand steps of producing and disseminating animation contents as synthesis images intended to be implemented by virtue of the combined action of a plurality of terminals and of a central server, and on the other hand steps of managing these animation contents, said steps being adapted to allow the central server to centralize and manage the set of data produced at the stage of the production steps.

Description

 Computer-implemented method for creating content including computer generated images

The present invention relates to a computer-implemented method for the creation, in a collaborative manner and in a process, also called pipeline, unified and real-time, of digital animated and sound sequences comprising synthetic images.

 In the field of audio-visual creation, the term 2D is generally opposed, associated with traditional animation for example produced by a succession of images drawn by hand or with video, with the term 3D, corresponding to the creation of animated sequences or still images whose creation is the result of calculations generally performed by a computer. It is for this reason that the images produced in 3D are called synthetic images.

 3D animated sequences can be of two types: precomputed or real-time. In the case of pre-calculated sequences, 3D animations are calculated in advance and the content created is then saved in a video file or in the form of a sequence of digital images. Once calculated, the content of the images can no longer be modified. Real-time sequences are calculated at the time of display, generally by dedicated processors known as GPUs or graphics cards specially designed to calculate computer graphics at very high speed

 It is well known in the prior art that a frequency of generation of these 2D or 3D animated sequences, precalculated or real-time, is generally at least 24 images per second regardless of the size of the image. , the number of outputs and the sound quality generated.

 The production of contents in synthetic image responds for the skilled person to a set of distinct tasks, the main steps of which are, in the usual order of realization, with reference to FIG. 1:

E1. A stage of creation of 3D models (a human, an animal, a possibly articulated object), stage also called modeling or in English surfacing. The appearance of the model such as the color of its surface or a matt or shiny appearance for example, is also defined during this step. These models are called assets.

 E2. A so-called layout stage (this term having no French-speaking equivalent for those skilled in the art). During this step we assemble and arrange the objects created in the previous step to form more complex sets. In other words, we set up “scenes”, in the cinematographic sense, including for example sets and characters positioned to meet the needs of the story and aesthetic considerations. Several angles of view are selected to film these virtual decors and the possible 3D characters who will be there.

 E3. A so-called animation stage. It consists in animating the elements put in place during the layout using different methods.

E4. A lighting stage. To be visible, the elements making up the scenes from the layout, filmed from the viewing angles chosen during the layout stage, must be lit.

 E5. An editing stage, during which the different virtual scenes filmed and animated from the different viewing angles are placed end to end to form what constitutes the film.

 A usual process for producing animation content in computer graphics, called production pipeline, also generally comprises, before the editing step E5, a rendering step, during which effects of material and texture are applied. the elements of the scenes represented in order to give them a visual appearance conform to the desired artistic criteria.

There are other steps that we have not described here because they are not strictly necessary for the realization of linear animation content. One can quote for example the stage known as of the effects which makes it possible to create effects of explosion, smoke, liquid, fire, or to simulate the movement of clothing, etc., the stage of compositing which consists in mixing several image sources to form only one, and that of grading which consists in modifying the color balance of an image to modify its appearance. Furthermore, the realization of a linear narrative content in animation is often preceded by the description of this content in written form (commonly referred to as script or screenplay) and a storyboard, which is a representation of this script in the form of a succession of drawn images.

 All of these work steps constitute a production process commonly known as the production pipeline.

 Such a production pipeline is carried out in a sequential, linear and fragmented manner. However, each step of this pipeline requires IT tools, also called software solutions, specialized and generally independent of each other; moreover, such projects generally involve a large number of people working simultaneously on all these disparate tools.

 In addition, known production pipelines for carrying out professional 3D animation projects for precalculated linear animations, such as an animated film, are generally not suitable for the design of linear real-time animation content. or requiring little interaction for media such as augmented reality or virtual reality.

 The process of producing animation content (which we will more generally refer to as 3D animation) is above all a creative process. Such a creative process requires that iteratively be possible to test ideas, preferably quickly and often, on all aspects of the medium.

 For example, producing linear 3D animation content requires that it be possible, at any time during the creation process, to make modifications to the stages of modeling, layout, animation, lighting or assembly because the results produced at each of these stages have an impact on the final result; in other words on the content produced at the end of the chain.

 A 3D animated feature film project for cinema, for example, is the result of tens or even hundreds of thousands of modifications made by all the people contributing to its realization.

Some of these modifications are minor, called micro-modifications, such as for example small adjustments on the color of a object, over the length of a shot in a montage, or major, say macro modifications, such as for example deciding to modify the appearance of the main character of the story.

 Macro-modifications are less frequent than micro-modifications but they are more visible and have a greater impact on the creation process. However, with regard to these criteria, the production pipelines of the prior art pose many problems, including:

1. Because they are linear, a modification made upstream of the production chain requires going through all the stages which are downstream of the stage where the modification is made, before being able to be judged in the context final content (at the end of the editing stage). The process is similar to that of a domino or cascade effect: a modification upstream triggers a whole series of events downstream until reaching the last stage of the chain. 2. Since the tools used at the various stages of production do not produce results in real time and do not communicate with each other (due to the fragmented nature of the production pipeline), the changes made cause significant loss of time of production. It is not uncommon for a change to take several minutes, several hours, or sometimes several days before it can produce a visible result, in particular depending on its position in the production chain.

 One of the well-known problems is to optimize the process of creating 3D animation content, mainly linear, whether real-time or precomputed, by ensuring in particular that a large number of people can work simultaneously on the production. of these contents.

To solve the problems set out above, we propose a process of unified collaborative and real-time pipeline implemented by computer for the collaborative creation of animation content, characterized in that it comprises on the one hand stages of production and distribution of animation content in synthetic images intended to be implemented by a plurality of terminals in cooperation with a central server, and secondly steps of management of this animation content adapted to allow the central server to centralize and manage all the data produced at the stage of production stages;

said stages of production of said unified real-time process comprising:

 - a step of creating an animation content project;

 - a step of creating one or more 3D scenes and one or more 3D sequences in said created project;

 - a step of opening and editing at least one 3D scene;

 - a step of opening and editing at least one 3D sequence created to mount said content in computer generated images;

 - stages of broadcasting animation content;

said management steps comprising:

 - a step of managing a production history, adapted to ensure the transmission and recording of the result of the implementation of production steps by a terminal to the central server; - a step of updating the project stored on said server based on said results of the implementation of production steps by a terminal transmitted during the step of managing the production history;

 - a conflict detection step adapted to be implemented on the server so as to detect when at least two production steps have created, modified or deleted, directly or via another linked data item, simultaneously at least one and the same stored data item on the central server;

 - a conflict resolution step, when a conflict is detected in the previous step, capable of determining the creation or creations, modifications or deletions to be applied to said at least one data item for which a conflict is detected.

 Thus, a simple, unified, collaborative and connected process is obtained capable of managing, within the same application, the creation and distribution of animation content comprising synthetic images, suitable for precomputed or real-time rendering.

Advantageously and in a nonlimiting manner, the method comprises a step of real-time synchronization of the project between the central server and the said terminals so that each terminal implementing the production steps of the process receives all or part of the updated project data according to all the modifications and creations made by all of the terminals and the server, said synchronization step being adapted to be implemented by the server during operation in collaborative work mode and / or by said terminals when they connect to the server. Thus, we can ensure that any user working from a terminal remote from the server has the latest version of the current content project at all times, even when a large number of users are working on the project simultaneously.

 Advantageously and in a nonlimiting manner, the method comprises, for said steps of updating and synchronizing the project between the central server and said terminals, a plurality of data synchronization modules, said plurality of modules comprising:

 a real-time update module adapted to implement a cryptographic encoding function generating a hash key as a function of said project data, said real-time update module being adapted to determine whether data from the imported project must be saved by said terminals and the server;

 - a real-time optimization module able to detect changes in transient states of project data, and being adapted to compress said list of project creation history so as to reduce the amount of data transferred and stored by said terminals and the server;

 - a real-time control module using said hash key so as to control the integrity of the data transmitted between said terminals and the server,

 - a real-time learning module, capable of analyzing data from the history of project creation, and defining an order of priority, according to which said server transmits and updates the data to said terminals;

- a real-time versioning module, capable of preserving the history of project creation in the form of a series of backups of the total state of the project and of intermediate revisions relating to these states; said frequency of backups of the total states being a function of learning data from said real-time learning module;

 - a real-time marking module capable of authorizing a user of a terminal to mark with at least one tag a key stage in the development of the project, said marking module making it possible to restore said project to its state at the moment marking.

 Thus, the update and synchronization steps are reliable, robust and fast.

 Advantageously and in a nonlimiting manner, the method further comprises steps for managing access control to prohibit or authorize the implementation of all or part of the steps of production and management at a terminal connected to the server. Thus, the rights to implement the process can be segmented in order to limit interactions during collaborative work involving many people. Access control also makes it possible to limit the risks of modification or deletion of content, for example accidental.

 Advantageously and in a nonlimiting manner, the conflict resolution step includes the exclusion from the project of a first result of the implementation of production steps by a first terminal, when a second result of the implementation of production steps by a second terminal generated the detection of a conflict, the previous event being excluded if one of the following criteria is met:

 - the first result deletes an object that has been deleted, modified, added or referenced by the second result;

 - the first result adds an object that has been deleted, added or modified by the second result;

 - the first result modifies a property of an object which has been deleted by the second result;

 - the first result modifies a unique property of an object which has also been modified by the second result;

- the first result adds a reference to an object which has been deleted by the second result; - the first result adds a reference to an object or a value for a property of an object that can have several values, which has been added, deleted or changed by the second result;

 - the first result deletes a reference to an object or a value of an object that can receive several values for the same property having been added, deleted or changed by the second result;

 - the first result moves a reference to an object or a value of a property that can receive several values having been added, deleted or moved to the same property by the second result.

 Advantageously and in a nonlimiting manner, the method comprises an automatic learning module adapted to optimize the sequence of loading data into the memory of said terminals in order to restore in animated and sound image the content of the project in real time on said terminals, based on the data from the project creation history, the project data and metadata generated by said terminals. Thus, it is possible to optimize the bandwidth used between the terminals and the server as well as the memory occupied and the calculation time required both on the terminal side and on the server side.

 Advantageously and in a nonlimiting manner, said steps of production and distribution of animation content, comprise a step of real-time display of said animation content on an augmented reality device, such as a smartphone or a tablet. , connected to said server.

 In particular, the method implements a step of creating a virtual camera adapted for an augmented reality device, said step of creating a virtual camera being implemented after said step of opening and editing at least minus a 3D scene.

 The invention also relates to a server device comprising a network interface, a storage memory and a processor for implementing at least the management steps and / or the steps of producing and broadcasting the animation content of the method as described. previously.

The invention also relates to an augmented reality assembly, comprising a server device as described above and a device augmented reality, such as a smartphone or a tablet, said server device implementing the steps of producing and broadcasting the animation content of the method as described above.

 The invention also relates to a computer terminal for controlling a man-machine interface adapted to execute and / or carry out at least the production steps of the method described above, and comprising a network interface for communicating with said server device described above.

 The invention also relates to a computer system comprising a server device as described above and one or more computer terminals as described above.

 The invention also relates to a storage medium readable by a computer, for example a hard disk, a mass storage medium, an optical disk, or any other suitable means, having recorded on it instructions which control a server device and / or a computer terminal to execute a method as described above.

 Other particularities and advantages of the invention will emerge on reading the description given below of a particular embodiment of the invention, given by way of indication but not limitation, with reference to the appended drawings in which:

 - Figures 1 and 2 are schematic views of a production pipeline of the prior art;

 - Figure 3 is a schematic view of the interactions between stages of production of a process according to an embodiment of the invention;

 - Figure 4 is a graphical representation of an animation content project in computer graphics;

- Figure 5 is a representation of a 3D scene known from the prior art represented in its most conventional form by a series of objects or 3D models, called assets, each comprising properties allowing to modify the appearance; - Figure 6 is a schematic view of the organization of the data of a project content of a method according to an embodiment of the invention;

 - Figures 7 to 16 are simplified views of user interfaces of the implementation of the method on a computer according to an embodiment of the invention;

 - Figure 17 is a schematic view of a synchronization step according to an embodiment of the invention;

 - Figure 18 is a schematic view of a group of diffusion and distribution steps according to one embodiment of the method;

 - Figure 19 is a schematic view of a group of diffusion and distribution steps according to another embodiment of the method.

 The invention relates to the design of a process dedicated to the creation, production, distribution and distribution of linear animation content or more generally the creation and distribution of animated and sound sequences using a variety of sound sources. and graphics which can be combined together such as, for example, computer graphics, also called 3D content, mainly, but also digital images and videos, said 2D content, in a process, or pipeline, which is both unified, real-time, collaborative and connected to other methods of creating real-time animation content, especially for augmented reality.

 The animated and sound sequences generated by this invention can either be precalculated and saved in video files for example, or calculated on the fly which allows them to be used on augmented reality or virtual type systems or any other system of or existing or future display or broadcast (such as streaming) for which sound and animated sequences in computer graphics must be calculated on the fly, in real time (3D real-time visualization).

The method implemented by computer according to the invention comprises a plurality of production steps leading to the production of content, which can be implemented in parallel and independently of each other. The method according to the invention is also called Collaborative Unified Pipeline or Collaborative Unified Pipeline in English, to which we will refer later in this document by the acronym CUP.

 In the following description, the user of the process will be referred to as any person, or any group of people, acting on the process implemented by computer according to the invention, via a computer or any device able to communicate with the computer implementing all or part of the process.

 The different stages of production, which can also be called functions, are first described separately from each other, then presented in the context of a detailed embodiment.

 The method according to the invention comprises two groups of main production steps: creation and editing steps and dissemination steps.

 The first group of production steps is generally implemented on user terminals, while the second group of steps is in this embodiment implemented on the server.

 The method further comprises a third group of steps called management steps, these steps being jointly implemented by the terminals and the server, these steps notably comprising the history and conflict resolution steps, which will be described later. .

 The first group of production steps called creation and editing functions includes all of the steps E1 -E5 of the production of 3D animation content, with reference to FIG. 1, from the step of the modeling E1 until the final stage of assembly E5 as we have described them in the prior art.

 Also the method according to the invention implemented by computer makes it possible to create 3D real-time animation content from start to finish, this first group of steps comprising five steps:

 1. Create or open an animation content project;

2. Creation of new 3D scenes which may however contain a mix of other sources (such as digital images, videos, etc.), and creation of new sequences; Opening and editing of 3D scenes created in the previous step. In this step the user of the process can model on site or import 3D models created with other solutions, choose viewing angles (via virtual cameras that are placed in the scene), add lights, and animate all the objects in the scene (models, cameras, light sources, etc.) and all the properties of these objects (such as the color of a 3D object). A scene can also contain several versions of the animation (or take animation in the terminology of those skilled in the art);

Opening and editing of sequences created in step 1.2. In this step, the user of the process can edit the content of a sequence. The process involves putting a set of clips end to end as in any video editing solution. Unlike video editing software, the invention uses as a plan not videos but the 3D scenes created in the previous step 1.3. For each scene used in the montage of the sequence, the user must at least specify the camera or the angle of view from which this scene will be calculated.

 As with any assembly tool, however, the order and length of the planes that make up the assembly can also be changed. In summary, a shot in this system is defined at least by a 3D scene, the version of the animation that must be used for this scene when it is played, a viewing angle from which this scene is filmed when it is played in the montage, and usual montage information like the position of the plane in the montage, its duration, and its point of entry and exit.

 4.1. It is possible to create a sequence from a sequence of shots using a single 3D scene filmed from different angles of view.

4.2. It is also possible to use several 3D scenes in the same sequence. The possibility of mixing different scenes in a single sequence is a characteristic of the invention; 5. Play the content by playing the sequences created and edited in step 4 above.

 5.1. In a first embodiment of the invention, the content of the project is calculated in 2D to be projected on the screen of the computer on which the system is running (it may also be the screen of a tablet or smartphone or any projection device connected to the computer).

 5.2. In a second embodiment of the invention, not exclusive of the first, this content is calculated to be broadcast on virtual and augmented reality systems.

 5.3. In a third embodiment of the invention which is described in detail in the remainder of the document, the content can be calculated on the fly on one or more processors and the result, the video and audio output, broadcast (or streamed according to a neologism from English frequently used by those skilled in the art) to another electronic / computer device.

 Note that the scenes, the sequences, and the finalized content constituted by all the sequences, are played in real time and can be calculated as we have just indicated to adapt to the constraints of any system d display whether it is a computer, smartphone or tablet screen, a virtual or augmented reality system, or any other suitable device.

As these are 3D scenes filmed from a viewing angle chosen by the system user, these are calculated on the fly. The fact that the images are not precalculated as in the case of videos is a key element of the invention, since it allows the user of the system to modify any element of the project at any stage of the content production and distribution, for example the position of an object in a scene, the position of a camera, the position and intensity of a light source, the animation of a character, the editing of a sequence, using any display system and being able to see the result of its changes in real time. All these steps can be carried out by the only method implemented by computer according to the invention which, associated with a system of succession of display of man-machine interface screens, allows the user to pass from one step to another smoothly.

 In other words, this screen or navigation system was designed to bring together all the stages of the production of 3D animation content in a single process, in other words in a single solution, in order to allow the user to work on any aspect of the film (layout, editing, lighting, animation, etc.) in parallel and with real-time feedback (next point).

 Indeed, the process according to the invention is a real-time process. To do this, the process relies on two elements:

 The unified pipeline solution described above (1) takes advantage of the capabilities of graphics processors (GPUs) which have been designed to accelerate tasks such as the calculation of computer generated images or the calculation of distortions of animated 3D objects whose processing computing lends itself well to massively parallel computing architectures. The use of graphics processors (GPUs) does not exclude the use of central processing units (CPUs) in the solution. The IT processing resources required by the solution are much greater than those required by a software solution designed for text editing (the solution falls into the category called "data-intensive computing" in English). It is therefore preferable to be able to exploit all the available resources of the IT / electronic device on which the solution is executed, which implies combining the computing capacities of the CPU or GPU (s) available on the IT device where the solution is put into practice. .

 The method according to the invention is adapted so as to allow collaborative implementation of operation.

 To this end, the method according to the invention allows several users to work at the same time on the same content / project / 3D animation film and to see in real time the changes made by all of these users.

The process therefore allows simultaneous collaborative work to be done remotely. Also, the method is partially implemented on a server which centralizes the data, while another part of the method is implemented on terminals, for example desktop computers, tablets or smartphones. The centralized part of the process being common for the implementation of the process by all of the terminals of the same 3D animation content project.

 In a preferred version of the invention, the users have access to the project data thanks to a software solution (hereinafter called the client application) executed on their terminal, in other words on their computer device which the user uses for work.

 The terminal is a complete computer processing unit which has one or more central and graphical processing units as well as one or more video and audio output devices which make it possible to display images and play sounds on a variety of devices (computer screen, virtual reality headset, speaker, headset, etc.).

 When the application starts, the computer program (client application) running on the terminal connects to a remote application (hereinafter called server application), which is itself executed on the server of the network to which the terminal is connected (hereinafter called S server).

 To allow client and server applications to process the data they send and receive, the project data is encapsulated according to a protocol specific to the invention.

 For the transit of data encapsulated on the network, any standard protocol can be used (such as TCP / IP which is the protocol used for data exchange on the Internet). In a preferred version of the invention, the terminal and the server form a local network (called LAN for Local Area Network).

In another version of the invention, the terminal and the server belong to different networks but can nevertheless communicate using an Internet type connection for example. In this case they form a so-called extended network or WAN (for Wide Area Network in English). A work session is created as soon as at least one client is connected to the server; the number of client applications connecting to the server in a work session has no upper limit.

 This division allows the client application Ci to send to the server application all the modifications made to a project P from terminal T 1.

 When it receives a modification, the server application S performs two tasks: 1) it applies this modification to its own version of the project 2) it diffuses this modification to all of the clients with which it shares a connection C2, C3,. .., CN with the exception of the client from which the modification comes, which allows these client applications to apply it to their own version of the project.

 All versions of the project, whether those maintained by the different client applications Ci, C2, C3, ..., CN OR that maintained by the server application S are then updated or synchronized.

 All users of the process who are distant from each other and work on different terminals therefore have the same “view” of the P project at all times.

 In the present description, client application means all of the steps of the method implemented on the user's terminal, as opposed to the server application, corresponding to the steps implemented on the central server S.

 In this version of the invention, there are as many (local) copies of the P project as there are terminals, in addition to the copy of the project located on the server; in a work session, all these copies are identical.

When a new client application is launched and the version of the Pc project on the terminal disk is not the same as the P _s version on the server, the server application then proceeds to a step synchronization, during which it sends to the client application all the modifications necessary for updating the project P _s so that at the end of the process, the project Pc is identical to Ps.

The method implemented further comprises a history function, a connected function and distribution functions. The history function is implemented so that all the modifications made to the project, by all the users acting on their remote terminals, simultaneously or not, since its creation are saved on the server S, since each time that a user makes a modification, whether it is a minor or major change, this modification is sent to the server which saves it locally before it in turn disseminates it according to the process which has just been explained . The user of the process therefore does not technically need to save the modifications made in order to preserve his changes.

 The data of the history of changes of a project are saved in the memory of the server application but also on the storage space, for example in a hard disk, which is associated with it.

 Historical data can be divided into two main categories.

 The first type of data is represented by all the assets imported or created in the project by users. An asset being an English term well known to those skilled in the art and including in particular 3D models, images or textures, sounds, videos, materials, etc.

 In the method according to the invention, this data is described as blobs (acronym for Binary Large Objects) which can range from a few kilobytes to more than a thousand megabytes (gigabytes).

 These blobs are stored on the server storage space in the form of binary data.

 The second type of data is represented by objects to which properties are attached.

 An object is defined as a set of key-value pairs called property. Each property contains either a value or a reference (to a blob or another object), or multivalued (list of values or references).

For example, an object of type “3D object” references a blob containing the mesh information of a 3D model and properties such as the position of this object in a 3D scene, as well as references to the materials assigned to it. Material is another example of an object that contains information about the appearance of a 3D model such as its color or its brightness, each of these properties can contain either a constant value or a reference to texture type blobs.

 The amount of memory required to store this type of information on the server disk is relatively negligible compared to the size of the blobs.

 These two types of data differ in size but also in their frequency of editing. Blob data is more rarely added to the project than data of the second type, the editing of which is much more frequent. Changing the color of an object, for example, can be done in an iterative process in real time, leading to tens or even hundreds of changes per second. This data can be seen as representing the creation history of the project.

 Here is for example a possible sequence of change of this type: 1.Create a new scene

 2. Rename the scene to “SCN_1”

 3. Add an imported 3D object in SCN_1

 4. Change the position of this object

 5. Change the color of this object (red)

 6. Change the color of this object (green)

 7. Change the color of this object (blue)

 8. Add a color texture to this object.

 At this stage of project creation, the project therefore consists of an editing history comprising steps 1 -8 and two blobs saved both on the server's hard disk but also on that of the client application in what we call in the invention a blob store (warehouse of blobs).

 Using this information, it is possible, for example, to update the project of a second user U2 connecting to the server after the changes made by U1 have been saved.

 By applying the history editing tasks to the project of the second user U2, their project can be updated. For example :

1. A new scene is created in the local copy of the U2 project, 2. This scene is renamed SCN_1

 3. The 3D object is imported from the server blob store, saved in the client application blob store and added to the scene.

 4. The position of the object is changed,

 5. The color of the object is changed (red),

 6. The color of the object is changed (green),

 7. The color of the object is changed (blue),

 8. The texture is imported from the server blob store, saved in the client application blob store and added to the scene

 The method according to the invention comprises modules adapted to the collaborative function and to the generation of the history of the solution which results therefrom. These modules are:

- update management: a distinction is made between 1) updates in the context of a real-time collaborative work session (i.e. when several client applications are already connected to the server) and 2) updates updates made when an application connects to the server after a disconnection time:

 1. Changes from a client application are sent to the server application, which saves them locally (in a process described below) and then sends them back to the other connected client applications, which then execute these changes locally. We are in a logic of “push”: the server pushes the changes.

2. When a client application connects to the server after a disconnection time (or for the first time), it obtains from the server a project status (via a module described below) which allows it to establish the list of all blobs that have been added to this project since its last connection. The client application is then able to establish the missing blobs by comparing this list with the list of blobs already present in its local blob store. Only missing blobs are thus returned by the server application to the client application. We are in a logic of “pull”: it is the client who requests the list of data he needs to update himself. - blobs management: when binary type data is added to the project, it sometimes happens that a user adds it several times. Binary data is sometimes associated in the form of “bundles” or packets.

 As an example, a B1 bundle comprising mesh information describing a 3D model and three textures (T1 T2 and T3). In a later work step, the user may import into the project a new version of the “bundle” B1 which we will call B2.

 In this new B2 bundle, only the T3 texture is different from the files contained in the B1 bundle. It is therefore relatively inefficient to reimport into the project the mesh information of the 3D object as well as the textures T1 and T2, only T3 having to be the subject of an update. The storage space and the use of bandwidth necessary to transfer binary information to the server, then from the server to client applications being expensive and limited, it is necessary to only transit and store only the data new.

 The method according to the invention therefore comprises a module making it possible to calculate on the basis of the information that the blob contains a unique signature. In the main embodiment of the invention, we use a sha type key or hash value, that is to say a key obtained by a cryptographic hash function which generates a unique fingerprint for each blob in the project.

 The function that generates this hash value uses the binary data of the blobs as input.

 When the sha for a blob is calculated, the method compares the hash value obtained with those of each of the blobs contained in the blob store:

 • If the process finds a sha in the blob store with the same key, it follows that the blob already exists in the project, and that it is therefore not necessary to import it.

• If the sha does not yet exist, then the blob is imported. According to certain embodiments of the invention, the storage capacity and internet traffic on the server side are limited. The user must therefore make good use of this storage capacity and bandwidth and the system must therefore inform him of the impact that an import operation can have on the use of the quota of disk space and of traffic reserved for him.

 Thus, according to a particular embodiment of the method according to the invention, when the user imports blobs into the project, the client application proceeds in this way:

 1.All the blobs contained in a bundle (the imported package) are read from memory and a hash value is calculated for each blob in the bundle. If the blob exists in the blob store it is ignored. If the blob does not exist, its size is added to the total size of the data that the user wants to import.

 2. Once all the blobs in a bundle have been analyzed according to the process described above, we obtain the total size of the data to be imported into the project and therefore to be stored on the server. This figure can thus be presented to the user through a user interface. If the user realizes that the quantity of data to import exceeds the remaining storage capacity on the server or that it is too large (due to a handling error for example) he can decide to cancel the process of import or increase the storage size on the server. Otherwise, he can confirm the import. If the import is confirmed by the user, the data is then transferred to the server and then becomes accessible to the other users of the project.

This two-step import module was created in the context of the development of the collaborative functions of the method according to the invention and is specific to it. - management of the creation history: in the example given above, several stages of the history represent successive and potentially very rapid modifications, for example of the order of a few milliseconds, of a property of the project or of the client application. For example, in the stages of the U2 project described above, stages 5, 6 and 7, the three consecutive changes made to the color of an object, are very rapid. When modifications are made to a property of an object quickly, the intention of the user is to pass from the state Eo in which this property is located before it is changed, to the state Ei in step 5, then in state E2 in step 6, then finally in state E3 in step 7.

 These modifications being carried out in real time (they require only a few milliseconds to be executed), they appear to the user only as a continuous succession, or a constant flow of changes. The user stops the iterative process at state E3. It is therefore possible to consider that the intention of the user is to pass from Eo to E3 and that the states E1 and E2 are only intermediate states called transient, through which the user passes before stopping on l 'desired end state (E3). A state is said to be transient when its lifespan is very short (a few milliseconds only). The process implements the following steps:

 • Sending real-time revisions by the server to client applications in a collaborative editing session: when a user U1 moves an object in a scene S1, and another user U2 edits the content of the same scene S1 at the same time, U2 sees the object move as it moves in the scene of user U1. This is possible because all revisions, whether transient or not, are sent to the server, which returns them without delay to all of the client applications used to edit the content of the project.

• Saving of revisions in the creation history of the project: when the user stops modifying a property of the system (what happens when the next modification concerns another property of the system or when the concerned property stops being modified during a given time), the server application compresses the list of revisions to remove the transient states and replace it with a revision passing the property from the Eo state directly to the E3 state, according to our example, and this is the result of this compression which is saved in the creation history of the project. In general terms, when a property of the system goes from an EN state to an EN _{+ P state} WHERE P is the number of transient states, the part of the process in charge of managing the history does not preserve in the history the P transient states but a single modification making it possible to pass from the EN state to the EN ₊ state P directly. This compression method can be implemented by the method according to the invention, either on the client application or on the server application.

- management by the server application of corrupted blobs: it sometimes happens that certain blobs transmitted by the network from client applications to the server only partially or modify the server. The reasons why a blob can be corrupted are multiple: the client application that sends the data stops unexpectedly, internet outage, computer attack, etc. To remedy this problem, the method implements the following steps:

 • Step 1: the client application calculates the hash value HB of a blob B and sends a request to the server application telling it that it is about to send it a blob with a hash value H B. Immediately afterwards, the client application begins to send data from blob B in relation to this request.

 • Step 2: when the server stops receiving data associated with blob B, it considers that the data has been transmitted in full. It then calculates the hash value of the H’B server-side blob using the same algorithm as that used by the client application. If the hash value H’B is equal to that sent by the client application (H B), the server is guaranteed that the data in blob B is complete and intact and the process stops at this stage. If the value is different, the server goes to step 3.

 • Step 3: as soon as the server application re-establishes a connection with the client application, it sends a request asking it to return the data for the blob whose data is incomplete.

The server application sends the same request to all client applications sharing the same project, in the event that one of the client applications is in possession of the same blob and the client application that sent the blob initially, would be unavailable. The server application repeats step 3 until it obtains a complete copy of the blob data. Additionally, the server does not send blob B data to other client applications until the server-side backup is complete.

 This module, which incorporates the hash value used for managing the blob store, is important because it guarantees the reliability of the collaborative function of the process according to the invention. Furthermore, the previous case describes the module when the data passes from the client application to the server application, but the same module is used when data is transmitted (in the case of an update for example) from the server application to any client application.

- “Prioritization” of blobs: according to one embodiment of the method according to the invention, the blobs are transmitted from the server application to the client applications according to criteria determined by the client applications. Several scenarios can arise:

 • The bandwidth of the application is little used: in this case, the blobs are sent by the server application to the client application in the order in which the blobs arrived on the server, therefore without any “Policy” or particular strategy .

• After a few hours or a few days of work on a project, it is not uncommon for the state of the project to have changed considerably. A user who reconnects to the project after a long period of absence must wait for all the new blobs in the project to be transferred from the server to their terminal before they can resume work. However, it is rare that the user needs to access all new blobs upon login. The method exploits this observation in the following manner: the client application detects the part of the project on which the user first works, for example a particular scene of the project and transmits this information to the server application which will send the blobs contained in this scene before the others. This prioritization or prioritization process sends the “useful” information first to the user, which reduces waiting time and improves their experience. It is particularly useful for client applications with limited bandwidth and storage space, such as the augmented reality client application on a mobile phone. In the example mentioned above, the metric used to determine the order of blobs to be sent in priority by the server to the client is simple (it is based on the part of the project on which the user is working) but it can take much more complex forms especially when it is based on a learning process. In fact, according to an embodiment of the method according to the invention, and as a consequence of the collaborative function of the invention, the server application is able to know and therefore to learn on the basis of the creation history of the project the working habits of each user working on the project, and in general the involvement of each user of the system in different projects. This machine-based learning process provides a decision matrix allowing the server application to adopt in real time a strategy for prioritizing the delivery of blobs that is best suited to each user and each client application. . The server application therefore maintains a list of priorities for sending blobs per user for each client application (desktop computer, augmented reality application on a smartphone, etc.). If the result of the learning process on the basis of machine learning indicates for example that a user is working more particularly on one of the project assets than another, all the data related to this asset will have their priority in the list sending blobs increased. When the priorities of all pending blobs on the server for a particular client application have been updated, then the server sends them to the client application in descending order of priority. This process takes place in real time (the priorities for each client application and each user of the system are continuously updated) and the priority list may change during the sending of blobs (due to new information communicated to the server by the client).

• Module for storing intermediate states (tag / snaoshot) and creation history: when a user launches a client application and loads the data of a project that has been subject to modifications since his last connection, the The server application determines by comparing its creation history with that of the client application, the state E _c in which the project is located on the client application. From the state Es in which the project is on the server (with Es> = to Ec), it then deduces the section of the history H to be executed on the client application to update the project . In other words: H = Es - Ec. This module however becomes ineffective as the creation history of the project grows.

For example, a group of users works on a project for a relatively long period, for example several weeks or several months. The project is complex: the history includes tens or even hundreds of thousands of state changes called revisions and the blob store includes several tens of gigabytes of data. In the case where a user U joins the project, following the logic described above, the server will have to send all the blobs (including those which are potentially no longer used in the most recent version of the project) and the entire content of the project history for the new user; in order to put the project on the user's system in the Es state, all revisions since the creation of the project will then be executed on the client application, which can take a long time for a project with an important history like this is the case in our example. According to one embodiment of the method according to the invention, the server application automatically and regularly saves a total state of the project. This total state can be seen as a version or image (snapshot in English) of the project at time t. The fact that there is a backup of the total state of the project at time t is also preserved in the creation history of the project. Thanks to that method, the server only has to send to the new user U, the data relating to the last saving of the total state of the Eïotai project then all the modifications carried out on the project since the moment when E Total was generated. In the project history, the modifications made to a project property are always defined in the creation history, as relating to the state in which this property is in the last backup of the total state of the project. The server performs a full backup of the project when the number of revisions since the last backup of the total report exceeds the QR value set by the system.

• Management of the history by the user on the client side: thanks to the module described above, there are on the server a series of backups known as total status (project images taken at more or less regular intervals). According to one embodiment of the method according to the invention, this series of total state backups of the project and the history of the modifications made between each total state backup is exposed in the user interface of the client application under the form of a timeline representing the entire history of the project since its creation. By moving on this line, the user can ensure that the project is restored to a previous state. To do this, the same module as that previously described is used. The server application sends update information from the client application using the T Total project state backup most immediately prior to the desired restore restore period, then sends the additional modifications from the moment this backup has been performed until the desired restoration time (T Restores). The project is then restored to the state in which it was at the time ÏRestaure. Through the same user interface, the user can leave in the creation history tags or tags in English allowing him to mark in the creation history of the project stages considered key to its evolution. These tags or tags allow you to quickly restore versions of the project and in particular to establish visual or other comparisons between different states of the project in a simple and fast way. According to an embodiment of the method according to the invention there is a special tag generated automatically rather than by the user: this special tag is added when the project has not been modified by any of the client applications after a period of QT . Indeed we consider in this case, that an absence of change for a long period of time indicates that the project is potentially in a satisfactory or stable state for the users of the method according to the invention and that this state therefore deserves to be preserved.

The method according to the invention therefore comprises a set of modules collaborating with each other, in the main embodiment according to an interdependent operation, built on common concepts such as for example the calculation of the hash value and exploiting the collaborative function of the invention. The method includes in particular:

 • A real-time A module for synchronizing project data on client applications implemented either by the server in the case of a collaborative work session (push) or by client applications when they connect to the server ( sweater),

 • A real-time module B which, based on a hash value calculated on the binary data of the blobs thanks to a cryptographic encoding function, makes it possible to decide whether imported blobs should be added or not to the blob store,

 • A real-time C module differentiating transient state changes from other state changes, making it possible to compress the list of project creation history significantly, and reducing the impact on the amount of data stored on storage spaces, in memory and transiting on the network,

• A real-time D module exploiting the hash key guaranteeing the integrity of the data transmitted between the client applications and the server application, • A real-time E module using a learning algorithm

(machine learning) the data from the history of project creation to prioritize the order in which the server application delivers, as part of the update, blobs to different users and different client applications connected to the project,

 • A real-time F module preserving the history of project creation in the form of a series of backups of the total state of the project and of intermediate revisions relating to these states. The frequency of the backups of the total states being determined by an algorithm based on a machine learning module in real time exploiting the historical data,

 • A real-time G module allowing the user of the process through a user interface of the client application to mark with tags the key moments in the evolution of the project and to go back in time using these tags or not to easily restore the project to previous states, from which comparisons between different project states can be presented to the user for comparative purposes.

Optimization module for the management and viewing process of content by learning system using, among other things, historical data.

One of the functions of the method according to the invention is to view, in real time or delayed, 3D animation content constituted by a set of plans or clips organized in the form of sequences, as described above. The objective is to allow users of the process, on the client application side, to create the most complex content possible while maintaining the best viewing performance, that is to say with a higher frequency of display of images and sound or equal to 30 images per second for an image definition greater than or equal to the standard of image format known as Full HD. In this context, the device implements a module making it possible to optimize the process by which the data forming the content to be viewed are transformed into animated and sound images. The collaborative use of unified device generates large amounts of information on 1) the use of the device itself and 2) the content produced by the users of the device. This information collected by the server application includes 1) the creation history of the project, 2) metadata related to the use of the device and to the editing of the project 3) all the data of which the project is consisting. The creation history has already been presented above. Metadata can include metrics such as the memory size required to load a given 3D scene, the time it took to load this scene, the frequency of use of a scene or a given asset (how many times has it been edited by system users, how often does the scene appear in the sequences of the final animation content), etc. Users of the device also frequently view the different scenes and sequences making up the project; thus during these views, it is possible to collect information on the calculation time of each image for each scene, on the use of the memory which may vary depending on what is visible on the screen, etc.

 Note that it is the collaborative and unified nature of the device that allows 1) to generate new information and 2) to centralize it in the cloud, and that it is thanks to this that this optimization module can be implemented. The current devices which are neither collaborative nor unified have access only to some of this data and in a non-centralized manner and in fact, do not have the possibility of implementing the same process.

This data can vary depending on the client application used (that for smartphone or desktop computer for example) and the characteristics of the GPU and CPU of the system on which the client application is executed (memory quantity, number of cores, etc. .). Finally, note that when the final content of the project is played by the process (where the 3D scenes are displayed on the screen with sound according to the editing information defined in the steps implemented by the process to edit sequences), the process by which this content is calculated to be rendered is predictive since it is, in the most common case of the use of the process, linear (in contrast to so-called interactive content, the content of which changes when it is played as for example in the case of a video game). According to a mode of carrying out the method according to the invention, a machine learning algorithm uses all of the information available to it on the project (creation history, metadata collected over time by hardware configuration used, as well as the project data), to plan (schedule) and optimize the use of the resources of the system on which the client application is executed, in order to best guarantee that the content of the project is played in the required conditions (resolution of image, number of images per second, etc.). This resource optimization planning module defines the part of the method according to the invention is here called film engine, which will be referred to below under the term of movie engine. As an example, the method during an information gathering step detected that an S3 scene requires 3 seconds to be loaded and 5 GB of memory on the GPU; this scene appears 10 seconds after the start of the animation sequence (a Q1 sequence made up of 10 shots referring to 3 different scenes S1, S2 and S3): the process is therefore able to plan the loading of the scene at least 3 seconds before it is necessary to display it on the screen and at least 5 GB of memory on the GPU is free by the time the loading process begins, even if it means removing from memory data whose method n not immediately needed if necessary. The method therefore comprises a movie engine, the operation of which according to the main embodiment of the invention is as follows:

 • The server application collects the following information:

 • Metadata sent by the different client applications used for editing project content,

 • The creation history of the project

 • Project data.

 • The server processes and reorganizes this information into information packets relevant to the movie engine which are then sent to client applications (on the same principle as sending blobs),

• These information packets provide input to the movie engine whose task is to optimize the answer to the following problem: “What data to load and when to load it based on the hardware configuration on which the client application is executed, so as to guarantee uninterrupted real-time viewing.

 • The movie engine refines substantially permanently, and preferably at a frequency higher than the frequency of user events on the terminals, in real time, the answer to this problem based on the information which is sent to it continuously. by the server application. The movie engine explores different strategies by adapting the parameters of the problem in order to optimize its response in a process of continuous self-learning. So while a configuration S1 seems more efficient to a user of the system than a configuration S2, the movie engine can discover within the framework of this learning process that S2 by means of modifications to specific parameters of the system is actually more more efficient than S1. For example, one strategy may be to prioritize loading and unloading data from client storage space into and from GPU memory as quickly as possible rather than preserving as much data as possible in GPU memory as quickly as possible. as long as possible.

· The movie engine has alternative strategies to work around system limitations if the planning process is not sufficient to guarantee uninterrupted viewing. According to one embodiment of the method according to the invention, it can:

• Precompute before starting to view the content (and put in a buffer, ie a reserved memory space) parts of the content before they are played, when it has been detected only despite all possible optimizations, these parts of the project cannot, for example, be played in real time under the required viewing conditions. · Plan the calculation of the project in parallel on several GPUs when a single GPU is not enough and recompose the images calculated by these GPUs in a continuous video stream. These different options are part of the parameters that the movie engine can modify in its learning algorithm in order to offer the best possible response according to the constraints of the system (hardware configuration) and the project.

 The method according to the invention is also a connected method. Indeed, the collaborative nature of the project requires that the version of the project that is located on the server S to which the client applications are connected, ie the reference version of the project. Having all the project data (including its history) on the server allows you to develop a set of satellite applications that can either access the project data from the server or directly interface with the client application.

 These satellite applications can be thought of as another type of client application.

 To this end, the method according to the invention comprises a step of connecting a satellite application to the server. In a main embodiment of the invention a software solution is executed on a smartphone or a tablet equipped with augmented reality functionality. Also by way of example, a satellite application on the server S reads the data of the project P on the server S and displays the different scenes of the project on the application of the smartphone. The user of the application can then select one of the scenes of the project, then using the augmented reality system, deposit the content of this virtual scene Sv on any surface of the real world whose phone is able to know the position and orientation in 3D space (it is often in the simplest case a horizontal or vertical surface, such as the surface of a table or that of a wall). The 3D Sv virtual scene is then added to the video stream coming from the camera of the superimposed phone. The purpose of this device is to allow the user to play the 3D Sv scene and to be able to film it in augmented reality.

To do so, the application offers a camera recording function. When the application user activates this recording function, the movements of the camera in 3D space (which are provided by the augmented reality system) and the images of the video stream created are stored in the memory of the smartphone. . Once the recording is complete, the camera movements, the video images and all the other auxiliary data created by the augmented reality system (such as the so-called tracking points which are points of the real scene used by the augmented reality system to calculate the position and rotation of the smartphone in space) are saved in the P project on the server.

 This acquisition method notably allows the user to create animated virtual cameras for a 3D animation content project using a consumer device (smartphones or tablets).

 The computer-implemented method also includes, according to a particular embodiment, a step of connecting a real-time application to the client application. In this particular embodiment, it is possible to associate a motion capture system making it possible to record the positions and rotations of objects or members of living beings (body and face), to control a virtual counterpart on computer (camera, 3D model, or avatar). This method makes it possible to directly record the data captured on the server S in the project P; they are then immediately accessible to all client applications connected to the server.

 These different embodiments of the invention exploit two connection modes, one where the satellite application accesses the data of the project P on the server S via a network connection of the Internet type. The other in which a satellite application communicates directly with a client application (by a streaming system for example) leaving the responsibility for the client application to communicate with the server to access the project data on the server.

 The method according to the invention further comprises a second group of production steps called diffusion steps.

 These broadcasting steps include in one embodiment a local calculation and broadcasting step.

Also according to this embodiment, the user of the client application C which uses to execute this application a computer device of the desktop or portable computer type equipped with one or more central processing units (CPU) and one or more multiple graphics processing units (GPUs) can calculate animated sound sequences on the fly (in real time), locally, using the resources of these different processing units.

 The video and audio outputs created can be redirected to any viewing device connected to the computer such as a 2D screen and speakers or a virtual reality headset.

 In the case of a dynamic viewing system such as for example a virtual or augmented reality system where the user of the viewing system controls the camera, the information concerning the position and rotation of the camera provided by the viewing system is taken into account in the creation of the video and audio stream creating a feedback loop: the augmented or virtual reality system for example provides 3D information on the position and rotation of the real camera (smartphone or virtual reality headset) which allow the corresponding video and audio stream to be calculated on the computer to which it is connected, these streams being themselves connected to the respective video and audio inputs of the virtual or augmented reality system.

 According to a second embodiment of the invention, the calculation and streaming is carried out remotely from the server S.

 Also in this second embodiment, the same method as that described above is used but this time the video and audio stream is calculated on the server either offline (offline) or in real time.

 In offline mode audio and video streams can be saved in a video. In real-time mode, video and audio streams are calculated on the fly, dynamically and are broadcast (streaming) to another computer or electronic device connected to the server by a LAN (local) or WAN (Internet for example) type network. ).

In this version of the invention, it is possible to calculate a finalized version of the project, whether in offline form (offline) or in real time on as many processing units (CPU and GPU) as the infrastructure of the data center to which the server is locally connected allows this (note that insofar as the data of the P project which is on the server S is on the local network to which the processing units are also connected, access to this data is fast). It is also possible to use any solution calculating 3D synthetic images to create the finalized images of this content.

 In the offline version, a user can adapt the speed with which a finalized version of the film is calculated by increasing the number of processing units dedicated to this task.

 In the real-time version, a user of the process can access remote computing resources much greater than those available on his local computer (or the electronic device he uses to view content such as a smartphone or a tablet) in order to obtain a finalized version of the real-time content of quality much higher than the version he could obtain by exploiting the resources of his own computer.

 This latter embodiment of the invention allows the computing resources (the GPUs and the CPUs used in the calculation of the content) to be physically separated from the device for viewing this content. This device is different from the case of streaming video from a server to, for example, a smartphone via the Internet, where the content of the video is pre-calculated. In the case of the invention, it is a matter of calculating the content of the animation project on the fly, at the very moment when it is broadcast (streamed) to this smartphone.

 In this case, a protocol suitable for streaming real-time content such as RTSP (Real-Time Streaming Protocol in English) is required. The content of the project is calculated live, dynamically on demand. By dynamic, it is understood that the content of the project can be changed at the same time of its dissemination (which is of course not the case for a video). This is particularly necessary when the user of the process controls the camera as in the case of virtual and augmented reality. This is the same feedback loop as that described above, but in this version of the invention, the virtual or augmented reality system and the server S are connected by a LAN or WAN network (Internet for example).

The data on the position and rotation of the camera created by the virtual or augmented reality device are therefore sent to the server S via this network (input); this information is then used to calculate in direct on the fly, a video and audio stream on the server S which is returned (output) to the device by the network from which the information on the camera came.

 The possibility of dynamically modifying the animation content while it is being broadcast / streamed also makes it possible to adapt the content according, for example, to the preferences of each person watching it.

 In the main embodiment of the invention, one or more processing units (hereinafter called calculation group) are assigned to each person watching a version of the animation content so that each calculation group can create a different version of this content from the same S project. This solution is similar to the concept of asynchronous multi-casting in the broadcasting or streaming industry except that in the case described here, each video and audio stream generated and broadcast to each client connected to the streaming server is unique.

 Also it is possible to dynamically select objects from the scene as the film is viewed, to be able to interact with them.

 When a 3D animation film is pre-calculated the information concerning the composition of the scene is lost since the pixels as already indicated above, have no idea of the 3D models that they represent.

 This information can be saved at the pixel level in the form of metadata, thus transforming them into "intelligent pixels".

 When the content of the animation project is calculated on the fly, then broadcast in just-in-time flow, all the information on the content of the project is known since it exists on the server S. It is therefore sufficient for example for the user of the process indicate with the mouse or a touch screen the object he wishes to select; the information on the position of the cursor on the screen is then sent to the server, which deduces by a set of simple calculations, the 3D model that the user has selected.

It is then possible to send it additional information on this model or to offer it a set of services associated with this object (such as printing it in 3D, ordering it online, etc.). It is also possible to know the entire manufacturing history of this model (who created it, who modified it, etc.) The method according to the invention thus responds to the technical problems linked to the fragmented nature of non-real-time production pipelines, the absence of a collaborative solution, and the disconnection of the production process from the process of broadcasting 3D animation content. (whether real-time or not).

 The method according to the invention solves all of these technical problems in a global process dedicated more particularly to the creation of real-time 3D linear animation content for traditional media (television and cinema) and new media (reality and augmented).

 The present method according to the invention is designed specifically for the creation of linear animation content or more generally 3D narrative content which may contain elements of interactivity but which in any case are clearly distinguished from a video game. In this method, one or more users can, in a unified process, work in real time and in parallel on any aspect of 3D animation content (and / or mixing a variety of visual and sound sources such as example videos, digital images, prerecorded or procedurally generated audio sources, etc.) in simultaneous and remote collaborative mode using a variety of electronic and / or computer devices such as for example a smartphone, a tablet, a laptop or desktop, headset, or any other virtual or augmented reality system, and to stream that content through a variety of methods such as posting a video of the content to a video distribution platform or streaming '' a dynamic live video stream (i.e. generated on the fly, or created dynamically on demand) from a server to n'impo rte which interactive display device or not (virtual reality headset, smartphone or tablet screen, computer screen, etc.).

 According to a detailed embodiment of the invention described with reference to Figures 7 to 16, the method according to the invention, in other words the unified collaborative pipeline (CUP), can be implemented on a computer as described below .

1. Launch the client application: a user U1 launches the client application on a desktop computer equipped with a CPU and a GPU. This computer (also called terminal) is connected by a remote WAN type network to a server located in a data center or cloud platform, as shown in Figure 16.

 To identify himself on server S (on which the server application is located), U1 must provide a user identifier (username) and a password, figure 7, validated by the server application.

Creation / opening of a project: once connected, another screen, figure 8 is offered to U1 which allows it either to create a new content project or to open an existing project. The user U1 has the possibility of customizing the icon of the P project by dragging and dropping (drag-and-drop) an image stored on the local disk of the computer on the icon of the project 23.

 In the case of an existing project, the user U1 can click once on the icon of the project P for a preview of the content of the project in the form of a small video or teaser 24 for example of thirty seconds maximum, pre - calculated or calculated on the fly. Double-clicking on the P project icon opens it.

Creation / opening of 3D virtual scenes or animated and sound sequences: the opening of the project causes the synchronization of the data on the local disk of the terminal from the server. When the local version of the project is up to date (identical in all respects to the version saved on the server), another screen hereafter called the project editor is displayed, figure 1 1. It is divided vertically into two large spaces : on the left a list of virtual 3D scenes 51 and on the right a list of the sequences making up the film 52.

Each space has an icon which makes it possible to create either a new scene 54 or a new sequence 57.

The scenes and sequences are displayed as a series of cards 55 comprising an image of the scene or of the sequence chosen by the user U1 or in a random manner (thumbnail or snapshot) and the name of the scene or sequence which can be edited. . Scenes can be duplicated and deleted. Double-clicking on the map of a scene opens the scene for editing. Editing the animated scene: when user U1 opens a scene, a new screen is presented to it, Figure 12. This screen (hereinafter called the scene editor) offers a workspace from which the user can edit all aspects of a 3D virtual scene such as importing or modeling 3D models on site, importing or creating animations, importing cameras or creating new viewing angles from which the scene can be filmed (by having virtual cameras in the 3D scene), import or create light sources, videos, digital images, sounds, etc.

The scene editor presents a time bar which allows the user of the process to move in time of the scene. The content of the scene is visible through a kind of window open on the 3D scene, calculated in real time on the fly, which is called the viewport in English 71. When the user clicks on the camera icon in the toolbar, a window appears on the screen comprising the list, presented in the form of maps, of all the cameras already created in scene 82. Each map includes the name of the camera and a small image which represents an image of the scene taken from this camera. Double-clicking on one of these maps displays the 3D scene filmed from the selected camera in the viewport.

 The camera can be animated. To create a new camera, you have to move freely in the 3D scene, then when a point of view is suitable, click on the 'ne \ ri button of the cameras window 82 which has the effect 1) to add a map to the camera list, 2) create a new camera positioned in the 3D space of the scene at the desired location. Editing of a sound and visual sequence: once the user has created one or more scenes, he can return to the project editor, figure 1 1.

By double-clicking on the card representing a sequence 58, the user opens a new screen hereinafter called the sequence editor, FIG. 13. This screen allows the user to edit the content of a sequence. This screen is separated into three main sections: - a 3D window or viewport in English which is the usual terminology for those skilled in the art, allows the user to see the result of its assembly 91,

 - a list of all 3D scenes that can be used in the editing of sequence 92 and

 - a time bar or timeline in English which is the usual terminology for those skilled in the art, that is to say the space where the user will create his montage by putting plans end to end 93. The creation of 'A map on the timeline is operated by a drag-and-drop operation of a map representing a 3D scene (hereinafter SCN) from the section listing all the 3D scenes of the project, on the timeline.

By default, the plan thus created on the timeline has the same duration as the duration of the SCN scene. However, this duration can be adjusted as in any editing tool.

Finally it is necessary once the plan has been created to specify the angle of view from which the 3D SCN scene must be filmed as well as the version of the animation desired for this plan. By clicking on the map, as for example in reference 101, a window appears on screen 97.

 This window includes the list of cameras and animations of the 3D SCN scene. The user just has to choose the camera and the version of the animation he wants to use for this plan by clicking on the camera and animation icon representing his choice.

 Other elements such as audio sources can also be added to this timeline to add sound to the image. The viewport includes certain controls 99 which allow the user to play the sequence to check the result of its editing.

Watch the sequence in virtual reality: by activating the virtual reality function 100 in the sequence editor, it is possible to watch the sequence not only on the computer screen but also on a virtual reality headset connected to the user's computer. Play the film in its entirety: by activating the function of viewing the film, figure 14 from the project editor 53, the user has the possibility of playing the entire film, ie the sequences placed end to end . The sequences are played in the same order as the order in which they are arranged in the project editor 52.

Creation of an augmented reality virtual camera: the user launches a satellite application, with reference to FIG. 19, on a smartphone equipped with the augmented reality function, or any other suitable device.

 The application connects to the server S to read the project data P 1207, 1208. Then appear on the screen of the smartphone the list of scenes in the form of cards identical to those used for the project editor 1205.

 Via the touch screen of the smartphone, the user selects an SCN scene, the content of which he can then drop onto a surface of the real world to fix it there. The 3D virtual scene is then filmed by the phone as if it were part of the real world.

By activating the recording function 1201, it is then possible to record the movements of the smartphone in real 3D space while moving around the virtual scene.

 Once the recording is complete, the smartphone saves the information of the camera movement that has just been created on the S server by adding a new animated camera to the SCN scene of the project.

 This camera movement is then available in project P in the client application from the scene editor or the sequence editor.

Collaborative work: another user of the process below, named user U2, connects to the server S by launching the client application C2 on his own computer.

 By activating the project sharing function, with reference to FIG. 9, the user U1 can give the second user U2 access to the project P. The user U2 therefore has access to all the data of this project and can modify the content as desired. Whenever user U1 or user U2 edits the content of this project, the changes are immediately reflected or visible on the screen of the other user.

For example, user U1 creates a new scene from the project editor. This scene appears as a new card in the interface of the two users although it was user U1 who modified the project. The second user U2, who now also has access to this new scene, decides to open it to import a 3D model. The model is then visible and available both in the project of the second user U2, which has just imported it, but also in the project of the first user U1, which, however, has done nothing.

 The first user U1 decides to change the color of this object. This color change is also applied to the project model of the second user U2. This principle applies to all aspects of the project regardless of the number of users connected to the S server.

Manage different versions of a project thanks to the history, with reference to figure 15: users U2 and U1 can explore different versions of the same project P.

 By accessing the screen below named history editor from the client application 1 10, the second user U2 can create a second version P 'of the project below called branch 1 1 1. All the modifications carried out by the first user U1 in project P will no longer be visible to the second user U2 as long as he is working on project P '.

Conversely, the modifications made by the second user U2 on

P ’will not be visible to U1. By looking at the history editor it is possible to see that users U1 and U2 are working on two different branches, these branches being shown visually in an explicit manner, as shown in FIG. 15.

Users U2 and U1 thus work for some time but later realize that working on two versions of the project is no longer necessary. However, they want to integrate the modifications that were made to the second version of the P 'project in the P project. This operation can be carried out by selecting the two branches of P and P' projects and then performing a so-called merge operation, merge in English, which is the term used for those skilled in the art, which consists of taking the modifications made to the second P 'project and integrating them into the main version of the P project; the two projects have been merged and the modifications made to two projects since the creation of the P 'branch have been consolidated into a single version, the main version P.

 This merge operation is also shown explicitly in the history editor 1 15.

11. Play the film in augmented reality: a person launches a satellite application on a smartphone equipped with the augmented reality function. This person does not want to edit the content of a project but to watch it, as a spectator. This application connects to the S server and provides this viewer with a list of all the projects available. Thanks to the touch screen of the smartphone, he selects a project, then selects, using the graphic interface provided by the augmented reality application, a real world surface on which the computer-generated film will be played; such as the surface of a table.

 12. Calculate the film remotely on the server with dynamic content creation, with reference to Figure 18: the user U1 wants to show the result of his work on a tablet which however does not have the processing capacity necessary for the calculate on the fly in real time. The web page of an Internet browser allows him to see the list of available projects. Selecting one of these projects using the mouse, or using a touch screen or any other suitable device, does two things:

12.1. On the one hand an application or a service allowing to receive a real-time video stream; based on an RTSP-type real-time broadcast protocol and display it, is launched on the tablet. It can also be the web page from which the user accesses the list of projects, since the so-called video tag in HTML5 makes it possible to receive and display real-time video streams on a web page.

12.2. On the other hand, a streaming server is launched on the S server. It is an application that will calculate a finalized version of the project on as many processing units (GPU and CPU) as desired by the user, as a service parameter, then broadcast / stream the result of this just-in-time calculation to the user's tablet. The content of this incoming stream will then be displayed on the tablet screen using the process launched in the previous step (a). The user can interact with the content of the film watched. For example, it is possible to select an object on the screen using the mouse or the touch screen. The object is represented as a set of pixels on the screen, but the streaming application can know the model or 3D models represented by these pixels. The selected 3D model can therefore appear on the screen surrounded by a contour (to indicate that it is selected) and then a whole set of services associated with this object can be presented to it.

 As an example in particular:

 1. It is possible to customize the 3D model. Alternative versions to the selected model are offered to the user who can choose the one he prefers. The film continues to be viewed, but with the version of the model chosen by the user;

 2. Information about what the model represents can be displayed on the screen;

 3. The user can order a 3D print of the selected model.

 The broadcaster, that is to say the service in charge of broadcasting the content to the tablet, smartphone, etc. of one or more users of the service, can also modify the content of the project while it is being calculated and disseminated. In the case of the retransmission of a live sporting event, for example, it is possible to adapt the content of the animation according to the news of this event. In this case the modifications are made not by the service user but by the service operator (the broadcaster). It is possible to create as many personalized versions as users connected to the service.

 In order to manage the collaborative work of several users U1, U2, ... sharing the same part of the server application, in other words sharing the same set of process steps implemented by computer, the process also includes management steps access rights. To this end, the server includes user authentication steps. When a client application is implemented from a terminal, this application first connects to the server which implements the prior authentication step.

This authentication step then assigns a digital authentication token, which includes hashed authentication data, encrypted or encoded using any suitable technique known to those skilled in the art, and access right data, which will have been previously defined in a server database.

 In this way we can ensure that a user can only act on the process for a set of production steps that are authorized to him. In a conventional manner, authorizations of the administrator type can be provided, giving the right to implement production steps and management steps, an authorization of the producer type, giving for example rights for all of the production stages, and targeted authorizations, for example an authorizer authorization allowing only access for modification and creation at the animation stage of the produced content.

 The data of the animation content produced are all stored on the central server.

 Asset-type animation content data, as defined above, is stored in the form of large binary objects, known as Binary Large Objects, generally abbreviated by the acronym BLOB.

 This stored data is organized in the form of data groups, known in the technical field under the name of Data Pool.

 However, the data storage mode is not limited to this storage and referencing mode. Any other technical server storage solution that can be adapted to the invention.

Each data item is associated with a state R _n on the server. This state is associated with modifications, so that in the preceding state the same datum was in a state R _n -i which following a recorded modification known as Cn brought the object to the state R _n .

 The method according to the invention implements a step of managing editing and creation conflicts.

This management step is subdivided into two sub-steps: a conflict detection step and a conflict resolution step. The conflict detection step is linked to the history step in that it detects which concomitant actions of the history act on similar data stored in the central server.

 When two or more editing, modification or creation actions, carried out by production steps, are recorded by the history step on the server, and referring to identical or linked data, then l The conflict resolution stage is implemented.

 This conflict resolution step aims to give priority to the latest modifications, creations or deletions.

Consequently, by way of example, when an object is in a state R _n on the server, by extension one can also speak of state R _n of the server for the object in question.

A first user U1 on a first terminal makes a modification leading to changing a state via an action f bringing the server to a state R _P (which is written Rp = Rn-> p), event recorded in the history.

 A second user, working simultaneously on the same project and on the same object, or on a linked object, commands the server to change the state to Rf = Rn-> f, also saved in the history.

 In this situation, the conflict detection method detects that two concurrent states are mutually exclusive.

 To this end, the method then implements the conflict resolution step to determine which state the server should take, Rp, Rf or a different state.

 As noted, history creates a temporal relationship between events. In this situation, event p is recorded as prior to event f.

 By event p or f is meant the result of the implementation of a production step as described above.

 To resolve this conflict, the method implements a step of determining the exclusion of the event p.

 Also, the event p is excluded if it meets one of the following criteria:

- the event p deletes an object which has been deleted, modified, added or referenced by the event f; - event p adds an object which has been deleted, added or modified by event f;

 - the event p modifies a property of an object which has been deleted by the event f;

 - the event p modifies a unique property of an object which has also been modified by the event f;

 - event p adds a reference to an object which was deleted by event f;

 - the event p adds a reference to an object or a value for a property of an object which can have several values, which was added, deleted or changed by the event f;

 - the event p deletes a reference to an object or a value of an object that can receive several values for the same property having been added, deleted or changed by the event f;

 - the event p moves a reference to an object or a value of a property which can receive several values having been added, deleted or moved to the same property by the event f.

If event p falls into one of these cases, it is ignored, and the project is updated according to the last event f. Otherwise the event p is kept with the event f.

 The terminals then receive from the server an indication of updating the project, synchronizing the local data on the terminals with the state of the server according to the resolution of the conflict.

 Thus, it is possible to resolve in a simple and effective manner the editing conflicts having an impact on the process of producing content, in real time, while ensuring that these modifications are updated directly at all stages of production, and reflected in real time on all user terminals.

 The invention also relates to a computer system as shown in FIG. 16 comprising a server 1 105 and one or more terminals 1100.

A terminal 1100 includes a computer device composed of display systems, processing units of the CPU and GPU type or the like, and storage capacity to locally save a version of the P 1 102 project.

 The client application 1 101 according to the invention, which allows the content of this project to be edited, is executed on this device.

 The terminal is connected to the server S 1 105 by a local or remote network of LAN or WAN 1 106 type. In the case of a remote connection of WAN type, the server is said to be in the cloud (or in the cloud). The server S is itself composed of processing units (of CPU and GPU type) and of storage capacity 1,103 used to save on the server a version of the project P. The server application described in this innovation is executed on this server 1104. Several terminals are connected to the server via the network user 1, user 2, ..., user N.

 Figure 17 shows schematically the way in which a plurality of different content projects is synchronized with a plurality of different terminals.

 In the first step, a modification made to project P by a user on the terminal TA is first saved locally 1 ’then broadcast to the server 1. In the second step, the server saves this change in its own version of project 2.

 In the third and last step, the server distributes the modification to all terminals except the one from which it comes 3 which apply it in turn and save it locally 3 ’.

 At the end of this step, all versions of the project that exist on all terminals and on the server are identical, in other words the projects are synchronized.

 FIG. 18 is a representation of the module by which the content of a project can be calculated on the fly and broadcast in just-in-time flow to as many (interactive) display devices as necessary.

In the figure three types of interactive display devices are represented: a virtual reality headset 1 1 10 and the controllers associated therewith, a tablet or a smartphone equipped with augmented reality functions and touch screens 11 1 1, and a computer with a keyboard and a 1,112 mouse. The information generated by these various devices (such as the position of the virtual reality headset or the smartphone in the 3D space of the real world) is sent to the server to which they are connected 1 1 13.

 These servers are different from the project server S: they are servers known as streaming 1 1 15.

 They are connected to the S server via a local area network (LAN) which allows them to access project data quickly. There is one streaming server per display or viewing device. This allows each streaming server equipped with its own CPU and GPU processing units to calculate a single 1 1 14 video and audio stream that responds to inputs from the viewing system. Each flow is therefore potentially unique.

 FIG. 19 represents the module allowing a system equipped with augmented reality functions such as a smartphone or a tablet to connect to the server S by means of a software solution executed on this system in order to access the project data as per example, in this case, the 3D scenes of project P.

 In the example illustrated by this figure 19, in step 1, the 3D scenes are displayed on the screen of the smartphone in the form of 1205 maps.

 In step 2, the application then allows you to play and film these 3D scenes in augmented reality.

 In step 3, once the scene has been filmed, all the data captured by the augmented reality system such as for example the movement of the camera or the video are then saved on the server S 1 105.

Claims

1. Process of unified collaborative and real-time pipeline implemented by computer for the collaborative creation of animation content, characterized in that it comprises on the one hand stages of production and distribution of animation content in synthetic images intended to be implemented by a plurality of terminals in cooperation with a central server, and on the other hand, steps for managing this animation content adapted to allow the central server to centralize and manage all data produced at the production stage;

said stages of production of said unified real-time process comprising:

 - a step of creating an animation content project;

 - a step of creating one or more 3D scenes and one or more 3D sequences in said created project;

 - a step of opening and editing at least one 3D scene;

 - a step of opening and editing at least one 3D sequence created to mount said content in computer generated images;

 - stages of broadcasting animation content;

said management steps comprising:

 - a step of managing a production history, adapted to ensure the transmission and recording of the result of the implementation of production steps by a terminal to the central server;

 - a step of updating the project stored on said server based on said results of the implementation of production steps by a terminal transmitted during the step of managing the production history;

 - a conflict detection step adapted to be implemented on the server so as to detect when at least two production steps have created, modified or deleted, directly or via another linked data item, simultaneously at least one and the same stored data item on the central server;

- a conflict resolution step, when a conflict is detected in the previous step, capable of determining the creation or creations, modifications or deletions to be applied to said at least one datum for which a conflict is detected.

2. Method implemented by computer according to claim 1, characterized in that it comprises a step of real-time synchronization of the project between the central server and said terminals so that each terminal implementing the steps of production of the method receives all or part of the up-to-date project data as a function of all the modifications and creations made by all the terminals and the server, said synchronization step being adapted to be implemented by the server during operation in mode collaborative work and / or by said terminals when they connect to the server.

3. Method implemented by computer according to claim 2, characterized in that it comprises, for said steps of updating and synchronizing the project between the central server and said terminals, a plurality of data synchronization modules, said plurality of modules comprising:

 a real-time update module adapted to implement a cryptographic encoding function generating a hash key as a function of said project data, said real-time update module being adapted to determine whether data from the imported project must be saved by said terminals and the server;

 - a real-time optimization module able to detect changes in transient states of project data, and being adapted to compress said list of project creation history so as to reduce the amount of data transferred and stored by said terminals and the server;

 - a real-time control module using said hash key so as to control the integrity of the data transmitted between said terminals and the server,

- a real-time learning module, able to analyze data from the history of project creation, and to define an order of priority, according to which said server transmits and updates the data to said terminals; - a real-time versioning module, capable of preserving the history of project creation in the form of a series of backups of the total state of the project and of intermediate revisions relating to these states; said frequency of backups of the total states being a function of learning data from said real-time learning module;

 - a real-time marking module capable of authorizing a user of a terminal to mark with at least one tag a key stage in the development of the project, said marking module making it possible to restore said project to its state at the moment marking.

4. Method implemented by computer according to any one of claims 1 to 3, characterized in that it further comprises steps of access control management to prohibit or authorize the implementation of all or part of production and management steps at a terminal connected to the server.

5. A computer-implemented method according to any one of claims 1 to 4, characterized in that the conflict resolution step comprises a list of exclusion of a first result of the implementation of production by a first terminal, when a second result of the implementation of production steps by a second terminal has caused the detection of a conflict, the previous event being excluded if at least one of the following criteria is met:

 - the first result deletes an object that has been deleted, modified, added or referenced by the second result;

 - the first result adds an object that has been deleted, added or modified by the second result;

 - the first result modifies a property of an object which has been deleted by the second result;

 - the first result modifies a unique property of an object which has also been modified by the second result;

- the first result adds a reference to an object which has been deleted by the second result; - the first result adds a reference to an object or a value for a property of an object that can have several values, which has been added, deleted or changed by the second result;

 - the first result deletes a reference to an object or a value of an object that can receive several values for the same property having been added, deleted or changed by the second result;

 - the first result moves a reference to an object or a value of a property that can receive several values having been added, deleted or moved to the same property by the second result.

6. Method implemented by computer according to any one of claims 1 to 5, characterized in that it comprises an automatic learning module adapted to optimize the sequence of loading of data into the memory of said terminals in order to restore in animated image and sound the content of the project in real time on said terminals, according to the data of the creation history of the project, the project data and metadata generated by said terminals.

7. A method implemented by computer according to any one of claims 1 to 6, said stages of production and distribution of animation content, comprise a step of displaying in real time said animation content on a augmented reality device, such as a smartphone or tablet, connected to said server.

8. Server device comprising a network interface, a storage memory and a processor for implementing at least the management steps and / or the broadcasting and distribution steps of the animation content of the method according to any one of claims. 1 to 7.

9. An augmented reality assembly, comprising a server device according to claim 8 and an augmented reality device, such as a smartphone or a tablet, said server device implementing the steps of producing and broadcasting the animation content of the method according to claim 7.

10. Computer terminal for controlling a man-machine interface adapted to execute and / or carry out at least the production steps of the method according to any one of claims 1 to 7, and comprising a network interface for communicating with said server device according to the claim 8 or 9.

1 1. Computer system comprising a server device according to claim 8 or 9 and one or more computer terminals according to claim 10.

12. Storage medium readable by a computer having recorded on it instructions which control a server device and / or a computer terminal to execute a method according to any one of claims 1 to 7.