Digital human driven data synchronization and frame rate adaptive rendering method and device

By using a rendering method that drives data synchronization and frame rate adaptation for digital humans, the problems of asynchrony and motion lag in digital human rendering are solved. This method enables synchronized rendering of faces and limbs and synchronized driving of multiple digital humans, thereby improving the stability and synchronization of rendering effects.

CN116309995BActive Publication Date: 2026-01-23BEIJING KNOWLEDGE ATLAS TECHNOLOGY CO LTD
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
CN202310189426.5
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2023-02-22
Publication Date
2026-01-23
Estimated Expiration
2043-02-22

AI Technical Summary

Technical Problem

In the current process of rendering digital humans, different parts of a single digital human and multiple digital humans are not synchronized, resulting in sluggish or jittery movements, and there is a lack of a solution for overall synchronization.

Method used

By acquiring the driving data of a single or multiple digital humans, performing frame rate preprocessing and synchronization, using the rendering engine to save the driving data to the corresponding data pool, and rendering the behavior under the tick signal, combined with the virtual camera to capture the image, the independent rendering synchronization of the face and limbs is achieved, and the external data frame rate is dynamically adjusted according to the frame rate of the rendering output.

Benefits of technology

It achieves independent and synchronized rendering of digital human faces and limbs, and synchronous driving of multiple digital humans, solving the problems of motion lag or jitter, and dynamically adjusting the frame rate in real-time scenes, thereby improving the stability and synchronization of rendering effects.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN116309995B_ABST
    Figure CN116309995B_ABST
Patent Text Reader

Abstract

The application provides a digital human driving data synchronization and frame rate adaptive rendering method, including: S1: obtaining driving data of multiple parts of a single digital human, initializing the frame rate of the driving data, and preprocessing the driving data according to the frame rate; S2: sending the preprocessed driving data to a rendering engine, and saving the preprocessed driving data to a driving data pool corresponding to each part through the rendering engine; S3: when the rendering engine receives a tick signal, sending first frame data of the driving data pool to the rendering engine, and rendering the behavior of the single digital human through the rendering engine according to the received data; S4: capturing a current frame picture through a virtual camera of the rendering engine, and saving the current frame picture as a picture or pushing the current frame picture to a video stream server; and S5: sending the tick signal through the rendering engine, and repeating steps S3 to S5 until the driving data pool is empty. The application realizes synchronization of the overall rendering effect after the digital human is driven.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of digital human rendering technology, and in particular to a rendering method and apparatus for digital human-driven data synchronization and frame rate adaptation. Background Technology

[0002] Digital humans are a product of the integration of information science and life science, utilizing information science methods to virtually simulate the human body at different levels of form and function. With the development of AI models, text-based AI chat can provide increasingly realistic content, and further data-driven digital humans can offer an even more lifelike and natural interactive experience.

[0003] Currently, there are two main approaches to driving digital humans: motion capture and algorithm-driven approaches. Most digital human driving methods use separate approaches for facial and limb driving. Existing technical solutions mostly focus on driving one part of the body, including solutions focused on standard driving protocols, motion capture driving optimization solutions, and algorithm solutions that use voice to drive the face. There are also solutions that focus on solving facial and audio synchronization, but there is a lack of solutions that can achieve overall synchronization when driving a complete digital human. Summary of the Invention

[0004] This application aims to at least partially address one of the technical problems in the related art.

[0005] Therefore, the first objective of this application is to propose a rendering method for digital human-driven data synchronization and frame rate adaptation, which solves the technical problems of asynchronous driving of different parts of a single digital human and multiple digital humans, as well as the lag or jitter of movements in the existing digital human rendering process. It realizes the independent rendering synchronization of digital human faces and limbs and the synchronous driving of multiple digital humans. At the same time, it realizes the synchronization of digital human behavior in cases of further subdivision of independent parts such as limb movement style and facial emotion superposition. Moreover, it can dynamically adjust the frame rate of external data according to the frame rate of the rendering output in real-time scenes.

[0006] The second objective of this application is to propose a rendering device for digital human-driven data synchronization and frame rate adaptation.

[0007] The third objective of this application is to propose a computer device.

[0008] The fourth objective of this application is to provide a non-transitory computer-readable storage medium.

[0009] To achieve the above objectives, the first aspect of this application proposes a rendering method for digital human driving data synchronization and frame rate adaptation, comprising: S1: acquiring driving data for multiple parts of a single digital human, initializing the frame rate of the acquired driving data, and preprocessing the driving data according to the frame rate; S2: sending the preprocessed driving data to the rendering engine, and saving the preprocessed driving data to the driving data pool corresponding to each part through the rendering engine; S3: when the rendering engine receives a tick signal, sending the first frame data of the driving data pool to the rendering engine, and rendering the behavior of the single digital human according to the received data through the rendering engine; S4: capturing the current frame image through the virtual camera of the rendering engine, saving the current frame image as an image or pushing it to a video streaming server; S5: sending a tick signal through the rendering engine, and repeating steps S3 to S5 until the driving data pool is empty.

[0010] Optionally, in one embodiment of this application, preprocessing the driving data according to the frame rate includes:

[0011] Add a specified value or factor to the drive channel and align the drive data of different parts of the corresponding single digit human.

[0012] Optionally, in one embodiment of this application, before saving the current frame as an image or streaming it to a video streaming server, the following steps are included:

[0013] Perform image preprocessing operations on the current frame, including quality inspection and overlaying layers.

[0014] Optionally, in one embodiment of this application, when pushing the current frame to a video streaming server, the following steps are included:

[0015] The average frame rate of the video stream within a certain time window is detected, and the average frame rate is compared with the frame rate of the acquired driving data.

[0016] When the average frame rate is higher than the frame rate at which the driver data is acquired, frame compensation is performed on the frame rate at which the driver data is acquired.

[0017] When the average frame rate is lower than the frame rate at which the driver data is acquired, frame compression is performed based on the frame rate at which the driver data is acquired.

[0018] Optionally, in one embodiment of this application, the method further includes:

[0019] By acquiring the driving data of multiple parts of the multi-digital human and increasing the driving data pool corresponding to each part of the multi-digital human, the driving data rendering synchronization of the multi-digital human can be achieved.

[0020] To achieve the above objectives, a second aspect of this application provides a rendering apparatus for digital human-driven data synchronization and frame rate adaptation, comprising:

[0021] The acquisition module is used to acquire driving data of multiple parts of a single digital human, initialize the frame rate for acquiring driving data, and preprocess the driving data according to the frame rate.

[0022] The storage module is used to send the pre-processed driver data to the rendering engine, and the rendering engine saves the pre-processed driver data to the corresponding driver data pool of each part.

[0023] The rendering module is used to send the first frame of data from the driving data pool to the rendering engine when the rendering engine receives the tick signal, and to render the behavior of the single digital human based on the received data.

[0024] The capture module is used to capture the current frame using the rendering engine's virtual camera, and save the current frame as an image or push it to the video streaming server.

[0025] The iteration module is used to send tick signals through the rendering engine and repeat the rendering and capture modules until the driving data pool is empty.

[0026] Optionally, in one embodiment of this application, the acquisition module is further configured to:

[0027] Add a specified value or factor to the drive channel and align the drive data of different parts of the corresponding single digit human.

[0028] Optionally, in one embodiment of this application, the apparatus further includes:

[0029] The multi-digital human rendering module is used to obtain the driving data of multiple parts of the multi-digital human and add the driving data pool corresponding to each part of the multi-digital human to achieve synchronous rendering of driving data of multiple digital humans driven simultaneously.

[0030] To achieve the above objectives, a third aspect of this application provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the rendering method for digital human-driven data synchronization and frame rate adaptation described in the above embodiments.

[0031] To achieve the above objectives, a fourth aspect of this application provides a non-transitory computer-readable storage medium that, when the instructions in the storage medium are executed by a processor, enables the execution of a digital human-driven data synchronization and frame rate adaptive rendering method.

[0032] The rendering method, apparatus, computer equipment, and non-transitory computer-readable storage medium for digital human-driven data synchronization and frame rate adaptation in this application solve the technical problems of asynchronous driving of different parts of a single digital human and multiple digital humans, as well as lag or jitter in movement during the existing digital human rendering process. It realizes independent rendering synchronization of digital human face and limbs and synchronous driving of multiple digital humans. At the same time, it realizes the synchronization of digital human behavior in cases of further subdivision of independent parts such as limb movement style and facial emotion superposition. Moreover, it can dynamically adjust the frame rate of external data according to the frame rate of the rendering output in real-time scenes.

[0033] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0034] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0035] Figure 1 This is a flowchart illustrating a rendering method for digital human-driven data synchronization and frame rate adaptation provided in Embodiment 1 of this application.

[0036] Figure 2 This is another flowchart of the digital human-driven data synchronization and frame rate adaptive rendering method according to an embodiment of this application;

[0037] Figure 3 This is an example diagram illustrating the frame rate adjustment configuration of the digital human-driven data synchronization and frame rate adaptive rendering method according to an embodiment of this application.

[0038] Figure 4 This is a schematic diagram of the structure of a rendering device for digital human-driven data synchronization and frame rate adaptation provided in Embodiment 2 of this application. Detailed Implementation

[0039] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0040] The following description, with reference to the accompanying drawings, describes a rendering method and apparatus for digital human-driven data synchronization and frame rate adaptation according to embodiments of this application.

[0041] Figure 1 This is a flowchart illustrating a rendering method for digital human-driven data synchronization and frame rate adaptation provided in Embodiment 1 of this application.

[0042] like Figure 1 As shown, the digital human-driven data synchronization and frame rate adaptive rendering method includes the following steps:

[0043] S1: Obtain driving data for multiple parts of a single digital human, initialize the frame rate for obtaining driving data, and preprocess the driving data according to the frame rate;

[0044] S2: Send the pre-processed driver data to the rendering engine, and the rendering engine saves the pre-processed driver data to the corresponding driver data pool for each part.

[0045] S3: When the rendering engine receives the tick signal, it sends the first frame of data from the driving data pool to the rendering engine and renders the behavior of the single digital human based on the received data.

[0046] S4: Capture the current frame using the rendering engine's virtual camera, and save the current frame as an image or push it to the video streaming server;

[0047] S5: Send a tick signal through the rendering engine and repeat steps S3 to S5 until the driving data pool is empty.

[0048] The digital human driving data synchronization and frame rate adaptive rendering method of this application embodiment includes the following steps: S1: Acquire driving data for multiple parts of a single digital human, initialize the frame rate for acquiring the driving data, and preprocess the driving data according to the frame rate; S2: Send the preprocessed driving data to the rendering engine, and the rendering engine saves the preprocessed driving data to the driving data pool corresponding to each part; S3: When the rendering engine receives a tick signal, send the first frame data of the driving data pool to the rendering engine, and render the behavior of the single digital human according to the received data; S4: Capture the current frame image through the virtual camera of the rendering engine, and save the current frame image as an image or push it to a video streaming server; S5: Send a tick signal through the rendering engine, and repeat steps S3 to S5 until the driving data pool is empty. Therefore, it can solve the technical problems of asynchronous driving of different parts of a single digital human and multiple digital humans, as well as the lag or jitter of movements in the existing digital human rendering process. It realizes the independent rendering and synchronization of digital human faces and limbs and the synchronous driving of multiple digital humans. At the same time, it realizes the synchronization of digital human behavior in cases of further subdivision of limb movement style and facial emotion superposition, and can dynamically adjust the frame rate of external data according to the frame rate of the rendering output in real-time scenes.

[0049] This application provides a method for adaptively adjusting the module-driven, drive data synchronization, and drive data generation based on the rendering frame rate during digital human rendering, which solves the problems of asynchronous driving of different parts of a single digital human and the occurrence of lag or jitter in the movements of multiple digital humans during the digital human rendering process.

[0050] Compared to existing technical solutions, this application focuses on the synchronization of the overall rendering effect after the digital human is driven, including the synchronization of independent rendering of face and limbs, the synchronization of multiple digital human driving and the further subdivision of limb movement styles and facial emotion superposition in the case of digital human behavior synchronization. In real-time scenes, the frame rate of external data can also be dynamically adjusted according to the frame rate of the rendering output.

[0051] This application can acquire driving data for multiple parts of a digital human, such as facial and limb driving data, or driving data for even more subdivided parts. The driving data can come from various sources; it can be generated by the algorithm based on speech or text, real-time motion capture data, or offline data saved from motion capture. Furthermore, there are no restrictions on the driving protocol; different protocols can be used to drive different parts of the digital human.

[0052] like Figure 2 As shown, the specific process of this application includes: Step 1: Receive digital human driving data from external sources (motion capture or algorithm), and preprocess the driving data according to the currently set frame rate; Step 2: Send the driving data to the rendering engine, and the rendering engine stores it in the corresponding data pool; Step 3: The rendering engine has a tick signal for each frame, and sends the first frame data of all driving data pools at the tick time; Step 4: The rendering engine renders the behavior of each part of the digital human according to the received data; Step 5: Capture the current frame image through the camera; Step 6: Perform image preprocessing operations such as image quality detection and overlay layers if necessary; Step 7: Save the image or push it to the video streaming server, return to Step 3, until the driving data pool is empty.

[0053] Furthermore, in this embodiment of the application, the preprocessing of the driving data according to the frame rate includes:

[0054] Add a specified value or factor to the drive channel and align the drive data of different parts of the corresponding single digit human.

[0055] In this embodiment, the driving channels include, but are not limited to, driving points bound to the digital human, such as lip movements, eye movements, or limb joints. Specifically, superimposing a specified value on the driving channel can be done by superimposing a fixed value on the lip movement control channel to maintain a smile during dialogue. Specifying an influence factor on the driving channel involves performing a linear or non-linear operation between the driving data value and this factor during preprocessing to enhance or reduce the amplitude of the digital human's facial expressions and body language. Data alignment addresses the driving data for different parts of a single digital human.

[0056] To maintain rendering synchronization of different parts of the digital human during the driving process, the frame rates of the driving data for all parts of the single digital human are forcibly aligned. Parts with less driving data are aligned with other parts by supplementing them with empty data or adjacent frame data. If the frame rates provided by the driving data generation algorithms for different parts are different, the frame rate of the lowest part is used to compress the data of other parts to achieve the effect of aligning all data.

[0057] In real-time scenarios, after the video stream is pushed out after rendering the screen, the actual output video stream frame rate can be obtained by pulling the video stream from the video stream server. The preprocessed data frame rate can be updated in real time based on this data, or a time window can be set to calculate the average frame rate within the time window and update the preprocessed data frame rate periodically.

[0058] Furthermore, in this embodiment of the application, before saving the current frame as an image or streaming it to a video streaming server, the following steps are included:

[0059] Perform image preprocessing operations on the current frame, including quality inspection and overlaying layers.

[0060] When high rendering quality is required, such as when only the digital human image is retained and no other virtual objects are allowed in the scene, or when the rendering machine has poor performance and the rendered output is unstable, the image content can be quality checked before saving the image or streaming to avoid outputting abnormal images. Static elements (such as logos) or external sources (such as external camera streams) that are not suitable for inclusion in the rendering scene can be overlaid as layers on the digital human rendering output during output.

[0061] Furthermore, in this embodiment of the application, when pushing the current frame to the video streaming server, the following steps are included:

[0062] The average frame rate of the video stream within a certain time window is detected, and the average frame rate is compared with the frame rate of the acquired driving data.

[0063] When the average frame rate is higher than the frame rate at which the driver data is acquired, frame compensation is performed on the frame rate at which the driver data is acquired.

[0064] When the average frame rate is lower than the frame rate at which the driver data is acquired, frame compression is performed based on the frame rate at which the driver data is acquired.

[0065] In real-time streaming scenarios, due to performance differences in rendering environments with varying configurations and performance fluctuations during the rendering process, the actual rendered frame rate may differ from the frame rate of the external input data. In such cases, by detecting the average frame rate of the streamed video over a certain time window, appropriate frame compression or compensation can be applied to the driving data to match the rendering frame rate, resulting in a more stable and smoother rendering effect. Frame rate adjustment can be done directly with the external input data or during preprocessing.

[0066] like Figure 3 As shown, the process involves obtaining the launched video stream; detecting the average frame rate of the launched video stream within a certain time window; and updating the frame rate configuration of the data preprocessing based on the average frame rate.

[0067] The following section uses the most common scenario—where the face and limbs are driven independently—as an example to explain the rendering process in detail:

[0068] Since the face and limbs are driven independently, two data pools corresponding to the face and body are used respectively.

[0069] First, upon receiving the driving data, it undergoes preprocessing. This includes adding specified values ​​or factors to certain driving channels to achieve specific style effects and aligning data from different parts. Then, all the driving data is sent to the rendering engine. In this example, both the face and limbs are driven using the Livelink protocol, so the sending method for both types of driving data is exactly the same. The rendering engine renders the first frame of the face and limb data from the data pool each time it receives a tick signal, and then captures the image. Depending on the configuration, the image can then be saved locally or pushed to the video stream.

[0070] Furthermore, in the embodiments of this application, the method further includes:

[0071] By acquiring the driving data of multiple parts of the multi-digital human and increasing the driving data pool corresponding to each part of the multi-digital human, the driving data rendering synchronization of the multi-digital human can be achieved.

[0072] In this application, when digital humans are driven by multiple independent parts in a more detailed manner or when multiple digital humans are driven simultaneously, global drive synchronization can be achieved by adding a corresponding drive data pool.

[0073] In this embodiment, different parts of the data are synchronized sequentially for each individual digital human. The synchronized data is then sent to the rendering engine. The sending order is that one frame of data for all digital humans is sent per frame, and the next frame of data is sent only after all single-frame data for all digital humans has been sent. This achieves simultaneous driving data rendering synchronization for multiple digital humans.

[0074] This application can realize synchronous rendering of driving data when a single digital human is driven by different components, as well as synchronous rendering of driving data when multiple digital humans are driven simultaneously; it can also realize automatic adjustment of driving data to adapt to rendering performance in real-time streaming scenarios.

[0075] Figure 4 This is a schematic diagram of the structure of a rendering device for digital human-driven data synchronization and frame rate adaptation provided in Embodiment 2 of this application.

[0076] like Figure 4 As shown, the digital human-driven data synchronization and frame rate adaptive rendering device includes:

[0077] The acquisition module 10 is used to acquire driving data of multiple parts of a single digital human, initialize the frame rate for acquiring driving data, and preprocess the driving data according to the frame rate.

[0078] The storage module 20 is used to send the preprocessed driver data to the rendering engine, and the rendering engine saves the preprocessed driver data to the corresponding driver data pool of each part.

[0079] Rendering module 30 is used to send the first frame of data from the driving data pool to the rendering engine when the rendering engine receives the tick signal, and to render the behavior of the single digital human based on the received data.

[0080] The capture module 40 is used to capture the current frame image through the virtual camera of the rendering engine, and save the current frame image as an image or push it to the video streaming server.

[0081] Iteration module 50 is used to send tick signals through the rendering engine and repeat the rendering module and capture module until the driving data pool is empty.

[0082] The digital human driving data synchronization and frame rate adaptive rendering apparatus of this application includes an acquisition module for acquiring driving data of multiple parts of a single digital human, initializing the frame rate of the acquired driving data, and preprocessing the driving data according to the frame rate; a storage module for sending the preprocessed driving data to the rendering engine, and saving the preprocessed driving data to the driving data pool corresponding to each part through the rendering engine; a rendering module for sending the first frame data of the driving data pool to the rendering engine when the rendering engine receives a tick signal, and rendering the behavior of the single digital human according to the received data through the rendering engine; a capture module for capturing the current frame image through the virtual camera of the rendering engine, saving the current frame image as an image or pushing it to a video streaming server; and an iteration module for sending the tick signal through the rendering engine and repeating the rendering module and the capture module until the driving data pool is empty. Therefore, it can solve the technical problems of asynchronous driving of different parts of a single digital human and multiple digital humans, as well as the lag or jitter of movements in the existing digital human rendering process. It realizes the independent rendering and synchronization of digital human faces and limbs and the synchronous driving of multiple digital humans. At the same time, it realizes the synchronization of digital human behavior in cases of further subdivision of limb movement style and facial emotion superposition, and can dynamically adjust the frame rate of external data according to the frame rate of the rendering output in real-time scenes.

[0083] Furthermore, in this embodiment of the application, the acquisition module is also used for:

[0084] Add a specified value or factor to the drive channel and align the drive data of different parts of the corresponding single digit human.

[0085] Furthermore, in this embodiment of the application, the apparatus further includes:

[0086] The multi-digital human rendering module is used to obtain driving data for multiple parts of a multi-digital human and add driving data pools corresponding to each part of the multi-digital human, thereby achieving synchronous rendering of driving data for simultaneous driving of multiple digital humans.

[0087] To implement the above embodiments, this application also proposes a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the digital human-driven data synchronization and frame rate adaptive rendering method described in the above embodiments.

[0088] To implement the above embodiments, this application also proposes a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the digital human-driven data synchronization and frame rate adaptive rendering method of the above embodiments.

[0089] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0090] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0091] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0092] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0093] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0094] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0095] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0096] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. A rendering method for digital human-driven data synchronization and frame rate adaptation, characterized in that, Includes the following steps: S1: Obtain driving data for multiple parts of a single digital human, initialize the frame rate for obtaining the driving data, and preprocess the driving data according to the frame rate. The preprocessing includes superimposing a specified value or factor on the driving channel and aligning the driving data for different parts of the corresponding single digital human. S2: The preprocessed driver data is sent to the rendering engine, and the rendering engine saves the preprocessed driver data to the driver data pool corresponding to each part. S3: When the rendering engine receives the tick signal, it sends the first frame data of the driving data pool to the rendering engine, and the rendering engine renders the behavior of the single digital human according to the received data. S4: Capture the current frame using the virtual camera of the rendering engine, and save the current frame as an image or stream it to a video streaming server; wherein, before saving the current frame as an image or streaming it to the video streaming server, perform image preprocessing operations on the current frame, including quality detection and overlay layers; when streaming the current frame to the video streaming server, detect the average frame rate within a certain time window of the stream, and compare the average frame rate with the frame rate of the acquired driving data; when the average frame rate is higher than the frame rate of the acquired driving data, perform frame compensation on the frame rate of the acquired driving data; when the average frame rate is lower than the frame rate of the acquired driving data, perform frame compression on the frame rate of the acquired driving data. S5: Send a tick signal through the rendering engine and repeat steps S3 to S5 until the drive data pool is empty.

2. The method as described in claim 1, characterized in that, The method further includes: By acquiring the driving data of multiple parts of the multi-digital human and increasing the driving data pool corresponding to each part of the multi-digital human, the driving data rendering synchronization of the multi-digital human can be achieved.

3. A rendering device for digital human-driven data synchronization and frame rate adaptation, characterized in that, include: The acquisition module is used to acquire driving data of multiple parts of a single digital human, initialize the frame rate for acquiring the driving data, and preprocess the driving data according to the frame rate. The preprocessing includes superimposing a specified value or factor on the driving channel and aligning the driving data of different parts of the corresponding single digital human. The storage module is used to send the preprocessed driver data to the rendering engine, and the rendering engine saves the preprocessed driver data to the driver data pool corresponding to each part. The rendering module is used to send the first frame of data from the driving data pool to the rendering engine when the rendering engine receives a tick signal, and to render the behavior of the single digital human based on the received data by the rendering engine. A capture module is used to capture the current frame using the virtual camera of the rendering engine, and save the current frame as an image or stream it to a video streaming server. Before saving the current frame as an image or streaming it to the video streaming server, image preprocessing is performed on the current frame, including quality detection and layer overlay. When streaming the current frame to the video streaming server, the average frame rate within a certain time window of the stream is detected, and the average frame rate is compared with the frame rate of the acquired driving data. When the average frame rate is higher than the frame rate of the acquired driving data, frame compensation is performed on the frame rate of the acquired driving data; when the average frame rate is lower than the frame rate of the acquired driving data, frame compression is performed on the frame rate of the acquired driving data. An iteration module is used to send tick signals through the rendering engine and repeat the rendering module and capture module until the driving data pool is empty.

4. The apparatus as described in claim 3, characterized in that, The device further includes: The multi-digital human rendering module is used to obtain the driving data of multiple parts of the multi-digital human and add the driving data pool corresponding to each part of the multi-digital human to achieve synchronous rendering of driving data for multiple digital humans driven simultaneously.

5. A computer device, characterized in that, The method includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, it implements the method as described in any one of claims 1-2.

6. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-2.

Citation Information

Patent Citations

  • Three-dimensional scene distributed rendering synchronous refreshing method and system

    CN103700133A

  • Animation generation method and device, storage medium and electronic equipment

    CN113538641A

  • Digital human rendering method and system under condition of low-configuration display card

    CN115471599A