WO2020016526A1 - Procédé mis en oeuvre par ordinateur pour la création de contenus comprenant des images de synthèse - Google Patents

Procédé mis en oeuvre par ordinateur pour la création de contenus comprenant des images de synthèse Download PDF

Info

Publication number
WO2020016526A1
WO2020016526A1 PCT/FR2019/051796 FR2019051796W WO2020016526A1 WO 2020016526 A1 WO2020016526 A1 WO 2020016526A1 FR 2019051796 W FR2019051796 W FR 2019051796W WO 2020016526 A1 WO2020016526 A1 WO 2020016526A1
Authority
WO
WIPO (PCT)
Prior art keywords
project
server
data
real
result
Prior art date
Application number
PCT/FR2019/051796
Other languages
English (en)
Other versions
WO2020016526A4 (fr
Inventor
Jean-Colas PRUNIER
Original Assignee
Fairytool
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fairytool filed Critical Fairytool
Priority to US17/255,551 priority Critical patent/US20210264686A1/en
Priority to CA3102192A priority patent/CA3102192A1/fr
Priority to CN201980048030.0A priority patent/CN112449707A/zh
Priority to EP19759643.0A priority patent/EP3824440A1/fr
Publication of WO2020016526A1 publication Critical patent/WO2020016526A1/fr
Publication of WO2020016526A4 publication Critical patent/WO2020016526A4/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T19/00—Manipulating 3D models or images for computer graphics
    • G06T19/20—Editing of 3D images, e.g. changing shapes or colours, aligning objects or positioning parts
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T13/00—Animation
    • G06T13/20—3D [Three Dimensional] animation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T19/00—Manipulating 3D models or images for computer graphics
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T2213/00—Indexing scheme for animation
    • G06T2213/08—Animation software package
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T2219/00—Indexing scheme for manipulating 3D models or images for computer graphics
    • G06T2219/024—Multi-user, collaborative environment

Definitions

  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • assets are called assets.
  • a so-called layout stage (this term having no French-speaking equivalent for those skilled in the art).
  • a so-called animation stage It consists in animating the elements put in place during the layout using different methods.
  • 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.
  • 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.
  • 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 is the result of tens or even hundreds of thousands of modifications made by all the people contributing to its realization.
  • micro-modifications such as for example small adjustments on the color of a object, over the length of a shot in a montage
  • 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.
  • the production pipelines of the prior art pose many problems, including:
  • 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.
  • 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.
  • 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;
  • stages of production of said unified real-time process comprising:
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • an augmented reality device such as a smartphone or a tablet.
  • 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.
  • 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.
  • FIG. 1 and 2 are schematic views of a production pipeline of the prior art
  • FIG. 3 is a schematic view of the interactions between stages of production of a process according to an embodiment of the invention.
  • FIG. 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;
  • FIGS. 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.
  • FIG. 17 is a schematic view of a synchronization step according to an embodiment of the invention.
  • FIG. 18 is a schematic view of a group of diffusion and distribution steps according to one embodiment of the method.
  • FIG. 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.
  • 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 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • 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).
  • this content is calculated to be broadcast on virtual and augmented reality systems.
  • 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.
  • 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).
  • 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.
  • graphics processors GPUs
  • CPUs central processing units
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 client application 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.).
  • server application a remote application
  • S server the server application
  • the project data is encapsulated according to a protocol specific to the invention.
  • any standard protocol can be used (such as TCP / IP which is the protocol used for data exchange on the Internet).
  • TCP / IP which is the protocol used for data exchange on the Internet.
  • the terminal and the server form a local network (called LAN for Local Area Network).
  • the terminal and the server belong to different networks but can nevertheless communicate using an Internet type connection for example.
  • they form a so-called extended network or WAN (for Wide Area Network in English).
  • WAN 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.
  • the server application S 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.
  • 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.
  • the server application 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.
  • 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).
  • 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.
  • 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 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.
  • 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).
  • the 3D object is imported from the server blob store, saved in the client application blob store and added to the scene.
  • 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:
  • a client application 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.
  • 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.
  • a B1 bundle comprising mesh information describing a 3D model and three textures (T1 T2 and T3).
  • the user may import into the project a new version of the “bundle” B1 which we will call B2.
  • 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.
  • 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.
  • the method compares the hash value obtained with those of each of the blobs contained in the blob store:
  • 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.
  • the client application when the user imports blobs into the project, the client application proceeds in this way:
  • 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.
  • stages 5, 6 and 7 the three consecutive changes made to the color of an object, are very rapid.
  • 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.
  • the blobs are transmitted from the server application to the client applications according to criteria determined by the client applications.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • T Restores desired restoration time
  • the project is then restored to the state in which it was at the time ⁇ Restaure.
  • 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.
  • 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 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.
  • 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.
  • 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. .).
  • 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).
  • 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.
  • 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:
  • 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),
  • 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:
  • 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.
  • the method according to the invention comprises a step of connecting a satellite application to the server.
  • a software solution is executed on a smartphone or a tablet equipped with augmented reality functionality.
  • 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.
  • the application offers a camera 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. .
  • 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.
  • 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.
  • the method according to the invention further comprises a second group of production steps called diffusion steps.
  • broadcasting steps include in one embodiment a local calculation and broadcasting step.
  • 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.
  • CPU central processing units
  • GPUs graphics 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.
  • 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.
  • 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.
  • the calculation and streaming is carried out remotely from the server S.
  • audio and video streams can be saved in a video.
  • 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. ).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • RTSP Real-Time Streaming Protocol in English
  • the content of the project is calculated live, dynamically on demand.
  • 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.
  • 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.
  • one or more processing units 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.
  • This information can be saved at the pixel level in the form of metadata, thus transforming them into "intelligent pixels”.
  • 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.
  • 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.).
  • the method according to the invention in other words the unified collaborative pipeline (CUP), can be implemented on a computer as described below .
  • CUP unified collaborative pipeline
  • a user U1 launches the client application on a desktop computer equipped with a CPU and a GPU.
  • This computer also called terminal
  • This computer is connected by a remote WAN type network to a server located in a data center or cloud platform, as shown in Figure 16.
  • U1 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.
  • 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.
  • the opening of the project causes the synchronization of the data on the local disk of the terminal from the server.
  • 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 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.
  • 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.
  • 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.
  • sequence editor 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 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.
  • SCN 3D scene
  • 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.
  • 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.
  • 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.
  • the user 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 '.
  • 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.
  • 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.
  • 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.
  • 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.
  • the process also includes management steps access rights.
  • the server includes user authentication steps.
  • this application 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.
  • 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 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.
  • 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.
  • This conflict resolution step aims to give priority to the latest modifications, creations or deletions.
  • the conflict detection method detects that two concurrent states are mutually exclusive.
  • the method then implements the conflict resolution step to determine which state the server should take, Rp, Rf or a different state.
  • event p is recorded as prior to event f.
  • event p or f is meant the result of the implementation of a production step as described above.
  • the method implements a step of determining the exclusion of the event p.
  • the event p is excluded if it meets one of the following criteria:
  • 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.
  • 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.
  • 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.
  • the server 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.
  • a modification made to project P by a user on the terminal TA is first saved locally 1 ’then broadcast to the server 1.
  • the server saves this change in its own version of project 2.
  • 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 ’.
  • 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.
  • 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.
  • LAN local area network
  • 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.
  • step 1 the 3D scenes are displayed on the screen of the smartphone in the form of 1205 maps.
  • step 2 the application then allows you to play and film these 3D scenes in augmented reality.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Graphics (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Architecture (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Economics (AREA)
  • Data Mining & Analysis (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • General Business, Economics & Management (AREA)
  • Processing Or Creating Images (AREA)

Abstract

L'invention concerne un procédé mis en œuvre par ordinateur pour la création de manière collaborative et dans un processus unifié temps-réel, de contenus d'animation, caractérisé en ce qu'il comprend d'une part des étapes de production et de diffusion de contenus d'animation en images de synthèse destinées à être mises en œuvre grâce à l'action combinée d'une pluralité de terminaux et d'un serveur central, et d'autre part des étapes de gestion de ces contenus d'animation adaptées pour permettre au serveur central de centraliser et gérer l'ensemble des données produites au stade des étapes de production.

Description

Procédé mis en œuvre par ordinateur pour la création de contenus comprenant des images de synthèse
La présente invention se rapporte à un procédé mis en oeuvre par ordinateur pour la création de manière collaborative et dans un processus, aussi appelé pipeline, unifié et temps-réel, de séquences animées et sonores numériques comprenant des images de synthèse.
Dans le domaine de la création audio-visuelle, on oppose généralement le terme 2D, associé à l'animation traditionnelle par exemple réalisée par une succession d’images dessinées à la main ou à la vidéo, au terme 3D, correspondant à la création de séquences animées ou d'images fixes dont la création est le résultat de calculs généralement réalisés par un ordinateur. C'est pour cette raison que les images produites en 3D sont qualifiées d'images de synthèse.
Les séquences animées 3D peuvent être de deux types : précalculées ou temps-réel. Dans le cas des séquences précalculées les animations 3D sont calculées à l'avance et les contenus créés sont ensuite sauvegardés dans un fichier vidéo ou sous la forme d'une séquence d'images numériques. Une fois calculées, le contenu des images ne peut plus être modifié. Les séquences temps-réel sont calculées au moment de l’affichage, généralement par des processeurs dédiés dits GPU ou cartes graphiques spécialement conçus pour calculer des images de synthèse à très grande vitesse
Il est bien connu dans l’état de la technique qu’une fréquence de génération de ces séquences animées 2D ou 3D, précalculées ou temps-réel, est généralement d’au moins 24 images par seconde quelle que soit la taille de l’image, le nombre de sorties et la qualité sonore générée.
La réalisation de contenus en image de synthèse répond pour l’homme du métier à un ensemble de tâches distinctes dont les étapes principales sont, par ordre de réalisation habituelle, en référence à la figure 1 :
E1. Une étape de création de modèles 3D (un humain, un animal, un objet éventuellement articulé), étape aussi appelée modélisation ou en anglais surfacing. L’apparence du modèle comme la couleur de sa surface ou un aspect mat ou brillant par exemple, est aussi définie au cours de cette étape. Ces modèles sont appelés des assets.
E2. Une étape dite de layout (ce terme n’ayant pas d’équivalent francophone pour l’homme du métier). Au cours de cette étape on assemble et arrange les objets créés à l’étape précédente pour former des ensembles plus complexes. Autrement dit, on met en place des « scènes », au sens cinématographique, comprenant par exemple des décors et des personnages positionnés pour répondre aux besoins de l'histoire et à des considérations esthétiques. Plusieurs angles de vue sont sélectionnés pour filmer ces décors virtuels et les personnages 3D éventuels qui s’y trouveront.
E3. Une étape dite d’animation. Elle consiste à animer les éléments mis en place lors du layout au moyen de différentes méthodes.
E4. Une étape d’éclairage. Pour être visibles, les éléments composants les scènes issues du layout, filmés sous les angles de vue choisis à l’étape du layout, doivent être éclairés.
E5. Une étape de montage, au cours de laquelle les différentes scènes virtuelles filmées et animées depuis les différents angles de vue sont mises bout à bout pour former ce qui constitue le film.
Un procédé habituel de réalisation de contenu d’animation en images de synthèse, appelé pipeline de production, comprend aussi généralement, avant l’étape de montage E5, une étape de rendu, au cours de laquelle on applique des effets de matière et de texture aux éléments des scènes représentées afin de leur donner un aspect visuel conforment aux critères artistiques voulus.
Il existe d’autres étapes que nous n’avons pas décrites ici car elles ne sont pas strictement nécessaires à la réalisation d’un contenu d’animation linéaire. On peut citer par exemple l'étape dite des effets qui permet de créer des effets d’explosion, de fumée, de liquide, de feu, ou de simuler le mouvement des vêtements, etc., l’étape du compositing qui consiste à mélanger plusieurs sources d’image pour n’en former qu’une, et celle de l’étalonnage ( grading en anglais) qui consiste à modifier l’équilibre des couleurs d’une image pour en modifier son apparence. Par ailleurs, la réalisation d’un contenu narratif linéaire en animation est souvent précédée de la description de ce contenu sous une forme écrite (communément référencée sous le terme de script ou de scénario ou screenplay en anglais) et d’un storyboard, qui est une représentation de ce script sous la forme d’une succession d’images dessinées.
L’ensemble de ces étapes de travail constitue un procédé de production communément appelée pipeline de production.
Un tel pipeline de production est réalisé de manière séquentielle, linéaire et fragmentée. Or, chaque étape de ce pipeline requiert des outils informatiques, aussi appelés solutions logicielles, spécialisés et généralement indépendants les uns des autres ; de plus de tels projets impliquent généralement un grand nombre de personnes travaillant simultanément sur tous ces outils disparates.
En outre, les pipelines de production connus pour la réalisation de projet d’animation 3D professionnels pour des animations linéaires précalculées, tel qu’un film d’animation, ne sont généralement pas adaptés à la conception de contenus d'animation temps-réel linéaires ou nécessitant peu d'interactions pour des médias comme la réalité augmentée ou la réalité virtuelle.
Le processus de production de contenus d’animation (auquel on se référera plus généralement comme étant une animation 3D) est avant tout un processus créatif. Un tel processus créatif requiert qu’il soit possible par des itérations successives de tester, préférentiellement rapidement et souvent, des idées sur tous les aspects du médium.
Par exemple produire un contenu d’animation 3D linéaire, requiert qu’il soit possible à n’importe quel moment du processus de création, de faire des modifications aux étapes de la modélisation, du layout, de l’animation, de l’éclairage ou du montage car les résultats produits à chacune de ces étapes ont une incidence sur le résultat final ; autrement dit sur le contenu produit en fin de chaîne.
Un projet de long métrage d’animation 3D pour le cinéma par exemple est le résultat de dizaines voire de centaines de milliers de modifications faites par l’ensemble des personnes contribuant à sa réalisation.
Certaines de ces modifications sont mineures, dites micro-modifications, comme par exemple des ajustements de petite amplitude sur la couleur d’un objet, sur la longueur d’un plan dans un montage, ou majeures, dites macro modifications, comme par exemple décider de modifier l’apparence du personnage principal de l’histoire.
Les macro-modifications sont moins fréquentes que les micro- modifications mais elles sont plus visibles et ont un impact plus important sur le processus de création. Or, au regard de ces critères, les pipelines de production de l’art antérieur posent de nombreux problèmes parmi lesquels :
1. Parce qu’ils sont linéaires, une modification réalisée en amont de la chaîne de production, requiert de passer par toutes les étapes qui se trouvent en aval de l’étape où la modification est faite, avant de pouvoir être jugée dans le contexte du contenu final (en sortie de l’étape du montage). Le processus est similaire à celui d’un effet de domino ou de cascade : une modification en amont déclenche toute une série d’événements en aval jusqu’à atteindre la dernière étape de la chaîne. 2. Les outils utilisés aux différentes étapes de la production ne produisant pas de résultats en temps-réel et ne communiquant pas les uns avec les autres (de par la nature fragmentée du pipeline de production), les modifications apportées provoquent des pertes importantes de temps de production. Il n’est pas rare qu’une modification prenne plusieurs minutes, plusieurs heures, voire parfois plusieurs jours avant qu’elle ne puisse produire un résultat visible, notamment en fonction de sa position dans la chaîne de production.
Aussi un des problèmes bien connus est d'optimiser le processus de création de contenus d’animation 3D, principalement linéaires, qu’ils soient temps-réel ou précalculés, en assurant notamment qu’un grand nombre de personnes puissent travailler simultanément sur la production de ces contenus.
Pour résoudre les problème énoncés ci-dessus, nous proposons un procédé de pipeline unifié collaboratif et temps-réel mis en oeuvre par ordinateur pour la création de manière collaborative, de contenus d’animation, caractérisé en ce qu’il comprend d'une part des étapes de production et de diffusion de contenus d’animation en images de synthèse destinées à être mises en oeuvre par une pluralité de terminaux en coopération avec un serveur central, et d'autre part des étapes de gestion de ces contenus d’animation adaptées pour permettre au serveur central de centraliser et gérer l’ensemble des données produites au stade des étapes de production ;
lesdites étapes de production dudit procédé unifié temps-réel comprenant :
- une étape de création d’un projet de contenu d’animation ;
- une étape de création d’une ou plusieurs scènes 3D et d’une ou plusieurs séquences 3D dans ledit projet créé ;
- une étape d’ouverture et d’édition d’au moins une scène 3D ;
- une étape d’ouverture et d’édition d’au moins une séquence 3D créée pour monter ledit contenu en images de synthèse ;
- des étapes de diffusion du contenu d’animation ;
lesdites étapes de gestion comprenant :
- une étape de gestion d’un historique de production, adaptée pour assurer la transmission et l’enregistrement du résultat de la mise en oeuvre d’étapes de production par un terminal au serveur central ; - une étape de mise à jour du projet stocké sur ledit serveur en fonction desdits résultats de la mise en oeuvre d’étapes de production par un terminal transmis lors de l’étape de gestion de l’historique de production ;
- une étape de détection de conflits adaptée pour être mise en oeuvre sur le serveur de sorte à détecter lorsqu’au moins deux étapes de production ont créé, modifié ou supprimé, directement ou via une autre donnée liée, simultanément au moins une même donnée stockée sur le serveur central ;
- une étape de résolution de conflits, lorsqu’un conflit est détecté à l’étape précédente, apte à déterminer la ou les créations, modifications ou suppressions à appliquer à ladite au moins une donnée pour laquelle un conflit est détecté.
Ainsi, on obtient un procédé simple, unifié, collaboratif et connecté apte à gérer au sein d’un même applicatif la création et la diffusion de contenus d’animation comprenant des images de synthèse, adapté aux rendus précalculés ou temps-réel.
Avantageusement et de manière non limitative, le procédé comprend une étape de synchronisation temps-réel du projet entre le serveur central et lesdits terminaux de sorte que chaque terminal mettant en oeuvre les étapes de production du procédé reçoive tout ou partie des données du projet à jour en fonction de toutes les modifications et créations apportées par l’ensemble des terminaux et du serveur, ladite étape de synchronisation étant adaptée pour être mise en oeuvre par le serveur lors d’un fonctionnement en mode de travail collaboratif et/ou par lesdits terminaux lorsqu'ils se connectent au serveur. Ainsi, on peut s’assurer que toute personne utilisatrice travaillant depuis un terminal distant du serveur possède en permanence la dernière version du projet de contenu en cours, et ce même lorsqu’un grand nombre d’utilisateurs travaillent en simultané sur le projet.
Avantageusement et de manière non limitative, le procédé comprend pour lesdites étapes de mise-à-jour et de synchronisation du projet entre le serveur central et lesdits terminaux une pluralité de modules de synchronisation des données, ladite pluralité de modules comprenant :
- un module temps-réel de mise à jour adapté pour mettre en oeuvre une fonction d'encodage cryptographique générant une clef de hachage en fonction desdites données du projet, ledit module temps-réel de mise à jour étant adapté pour déterminer si des données du projet importées doivent être enregistrées par lesdits terminaux et le serveur ;
- un module temps-réel d’optimisation apte à détecter des changements d’états transitoires de données du projet, et étant adapté pour compresser ladite liste de l’historique de création des projets de sorte à réduire la quantité de données transférées et stockées par lesdits terminaux et le serveur ;
- un module temps-réel de contrôle exploitant ladite clef de hachage de sorte à contrôler l’intégrité des données transmises entre lesdits terminaux et le serveur,
- un module temps-réel d’apprentissage, apte à analyser les données de l’historique de création des projets, et à définir un ordre de priorité, selon lequel ledit serveur transmet et met à jour, les données auxdits terminaux ;
- un module temps-réel de versionnage, apte à préserver l’historique de création des projets sous la forme d’une série de sauvegardes d’état total du projet et de révisions intermédiaires relatives à ces états ; ladite fréquence des sauvegardes des états total étant fonction de données d’apprentissage dudit module temps-réel d’apprentissage ;
- un module temps-réel de marquage apte à autoriser un utilisateur d’un terminal à marquer par au moins une balise une étape clef de l'évolution du projet, ledit module de marquage permettant de rétablir ledit projet à son état à l’instant de marquage.
Ainsi, les étapes de mises à jour et de synchronisation sont fiables, robustes et rapides.
Avantageusement et de manière non limitative, le procédé comprend en outre des étapes de gestion de contrôle d’accès pour interdire ou autoriser la mise en oeuvre de tout ou partie des étapes de production et de gestion à un terminal connecté au serveur. Ainsi, on peut segmenter les droits de mise en oeuvre du procédé afin de limiter les interactions lors d’un travail collaboratif impliquant de nombreuses personnes. Le contrôle d’accès permet en outre de limiter les risques de modification ou de suppression de contenu par exemple accidentelle.
Avantageusement et de manière non limitative, l’étape de résolution de conflits comprend l’exclusion du projet d’un premier résultat de la mise en oeuvre d’étapes de production par un premier terminal, lorsqu’un deuxième résultat de la mise en oeuvre d’étapes de production par un deuxième terminal a généré la détection d’un conflit, l’événement antérieur étant exclu si l’un des critères suivants est rempli :
- le premier résultat supprime un objet qui a été supprimé, modifié, ajouté ou référencé par le second résultat ;
- le premier résultat ajoute un objet qui a été supprimé, ajouté ou modifié par le second résultat ;
- le premier résultat modifie une propriété d’un objet qui a été supprimé par le second résultat ;
- le premier résultat modifie une propriété unique d’un objet qui a aussi été modifié par le second résultat ;
- le premier résultat ajoute une référence à un objet qui a été supprimé par le second résultat ; - le premier résultat ajoute une référence à un objet ou une valeur pour une propriété d’un objet pouvant avoir plusieurs valeurs, qui a été ajoutée, supprimée ou changée par le second résultat ;
- le premier résultat supprime une référence à un objet ou une valeur d’un objet pouvant recevoir plusieurs valeurs pour la même propriété ayant été ajoutée, supprimée ou changée par le second résultat ;
- le premier résultat déplace une référence à un objet ou une valeur d’une propriété pouvant recevoir plusieurs valeurs ayant été ajoutée, supprimée ou déplacée dans une même propriété par le second résultat.
Avantageusement et de manière non limitative, le procédé comprend un module d’apprentissage automatique adapté pour optimiser la séquence de chargement des données dans la mémoire desdits terminaux afin de restituer en image animées et sonore le contenu du projet en temps-réel sur lesdits terminaux, en fonction des données de l’historique de création du projet, des données du projet et de méta-données générées par lesdits terminaux. Ainsi, on peut optimiser la bande passante utilisée entre les terminaux et le serveur ainsi que la mémoire occupée et le temps de calcul nécessaire tant côté terminal que côté serveur.
Avantageusement et de manière non limitative, lesdites étapes de production et de diffusion du contenu d’animation, comprennent une étape d’affichage en temps-réel dudit contenu d’animation sur un dispositif de réalité augmentée, tel qu’un smartphone ou une tablette, connecté audit serveur.
En particulier le procédé met en oeuvre une étape de création d’une caméra virtuelle adaptée pour un dispositif de réalité augmentée, ladite étape de création d’une caméra virtuelle étant mise en oeuvre après ladite étape d’ouverture et d’édition d’au moins une scène 3D.
L’invention concerne aussi un dispositif serveur comprenant une interface réseau, une mémoire de stockage et un processeur pour mettre en oeuvre au moins les étapes de gestion et/ou les étapes de production et de diffusion du contenu d’animation du procédé tel que décrit précédemment.
L’invention concerne aussi un ensemble de réalité augmentée, comprenant un dispositif serveur tel que décrit précédemment et un dispositif de réalité augmentée, tel qu’un smartphone ou une tablette, ledit dispositif serveur mettant en oeuvre les étapes de production et de de diffusion du contenu d’animation du procédé tel que décrit précédemment.
L’invention concerne aussi un terminal informatique pour commander une interface homme-machine adaptée pour exécuter et/ou réaliser au moins les étapes de production du procédé décrit précédemment, et comprenant une interface réseau pour communiquer avec ledit dispositif serveur décrit précédemment.
L’invention concerne aussi un système informatique comprenant un dispositif serveur tel que décrit précédemment et un ou plusieurs terminaux informatiques tels que décrits précédemment.
L’invention concerne aussi un support de stockage lisible par un ordinateur, par exemple un disque dur, un support de stockage de masse, un disque optique, ou tout autre moyen adapté, ayant enregistré sur lui des instructions qui commandent un dispositif serveur et/ou un terminal informatique pour exécuter un procédé tel que décrit précédemment.
D’autres particularités et avantages de l’invention ressortiront à la lecture de la description faite ci-après d’un mode de réalisation particulier de l’invention, donné à titre indicatif mais non limitatif, en référence aux dessins annexés sur lesquels :
- les figures 1 et 2 sont des vues schématiques d’un pipeline de production de l’art antérieur ;
- la figure 3 est une vue schématique des interactions entre des étapes de production d’un procédé selon un mode de réalisation de l’invention ;
- la figure 4 est une représentation graphique d’un projet de contenu d’animation en images de synthèse ;
- la figure 5 est une représentation d’une scène 3D connue de l’art antérieur représentée dans sa forme la plus classique par une série d’objets ou de modèles 3D, dits assets, comprenant chacun des propriétés permettant d’en modifier l’apparence ; - la figure 6 est une vue schématique de l’organisation des données d’un projet de contenu d’un procédé selon un mode de réalisation de l’invention ;
- les figures 7 à 16 sont des vues simplifiées d’interfaces utilisateur de la mise en oeuvre du procédé sur un ordinateur selon un mode de réalisation de l’invention ;
- la figure 17 est une vue schématique d’une étape de synchronisation selon un mode de réalisation de l’invention ;
- la figure 18 est une vue schématique d’un groupe d’étapes de diffusion et de distribution selon un mode de réalisation du procédé ;
- la figure 19 est une vue schématique d’un groupe d’étapes de diffusion et de distribution selon un autre mode de réalisation du procédé.
L’invention porte sur la conception d’un procédé dédié à la création, la production, la distribution et la diffusion de contenus d’animation linéaires ou plus généralement la création et la distribution de séquences animées et sonores en utilisant une variété de sources sonores et graphiques qui peuvent être combinées ensemble comme par exemple, des images de synthèse, aussi appelé contenu 3D, principalement, mais aussi des images numériques et des vidéos, dit contenu 2D, dans un processus, ou pipeline, qui soit à la fois unifié, temps-réel, collaboratif et connecté à d’autres méthodes de création de contenus d’animation temps-réel, notamment pour de la réalité augmentée.
Les séquences animées et sonores générées par cette invention peuvent être soit précalculées et sauvées dans des fichiers vidéo par exemple, soit calculées à la volée ce qui permet de les exploiter sur des systèmes de type réalité augmentée ou virtuelle ou n’importe quel autre système d’affichage ou de diffusion (comme par exemple le streaming) existant ou à venir pour lequel des séquences sonores et animées en images de synthèse doivent être calculées à la volée, en temps-réel (visualisation 3D temps-réel).
Le procédé mis en oeuvre par ordinateur selon l’invention comprend une pluralité d’étapes de production conduisant à la fabrication de contenus, pouvant être mises en oeuvre parallèlement et indépendamment les unes des autres. Le procédé selon l’invention est aussi appelé Pipeline Unifié Collaboratif ou en anglais Collaborative Unified Pipeline, auquel nous ferons référence dans la suite de ce document par l’acronyme CUP.
Dans la suite de la description on se référera à l’utilisateur du procédé comme toute personne, ou tout groupe de personnes, agissant sur le procédé mis en oeuvre par ordinateur selon l’invention, par l’intermédiaire d’un ordinateur ou de tout dispositif apte à communiquer avec l’ordinateur mettant en oeuvre tout ou partie du procédé.
Les différentes étapes de production, que l’on peut aussi appeler fonctions, sont décrites dans un premier temps séparément les unes des autres, puis présentées dans le cadre d'un mode de réalisation détaillé.
Le procédé selon l’invention comprend deux groupes d’étapes de production principaux : des étapes de création et d’édition et des étapes de diffusion.
Le premier groupe d’étapes de production est généralement mis en oeuvre sur les terminaux utilisateurs, tandis que le deuxième groupe d’étapes est dans ce mode de réalisation mis en oeuvre sur le serveur.
Le procédé comprend en outre un troisième groupe d’étapes appelé étapes de gestion, ces étapes étant conjointement mises en oeuvre par les terminaux et le serveur, ces étapes comprenant notamment les étapes d’historique et de résolution de conflit, qui seront décrites plus loin.
Le premier groupe d’étapes de production dites fonctions de création et d’édition comprend l’ensemble des étapes E1 -E5 de la production d’un contenu d’animation 3D, en référence à la figure 1 , depuis l’étape de la modélisation E1 jusqu’à l’étape finale du montage E5 telles que nous les avons décrites dans l’état antérieur de la technique.
Aussi le procédé selon l’invention mis en oeuvre par ordinateur permet de créer un contenu d’animation 3D temps-réel du début jusqu’à la fin, ce premier groupe d’étapes comprenant cinq étapes :
1. Créer ou ouvrir un projet de contenu d’animation ;
2. Création de nouvelles scènes 3D qui peuvent cependant contenir une mixité d’autres sources (comme des images numériques, des vidéos, etc.), et création de nouvelles séquences ; Ouverture et édition de scènes 3D créées à l’étape précédente. Dans cette étape l’utilisateur du procédé peut modéliser sur place ou importer des modèles 3D créés avec d’autres solutions, choisir des angles de vue (par l’intermédiaire de caméras virtuelles qui sont placées dans la scène), ajouter des lumières, et animer tous les objets de la scène (les modèles, les caméras, les sources de lumière, etc.) et toutes les propriétés de ces objets (comme par exemple la couleur d’un objet 3D). Une scène peut également contenir plusieurs versions de l’animation (ou take d’animation dans la terminologie de l’homme du métier) ;
Ouverture et édition des séquences créées à l’étape 1.2. Dans cette étape, l’utilisateur du procédé peut éditer le contenu d’une séquence. Le processus consiste à mettre un ensemble de plans bout à bout comme dans n’importe quelle solution de montage vidéo. À la différence des logiciels de montage vidéo, l’invention utilise en guise de plan non pas des vidéos mais les scènes 3D créées à l’étape précédente 1.3. Pour chaque scène utilisée dans le montage de la séquence, l’utilisateur doit au minimum spécifier la caméra ou l’angle de vue depuis lequel cette scène sera calculée.
Comme pour tout outil de montage cependant, l’ordre et la longueur des plans qui composent le montage peuvent être également changés. En résumé, un plan dans ce système est défini au minimum par une scène 3D, la version de l’animation qui doit être utilisée pour cette scène quand elle jouée, un angle de vue depuis lequel cette scène est filmée quand elle est jouée dans le montage, et les informations de montage habituelles comme la position du plan dans le montage, sa durée, et son point d’entrée et de sortie.
4.1. Il est possible de créer une séquence à partir d’un enchaînement de plans utilisant une seule et même scène 3D filmée depuis des angles de vue différents.
4.2. Il est également possible d’utiliser plusieurs scènes 3D dans la même séquence. La possibilité de mixer différentes scènes dans une seule et même séquence est une caractéristique de l’invention ; 5. Jouer le contenu en jouant les séquences créées et éditées à l’étape 4 précédente.
5.1 . Dans un premier mode de réalisation de l’invention, le contenu du projet est calculé en 2D pour être projeté sur l’écran de l’ordinateur sur lequel le système est exécuté (il peut également s’agir de l’écran d’une tablette ou d’un smartphone ou de n’importe quel dispositif de projection connecté à l’ordinateur).
5.2. Dans un deuxième mode de réalisation de l’invention, non exclusif du premier, ces contenus sont calculés pour être diffusés sur des systèmes de réalité virtuelle et augmentée.
5.3. Dans une troisième mode de réalisation de l’invention qui est décrit en détail dans la suite du document, le contenu peut être calculé à la volée sur un ou plusieurs processeurs et le résultat, la sortie vidéo et audio, diffusé (ou streamé selon un néologisme issu de l’anglais fréquemment employé par l’homme du métier) vers un autre dispositif électronique/informatique.
Notons que les scènes, les séquences, et le contenu finalisé constitué par l’ensemble des séquences, sont joués en temps-réel et peuvent être calculés comme nous venons de l’indiquer pour s’adapter aux contraintes de n’importe quel système d’affichage que ce soit un écran d’ordinateur, de smartphone ou de tablette, un système de réalité virtuelle ou augmentée, ou tout autre dispositif adapté.
Comme il s’agit de scènes 3D filmées depuis un angle de vue choisi par l’utilisateur du système, celles-ci sont calculées à la volée. Le fait que les images ne soient pas précalculées comme dans le cas des vidéos est un élément clef de l’invention, puisque cela permet à l’utilisateur du système de modifier n’importe quel élément du projet à n’importe quelle étape de la fabrication et de la diffusion du contenu, par exemple la position d’un objet dans une scène, la position d’une caméra, la position et l’intensité d’une source de lumière, l’animation d’un personnage, le montage d’une séquence, en utilisant n’importe quel système d’affichage et de pouvoir voir le résultat de ses changements en temps-réel. Toutes ces étapes peuvent être exécutées par le seul procédé mis en oeuvre par ordinateur selon l’invention qui, associé à un système de succession d’affichage d’écrans d’interface homme-machine, permet à l’utilisateur de passer d’une étape à une autre de manière fluide.
Autrement dit, ce système d’écran ou de navigation a été conçu pour réunir l'ensemble des étapes de la fabrication d’un contenu d'animation 3D dans un seul et même procédé, autrement dit dans une seule et même solution, afin de permettre à l’utilisateur de travailler sur n’importe quel aspect du film (le layout, le montage, l’éclairage, l’animation, etc.) en parallèle et avec un retour temps-réel (prochain point).
En effet, le procédé selon l’invention est un procédé temps-réel. Pour ce faire, le procédé s’appuie sur deux éléments :
La solution du pipeline unifié décrite ci-dessus (1 ) tire parti des capacités des processeurs graphiques (GPU) qui ont été conçus pour accélérer des tâches comme le calcul des images de synthèse ou le calcul des déformations d’objets 3D animés dont le traitement informatique se prête bien à des architectures de calcul de type massivement parallèle. L’usage de processeurs graphiques (GPU) n’exclut pas dans la solution l’usage d’unités centrales de traitement (CPU). Les ressources de traitement informatique requises par la solution sont bien supérieures à celles exigées par une solution logicielle conçue pour l’édition de texte (la solution rentre dans la catégorie nommée « data-intensive computing » en anglais). Il est donc préférable de pouvoir exploiter toutes les ressources disponibles du dispositif informatique/électronique sur lequel la solution est exécutée, ce qui implique de combiner les capacités de calcul du ou des CPU et GPU disponibles sur le dispositif informatique où la solution est mise en pratique.
Le procédé selon l’invention est adapté de sorte à permettre un fonctionnement de mise en oeuvre collaboratif.
À cet effet le procédé selon l’invention permet à plusieurs utilisateurs de travailler en même temps sur le même contenu/projet/film d’animation 3D et de voir en temps-réel les changements réalisés par l’ensemble de ces utilisateurs.
Le procédé permet donc de faire du travail collaboratif simultané à distance. Aussi, le procédé est partiellement mis en oeuvre sur un serveur qui centralise les données, tandis qu’une autre partie du procédé est mise en oeuvre sur des terminaux, par exemple des ordinateurs de bureau, des tablettes ou des smartphones. La partie centralisée du procédé étant commune pour la mise en oeuvre du procédé par l’ensemble des terminaux d’un même projet de contenu d’animation 3D.
Dans une version préférée de l’invention, les utilisateurs ont accès aux données du projet grâce à une solution logicielle (ci-après nommé application client) exécutée sur leur terminal, autrement dit sur leur dispositif informatique dont l’utilisateur se sert pour travailler.
Le terminal est une unité de traitement informatique complète qui dispose d’une ou de plusieurs unités centrales et graphiques de traitement ainsi que d’un ou de plusieurs dispositifs de sortie vidéo et audio qui permettent d’afficher des images et de jouer des sons sur une variété de dispositifs (écran d’ordinateur, casque de réalité virtuelle, haut-parleur, casque audio, etc.).
Au démarrage de l’application, le programme informatique (application client) exécuté sur le terminal, se connecte à une application distante (ci-après nommé application serveur), qui est elle-même exécutée sur le serveur du réseau auquel le terminal est connecté (ci-après nommé serveur S).
Pour permettre aux applications client et serveur de traiter les données qu’ils envoient et qu’ils reçoivent, les données du projet sont encapsulées selon un protocole spécifique à l’invention.
Pour le transit des données encapsulées sur le réseau, n’importe quel protocole standard peut être utilisé (comme par exemple TCP/IP qui est le protocole utilisé pour les échanges de données sur Internet). Dans une version préférée de l’invention, le terminal et le serveur forment un réseau local (nommé LAN for Local Area Network en anglais).
Dans une autre version de l’invention, le terminal et le serveur appartiennent à des réseaux différents mais peuvent néanmoins communiquer grâce à une connexion de type Internet par exemple. Ils forment dans ce cas un réseau dit étendu ou WAN (pour Wide Area Network en anglais). Une session de travail est créée dès lors qu’au moins un client est connecté au serveur ; le nombre d’applications client se connectant au serveur dans une session de travail n’a pas de limite supérieure.
Cette division permet à l’application client Ci d’envoyer à l’application serveur toutes les modifications faites à un projet P depuis le terminal T 1.
Quand elle reçoit une modification, l’application serveur S exécute deux tâches : 1 ) elle applique cette modification à sa propre version du projet 2) elle diffuse cette modification à l’ensemble des clients avec lesquels elle partage une connexion C2, C3, ... , CN à l’exception du client d’où provient la modification, ce qui permet à ces applications client de l’appliquer à leur propre version du projet.
Toutes les versions du projet, que ce soit celles maintenues par les différentes applications client Ci , C2, C3,..., CN OU celle maintenue par l’application serveur S sont alors à jour ou synchronisées.
Tous les utilisateurs du procédé qui sont distants les uns des autres et travaillent sur des terminaux différents ont donc en permanence la même“vue" sur le projet P.
Dans la présente description on entend par application client, l’ensemble des étapes du procédé mises en oeuvre sur le terminal de l’utilisateur, par opposition à l’application serveur, correspondant aux étapes mises en oeuvre sur le serveur central S.
Dans cette version de l’invention, il existe autant de copies (locales) du projet P que de terminaux, en plus de la copie du projet se trouvant sur le serveur ; dans une session de travail, toutes ces copies sont identiques.
Lorsqu’une nouvelle application client est lancée et que la version du projet Pc qui se trouve sur le disque du terminal n’est pas la même que la version Ps qui se trouve sur le serveur, l’application serveur procède alors à une étape de synchronisation, au cours de laquelle elle envoie à l’application client toutes les modifications nécessaires à la mise à jour du projet Ps de sorte qu’à la fin du processus, le projet Pc soit identique à Ps.
Le procédé mis en oeuvre comprend en outre une fonction d’historique, une fonction connectée et des fonctions de distribution. La fonction d’historique est mise en oeuvre de sorte que toutes les modifications apportées au projet, par tous les utilisateurs agissant sur leurs terminaux distants, simultanément ou non, depuis sa création sont sauvegardées sur le serveur S, puisqu’à chaque fois qu’un utilisateur effectue une modification, qu’il s’agisse d’un changement mineur ou majeur, cette modification est envoyée au serveur qui l’enregistre localement avant qu’il ne la diffuse à son tour selon le procédé qui vient d’être expliqué. L’utilisateur du procédé n’a donc pas besoin techniquement d’enregistrer les modifications apportées pour préserver ses changements.
Les données de l’historique des changements d’un projet sont sauvegardées dans la mémoire de l’application serveur mais également sur l'espace de stockage, par exemple dans un disque dur, qui lui est associé.
Les données de l’historique peuvent être divisées en deux grandes catégories.
Le premier type de données est représenté par toutes les assets importées ou créées dans le projet par les utilisateurs. Une asset étant un terme anglophone bien connu de l’homme du métier et comprenant notamment des modèles 3D, des images ou textures, des sons, des vidéos, des matériaux, etc.
Dans le procédé selon l’invention, ces données sont décrites comme des blobs (acronyme de Binary Large Objects) pouvant aller de quelques kilooctets à plus d’un millier de mégaoctets (gigaoctet).
Ces blobs sont stockés sur l’espace de stockage du serveur sous la forme de données binaires.
Le deuxième type de données est représenté par des objets auxquels sont rattachés des propriétés.
Un objet est défini comme un ensemble de paires clef-valeur dite propriété. Chaque propriété contient soit une valeur, soit une référence (vers un blob ou un autre objet), soit multivaluée (liste de valeur ou de références).
Ainsi par exemple un objet de type“objet 3D” référence un blob contenant les informations de maillage d’un modèle 3D et des propriétés comme la position de cet objet dans une scène 3D, ainsi que des références vers les matériaux qui lui sont assignés. Un matériau est un autre exemple d’objet qui contient des informations sur l’apparence d’un modèle 3D comme sa couleur ou sa brillance, chacune de ces propriétés pouvant contenir soit une valeur constante soit une référence à des blobs de type texture.
La quantité de mémoire nécessaire au stockage de ce type d’information sur le disque du serveur est relativement négligeable en comparaison de la taille des blobs.
Ces deux types de données diffèrent par leur taille mais également par leur fréquence d’édition. Les données de type blob sont plus rarement ajoutées au projet que les données du second type dont l’édition est par contre beaucoup plus fréquente. Changer la couleur d’un objet par exemple peut se faire dans un processus itératif en temps-réel, entraînant des dizaines voire des centaines de changements par seconde. Ces données peuvent être vues comme représentant l’historique de création du projet.
Voici par exemple une séquence possible de changement de ce type : 1.Créer une nouvelle scène
2. Renommer la scène en“SCN_1”
3. Ajouter un objet 3D importé dans SCN_1
4. Changer la position de cet objet
5. Changer le couleur de cet objet (rouge)
6. Changer la couleur de cet objet (vert)
7. Changer la couleur de cet objet (bleu)
8. Ajouter une texture de couleur à cet objet.
À ce stade de la création du projet, le projet est donc constitué d’un historique d’édition comprenant les étapes 1 -8 et de deux blobs sauvegardés à la fois sur le disque dur du serveur mais également sur celui de l’application client dans ce que nous appelons dans l’invention un blob store (entrepôt de blobs).
Grâce à ces informations il est possible par exemple de mettre à jour le projet d’un second utilisateur U2 se connectant au serveur après que les changements réalisés par U1 aient été enregistrés.
En appliquant les tâches d’édition de l'historique sur le projet du second utilisateur U2, son projet peut être mis à jour. Par exemple :
1. Une nouvelle scène est créée dans la copie locale du projet de U2, 2. Cette scène est renommée SCN_1
3. L’objet 3D est importé depuis le blob store du serveur, sauvegardé dans le blob store de l’application client et ajouté à la scène.
4. La position de l’objet est changée,
5. La couleur de l’objet est changée (rouge),
6. La couleur de l’objet est changée (vert),
7. La couleur de l’objet est changée (bleu),
8. La texture est importée depuis le blob store du serveur, sauvegardée dans le blob store de l’application client et ajoutée à la scène
Le procédé selon l’invention comprend des modules adaptés à la fonction collaborative et à la génération de l'historique de la solution qui en découle. Ces modules sont les suivants :
- gestion des mises à jour : on distingue 1 ) les mises à jour dans la cadre d’une session de travail collaboratif en temps-réel (c’est à dire lorsque plusieurs applications client sont déjà connectées au serveur) et 2) des mises à jour réalisées lorsqu’une application se connecte au serveur après un temps de déconnexion :
1 . Les changements provenant d’une application client sont envoyés à l’application serveur qui les sauve localement (dans un processus décrit ci-dessous) puis les renvoie aux autres applications clients connectées qui exécutent alors ces changements localement. Nous sommes dans une logique de“push” : le serveur pousse les changements.
2. Lorsqu’une application client se connecte au serveur après un temps de déconnexion (ou pour la première fois), elle obtient du serveur un état du projet (via un module décrit ci-dessous) qui lui permet d'établir la liste de tous les blobs ayant été ajoutés à ce projet depuis sa dernière connexion. L’application client est alors en mesure d'établir les blobs manquants en comparant cette liste avec la liste des blobs déjà présents dans son blob store local. Seuls les blobs manquants sont ainsi renvoyés par l’application serveur à l’application client. Nous sommes dans une logique de“pull” : c’est le client qui demande la liste des données dont il a besoin pour se mettre à jour. - gestion des blobs : lorsque des données de type binaires sont ajoutées au projet, il arrive parfois à un utilisateur de les ajouter plusieurs fois de suite. En effet les données binaires sont parfois associées sous forme de « bundles » ou paquet.
À titre d’exemple un bundle B1 comprenant des informations de maillage décrivant un modèle 3D et trois textures (T1 T2 et T3). Dans une étape de travail ultérieure, il se peut que l’utilisateur importe dans le projet une nouvelle version du“bundle” B1 que nous appellerons B2.
Dans ce nouveau bundle B2, seule la texture T3 est différente des fichiers contenus dans le bundle B1. Il est donc relativement inefficace de réimporter dans le projet les informations de maillage de l’objet 3D ainsi que les textures T1 et T2, seul T3 devant faire l’objet d’une mise à jour. L’espace de stockage et l’utilisation de la bande passante nécessaire pour transférer les informations binaires vers le serveur, puis depuis le serveur vers les applications client étant coûteux et limités, il est nécessaire de ne faire transiter et de ne stocker que les données nouvelles.
Le procédé selon l’invention comprend donc un module permettant de calculer sur la base des informations que le blob contient une signature unique. Dans le mode de réalisation principal de l’invention, nous utilisons une clef de type sha ou valeur de hachage, c’est à dire une clef obtenue par une fonction de hachage cryptographique qui génère une empreinte unique à chaque blob du projet.
La fonction qui génère cette valeur de hachage utilise en entrée les données binaires des blobs.
Lorsque le sha pour un blob est calculé, le procédé compare la valeur de hachage obtenue avec celles de chacune des blobs contenus dans le blob store :
• Si le procédé trouve un sha dans le blob store avec la même clef, il en est déduit que le blob existe déjà dans le projet, et qu’il n’est donc pas nécessaire de l’importer.
• Si le sha n’existe pas encore, alors le blob est importé. Selon certains modes de réalisation de l’invention, la capacité du stockage et de trafic internet du côté serveur sont limités. L’utilisateur doit donc faire bon usage de cette capacité de stockage et de bande passante et le système doit par conséquent l’informer de l’impact qu’une opération d’import peut avoir sur l’utilisation du quota d’espace disque et de trafic qui lui est réservé.
Ainsi selon un mode de réalisation particulier du procédé selon l’invention, lorsque l’utilisateur importe des blobs dans le projet, l’application client procède de la sorte :
1.Tous les blobs contenus dans un bundle (le paquet importé) sont lus en mémoire et une valeur de hachage est calculée pour chaque blob du bundle. Si le blob existe dans le blob store il est ignoré. Si le blob n’existe pas, sa taille est ajoutée à la taille totale des données que l’utilisateur souhaite importer.
2. Une fois que tous les blobs d’un bundle ont été analysés selon le processus décrit ci-dessus, on obtient la taille totale des données à importer dans le projet et donc à stocker sur le serveur. Ce chiffre peut ainsi être présenté à l’utilisateur à travers une interface utilisateur. Si l’utilisateur réalise que la quantité de données à importer dépasse la capacité de stockage restante sur le serveur ou qu’elle est trop importante (du fait d’une erreur de manipulation par exemple) il peut décider d’annuler le processus d’import ou d’augmenter la taille de stockage sur le serveur. Dans le cas contraire, il peut confirmer l’import. Si l’import est confirmé par l’utilisateur, les données sont alors transférées vers le serveur et deviennent alors accessibles aux autres utilisateurs du projet.
Ce module d’import en deux étapes a été créé dans le contexte de la mise au point des fonctions collaboratives du procédé selon l’invention et lui est spécifique. - gestion de l’historique de création : dans l’exemple donné ci-dessus, plusieurs étapes de l’historique représentent des modifications successives et potentiellement très rapides, par exemple de l’ordre de quelques millisecondes, d’une propriété du projet ou de l’application client. Par exemple, dans les étapes du projet U2 exposé précédemment, les étapes 5, 6 et 7, les trois changements consécutifs réalisés sur la couleur d’un objet, sont très rapides. Lorsque des modifications sont faites sur une propriété d’un objet de manière rapide, l’intention de l’utilisateur est de passer de l’état Eo dans lequel se trouve cette propriété avant qu’elle ne soit changée, à l’état Ei à l’étape 5, puis à l’état E2 à l’étape 6, puis enfin à l’état E3 à l’étape 7.
Ces modifications étant réalisées en temps-réel (elles ne demandent que quelques millisecondes pour être exécutées), elles n’apparaissent à l’utilisateur que comme une succession continue, ou un flux constant de changements. L’utilisateur arrête le processus itératif à l’état E3. Il est donc possible de considérer que l’intention de l’utilisateur est de passer de Eo à E3 et que les états E1 et E2 ne sont que des états intermédiaires dit transitoires, par lesquels l’utilisateur passe avant de s’arrêter sur l’état final souhaité (E3). Un état est dit transitoire lorsque sa durée de vie est très brève (quelques millisecondes seulement). Le procédé met en oeuvre les étapes suivantes :
• Envoi des révisions en temps-réel par le serveur aux applications client dans une session d'édition collaborative : lorsqu’un utilisateur U1 déplace un objet dans une scène S1 , et qu’un autre utilisateur U2 édite le contenu de la même scène S1 en même temps, U2 voit l’objet se déplacer comme il se déplace dans la scène de l’utilisateur U1. Cela est possible car toutes les révisions qu’elles soient transitoires ou non sont envoyées au serveur qui les renvoie sans attendre à l’ensemble des applications clients utilisées pour éditer le contenu du projet.
• Sauvegarde des révisions dans l’historique de création du projet : lorsque l’utilisateur arrête de modifier une propriété du système (ce qui se produit lorsque la modification suivante concerne une autre propriété du système ou lorsque la propriété concernée arrête d’être modifiée pendant un temps donné), l’application serveur compresse la liste de révisions pour en supprimer les états transitoires et la remplacer par une révision faisant passer la propriété de l’état Eo directement à l’état E3, selon notre exemple, et c’est le résultat de cette compression qui est sauvé dans l’historique de création du projet. En termes généraux, lorsqu’une propriété du système passe d’un état EN à un état EN+P OÙ P est le nombre d’états transitoires, la partie du procédé en charge de la gestion de l’historique ne préserve pas dans l’historique les P états transitoires mais une seule modification permettant de passer de l’état EN à l’état E N+P directement. Cette méthode de compression, peut être mise en oeuvre par le procédé selon l’invention, soit sur l’application client soit sur l’application serveur.
- gestion par l’application serveur des blobs corrompus : il arrive parfois que certains blobs transmis par le réseau depuis les applications clients vers le serveur n’arrivent au serveur que de façon partielle ou modifiées. Les raisons pour lesquelles un blob peut être corrompu sont multiples : l’application client qui envoie les données s’arrête inopinément, coupure internet, attaque informatique, etc. Pour remédier à ce problème, le procédé met en oeuvre les étapes suivantes :
• Étape 1 : l’application client calcule la valeur de hachage H B d’un blob B et envoie une requête à l’application serveur lui signifiant qu’elle s’apprête à lui envoyer un blob avec une valeur de hachage H B. Immédiatement après, l’application client commence à envoyer les données du blob B en relation avec cette requête.
• Étape 2 : lorsque le serveur cesse de recevoir les données associées au blob B, il considère que les données ont été transmises en intégralité. Il calcule alors la valeur de hachage du blob côté serveur H’B en utilisant le même algorithme que celui utilisé par l’application client. Si la valeur de hachage H’B est égale à celle envoyée par l’application client (H B), le serveur a la garantie que les données du blob B sont complètes et intègres et le processus s’arrête à cette étape. Si la valeur est différente, le serveur passe à l’étape 3.
• Étape 3 : dès que l’application serveur rétablit une connexion avec l’application client, elle lui envoie une requête lui demandant de renvoyer les données pour le blob dont les données sont incomplètes.
L’application serveur envoie la même requête à toutes les applications client partageant le même projet, dans l’hypothèse où l’une des applications client serait en possession du même blob et où l’application client qui a envoyé le blob initialement, serait indisponible. L’application serveur répète l’étape 3 jusqu’à ce qu’il obtienne une copie complète des données du blob. Par ailleurs, le serveur n’envoie pas les données relatives au blob B aux autres applications clients tant que la copie sauvegardée côté serveur n’est pas complète.
Ce module qui reprend la valeur de hachage utilisée pour la gestion du blob store, est important car il garantit la fiabilité de la fonction collaborative du procédé selon l’invention. Par ailleurs le cas précédent décrit le module lorsque les données transitent de l’application client vers l’application serveur, mais le même module est exploité lorsque des données sont transmises (dans le cas d’une mise à jour par exemple) depuis l’application serveur vers n’importe quelle application client.
-“Priorisation" des blobs : selon un mode de réalisation du procédé selon l’invention, les blobs sont transmis depuis l’application serveur vers les applications clients en fonction de critères déterminés par les applications client. Plusieurs cas de figures peuvent se présenter :
• La bande passante de l’application est peu sollicitée : dans ce cas, les blobs sont envoyés par l’application serveur à l’application client dans l’ordre où les blobs sont arrivés sur le serveur donc sans“Policy” ou stratégie particulière.
• Après quelques heures ou quelques jours de travail sur un projet, il n’est pas rare que l’état du projet ait considérablement changé. Un utilisateur qui se reconnecte au projet après un long moment d’absence doit attendre que tous les nouveaux blobs du projet soient transférés depuis le serveur sur son terminal avant de pouvoir reprendre le travail. Il est cependant rare que l’utilisateur ait besoin d’accéder à toutes les nouveaux blobs dès l’ouverture de la session. Le procédé exploite cette observation de la manière suivante : l’application client détecte la partie du projet sur laquelle l’utilisateur travaille en premier comme par exemple une scène particulière du projet et transmet cette information à l’application serveur qui va envoyer les blobs contenus dans cette scène avant les autres. Ce processus de hiérarchisation ou de priorisation envoie les informations“utiles” en premier à l’utilisateur ce qui permet de réduire le temps d’attente et d’améliorer son expérience. Il est particulièrement utile pour les applications client dont la bande passante et l’espace de stockage sont limités comme par exemple l’application client de réalité augmentée sur téléphone portable. Dans l’exemple mentionné ci-dessus la métrique utilisée pour déterminer l’ordre des blobs à envoyer en priorité par le serveur au client est simple (elle se base sur la partie du projet sur laquelle l’utilisateur travaille) mais elle peut prendre des formes beaucoup plus complexes notamment lorsqu’elle est basée sur un processus d’apprentissage. En effet selon un mode de réalisation du procédé selon l’invention, et en conséquence de la fonction collaborative de l’invention, l’application serveur est en mesure de connaître et donc d’apprendre sur la base de l’historique de création du projet les habitudes de travail de chaque utilisateur travaillant sur le projet, et de manière générale l’implication de chaque utilisateur du système dans différents projets. Ce processus d’apprentissage à base de machine learning fournit une matrice de décision permettant à l’application serveur d’adopter en temps-réel une stratégie pour la hiérarchisation de la livraison des blobs la mieux adaptée possible à chaque utilisateur et à chaque application client. L’application serveur maintient donc une liste de priorités d’envoi des blobs par utilisateur pour chaque application client (ordinateur de bureau, application de réalité augmentée sur smartphone, etc.). Si le résultat du processus d’apprentissage sur la base de machine learning indique par exemple qu’un utilisateur travaille plus particulièrement sur une des assets du projet plutôt qu’une autre, toutes les données en relation avec cette asset auront leur priorité dans la liste d’envoi des blobs augmentée. Lorsque les priorités de tous les blobs en attente sur le serveur pour une application client particulière ont été mises à jour, alors le serveur les envoie à l’application client dans l’ordre décroissant de priorité. Ce processus s’opère en temps-réel (les priorités pour chaque application client et chaque utilisateur du système sont continuellement mises à jour) et la liste des priorités peut changer pendant l’envoi des blobs (du fait d’une nouvelle information communiquée au serveur par le client).
• Module de stockage des états intermédiaires (tag / snaoshot) et de l’historique de création : lorsqu’un utilisateur lance une application client et charge les données d’un projet qui a fait l’objet de modifications depuis sa dernière connexion, l’application serveur détermine en comparant son historique de création avec celui de l’application client, l’état Ec dans lequel se trouve le projet sur l’application client. À partir de l’état Es dans lequel se trouve le projet sur le serveur (avec Es >= à Ec), il en déduit alors la section de l’historique H devant être exécutée sur l’application client pour mettre le projet à jour. Autrement dit : H = Es - Ec. Ce module devient cependant inefficace au fur et à mesure que l’historique de création du projet grossit.
À titre d’exemple, Un groupe d’utilisateurs travaille sur un projet pendant une période relativement longue, par exemple plusieurs semaines ou plusieurs mois. Le projet est complexe : l’historique comprend des dizaines voire des centaines de milliers de changements d’état appelés révisions et le blob store comprend plusieurs dizaines de gigaoctet de données. Dans le cas où un utilisateur U rejoint le projet, suivant la logique décrite ci-dessus, le serveur devra envoyer tous les blobs (y compris ceux qui ne sont potentiellement plus utilisés dans la version la plus récente du projet) et l’intégralité du contenu de l’historique du projet au nouvel utilisateur ; afin de mettre le projet sur le système de l’utilisateur dans l’état Es, toutes les révisions depuis la création du projet seront alors exécutées sur l’application client, ce qui peut prendre beaucoup de temps pour un projet avec un historique important comme c’est le cas dans notre exemple. Selon un mode de réalisation du procédé selon l’invention, l’application serveur sauve automatiquement et régulièrement un état total du projet. Cet état total peut être vu comme une version ou image {snapshot e n anglais) du projet à l’instant t. Le fait qu’il existe une sauvegarde de l’état total du projet à l’instant t est également préservé dans l’historique de création du projet. Grâce à cette méthode, le serveur n’a plus qu’à envoyer au nouvel utilisateur U, les données relatives à la dernière sauvegarde de l’état total du projet Eïotai puis toutes les modifications réalisées sur le projet depuis le moment où E Total a été généré. Dans l’historique du projet, les modifications réalisées à un propriété du projet sont toujours définies dans l’historique de création, comme relatives à l’état dans lequel se trouve cette propriété dans la dernière sauvegarde de l’état total du projet. Le serveur procède à la sauvegarde totale du projet lorsque le nombre de révisions depuis la dernière sauvegarde de l'état total dépasse la valeur Q R fixée par le système.
• Gestion de l’historique par l’utilisateur côté client : grâce au module décrit ci-dessus, il existe sur le serveur une série de sauvegardes dites d’état total (des images du projet prises à intervalle plus ou moins réguliers). Selon un mode de réalisation du procédé selon l’invention, cette suite de sauvegardes d’état total du projet et l’historique des modifications réalisées entre chaque sauvegarde d’état total est exposée dans l’interface utilisateur de l’application client sous la forme d’une ligne de temps représentant l’intégralité de l’historique du projet depuis sa création. En se déplaçant sur cette ligne, l’utilisateur peut faire en sorte que le projet soit restauré dans un état antérieur. Pour se faire, le même module que celui précédemment décrit est utilisé. L'application serveur envoie les informations de mise à jour de l’application client en utilisant la sauvegarde de l’état total du projet T Total la plus immédiatement antérieure au moment ÏRestaure de restauration désiré, puis envoie les modifications additionnelles depuis le moment où cette sauvegarde a été réalisée jusqu’au moment de restauration désiré (T Restaure). Le projet est alors restauré dans l’état où il était à l’instant ÏRestaure . À travers la même interface utilisateur, l’utilisateur peut laisser dans l’historique de création des balises ou tags en anglais lui permettant de marquer dans l’historique de création du projet des étapes jugées clef de son évolution. Ces balises ou tags permettent de rapidement rétablir des versions antérieures du projet et notamment d’établir des comparaisons visuelles ou autres entre différents états du projet de manière simple et rapide. Selon un mode de réalisation du procédé selon l’invention il existe une balise spéciale générée automatiquement plutôt que par l’utilisateur : cette balise spéciale est ajoutée lorsque le projet n’a pas été modifié par aucune des applications client après un laps de temps QT. En effet nous considérons dans ce cas, qu’une absence de changement pendant un laps de temps long indique que le projet est potentiellement dans un état satisfaisant ou stable pour les utilisateurs du procédé selon l’invention et que cet état mérite donc d'être préservé.
Le procédé selon l’invention comprend donc un ensemble de modules collaborant les uns avec les autres, dans le mode de réalisation principal selon un fonctionnement interdépendant, bâtis sur des concepts communs comme par exemple le calcul de la valeur de hachage et exploitant la fonction collaborative de l’invention. Le procédé comprend notamment :
• Un module A temps-réel de synchronisation des données du projet sur les applications clients mis en oeuvre soit par le serveur dans le cas d’une session de travail collaboratif (push) soit par les applications client lorsqu'ils se connectent au serveur (pull),
• Un module B temps-réel qui à partir d’une valeur de hachage calculée sur les données binaires des blobs grâce à une fonction d’encodage cryptographique, permet de décider si des blobs importés doivent être ajouté ou non au blob store,
• Un module C temps-réel différenciant les changements d’états transitoires des autres changements d’état, permettant de compresser la liste de l'historique de création des projets de manière significative, et réduisant l’impact sur la quantité de données stockées sur les espaces de stockage, en mémoire et transitant sur le réseau,
• Un module D temps-réel exploitant la clef de hachage garantissant l’intégrité des données transmises entre les applications client et l’application serveur, • Un module E temps-réel exploitant dans un algorithme d’apprentissage
(machine learning) les données de l’historique de création des projets pour hiérarchiser l’ordre dans lequel l’application serveur délivre dans le cadre de mise à jour, les blobs aux différents utilisateurs et différentes applications client connectés au projet,
• Un module F temps-réel préservant l’historique de création des projets sous la forme d’une série de sauvegardes d’état total du projet et de révisions intermédiaires relatives à ces états. La fréquence des sauvegardes des états total étant déterminée par un algorithme basé sur un module d’apprentissage (machine learning) en temps-réel exploitant les données de l’historique,
• Un module G temps-réel permettant à l’utilisateur du procédé à travers une interface utilisateur de l’application client de marquer par des balises les moments clefs de l'évolution du projet et de revenir dans le temps en utilisant ou non ces balises pour facilement rétablir le projet dans des états antérieurs, à partir desquels des comparaisons entre différents états du projet peuvent être présentées à l’utilisateur à des fins comparatives.
Module d’optimisation de la gestion et du processus de visionnage des contenus par système d’apprentissage exploitant entre autres les données de l’historique.
Une des fonctions du procédé selon l’invention est de visionner en temps- réel ou en différé un contenu d’animation 3D constitué par un ensemble de plans ou clips organisés sous forme de séquences, comme décrit ci-dessus. L’objectif est de permettre aux utilisateurs du procédé, côté application client, de créer les contenus les plus complexes possibles tout en maintenant les meilleures performances de visionnage, c’est à dire avec une fréquence d’affichage des images et du son supérieure ou égale à 30 images par seconde pour une définition d’image supérieure ou égale au standard de format d’image dit Full HD. Dans ce contexte, le dispositif met en place un module permettant d’optimiser le processus par lequel les données formant le contenu à visionner sont transformées en images animées et sonores. L’usage collaboratif du dispositif unifié génère de grandes quantités d’information sur 1 ) l’usage du dispositif lui-même et 2) les contenus fabriqués par les utilisateurs du dispositif. Ces informations collectées par l’application serveur comprennent 1 ) l’historique de création du projet, 2) les méta-données connexes à l’usage du dispositif et à l’édition du projet 3) l'intégralité des données dont le projet est constitué. L’historique de création a déjà été présenté ci-dessus. Les méta-données peuvent inclure des métriques comme par exemple la taille mémoire nécessaire pour le chargement d’une scène 3D donnée, le temps qu’il a fallu pour charger cette scène, la fréquence d’utilisation d’une scène ou d’une asset donnée (combien de fois a-t-elle été éditée par les utilisateurs du système, combien de fois la scène apparaît-elle dans les séquences du contenu d’animation final), etc. Les utilisateurs du dispositif visionnent également fréquemment les différentes scènes et séquences constituant le projet ; ainsi durant ces visionnages, il est possible de collecter des informations sur le temps de calcul de chaque image pour chaque scène, sur l’usage de la mémoire qui peut varier en fonction de ce qui est visible à l’écran, etc.
Soulignons que c’est caractère collaboratif et unifié du dispositif qui permet 1 ) de générer des informations nouvelles et 2) de les centraliser dans le cloud, et que c’est grâce à cela que ce module d’optimisation peut être mis en oeuvre. Les dispositifs actuels qui ne sont ni collaboratifs ni unifiés n’ont accès qu’à certaines de ces données et de façon non-centralisée et de fait, n’ont pas la possibilité de mettre en oeuvre le même procédé.
Ces données peuvent varier en fonction de l’application client utilisée (celle pour smartphone ou ordinateur de bureau par exemple) et des caractéristiques du GPU et du CPU du système sur lequel l’application client est exécutée (quantité mémoire, nombre de coeurs, etc.). Notons finalement que lorsque le contenu final du projet est joué par le procédé (où les scènes 3D sont affichées à l’écran avec le son selon les informations de montage définies dans les étapes mises en oeuvre par le procédé pour éditer des séquences), le processus par lequel ce contenu est calculé pour être restitué est prédictif puisqu’il est, dans le cas le plus commun de l’usage du procédé, linéaire (en opposition à des contenus dits interactifs, dont les contenus changent lorsqu’ils sont joués comme par exemple dans le cas d’un jeu vidéo). Selon un mode de réalisation du procédé selon l’invention, un algorithme à base d’apprentissage (machine learning) exploite l’intégralité des informations dont il dispose sur le projet (l’historique de création, les métadonnées collectées au fil du temps par configuration hardware utilisée, ainsi que les données du projet), pour planifier ( scheduler ) et optimiser l’usage des ressources du système sur lequel l’application client est exécutée, afin de garantir au mieux que le contenu du projet soit joué dans les conditions requises (résolution de l’image, nombre d’images par seconde, etc.). Ce module de planification de d’optimisation des ressources définit la partie du procédé selon l’invention est ici appelé moteur de film, auquel on se référera par la suite sous le terme de movie engine. À titre d’exemple, le procédé au cours d’une étape de collecte d’informations a détecté qu’une scène S3 requiert 3 secondes pour être chargée et 5 Go de mémoire sur le GPU ; cette scène apparaît 10 secondes après le début de la séquence d’animation (une séquence Q1 composée de 10 plans faisant référence à 3 scènes différentes S1 , S2 et S3) : le procédé est donc apte à planifier le chargement de la scène au moins 3 secondes avant qu’il soit nécessaire de l’afficher à l’écran et qu’au moins 5 Go de mémoire sur le GPU soit libre au moment où le processus de chargement commence, quitte à supprimer de la mémoire des données dont le procédé n’a pas immédiatement besoin si nécessaire. Le procédé comprend donc un movie engine dont le fonctionnement selon le mode de réalisation principal de l’invention est le suivant :
• L’application serveur collecte les informations suivantes :
• Les métadonnées envoyées par les différentes applications client utilisées pour l’édition du contenu du projet,
• L’historique de création du projet
• Les données du projet.
• Le serveur traite et réorganise ces informations dans des paquets d’informations pertinentes pour le movie engine qui sont ensuite envoyés aux applications client (sur le même principe que l’envoi des blobs),
• Ces paquets d’informations fournissent les données d’entrée au movie engine dont la tâche est d’optimiser la réponse au problème suivant : “quelles données charger et quand les charger sur la base de la configuration hardware sur laquelle l’application client est exécutée, de manière à garantir un visionnage en temps-réel sans interruption.
• Le movie engine affine de manière sensiblement permanente, et de manière préférée à une fréquence supérieure à la fréquence des événements utilisateurs sur les terminaux, en temps-réel, la réponse à ce problème sur la base des informations qui sont lui sont envoyées en continu par l’application serveur. Le movie engine explore différentes stratégies en adaptant les paramètres du problème afin d’optimiser sa réponse dans un processus d’auto apprentissage continu. Ainsi alors qu’une configuration S1 semble plus performante à un utilisateur du système qu’une configuration S2, le movie engine peut découvrir dans le cadre de ce processus d’apprentissage que S2 moyennant des modifications à des paramètres spécifiques du système est en réalité plus performante que S1. Par exemple, une stratégie peut consister à privilégier le chargement et le déchargement des données depuis l’espace de stockage du client dans et de la mémoire du GPU le plus vite possible plutôt que de préserver un maximum de données dans la mémoire du GPU le plus longtemps possible.
· Le movie engine possède des stratégies alternatives pour contourner des limitations du système si le processus de planification n’est pas suffisant pour garantir un visionnage sans interruption. Il peut selon un mode de réalisation du procédé selon l’invention :
• Précalculer avant le démarrage du visionnage du contenu (et mettre dans un tampon c’est à dire un espace mémoire réservé) des parties du contenu avant qu’elles ne soient jouées, lorsqu’il a été détecté que malgré toutes les optimisations possibles, ces parties du projet ne peuvent par exemple par être jouées en temps-réel dans les conditions de visionnage requises. · Planifier le calcul du projet en parallèle sur plusieurs GPUs lorsqu’un seul GPU n’est pas suffisant et recomposer les images calculées par ces GPUs dans un flux vidéo continu. Ces différentes options font partie des paramètres que le movie engine peut modifier dans son algorithme d’apprentissage afin d’offrir la meilleure réponse possible en fonction des contraintes du système (configuration hardware) et du projet.
Le procédé selon l’invention est en outre un procédé connecté. En effet, la nature collaborative du projet requiert que la version du projet qui se trouve sur le serveur S auquel les applications client sont connectées, soit la version de référence du projet. Le fait de disposer de l’ensemble des données du projet (y compris de son historique) sur le serveur, permet de développer un ensemble d’application satellites qui peuvent soit accéder aux données du projet depuis le serveur, soit s’interfacer directement avec l’application client.
Ces applications satellite peuvent être considérées comme un autre type d’application client.
À cet effet le procédé selon l’invention comprend une étape de connexion d’une application satellite au serveur. Dans un mode de réalisation principale de l’invention une solution logicielle est exécutée sur un smartphone ou une tablette équipée de fonctionnalité de réalité augmentée. Aussi à titre d’exemple, une application satellite au serveur S lit les données du projet P sur le serveur S et affiche les différentes scènes du projet sur l’application du smartphone. L’utilisateur de l’application peut alors sélectionner l’une des scènes du projet, puis à l’aide du système de réalité augmentée, déposer le contenu de cette scène virtuelle Sv sur n’importe quelle surface du monde réel dont le téléphone est capable de connaître la position et l’orientation dans l’espace 3D (il s’agit souvent dans le cas le plus simple d’une surface horizontale ou verticale, comme la surface d’une table ou celle d’un mur). La scène virtuelle 3D Sv est alors ajoutée au flux vidéo provenant de la caméra du téléphone en surimpression. La finalité de ce dispositif est de permettre à l’utilisateur de jouer la scène 3D Sv et de pouvoir la filmer en réalité augmentée.
Pour se faire l’application propose une fonction d’enregistrement de la caméra. Lorsque l’utilisateur de l’application enclenche cette fonction d’enregistrement, les déplacements de la caméra dans l’espace 3D (qui sont fournis par le système de réalité augmentée) et les images du flux vidéo créées sont conservées dans la mémoire du smartphone. Une fois l’enregistrement terminé, les mouvements de la caméra, les images de la vidéo et toutes les autres données auxiliaires créées par le système de réalité augmentée (comme par exemple les points dit de tracking qui sont des points de la scène réelle utilisés par le système de réalité augmentée pour calculer la position et la rotation du smartphone dans l’espace) sont sauvés dans le projet P sur le serveur.
Cette méthode d’acquisition permet notamment à l’utilisateur de créer des caméras virtuelles animées pour un projet de contenu d’animation 3D au moyen d’un dispositif grand public (les smartphones ou les tablettes).
Le procédé mis en oeuvre par ordinateur comprend aussi selon un mode de réalisation particulier, une étape de connexion d’une application temps-réel à l’application client. Dans ce mode de réalisation particulier, il est possible d’associer un système de capture de mouvement permettant d'enregistrer les positions et rotations d'objets ou de membres d'êtres vivants (corps et visage), pour en contrôler une contrepartie virtuelle sur ordinateur (caméra, modèle 3D, ou avatar). Cette méthode permet d’enregistrer directement les données capturées sur le serveur S dans le projet P ; elles sont alors immédiatement accessibles à toutes les applications client connectées au serveur.
Ces différents modes de réalisation de l’invention exploitent deux modes de connexion, l’une où l’application satellite accède aux données du projet P sur le serveur S via une connexion réseau de type Internet. L’autre dans laquelle une application satellite communique directement avec une application client (par un système de streaming par exemple) laissant la responsabilité à l’application client de communiquer avec le serveur pour accéder aux données du projet sur le serveur.
Le procédé selon l’invention comprend en outre un deuxième groupe d’étapes de production dites étapes de diffusion.
Ces étapes de diffusion comprennent dans un mode de réalisation une étape de calcul et de diffusion ( streaming ) local.
Aussi selon ce mode de réalisation, l’utilisateur de l’application client C qui utilise pour exécuter cette application un dispositif informatique de type ordinateur de bureau ou portable équipé d’une ou plusieurs unités centrales de traitement (CPU) et d’une ou plusieurs unités graphiques de traitement (GPU) peut calculer les séquences animées sonores à la volée (en temps-réel), localement, en utilisant les ressources de ces différentes unités de traitement.
Les sorties vidéo et audio créées peuvent être redirigées vers n’importe quel dispositif de visionnage connecté à l’ordinateur comme un écran 2D et des haut-parleurs ou un casque de réalité virtuelle.
Dans le cas d’un système de visionnage dynamique comme par exemple un système de réalité virtuelle ou augmentée où l’utilisateur du système de visionnage contrôle la caméra, les informations concernant la position et la rotation de la caméra fournies par le système de visionnage sont prises en compte dans la création du flux vidéo et audio créant une boucle de rétroaction: le système de réalité augmentée ou virtuelle par exemple fournit les informations 3D sur la position et la rotation de la caméra réelle (du smartphone ou du casque de réalité virtuelle) qui permettent de calculer sur l’ordinateur auquel il est connecté le flux vidéo et audio correspondant, ces flux étant eux- mêmes connectés aux entrées vidéo et audio respectives du système de réalité virtuelle ou augmentée.
Selon un deuxième mode de réalisation de l’invention, le calcul et streaming est réalisé à distance depuis le serveur S.
Aussi dans ce deuxième mode de réalisation, le même procédé que celui décrit ci-dessus est utilisé mais cette fois-ci le flux vidéo et audio est calculé sur le serveur soit hors ligne ( offline ) soit en temps-réel.
Dans le mode hors-ligne les flux audio et vidéo peuvent être sauvés dans une vidéo. Dans le mode temps-réel, les flux vidéo et audio sont calculés à la volée, dynamiquement et sont diffusés (streaming) vers un autre dispositif informatique ou électronique connecté au serveur par un réseau de type LAN (local) ou WAN (Internet par exemple).
Dans cette version de l’invention, il est possible de calculer une version finalisée du projet que ce soit dans la forme hors ligne (offline) ou temps-réel sur autant d’unités de traitement (CPU et GPU) que l’infrastructure du centre de calcul auquel le serveur est localement connecté le permet (notons que dans la mesure où les données du projet P qui sont sur le serveur S sont sur le réseau local auquel sont également connectés les unités de traitement, l’accès à ces données est rapide). Il est également possible d’utiliser n’importe quelle solution de calcul d’images de synthèse 3D pour créer les images finalisées de ce contenu.
Dans la version hors ligne ( offline ), un utilisateur peut adapter la vitesse avec laquelle une version finalisée du film est calculée en augmentant le nombre d’unités de traitements dédiées à cette tâche.
Dans la version temps-réel, un utilisateur du procédé peut accéder à distance, à des ressources de calcul beaucoup plus importantes que celles dont il dispose sur son ordinateur local (ou le dispositif électronique qu’il utilise pour visualiser le contenu comme un smartphone ou une tablette) afin d’obtenir une version finalisée du contenu en temps-réel de qualité bien supérieure à la version qu’il pourrait obtenir en exploitant les ressources de son propre ordinateur.
Ce dernier mode de réalisation de l’invention permet aux ressources de calcul (les GPU et les CPU utilisés dans le calcul du contenu) d’être physiquement séparées du dispositif de visualisation de ce contenu. Ce dispositif est différent du cas de la diffusion d’une vidéo par streaming depuis un serveur vers par exemple un smartphone via Internet, où le contenu de la vidéo est pré-calculé. Dans le cas de l’invention il s’agit de calculer le contenu du projet d’animation à la volée, au moment même ou il est diffusé (streamé) vers ce smartphone.
Un protocole adapté au streaming de contenu temps-réel comme par exemple RTSP ( Real-Time Streaming Protocol en anglais) est dans ce cas requis. Le contenu du projet est calculé live, de façon dynamique à la demande. Par dynamique, il est entendu que le contenu du projet peut être changé au moment même de sa diffusion (ce qui n’est bien entendu pas le cas pour une vidéo). Cela est notamment nécessaire lorsque l’utilisateur du procédé contrôle la caméra comme dans le cas de la réalité virtuelle et augmentée. Il s’agit de la même boucle de rétroaction que celle décrite ci-dessus mais dans cette version de l’invention, le système de réalité virtuelle ou augmentée et le serveur S sont connectés par un réseau LAN ou WAN (Internet par exemple).
Les données sur la position et la rotation de la caméra créées par le dispositif de réalité virtuelle ou augmentée sont donc envoyées au serveur S via ce réseau (entrée) ; ces informations sont ensuite utilisées pour calculer en direct à la volée, un flux vidéo et audio sur le serveur S qui est renvoyé (sortie) au dispositif par le réseau d’où les informations sur la caméra sont venues.
La possibilité de modifier dynamiquement le contenu d’animation alors qu’il est diffusé/streamé, permet également d’adapter le contenu en fonction par exemple des préférences de chaque personne qui le regarde.
Dans le mode de réalisation principal de l’invention, il est assigné une ou plusieurs unités de traitement (nommée ci-après groupe de calcul) à chaque personne regardant une version du contenu d’animation de sorte que chaque groupe de calcul puisse créer une version différente de ce contenu à partir du même projet S. Cette solution est similaire au concept de multi-casting asynchrone dans l’industrie du broadcasting ou streaming sauf que dans le cas décrit ici, chaque flux vidéo et audio généré et diffusé vers chaque client connecté au serveur de streaming est unique.
Aussi il est possible de sélectionner dynamiquement des objets de la scène au fur et à mesure que le film est visionné, pour pouvoir interagir avec eux.
Lorsqu’un film d’animation 3D est pré-calculé les informations concernant la composition de la scène sont perdues puisque les pixels comme déjà indiqué ci-dessus, n’ont aucune notion des modèles 3D qu’ils représentent.
Cette information peut être sauvée au niveau des pixels sous forme de métadonnée, les transformant ainsi en‘pixels intelligents’.
Lorsque le contenu du projet d’animation est calculé à la volée, puis diffusé en flux tendu, toutes les informations sur le contenu du projet sont connues puisqu’elles existent sur le serveur S. Il suffit donc par exemple à l’utilisateur du procédé d’indiquer à l’aide de la souris ou d’un écran tactile l’objet qu’il souhaite sélectionner ; les informations sur la position du curseur à l’écran sont ensuite envoyées au serveur qui en déduit par un ensemble de calculs simples, le modèle 3D que l’utilisateur a sélectionné.
Il est alors possible de lui renvoyer des informations supplémentaires sur ce modèle ou de lui offrir un ensemble de services associés à cet objet (comme par exemple l’imprimer en 3D, le commander par Internet, etc.). Il est également possible de connaître l’intégralité de l’historique de fabrication de ce modèle (qui l’a créé, qui l’a modifié, etc.) Le procédé selon l’invention répond ainsi aux problèmes techniques liés au caractère fragmenté des pipelines de production non temps-réel, à l’absence de solution collaborative, et à la déconnexion du processus de production du processus de diffusion des contenus d’animation 3D (qu’ils soient temps-réel ou non).
Le procédé selon l’invention résout l’ensemble de ces problèmes techniques dans un procédé global et dédié plus particulièrement à la création de contenus d’animation linéaires 3D temps-réel pour les médias traditionnels (télévision et cinéma) et les nouveaux médias (réalité virtuelle et augmentée).
Le présent procédé selon l’invention est conçu spécifiquement pour la création de contenus d’animation linéaires ou plus généralement de contenus narratifs 3D qui peuvent contenir des éléments d’interactivité mais qui se distinguent en tout cas clairement d’un jeu vidéo. Dans ce procédé, un ou plusieurs utilisateurs peuvent dans un processus unifié, travailler en temps-réel et en parallèle sur n’importe quel aspect d’un contenu d’animation 3D (et/ou mélangeant une variété de sources visuelles et sonores comme par exemple des vidéos, des images numériques, des sources audio préenregistrées ou générées procéduralement, etc.) en mode collaboratif simultané et à distance en utilisant une variété de dispositifs électroniques et/ou informatiques comme par exemple un smartphone, une tablette, un ordinateur portable ou de bureau, un casque ou n’importe quel autre système de réalité virtuelle ou augmentée, et de diffuser ces contenus grâce à une variété de procédés comme par exemple la publication d’une vidéo du contenu sur une plateforme de distribution vidéo ou le streaming d’un flux vidéo live dynamique (c’est à dire généré à la volée, ou créé dynamiquement à la demande) depuis un serveur vers n’importe quel dispositif d’affichage interactif ou non (casque de réalité virtuel, écran de smartphone ou de tablette, écran d’ordinateur, etc.).
Selon un mode de réalisation détaillé de l’invention décrit en référence aux figures 7 à 16, le procédé selon l’invention, autrement dit le pipeline collaboratif unifié (CUP), peut-être mis en oeuvre sur ordinateur tel que décrit ci-après.
1. Lancer l’application client : un utilisateur U1 lance l’application client sur un ordinateur de bureau équipé d’un CPU et d’un GPU. Cet ordinateur (aussi appelé terminal) est relié par un réseau distant de type WAN à un serveur situé dans un centre de calcul ou une plateforme cloud, tel que représenté figure 16.
Pour s’identifier sur le serveur S (sur lequel se trouve l’application serveur), U1 doit fournir un identifiant utilisateur ( username en anglais) et un mot de passe, figure 7, validé par l’application serveur.
Création/ouverture d’un projet : une fois connecté, un autre écran, figure 8 est offert à U1 qui lui permet soit de créer un nouveau projet de contenu soit d’ouvrir un projet existant. L’utilisateur U1 a la possibilité de personnaliser l’icône du projet P par un glisser-déplacer ( drag-and-drop en anglais) d’une image stockée sur le disque local de l’ordinateur sur l’icône du projet 23.
Dans le cas d’un projet existant, l’utilisateur U1 peut cliquer une fois sur l’icône du projet P pour un aperçu du contenu du projet sous la forme d’une petite vidéo ou teaser 24 par exemple de trente secondes maximum, pré-calculée ou calculée à la volée. Un double-clic sur l’icône du projet P provoque son ouverture.
Création/ouverture de scènes virtuelles 3D ou de séquences animées et sonores : l’ouverture du projet provoque la synchronisation des données sur le disque local du terminal depuis le serveur. Lorsque la version locale du projet est à jour (identique en tout point à la version sauvegardée sur le serveur), un autre écran ci-après nommé l’éditeur de projet est affiché, figure 1 1. Il est divisé verticalement en deux grands espaces : à gauche une liste de scènes 3D virtuelles 51 et à droite une liste des séquences composant le film 52.
Chaque espace comporte une icône qui permet de créer soit une nouvelle scène 54 soit une nouvelle séquence 57.
Les scènes et les séquences sont affichées comme une suite de cartes 55 comportant une image de la scène ou de la séquence choisie par l’utilisateur U1 ou de manière aléatoire (vignette ou snapshot) et le nom de la scène ou séquence qui peut être édité. Les scènes peuvent être dupliquées et supprimées. Un double-clic sur la carte d’une scène, ouvre la scène en édition. Edition de la scène animée : lorsque l’utilisateur U1 ouvre une scène, un nouvel écran lui est présenté, figure 12. Cet écran (ci-après nommé l’éditeur de scène) propose un espace de travail à partir duquel l’utilisateur peut éditer tous les aspects d’une scène virtuelle 3D comme par exemple importer ou modéliser sur place des modèles 3D, importer ou créer des animations, importer des caméras ou créer de nouveaux angles de vue à partir desquels la scène peut être filmée (en disposant des caméras virtuelles dans la scène 3D), importer ou créer des sources de lumière, des vidéos, des images numériques, des sons, etc.
L’éditeur de scène présente une barre de temps qui permet à l’utilisateur du procédé de se déplacer dans le temps de la scène. Le contenu de la scène est visible grâce à une sorte de fenêtre ouverte sur la scène 3D, calculée en temps-réel à la volée, qui s’appelle le viewport en anglais 71. Lorsque l’utilisateur clique sur l’icône de la caméra dans la barre des outils, une fenêtre s’affiche à l’écran comprenant la liste, présentée sous la forme de cartes, de toutes les caméras déjà créées dans la scène 82. Chaque carte comprend le nom de la caméra et une petite image qui représente une image de la scène prise depuis cette caméra. Un double- clic sur l’une de ces cartes permet de voir dans le viewport, la scène 3D filmée depuis la caméra sélectionnée.
La caméra peut être animée. Pour créer une nouvelle caméra, il faut se déplacer librement dans la scène 3D, puis lorsqu’un point de vue convient, cliquer sur le bouton‘ ne\ri de la fenêtre des caméras 82 ce qui a pour effet 1 ) d’ajouter une carte à la liste des caméras, 2) de créer une nouvelle caméra positionnée dans l’espace 3D de la scène à l’endroit souhaité. Edition d’une séquence sonore et visuelle : une fois que l’utilisateur a créé une ou plusieurs scènes, il peut revenir à l’éditeur de projet, figure 1 1.
Par un double-clic sur la carte représentant une séquence 58, l’utilisateur ouvre un nouvel écran nommé ci-après l’éditeur de séquence, figure 13. Cet écran permet à l’utilisateur d’éditer le contenu d’une séquence. Cet écran est séparé en trois grandes sections : - une fenêtre 3D ou viewport en anglais qui est la terminologie habituelle pour l’homme du métier, permet à l’utilisateur de voir le résultat de son montage 91 ,
- une liste de toutes les scènes 3D qui peuvent être utilisées dans le montage de la séquence 92 et
- une barre de temps ou timeline en anglais qui est la terminologie habituelle pour l’homme du métier, c’est à dire l’espace où l’utilisateur va créer son montage en y mettant bout à bout des plans 93. La création d’un plan sur la timeline s’opère par une opération de glisser- déplacer d’une carte représentant une scène 3D (ci-après SCN) depuis la section listant l’ensemble des scènes 3D du projet, sur la timeline.
Par défaut, le plan ainsi créé sur la timeline a la même durée que la durée de la scène SCN. Cependant, cette durée peut être ajustée comme dans n’importe quel outil de montage.
Enfin il est nécessaire une fois que le plan a été créé de préciser l’angle de vue depuis lequel la scène 3D SCN doit être filmée ainsi que la version de l’animation désirée pour ce plan. En cliquant sur le plan, comme par exemple à la référence 101 , une fenêtre s’affiche à l’écran 97.
Cette fenêtre comprend la liste des caméras et des animations de la scène 3D SCN. Il suffit alors à l’utilisateur de choisir la caméra et la version de l’animation qu’il souhaite utiliser pour ce plan en cliquant sur l’icône de la caméra et de l’animation représentant son choix.
D’autres éléments comme des sources audio peuvent être également ajoutés à cette timeline afin d’ajouter le son à l’image. Le viewport comprend certains contrôles 99 qui permettent à l’utilisateur de jouer la séquence pour vérifier le résultat de son montage.
Regarder la séquence en réalité virtuelle : en actionnant la fonction de réalité virtuelle 100 dans l’éditeur de séquence, il est possible de regarder la séquence non pas seulement sur l’écran de l’ordinateur mais également sur un casque de réalité virtuelle connecté à l’ordinateur de l’utilisateur. Jouer le film dans son intégralité : en actionnant la fonction du visionnage du film, figure 14 depuis l’éditeur de projet 53, l’utilisateur a la possibilité de jouer l’intégralité du film c’est à dire les séquences mises bout à bout. Les séquences sont jouées dans le même ordre que l’ordre dans lequel elles sont rangées dans l’éditeur de projet 52.
Création d’une caméra virtuelle en réalité augmentée : l’utilisateur lance une application satellite, en référence à la figure 19, sur un smartphone équipé de la fonction de réalité augmentée, ou de tout autre dispositif adapté.
L’application se connecte au serveur S pour y lire les données du projet P 1207, 1208. Apparaissent alors sur l’écran du smartphone la liste des scènes sous forme de cartes identiques à celles utilisées pour l’éditeur de projet 1205.
Via l’écran tactile du smartphone, l’utilisateur sélectionne une scène SCN dont il peut alors déposer le contenu sur une surface du monde réel pour l’y fixer. La scène virtuelle 3D est alors filmée par le téléphone comme si celle-ci faisant partie du monde réel.
En actionnant la fonction d’enregistrement 1201 , il est alors possible d’enregistrer les mouvements du smartphone dans l’espace réel 3D tout en se déplaçant autour de la scène virtuelle.
Une fois l’enregistrement terminé, le smartphone sauve les informations du mouvement de caméra qui vient d’être créé sur le serveur S en ajoutant une nouvelle caméra animée à la scène SCN du projet.
Ce mouvement de caméra est alors disponible dans le projet P dans l’application client depuis l’éditeur de scène ou l’éditeur de séquence.
Travail collaboratif : un autre utilisateur du procédé ci-après nommé utilisateur U2 se connecte au serveur S en lançant sur son propre ordinateur l’application client C2.
En activant la fonction de partage de projet, en référence à la figure 9, l’utilisateur U1 peut donner au second utilisateur U2 l’accès au projet P. L’utilisateur U2 a dès lors accès à toutes les données de ce projet et peut en modifier le contenu à sa guise. A chaque fois que l’utilisateur U1 ou l’utilisateur U2 édite le contenu de ce projet, les modifications sont immédiatement reflétées ou visibles sur l’écran de l’autre utilisateur.
Par exemple, l’utilisateur U1 créé une nouvelle scène depuis l’éditeur de projet. Cette scène apparaît sous la forme d’une nouvelle carte dans l’interface des deux utilisateurs bien que ce soit l’utilisateur U1 qui ait modifié le projet. Le deuxième utilisateur U2 qui a donc maintenant également accès à cette nouvelle scène décide de l'ouvrir pour y importer un modèle 3D. Le modèle est alors visible et disponible à la fois dans le projet du deuxième utilisateur U2 qui vient de l'importer mais également dans le projet du premier utilisateur U1 qui pourtant n'a rien fait.
Le premier utilisateur U1 décide de changer la couleur de cet objet. Ce changement de couleur est également appliqué au modèle du projet du deuxième utilisateur U2. Ce principe s’applique à tous les aspects du projet quel que soit le nombre d’utilisateurs connectés au serveur S.
Gérer différentes versions d’un projet grâce à l’historique, en référence à la figure 15 : les utilisateurs U2 et U1 peuvent explorer des versions différentes d’un même projet P.
En accédant à l’écran ci-après nommé éditeur de l’historique depuis l’application client 1 10, le deuxième utilisateur U2 peut créer une deuxième version P’ du projet ci-après appelée branche 1 1 1. Toutes les modifications réalisées par le premier utilisateur U1 au projet P ne seront plus visibles au deuxième utilisateur U2 tant que celui-ci travaillera sur le projet P’.
Réciproquement les modifications faites par le deuxième utilisateur U2 sur
P’ ne seront pas visibles par U1. En regardant l’éditeur de l’historique il est possible de voir que les utilisateurs U1 et U2 travaillent sur deux branches différentes, ces branches étant représentées de façon visuelle de manière explicite, tel que représenté figure 15.
Les utilisateurs U2 et U1 travaillent ainsi quelque temps mais réalisent plus tard que travailler sur deux versions du projet n’est plus nécessaire. Cependant, ils veulent intégrer les modifications qui ont été faites à la deuxième version du projet P’ dans le projet P. Cette opération peut être réalisée en sélectionnant les deux branches de projets P et P’ puis en effectuant une opération dite de fusion, merge en anglais qui est le terme consacré pour l’homme du métier, qui consiste à prendre les modifications faites au deuxième projet P’ et à les intégrer à la version principale du projet P ; les deux projets ont été fusionnés et les modifications faites aux deux projets depuis la création de la branche P’ ont été consolidées dans une seule et même version, la version principale P.
Cette opération de merge est également représentée de façon explicite dans l’éditeur de l’historique 1 15.
11. Jouer le film en réalité augmentée : une personne lance une application satellite sur un smartphone équipé de la fonction de réalité augmentée. Cette personne ne veut pas éditer le contenu d’un projet mais le regarder, comme spectateur. Cette application se connecte au serveur S et fournit à ce spectateur une liste de tous les projets disponibles. Grâce à l’écran tactile du smartphone, il sélectionne un projet, puis sélectionne grâce à l’interface graphique fournie par l’application de réalité augmentée une surface du monde réel sur laquelle le film en image de synthèse sera joué ; comme par exemple la surface d’une table.
12. Calculer le film à distance sur le serveur avec création dynamique de contenu, en référence à la figure 18 : l’utilisateur U1 souhaite montrer le résultat de son travail sur une tablette qui n’a cependant pas la capacité de traitement nécessaire pour le calculer à la volée en temps-réel. La page Web d’un navigateur Internet lui permet de voir la liste des projets disponibles. Sélectionner un de ces projets à l’aide de la souris, ou d’un écran tactile ou de tout autre dispositif adapté, déclenche deux choses :
12.1. D’une part une application ou un service permettant de recevoir un flux vidéo temps-réel ; basé sur un protocole de diffusion temps-réel de type RTSP et de l’afficher, est lancé sur la tablette. Il peut aussi s’agir de la page web depuis laquelle l’utilisateur accède à la liste des projets, puisque la balise dite video en HTML5 permet de recevoir et d’afficher dans une page web des flux vidéo temps-réel.
12.2. D’autre part un serveur de streaming est lancé sur le serveur S. Il s’agit d’une application qui va calculer une version finalisée du projet sur autant d’unités de traitement (GPU et CPU) que souhaité par l’utilisateur, comme paramètre du service, puis diffuser/streamer le résultat de ce calcul en flux tendu vers la tablette de l’utilisateur. Le contenu de ce flux entrant sera alors affiché sur l’écran de la tablette grâce au processus lancé à l’étape précédente (a). L’utilisateur peut interagir avec le contenu du film regardé. Il est par exemple possible de sélectionner un objet à l’écran à l’aide de la souris ou de l’écran tactile. L’objet est représenté comme un ensemble de pixels à l’écran, mais l’application de streaming peut connaître le modèle ou les modèles 3D représentés par ces pixels. Le modèle 3D sélectionné peut donc apparaître à l’écran entouré d’un contour (pour indiquer qu’il est sélectionné) puis tout un ensemble de services associés à cet objet peuvent lui être présentés.
A titre d’exemple notamment :
1. Il est possible de personnaliser le modèle 3D. Des versions alternatives au modèle sélectionné sont proposées à l’utilisateur qui peut choisir celui qu’il préfère. Le visionnage du film continue mais avec la version du modèle choisie par l’utilisateur ;
2. Des informations sur ce que représente le modèle peuvent être affichées à l’écran ;
3. L’utilisateur peut commander une impression 3D du modèle sélectionné.
Le broadcaster, c’est à dire le service en charge de diffuser le contenu vers la tablette, smartphone, etc. d’un ou plusieurs utilisateurs du service, peut aussi modifier le contenu du projet pendant qu’il est calculé et diffusé. Dans le cas de la retransmission d’un événement sportif en direct, à titre d’exemple, il est possible d’adapter le contenu de l’animation en fonction de l’actualité de cet événement. Dans ce cas les modifications sont opérées non pas par l’utilisateur du service mais par l’opérateur du service (le broadcaster). Il est possible de créer autant de versions personnalisées que d’utilisateurs connectés au service.
Afin de gérer le travail collaboratif de plusieurs utilisateurs U1 , U2, ... partageant une même partie d’application serveur, autrement dit partageant un même ensemble d’étapes du procédé mis en oeuvre par ordinateur, le procédé comprend aussi des étapes de gestion de droits d’accès. A cet effet le serveur comprend des étapes d’authentification utilisateur. Lorsqu’une application client est mise en oeuvre depuis un terminal, cette application se connecte tout d’abord au serveur qui met en oeuvre l’étape préalable d’authentification.
Cette étape d’authentification attribue alors un jeton numérique d’authentification, qui comprend des données d’authentification, hachées, cryptées ou encodées selon toute technique adaptée connue de l’homme du métier, et des données de droit d’accès, qui auront été préalablement définis dans une base de données du serveur.
De cette manière on peut s’assurer qu’un utilisateur ne pourra agir sur le procédé que pour un ensemble d’étapes de production qui lui sont autorisées. De manière classique, on peut prévoir des autorisations du type administrateur, donnant le droit de mettre en oeuvre des étapes de production et des étapes de gestion, une autorisation du type producteur, donnant par exemple des droits pour l’ensemble des étapes de productions, et des autorisations ciblées, par exemple une autorisation d’animateur ne permettant que l’accès en modification et création à l’étape d’animation du contenu produit.
Les données du contenu d’animation produit sont toutes stockées sur le serveur central.
Les données du contenu d’animation du type assets, tel que défini précédemment, sont stockées sous la forme d’objets binaires de grande taille, connus sous le terme anglais de Binary Large Objects, généralement abrégés par l'acronyme BLOB.
Ces données stockées sont organisées sous forme de groupes de données, connus dans le domaine technique sous l’appellation de Pool de données.
Toutefois le mode de stockage de données n’est pas limité à ce mode de stockage et de référencement. Toute autre solution technique de stockage sur serveur pouvant être adaptée à l'invention.
Chaque donnée est associée à un état Rn sur le serveur. Cet état est associé à des modifications, de sorte qu’à l’état précédent une même donnée était à un état Rn-i qui suite à une modification enregistrée dite Cn a amené l’objet à l’état Rn.
Le procédé selon l’invention met en oeuvre une étape de gestion des conflits d’édition et de création.
Cette étape de gestion est subdivisée en deux sous-étapes : une étape de détection de conflits et une étape de résolution des conflits. L’étape de détection de conflits est liée à l’étape d’historique en ce qu’elle détecte quelles actions concomitantes de l’historique agissent sur des données similaires stockées dans le serveur central.
Lorsque deux, ou plus, actions d’édition, de modification ou de création, réalisées par des étapes de productions, sont enregistrées par l’étape d’historique sur le serveur, et se référant à des données identiques, ou liées, alors l’étape de résolution de conflits est mise en oeuvre.
Cette étape de résolution de conflits vise à donner la priorité aux modifications, créations ou suppression les plus tardives.
Par conséquent, à titre d’exemple, lorsqu’un objet est dans un état Rn sur le serveur, par extension on peut parler aussi d’état Rn du serveur pour l’objet en question.
Un premier utilisateur U1 sur un premier terminal effectue une modification amenant à changer un état via une action f amenant le serveur vers un état RP (que l’on écrit Rp = Rn->p), événement enregistré dans l’historique.
Un deuxième utilisateur, travaillant simultanément sur le même projet et sur un même objet, ou sur un objet lié, commande au serveur un changement d’état vers Rf= Rn->f, enregistré aussi dans l’historique.
Dans cette situation, le procédé de détection de conflit détecte que deux états concomitants sont exclusifs l’un de l’autre.
A cet effet, le procédé met alors en oeuvre l’étape de résolution de conflit pour déterminer quel état doit prendre le serveur, Rp, Rf ou un état différent.
Comme indiqué l’historique créé une relation d’ordre temporelle entre les événements. Dans cette situation, l’événement p est enregistré comme antérieur à l’événement f.
On entend par événement p ou f, le résultat de la mise en oeuvre d’une étape de production telle que décrit précédemment.
Pour résoudre ce conflit le procédé met en oeuvre une étape de détermination de l’exclusion de l’événement p.
Aussi, l’événement p est exclu s’il répond à l’un des critères suivants :
- l’événement p supprime un objet qui a été supprimé, modifié, ajouté ou référencé par l’événement f ; - l’événement p ajoute un objet qui a été supprimé, ajouté ou modifié par l’événement f ;
- l’événement p modifie une propriété d’un objet qui a été supprimé par l’événement f ;
- l’événement p modifie une propriété unique d’un objet qui a aussi été modifié par l’événement f ;
- l’événement p ajoute une référence à un objet qui a été supprimé par l’événement f ;
- l’événement p ajoute une référence à un objet ou une valeur pour une propriété d’un objet pouvant avoir plusieurs valeurs, qui a été ajoutée, supprimée ou changée par l’événement f ;
- l’événement p supprime une référence à un objet ou une valeur d’un objet pouvant recevoir plusieurs valeurs pour la même propriété ayant été ajoutée, supprimée ou changée par l’événement f ;
- l’événement p déplace une référence à un objet ou une valeur d’une propriété pouvant recevoir plusieurs valeurs ayant été ajoutée, supprimée ou déplacée dans une même propriété par l’événement f.
Si l’événement p entre dans l’un de ces cas il est alors ignoré, et le projet est mis à jour selon le dernier événement f. Sinon l’événement p est conservé avec l’événement f.
Les terminaux reçoivent alors du serveur une indication de mise à jour du projet, synchronisant les données locales sur les terminaux avec l’état du serveur suivant la résolution du conflit.
Ainsi, on peut résoudre de manière simple et efficace les conflits d’édition ayant un impact sur le procédé de production de contenus, en temps-réel, tout en assurant que ces modifications soient mises à jour directement à toutes les étapes de production, et répercutées en temps-réel sur tous les terminaux utilisateur.
L’invention concerne aussi un système informatique tel que représenté figure 16 comprenant un serveur 1 105 et un ou plusieurs terminaux 1 100.
Un terminal 1 100 comprend un dispositif informatique composé de systèmes d’affichage, d’unités de traitement de type CPU et GPU ou autre, et de capacité de stockage permettant de sauvegarder localement une version du projet P 1 102.
L’application client 1 101 selon l’invention, qui permet d’éditer le contenu de ce projet est exécutée sur ce dispositif.
Le terminal est connecté au serveur S 1 105 par un réseau local ou distant de type LAN ou WAN 1 106. Dans le cas d’une connexion distante de type WAN le serveur est dit dans le nuage (ou dans le cloud). Le serveur S est lui-même composé d’unités de traitement (de type CPU et GPU) et de capacité de stockage 1 103 utilisée pour sauver sur le serveur une version du projet P. L’application-serveur décrite dans cette innovation est exécutée sur ce serveur 1104. Plusieurs terminaux sont connectés au serveur via le réseau utilisateur 1 , utilisateur 2,..., utilisateur N.
La figure 17 représente schématiquement la manière par laquelle on synchronise une pluralité de projets de contenus différents avec une pluralité de terminaux différents.
Dans la première étape une modification faite au projet P par un utilisateur sur le terminal TA est d’abord sauvée localement 1’ puis diffusée au serveur 1 . Dans la deuxième étape, le serveur enregistre cette modification dans sa propre version du projet 2.
Dans la troisième et dernière étape, le serveur diffuse la modification à tous les terminaux sauf à celui d’où elle provient 3 qui l’appliquent à leur tour et l’enregistrent localement 3’.
A la fin de cette étape, toutes les versions du projet qui existent sur tous les terminaux et sur le serveur sont identiques, autrement dit les projets sont synchronisés.
La figure 18 est une représentation du module par lequel le contenu d’un projet peut être calculé à la volée et diffusé en flux tendu vers autant de dispositifs d’affichage (interactifs) que nécessaire.
Dans la figure trois types de dispositifs d’affichage interactifs sont représentés : un casque de réalité virtuelle 1 1 10 et les contrôleurs qui lui sont associés, une tablette ou un smartphone équipé de fonctions de réalité augmentée et d’écrans tactiles 11 1 1 , et un ordinateur muni d’un clavier et d’une souris 1 112. Les informations générées par ces différents dispositifs (comme par exemple la position du casque de réalité virtuelle ou du smartphone dans l’espace 3D du monde réel) sont envoyées au serveur auquel ils sont connectés 1 1 13.
Ces serveurs sont différents du serveur S de projet : ce sont des serveurs dit de streaming 1 1 15.
Ils sont connectés au serveur S via un réseau local (LAN) ce qui leur permet d’accéder aux données du projet rapidement. Il existe un serveur de streaming par dispositif d’affichage ou de visionnage. Cela permet à chaque serveur de streaming équipé de ses propres unités de traitement CPU et GPU, de calculer un flux vidéo et audio unique 1 1 14 qui répond aux entrées du système de visionnage. Chaque flux est donc potentiellement unique.
La figure 19 représente quant à elle le module permettant à un système équipé de fonctions de réalité augmentée comme un smartphone ou une tablette de se connecter au serveur S grâce à une solution logicielle exécutée sur ce système afin d’accéder aux données du projet comme par exemple, dans ce cas, les scènes 3D du projet P.
Dans l’exemple illustré par cette figure 19, dans l’étape 1 , les scènes 3D sont affichées sur l’écran du smartphone sous forme de cartes 1205.
A l’étape 2, l’application permet alors de jouer et de filmer ces scènes 3D en réalité augmentée.
A l’étape 3, une fois la scène filmée, toutes les données capturées par le système de réalité augmentée comme par exemple le mouvement de la caméra ou la vidéo sont ensuite sauvegardées sur le serveur S 1 105.

Claims

REVENDICATIONS
1 . Procédé de pipeline unifié collaboratif et temps-réel mis en oeuvre par ordinateur pour la création de manière collaborative, de contenus d’animation, caractérisé en ce qu’il comprend d'une part des étapes de production et de diffusion de contenus d’animation en images de synthèse destinées à être mises en oeuvre par une pluralité de terminaux en coopération avec un serveur central, et d'autre part des étapes de gestion de ces contenus d’animation adaptées pour permettre au serveur central de centraliser et gérer l’ensemble des données produites au stade des étapes de production ;
lesdites étapes de production dudit procédé unifié temps-réel comprenant :
- une étape de création d’un projet de contenu d’animation ;
- une étape de création d’une ou plusieurs scènes 3D et d’une ou plusieurs séquences 3D dans ledit projet créé ;
- une étape d’ouverture et d’édition d’au moins une scène 3D ;
- une étape d’ouverture et d’édition d’au moins une séquence 3D créée pour monter ledit contenu en images de synthèse ;
- des étapes de diffusion du contenu d’animation ;
lesdites étapes de gestion comprenant :
- une étape de gestion d’un historique de production, adaptée pour assurer la transmission et l’enregistrement du résultat de la mise en oeuvre d’étapes de production par un terminal au serveur central ;
- une étape de mise à jour du projet stocké sur ledit serveur en fonction desdits résultats de la mise en oeuvre d’étapes de production par un terminal transmis lors de l’étape de gestion de l’historique de production ;
- une étape de détection de conflits adaptée pour être mise en oeuvre sur le serveur de sorte à détecter lorsqu’au moins deux étapes de production ont créé, modifié ou supprimé, directement ou via une autre donnée liée, simultanément au moins une même donnée stockée sur le serveur central ;
- une étape de résolution de conflits, lorsqu’un conflit est détecté à l’étape précédente, apte à déterminer la ou les créations, modifications ou suppressions à appliquer à ladite au moins une donnée pour laquelle un conflit est détecté.
2. Procédé mis en oeuvre par ordinateur selon la revendication 1 , caractérisé en ce qu’il comprend une étape de synchronisation temps-réel du projet entre le serveur central et lesdits terminaux de sorte que chaque terminal mettant en oeuvre les étapes de production du procédé reçoive tout ou partie des données de projet à jour en fonction de toutes les modifications et créations apportées par l’ensemble des terminaux et du serveur, ladite étape de synchronisation étant adaptée pour être mise en oeuvre par le serveur lors d’un fonctionnement en mode de travail collaboratif et/ou par lesdits terminaux lorsqu'ils se connectent au serveur.
3. Procédé mis en oeuvre par ordinateur selon la revendication 2, caractérisé en ce qu’il comprend pour lesdites étapes de mise-à-jour et de synchronisation du projet entre le serveur central et lesdits terminaux une pluralité de modules de synchronisation des données, ladite pluralité de modules comprenant :
- un module temps-réel de mise à jour adapté pour mettre en oeuvre une fonction d'encodage cryptographique générant une clef de hachage en fonction desdites données du projet, ledit module temps-réel de mise à jour étant adapté pour déterminer si des données du projet importées doivent être enregistrées par lesdits terminaux et le serveur ;
- un module temps-réel d’optimisation apte à détecter des changements d’états transitoires de données du projet, et étant adapté pour compresser ladite liste de l'historique de création des projets de sorte à réduire la quantité de données transférées et stockées par lesdits terminaux et le serveur ;
- un module temps-réel de contrôle exploitant ladite clef de hachage de sorte à contrôler l’intégrité des données transmises entre lesdits terminaux et le serveur,
- un module temps-réel d’apprentissage, apte à analyser les données de l'historique de création des projets, et à définir un ordre de priorité, selon lequel ledit serveur transmet et met à jour, les données auxdits terminaux ; - un module temps-réel de versionnage, apte à préserver l'historique de création des projets sous la forme d’une série de sauvegardes d’état total du projet et de révisions intermédiaires relatives à ces états ; ladite fréquence des sauvegardes des états total étant fonction de données d’apprentissage dudit module temps-réel d’apprentissage ;
- un module temps-réel de marquage apte à autoriser un utilisateur d’un terminal à marquer par au moins une balise une étape clef de l'évolution du projet, ledit module de marquage permettant de rétablir ledit projet à son état à l’instant de marquage.
4. Procédé mis en oeuvre par ordinateur selon l’une quelconque des revendications 1 à 3, caractérisé en ce qu’il comprend en outre des étapes de gestion de contrôle d’accès pour interdire ou autoriser la mise en oeuvre de tout ou partie des étapes de production et de gestion à un terminal connecté au serveur.
5. Procédé mis en oeuvre par ordinateur selon l’une quelconque des revendications 1 à 4, caractérisé en ce que l’étape de résolution de conflits comprend une liste d’exclusion d’un premier résultat de la mise en oeuvre d’étapes de production par un premier terminal, lorsqu’un second résultat de la mise en oeuvre d’étapes de production par un second terminal a provoqué la détection d’un conflit, l’événement antérieur étant exclu si au moins un des critères suivants est rempli :
- le premier résultat supprime un objet qui a été supprimé, modifié, ajouté ou référencé par le second résultat ;
- le premier résultat ajoute un objet qui a été supprimé, ajouté ou modifié par le second résultat ;
- le premier résultat modifie une propriété d’un objet qui a été supprimé par le second résultat ;
- le premier résultat modifie une propriété unique d’un objet qui a aussi été modifié par le second résultat ;
- le premier résultat ajoute une référence à un objet qui a été supprimé par le second résultat ; - le premier résultat ajoute une référence à un objet ou une valeur pour une propriété d’un objet pouvant avoir plusieurs valeurs, qui a été ajoutée, supprimée ou changée par le second résultat ;
- le premier résultat supprime une référence à un objet ou une valeur d’un objet pouvant recevoir plusieurs valeurs pour la même propriété ayant été ajoutée, supprimée ou changée par le second résultat ;
- le premier résultat déplace une référence à un objet ou une valeur d’une propriété pouvant recevoir plusieurs valeurs ayant été ajoutée, supprimée ou déplacée dans une même propriété par le second résultat.
6. Procédé mis en oeuvre par ordinateur selon l’une quelconque des revendications 1 à 5, caractérisé en ce qu’il comprend un module d’apprentissage automatique adapté pour optimiser la séquence de chargement des données dans la mémoire desdits terminaux afin de restituer en image animées et sonore le contenu du projet en temps-réel sur lesdits terminaux, en fonction des données de l’historique de création du projet, des données du projet et de méta-données générées par lesdits terminaux.
7. Procédé mis en oeuvre par ordinateur selon l’une quelconque des revendications 1 à 6, lesdites é tapes de production et de diffusion du contenu d’animation, comprennent une étape d’affichage en temps-réel dudit contenu d’animation sur un dispositif de réalité augmentée, tel qu’un smartphone ou une tablette, connecté audit serveur.
8. Dispositif serveur comprenant une interface réseau, une mémoire de stockage et un processeur pour mettre en oeuvre au moins les étapes de gestion et/ou les étapes de diffusion et de distribution du contenu d’animation du procédé selon l’une quelconque des revendications 1 à 7.
9. Ensemble de réalité augmentée, comprenant un dispositif serveur selon la revendication 8 et un dispositif de réalité augmentée, tel qu’un smartphone ou une tablette, ledit dispositif serveur mettant en oeuvre les étapes de production et de de diffusion du contenu d’animation du procédé selon la revendication 7.
10. Terminal informatique pour commander une interface homme-machine adaptée pour exécuter et/ou réaliser au moins les étapes de production du procédé selon l’une quelconque des revendications 1 à 7, et comprenant une interface réseau pour communiquer avec ledit dispositif serveur selon la revendication 8 ou 9.
1 1. Système informatique comprenant un dispositif serveur selon la revendication 8 ou 9 et un ou plusieurs terminaux informatiques selon la revendication 10.
12. Support de stockage lisible par un ordinateur ayant enregistré sur lui des instructions qui commandent un dispositif serveur et/ou un terminal informatique pour exécuter un procédé selon l’une quelconque des revendications 1 à 7.
PCT/FR2019/051796 2018-07-18 2019-07-17 Procédé mis en oeuvre par ordinateur pour la création de contenus comprenant des images de synthèse WO2020016526A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US17/255,551 US20210264686A1 (en) 2018-07-18 2019-07-17 Method implemented by computer for the creation of contents comprising synthesis images
CA3102192A CA3102192A1 (fr) 2018-07-18 2019-07-17 Procede mis en oeuvre par ordinateur pour la creation de contenus comprenant des images de synthese
CN201980048030.0A CN112449707A (zh) 2018-07-18 2019-07-17 由计算机实现的用于创建包括合成图像的内容的方法
EP19759643.0A EP3824440A1 (fr) 2018-07-18 2019-07-17 Procédé mis en oeuvre par ordinateur pour la création de contenus comprenant des images de synthèse

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FRFR1856631 2018-07-18
FR1856631A FR3084190B1 (fr) 2018-07-18 2018-07-18 Procede mis en œuvre par ordinateur pour la creation de contenus comprenant des images de synthese

Publications (2)

Publication Number Publication Date
WO2020016526A1 true WO2020016526A1 (fr) 2020-01-23
WO2020016526A4 WO2020016526A4 (fr) 2020-03-19

Family

ID=63579458

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2019/051796 WO2020016526A1 (fr) 2018-07-18 2019-07-17 Procédé mis en oeuvre par ordinateur pour la création de contenus comprenant des images de synthèse

Country Status (6)

Country Link
US (1) US20210264686A1 (fr)
EP (1) EP3824440A1 (fr)
CN (1) CN112449707A (fr)
CA (1) CA3102192A1 (fr)
FR (1) FR3084190B1 (fr)
WO (1) WO2020016526A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020181152A1 (fr) * 2019-03-05 2020-09-10 Farrokh Shokooh Gestion et modélisation de projet de réseau de services publics
US20220165024A1 (en) * 2020-11-24 2022-05-26 At&T Intellectual Property I, L.P. Transforming static two-dimensional images into immersive computer-generated content
US11620797B2 (en) * 2021-08-05 2023-04-04 Bank Of America Corporation Electronic user interface with augmented detail display for resource location
CN115314499B (zh) * 2022-10-10 2023-01-24 国网浙江省电力有限公司嵊州市供电公司 适用于电力领域的多终端协同工作方法及系统

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160171740A1 (en) * 2014-12-15 2016-06-16 Calay Venture S.à r.l. Real-time method for collaborative animation

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10872322B2 (en) * 2008-03-21 2020-12-22 Dressbot, Inc. System and method for collaborative shopping, business and entertainment
CN102332174B (zh) * 2011-09-06 2013-10-16 中国科学院软件研究所 一种协同草图动画生成方法和系统
CN102866886B (zh) * 2012-09-04 2015-04-29 北京航空航天大学 一种基于Web的算法动画可视化开发系统

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160171740A1 (en) * 2014-12-15 2016-06-16 Calay Venture S.à r.l. Real-time method for collaborative animation

Also Published As

Publication number Publication date
FR3084190B1 (fr) 2020-07-10
CA3102192A1 (fr) 2020-01-23
FR3084190A1 (fr) 2020-01-24
CN112449707A (zh) 2021-03-05
US20210264686A1 (en) 2021-08-26
WO2020016526A4 (fr) 2020-03-19
EP3824440A1 (fr) 2021-05-26

Similar Documents

Publication Publication Date Title
WO2020016526A1 (fr) Procédé mis en oeuvre par ordinateur pour la création de contenus comprenant des images de synthèse
US11402969B2 (en) Multi-source journal content integration systems and methods and systems and methods for collaborative online content editing
US9277198B2 (en) Systems and methods for media personalization using templates
US9460752B2 (en) Multi-source journal content integration systems and methods
CA2600207C (fr) Procede et systeme d'edition et de stockage distribues de supports numeriques via un reseau
EP2393022A2 (fr) Procédé de création d'une séquence média par groupes cohérents de fichiers médias
US9002175B1 (en) Automated video trailer creation
US9601157B2 (en) Methods and apparatus for remote motion graphics authoring
JP2020524866A (ja) コンテンツ取引合意のシステムおよび方法
US9578188B1 (en) Enterprise photo / video experience platform and kiosk systems
EP3497674B1 (fr) Système de composition ou de modification de séquences de réalité virtuelle, procédé de composition et système de lecture desdites séquences
FR2933226A1 (fr) Procede et systeme de production d'oeuvres audiovisuelles
FR2893470A1 (fr) Procede et dispositif de creation d'une sequence video representative d'une sequence video numerique et procedes et dispositifs de transmission et reception de donnees video associes
US12002491B2 (en) Visual effect design using multiple preview windows
FR3044852A1 (fr) Procede de gestion de contenus video pour leur edition
TW201905639A (zh) 線上整合擴增實境的編輯裝置與系統
EP1762068B1 (fr) Procede d'edition de pages multimedia aupres d'un terminal,avec pre-memorisation de parametres d'objets intervenant dans les scenes
EP2599053A2 (fr) Dispositif et procédé de génération d'images procédurales avec cache
KR101263179B1 (ko) 동영상을 이용한 이동단말기의 배경화면 설정 방법, 동영상을 이용한 배경화면 설정 장치가 포함된 이동단말기, 동영상을 이용한 이동단말기의 배경화면 설정 시스템 및 이동단말기의 배경화면 설정 방법을 저장한 기록매체
EP3560147B1 (fr) Automatisation des échanges entre objets communicants
WO2017093467A1 (fr) Procede de gestion de contenus video pour leur edition selectionnant des moments ponctuels et utilisant des modeles adaptifs automatisables
EP2800017A2 (fr) Génération d'un document sonore personnalisé relatif à un évènement
Park Netflix as Cinematheque
FR3005181A1 (fr) Generation d'un document multimedia personnalise relatif a un evenement
Cronan 5th Kind and Marvel: How studios increase efficiency, reduce costs and improve quality of content and products

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19759643

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 3102192

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2019759643

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2019759643

Country of ref document: EP

Effective date: 20210218