A multi-terminal digital asset deployment method, device and equipment

Abstract

The present application relates to the technical field of digital, disclose a kind of multi-terminal digital asset deployment method, device and equipment, method includes obtaining digital asset, and at least one label is configured for digital asset, label is used to identify the target terminal of digital asset support agency;According to label, generate different resource package for different terminal;In response to deployment instruction, the resource package corresponding to each target terminal in different resource package is distributed to the corresponding target terminal, the present application avoids tedious operation such as manual degradation, map compression, action rebinding, eliminates version confusion and incompatible risk, shortens cross-terminal deployment period, while reducing operation and maintenance cost.

Description

Technical Field

[0001] This invention relates to the field of digital technology, and specifically to a method, apparatus, and equipment for deploying digital assets across multiple terminals. Background Technology

[0002] With the increasing prevalence of digital (virtual) assets in marketing interactions, intelligent services, and brand displays, the number of digital assets is constantly growing, and the target terminal media for deployment are becoming increasingly diverse. The hardware capabilities of different terminals vary significantly: high-performance terminals (such as large screens in exhibition halls and desktop workstations) can support high-precision real-time rendering, while low-performance terminals (such as in-vehicle devices, mobile phones, smart home screens, and VR / AR headsets) are limited by computing power and storage, requiring lightweight processing of assets such as texture compression, skeleton simplification, and motion format conversion, making deployment more difficult.

[0003] In existing technologies, the cross-terminal deployment of digital assets has the following drawbacks: asset adaptation relies on manual processing, which is inefficient and prone to errors; there is a lack of a unified cross-terminal orchestration mechanism, and the deployment processes of different channels are independent of each other; there is a lack of one-click cross-device deployment capabilities, resulting in high operation and maintenance costs. Summary of the Invention

[0004] This invention provides a method, apparatus, and device for deploying digital assets across multiple terminals, in order to solve the problem that digital assets cannot be automatically adapted and distributed due to differences in the hardware capabilities of different terminals.

[0005] In a first aspect, the present invention provides a multi-terminal digital asset deployment method, the method comprising: acquiring digital assets and configuring at least one tag for the digital assets, the tag being used to identify target terminals supported by the digital assets; generating differentiated resource packages for different terminals based on the tags using the digital assets; and distributing resource packages corresponding to each target terminal in the differentiated resource packages to the corresponding target terminals in response to deployment instructions.

[0006] Based on the aforementioned technical means, by configuring tags for digital assets and generating differentiated resource packages, precise distribution to different target terminals is achieved. The tags clearly define the deployment scope, and the differentiated generation avoids the problem of unified resource packages causing lag or wasted computing power on some terminals, thereby improving the flexibility of multi-terminal deployment and resource utilization efficiency.

[0007] In one optional implementation, acquiring digital assets and configuring at least one tag for the digital assets, the tag being used to identify the target terminal of the Digital Asset Support Agency, includes: creating digital assets according to a preset method; after creation, configuring basic information for the digital assets, the basic information including at least one of asset identifier, asset type, version number, creation time, dependency relationship and initial availability status; configuring at least one tag for the digital assets with configured basic information.

[0008] Based on the above technical means, after the creation of digital assets, basic information (asset identifier, version number, dependency relationship, etc.) is configured, and a complete file is established for each asset. The version number prevents overwriting errors, the dependency relationship ensures that resources are complete, and the initial usability status intercepts unapproved assets, thereby reducing the risk of distribution failure caused by chaotic asset information from the source.

[0009] In one optional implementation, at least one tag is configured for the digital asset with configured basic information, including: configuring a channel tag, which is used to identify the terminal type to which the digital asset is to be deployed; configuring a terminal model tag, which is used to identify the specific terminal model to which the digital asset is to be deployed; configuring a terminal capability tag, which is used to identify the performance of the terminal to which the digital asset is to be deployed; and configuring a resource version tag, which is used to identify the version information of the digital asset itself.

[0010] Based on the above technical means, by configuring channel tags, terminal model tags, terminal capability tags, and resource version tags, fine-grained descriptions of deployment scope, specific devices, chip performance, and asset versions are achieved. Each tag can be flexibly combined, and the system automatically matches the adaptation strategy accordingly, which avoids both information loss and configuration redundancy, and improves the accuracy of adaptation.

[0011] In one optional implementation, based on tags, a differentiated resource package is generated using digital assets for different terminals, including: determining an adaptation strategy to be executed on the digital assets based on the tags, the adaptation strategy being used to differentiate the digital assets according to the terminal capabilities; performing adaptation processing on the digital assets according to the adaptation strategy; and generating a differentiated resource package corresponding to each terminal from the adapted digital assets.

[0012] Based on the aforementioned technical means, the adaptation strategy is automatically determined according to the tags and the digital assets are differentiated. The same original asset is transformed into a resource package adapted to the hardware capabilities of different terminals. High-performance terminals obtain a high-fidelity version, while low-performance terminals obtain a lightweight version. This ensures both the presentation effect and smooth operation, and achieves automatic matching of resources and hardware.

[0013] In one optional implementation, determining the adaptation strategy to be performed on the digital asset based on the tag includes: selecting an asset processing strategy and a rendering strategy based on the terminal capability tag in the tag; wherein the adaptation strategy includes at least one of the following: the degree of performing model LOD downgrading processing, the degree of performing texture compression, the degree of performing bone number limit clipping, the degree of performing material merging, the conversion of the action format, and performance testing; and the rendering strategy includes adopting a real-time rendering driven mode or a pre-rendered playback mode.

[0014] Based on the aforementioned technical means, specific adaptation and rendering strategies are selected according to the terminal capability tags, including the degree of model LOD degradation, texture compression ratio, number of bone clippings, material merging method, motion format conversion, and selection of real-time or pre-rendering mode. Each device obtains individually calibrated parameters, avoiding the inaccuracy caused by simple high, medium, and low grading, and making the adaptation granularity finer.

[0015] In one optional implementation, the adapted digital assets are used to generate differentiated resource packages for each terminal, including: generating a resource file directory, action and skeleton mapping files, dependency description files, loading configuration JSON and integrity verification codes based on the adapted assets, and encapsulating them into differentiated resource packages.

[0016] Based on the above technical means, when generating differentiated resource packages, resource file directories, action and skeleton mapping files, dependency description files, loading configuration JSON, and integrity verification codes are generated simultaneously. The standardized directory structure allows the terminal to index files without adjustment, the mapping files solve the differences in skeleton naming, and the verification code ensures correct transmission. The five types of files together guarantee the deployability and verifiability of the resource package.

[0017] In one optional implementation, in response to a deployment command, the resource packages corresponding to each target terminal in the differentiated resource package are distributed to the corresponding target terminals, including: in response to a full terminal deployment command, distributing the corresponding differentiated resource packages to all configured target terminals; and in response to a specified terminal deployment command, distributing the corresponding differentiated resource packages only to the target terminals specified by the user.

[0018] Based on the aforementioned technical means, two response methods are provided: full-terminal deployment and designated terminal deployment. Full-terminal deployment is suitable for unified version upgrades or the initial deployment of new assets, enabling a one-click global update. Designated terminal deployment only sends resource packages to the user-selected terminals, suitable for gray-scale testing or targeted repairs. The two methods operate independently, reducing deployment risks and resource waste.

[0019] Secondly, the present invention provides a multi-terminal digital asset deployment method, applied to a terminal, comprising: receiving a differentiated resource package generated by any one of the first aspect and its corresponding optional embodiments distributed from the cloud, wherein the differentiated resource package corresponds to the rendering capability of the terminal; performing integrity verification and version comparison on the received differentiated resource package; if the verification passes, loading the differentiated resource package into the local rendering engine, and displaying the digital image according to the corresponding rendering configuration called by the terminal; if the verification fails or loading is abnormal, automatically reverting to the previous asset version.

[0020] Thirdly, the present invention provides a multi-terminal digital asset deployment device, the device comprising: a tag configuration module for acquiring digital assets and configuring at least one tag for the digital assets, the tag being used to identify the target terminal supported by the digital asset; a differentiated resource package module for generating differentiated resource packages for different terminals based on the tags using the digital assets; and a deployment module for distributing resource packages corresponding to each target terminal in the differentiated resource package to the corresponding target terminal in response to a deployment instruction.

[0021] Fourthly, the present invention provides an electronic device, comprising: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the multi-terminal digital asset deployment method described in the first aspect or any corresponding embodiment thereof.

[0022] Fifthly, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to execute the multi-terminal digital asset deployment method described in the first aspect or any corresponding embodiment thereof.

[0023] In a sixth aspect, the present invention provides a computer program product, including computer instructions for causing a computer to execute the multi-terminal digital asset deployment method described in the first aspect or any corresponding embodiment thereof. Attached Figure Description

[0024] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0025] Figure 1 This is a schematic diagram of the first process of a multi-terminal digital asset deployment method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of a second process for a multi-terminal digital asset deployment method according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the third process of the multi-terminal digital asset deployment method according to an embodiment of the present invention; Figure 4 This is a flowchart illustrating a specific implementation of a multi-terminal digital asset deployment method according to an embodiment of the present invention; Figure 5 This is a structural block diagram of a multi-terminal digital asset deployment device according to an embodiment of the present invention; Figure 6This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0027] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in the present invention and their authorization should be obtained in accordance with relevant laws and regulations through appropriate means.

[0028] The relevant technologies generally suffer from the following shortcomings when deploying digital human assets across multiple terminals. First, asset adaptation heavily relies on manual processing, such as downgrading high-precision models, compressing textures, and rebinding actions for different terminal rendering engines. This process is inefficient and error-prone, often requiring two separate production pipelines for the same original digital human asset in showrooms and in vehicles. Second, deployment processes across different terminals are fragmented, lacking a unified orchestration method. Maintenance personnel need to master the packaging specifications, transmission protocols, and loading mechanisms of different channels, resulting in high maintenance costs for cross-channel deployments. Third, there is a lack of a one-click cross-device deployment mechanism. When a digital human image needs updating or a new terminal model is added, adaptation, packaging, uploading, and distribution must be repeatedly performed for each channel, significantly lengthening the deployment cycle. Fourth, there is a lack of unified resource loading verification and exception rollback mechanisms on the terminal side. If a resource package is incompatible with the terminal environment, it can lead to the digital human being being undisplayed, or even cause the rendering engine to crash, posing a significant risk during the update process. Based on the above shortcomings, it is necessary to provide a unified, automated, and highly reliable one-click deployment solution for cross-channel digital human assets to achieve the goal of "building a digital human image, automatically adapting to multiple terminals, and deploying across all channels with one click".

[0029] According to an embodiment of the present invention, a method for deploying digital assets on multiple terminals is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0030] This embodiment provides a multi-terminal digital asset deployment method, which can be used in the aforementioned cloud environment. Figure 1This is a flowchart of a multi-terminal digital asset deployment method according to an embodiment of the present invention, such as... Figure 1 As shown, the process includes the following steps: Step S101: Obtain digital assets and configure at least one tag for the digital assets. The tag is used to identify the target terminal of the Digital Asset Support Agency.

[0031] Step S102: Based on the tags, generate differentiated resource packages for different terminals using digital assets.

[0032] Step S103: In response to the deployment command, the resource packages corresponding to each target terminal in the differentiated resource package are distributed to the corresponding target terminals.

[0033] It should be noted that the digital assets in this embodiment of the invention use digital humans as an example, but are not limited to this. Digital assets encompass various forms, such as 3D models, 2D images, audio files, video clips, animation sequences, virtual items, or interactive content.

[0034] Specifically, after acquiring the digital human assets, the first step is to configure at least one tag for the digital human. This tag indicates which type of target terminal the digital human is intended to be deployed on. For example, in a car brand showroom scenario, the digital human needs to be deployed on both the in-vehicle screen and the showroom's large screen, thus assigning the digital human two tags: "in-vehicle" and "showroom".

[0035] Based on the configured tags, differentiated resource packages are created for different terminals. For example, the original digital human model itself is high-precision. For in-vehicle terminals, due to limited computing resources in the vehicle and the need for fast response while driving, a simplified resource package with a lower polygon count and smaller animation files is generated, for example, the polygon count is reduced to 50% and the animation files are compressed by 50%. However, for large screens in exhibition halls, where the terminal has ample performance and a focus on visual impact is desired, the original high-precision model, high-resolution textures, and complex 3D animations are retained to generate a complete resource package.

[0036] When a deployment command is received, the system will send the resource packages corresponding to each target terminal from the differentiated resource package to the corresponding terminal devices. For example, if the deployment command requires pushing the digital human to the in-vehicle system of a certain exhibition vehicle, and simultaneously pushing the same digital human to three large screens in the exhibition hall, the in-vehicle terminal will only receive the simplified version of the resource package, and the large screens in the exhibition hall will only receive the full version of the resource package, so there will be no confusion between them.

[0037] The multi-terminal digital asset deployment method provided in this embodiment first identifies the terminal type to which each asset is intended by configuring tags on the digital assets. Since different terminals have inherent differences in computing power, storage, display specifications, and network conditions, directly sending the same asset can lead to some terminals not running smoothly or wasting transmission resources. The introduction of tags allows the system to identify the type of terminal, thus providing a basis for subsequent differentiated processing. Based on the tags, differentiated resource packages are generated for different terminals, serving an adaptation and optimization function. The same original digital asset, after different processing strategies, will generate multiple resource packages. Each resource package matches the hardware capabilities of the target terminal in dimensions such as resolution, accuracy, bitrate, or animation complexity. Terminals with sufficient computing power can receive the high-fidelity version for optimal presentation, while resource-constrained terminals receive the lightweight version to ensure smooth operation. When a deployment command is issued, the system only distributes each resource package to the corresponding target terminal, achieving precise delivery. The entire process, from asset acquisition to terminal reception, forms an efficient and controllable link, reducing the network bandwidth consumption of invalid transmissions and lowering the burden on the terminal to process redundant data locally. Overall, this method, without altering the original digital asset content, enables the same asset to adaptively cover multiple terminal environments through the synergy of tag identification, differentiated generation, and targeted distribution, thereby improving deployment flexibility and resource utilization efficiency.

[0038] This embodiment provides a multi-terminal digital asset deployment method, which can be used in the aforementioned cloud environment. Figure 2 This is a flowchart of a multi-terminal digital asset deployment method according to an embodiment of the present invention, such as... Figure 2 As shown, the process includes the following steps: Step S201: Obtain digital assets and configure at least one tag for the digital assets, the tag being used to identify the target terminal of the Digital Asset Support Agency.

[0039] Step S202: Based on the tags, generate differentiated resource packages for different terminals using digital assets. For details, please refer to [link to relevant documentation]. Figure 1 Step S102 of the illustrated embodiment will not be described again here.

[0040] Step S203: In response to the deployment command, the resource packages corresponding to each target terminal in the differentiated resource package are distributed to the respective target terminals. For details, please refer to [link to details]. Figure 1 Step S103 of the illustrated embodiment will not be described again here.

[0041] Specifically, step S201 includes: Step S2011: Create digital assets according to the preset method.

[0042] Step S2012: After creation, configure basic information for the digital asset. The basic information includes at least one of the following: asset identifier, asset type, version number, creation time, dependencies, and initial availability status.

[0043] Step S2013: Configure at least one tag for the digital asset with configured basic information.

[0044] Specifically, digital assets can be created according to preset methods, such as manual modeling, 3D scanning, procedural generation, or importing from an external material library. For example, for digital humans, the platform can call the standard 3D digital human model pre-built in the platform to create a derivative model; it can also receive external 3D model files uploaded by users and perform structural verification and standardization processing on the model; it can also copy, edit or reorganize based on an existing digital human model.

[0045] After creation, configure basic information for the digital asset. This basic information includes at least one of the following: asset identifier, asset type, version number, creation time, dependencies, and initial availability status. The asset identifier is a unique number used to locate the digital asset in the system. The asset type specifies whether it is a 3D model, audio file, or animation sequence, etc. The version number records the current modification number, such as v1.0 or v1.1. For example, for the same digital human asset, the full version resource package generated for the exhibition hall terminal might be v2.0, while the simplified version resource package generated for the vehicle terminal might be v1.0. They iterate independently. When the digital human in the exhibition hall adds new facial animations, the exhibition hall resource package upgrades to v2.1, while the vehicle terminal resource package remains unaffected and remains v1.0. The creation time marks the moment the asset was created. Dependencies indicate which other resources the asset requires to run; for example, a digital human with skeletal animation might depend on a set of skeletal files and texture files. The initial availability status indicates whether the asset is allowed to be used immediately after creation, and can be set to "available" or "pending approval."

[0046] In addition to basic information, tags are added based on deployment scenarios. The values ​​of the tags come from a predefined set of terminal types, such as "mobile phone", "tablet", "vehicle screen", "exhibition hall screen", "smartwatch", etc. A digital asset can have multiple tags at the same time, indicating that it is ready to be deployed on multiple terminals.

[0047] The multi-terminal digital asset deployment method provided in this invention, through the sequential execution of three sub-steps—creation, configuration of basic information, and configuration of tags—transforms digital assets from raw materials into deployment units that can be identified and categorized by the system. The creation step provides diverse asset source entry points, incorporating platform-preset models, user-uploaded files, and copied / edited existing models into a unified process. The basic information step establishes a complete file for each asset, with asset identification enabling precise positioning, version numbers preventing overwriting errors during updates, dependency relationships ensuring other necessary resources are prepared, and initial availability preventing unapproved assets from being mistakenly used. The tagging step transforms deployment requirements into quantifiable markers, allowing the system to directly read tags and execute corresponding processing when generating differentiated resource packages, eliminating the need for repeated judgments of asset-terminal matching. Overall, the three steps work together to ensure the integrity and traceability of the assets themselves, while laying a data foundation for subsequent differentiated generation and accurate distribution, reducing the risk of distribution errors due to incomplete asset information or chaotic tagging.

[0048] In some optional implementations, step S2013 above includes: Step a1 configures channel tags, which are used to identify the terminal type where the digital asset is to be deployed.

[0049] Step a2: Configure the terminal model label. The terminal model label is used to identify the specific terminal model to be deployed for the digital asset.

[0050] Step a3: Configure terminal capability tags. Terminal capability tags are used to identify the performance of the terminal to which digital assets are to be deployed.

[0051] Step a4: Configure resource version tags. Resource version tags are used to identify the version information of the digital asset itself.

[0052] Specifically, when configuring tags, the first step is to configure channel tags. Channel tags are used to indicate the type of terminal where the digital asset will be deployed, such as mobile phones, tablets, in-vehicle screens, large screens in exhibition halls, or smartwatches. For example, if the digital human needs to be deployed on both in-vehicle screens and large screens in exhibition halls, the channel tags would be configured as "in-vehicle" and "exhibition hall".

[0053] Next, configure the terminal model label, which points to a more specific device model. Even with in-vehicle screens, different brands and models may have different screen resolutions or interaction methods. Therefore, you can further configure model labels, such as "Model Label: XX Brand 2026 High-End" or "Brand B_Smart Cockpit". The terminal model label allows the system to perform fine-grained adaptation for a specific device.

[0054] Then configure the terminal capability tags, which describe the performance level of the target terminal. Their values ​​can be quantified performance indicators (such as chip model, CPU clock speed, GPU floating-point performance, memory bandwidth, real-time rendering frame rate limit, etc.) or predefined performance levels (such as "high computing power," "medium computing power," "low computing power"), but are not limited to levels. Terminal capability tags can be configured in the following ways, for example: automatically configured based on the system's pre-stored terminal capability model. The terminal capability model is a data structure pre-stored by the system that describes the hardware performance and rendering capabilities of different target terminals. This model includes at least the following dimensions: terminal chip computing power level (such as common automotive chips like Qualcomm 8155, 8295, MTK8676, 8675, etc.), memory and storage capacity, and graphics interface support (such as OpenGL). The model records the performance parameters (such as GPU computing power, memory bandwidth, etc.) of different terminals (such as chip models, vehicle configurations, and device specifications), including ES, Vulkan, real-time rendering capability thresholds, and terminal types (such as showroom equipment, different vehicle models, etc.). When a user specifies a target terminal model for a digital asset (e.g., "XX brand 2026 high-end model" or "Snapdragon XR2 headset"), the terminal capability model can automatically query the model to obtain the computing power level or specific performance indicators of the terminal based on the input tag information, and generate corresponding terminal capability tags (such as "computing power level: high" or "GPU computing power: 2.9 TFLOPS"). Existing tags can be refreshed in batches when the model is updated later. Alternatively, users can manually configure the tags by directly filling in or selecting tag values ​​(such as specific performance descriptions) through the interface when creating or editing digital assets. Manual configuration has higher priority than automatic recommended values. Finally, resource version tags are configured. These tags record the version information of the digital asset itself, such as v1.0 or v1.1. When the digital human model is upgraded from an older version to a newer version, the new version will be tagged with "v1.1". When the system pushes to the terminal, it first compares the asset version tag corresponding to the resource package already deployed on the terminal with the latest asset version tag in the cloud, and only pushes resource packages with inconsistent versions. Simultaneously, differentiated resource packages generated for different terminal capabilities under the same asset version will inherit this version tag for convenient unified management. The four tags work together: the channel tag defines the deployment scope, the terminal model tag identifies the specific device, the terminal capability tag guides resource adaptation based on the chip model, and the resource version tag manages the update process.

[0055] It should be noted that when configuring tags, you can flexibly select according to actual needs. It's not necessary to configure every type of tag, nor is it limited to the four types mentioned above. For example, a digital human can generate resource packages based solely on the terminal's computing power, configuring only the terminal capability tag and labeling the chip model as "Snapdragon 8Gen2" or "Dimensity 9300." The system determines the precision of the resource package based on the computing power level. Another type of digital human may need to differentiate between terminal types and specific models, but not versions. In this case, only channel tags and terminal model tags are configured, such as the channel tag "in-vehicle" and the model tag "brand A_2025 central control screen." Resource package version information is managed through other methods. Custom tags can also be added in addition to the four types, such as "touch interaction" and "voice wake-up," to describe additional terminal characteristics. Each target terminal can have one or more tags, with no quantity limit or mandatory requirements. When generating differentiated resource packages, the system reads the configured tags and determines the processing strategy based on the tag combinations; missing tags mean that this dimension is not differentiated, and all terminals are treated uniformly in this dimension.

[0056] The tag configuration method provided in this invention offers fine-grained descriptive capabilities for digital asset distribution through a combination of channel tags, terminal model tags, terminal capability tags, and resource version tags. Channel tags define the deployment scope, enabling the system to clearly identify which terminal types the digital asset needs to generate resource packages for. Terminal model tags pinpoint specific devices, supporting refined adaptation for models with different screen ratios and interaction methods. Terminal capability tags categorize computing power levels based on chip models, guiding the simplification or compression degree during resource package generation to avoid resource waste on high-performance terminals or lag on low-performance terminals. Resource version tags manage resource package versions separately for different terminal types, comparing only version differences within the same channel during update pushes, reducing invalid transmissions. Crucially, tag configuration does not require all four categories to be present; they can be flexibly selected based on actual scenarios. When only capability tags are configured, the system processes them uniformly based on computing power; when only channel and model tags are configured, adaptation is performed based on device model. Custom tags such as "touch interaction" or "voice wake-up" can also be added as needed. This flexibility allows the same tag system to handle simple single-dimensional deployments as well as support multi-condition combination decisions in complex scenarios. Overall, it reduces the burden of tag configuration, increases the applicability of the system, and ensures the accuracy of resource package generation and distribution, avoiding information loss due to too few tags or configuration redundancy due to too many tags.

[0057] In one optional implementation, step S202 includes: Step b1: Determine the adaptation strategy to be applied to the digital asset based on the tag. The adaptation strategy is used to differentiate the digital asset based on the terminal capabilities.

[0058] Step b2: Adapt the digital assets according to the adaptation strategy.

[0059] Step b3: Adapt the processed digital assets and generate differentiated resource packages for each terminal.

[0060] Specifically, the system first reads the pre-configured tags on the digital human assets. Based on these tags, it determines the appropriate adaptation strategy to be applied to the digital human. The adaptation strategy is used to differentiate the digital assets based on the terminal capabilities. The tags indicate the type, model, or capabilities of the target terminal. After reading these tags, in one example, the system can look up the corresponding strategy from a pre-set adaptation rule base. For instance, if a digital human has the "vehicle-mounted" channel tag and the "Snapdragon 8155" capability tag, the adaptation strategy will stipulate that the number of polygons in the digital human's model be reduced to one-third of the original, the texture resolution be compressed to 1024x1024, and the animation frame rate be reduced from 60fps to 30fps. On the other hand, if a digital human has the "exhibition hall" channel tag and the "dedicated graphics card RTX4060" capability tag, the adaptation strategy will stipulate that the full number of polygons, 4K textures, and full animation frame rate be retained.

[0061] It should be noted that various implementation methods can be used when determining the adaptation strategy based on tags, not limited to the aforementioned method based on a preset rule base. For example, based on decision trees or scorecards: the system converts each tag into a numerical score (e.g., "Snapdragon 8155" computing power score 70, "Snapdragon 8295" score 95), calculates a comprehensive performance index through weighted summation or decision tree branching, and then maps the index range to an adaptation level (mild / moderate / severe), determining adaptation parameters based on the level. Another example is based on machine learning models: the system pre-trains regression or classification models (e.g., random forests, neural networks) using a large number of labeled samples. When inputting a combination of asset tags, the model directly outputs an adaptation strategy vector (including target facet ratio, texture compression target, etc.). Furthermore, based on large language models, the asset tag combination can be converted into natural language prompts and sent to a local or cloud-based large language model (e.g., GPT, LLaMA). The model returns structured adaptation instructions, which the system parses and executes, suitable for handling unseen tag combinations or complex scenarios requiring interpretation. Finally, constraint optimization can also be used to solve the problem: the performance limit of the target terminal (obtained by tag mapping) is used as a constraint, and the asset quality retention is used as the optimization objective. A linear or nonlinear programming problem is constructed to maximize the number of facets and texture resolution of the model while satisfying constraints such as frame rate and memory, and the optimal adaptation parameters are automatically obtained. The above examples are only feasible implementation methods. In actual deployment, one or a combination of them can be used. The core of all of them is to automatically determine the adaptation strategy based on the matching relationship between asset tags and terminal capabilities, avoiding manual intervention.

[0062] In one example, the system automatically selects the corresponding adaptation strategy based on the tags. The system matches the tags of digital assets with the model, automatically determines the performance level of the target terminal, and then decides on the adaptation strategy (such as model LOD downgrading, texture compression, skeleton clipping, etc.).

[0063] Next, the digital assets are adapted according to the adaptation strategy, and the various operations in the above strategy are executed. For the digital human on the vehicle terminal, the system calls the model simplification tool to reduce the number of faces in the high-precision mesh. For example, the texture compression algorithm is used to convert the texture to ASTC format and reduce the resolution. At the same time, redundant bones and redundant animation clips are removed. After processing, a lightweight version of the digital human is obtained. For the digital human on the exhibition hall screen, the system does not perform any simplification processing, maintains the original high-precision model and texture, and may even generate an additional set of higher-precision normal maps to enhance the details. The adaptation process can be completed automatically or combined with manual review to ensure that the processed assets are presented as expected on the target terminal.

[0064] After adapting the digital assets, differentiated resource packages are generated for each terminal. The processed asset files are packaged according to the directory structure required by the terminal. For example, the resource package for the vehicle terminal is named "car_digitalhuman_v2.1", which contains the model file with reduced polygons, compressed texture maps, simplified animation files, and a JSON file describing the rendering configuration. The resource package for the exhibition hall screen is named "exhibition_digitalhuman_v3.0", which contains the original high-precision model, complete textures, all animation sequences, and a rendering configuration file with ray tracing enabled. Each resource package is stored independently and distributed to the corresponding terminal device after the deployment command is issued. The same original digital asset generates multiple versions of resource packages through different adaptation strategies, and each version is only sent to its corresponding target terminal.

[0065] This invention employs an automatic tag matching and adaptation strategy. After reading the tags, the system directly retrieves the corresponding processing parameters from the rule base. Regardless of the chip used by the terminal, it can automatically obtain a customized adaptation solution. The adaptation processing stage performs operations such as model reduction, texture compression, and skeleton trimming according to the strategy, ensuring that the resource package neither exceeds the terminal's hardware capacity nor wastes the terminal's graphics performance. Each differentiated resource package generated contains a complete file directory, configuration file, and verification code, which can be stored and distributed independently. The same original digital asset thus generates multiple versions, each of which flows only to the terminal device with the corresponding tag, without interfering with each other. The entire process, from tagging to adaptation to packaging, automates multi-terminal deployment, reduces manual intervention costs, and avoids display lag or functional loss caused by resource package version mismatch.

[0066] In one alternative implementation, step b1 includes: Step b11: Select asset processing strategy and rendering strategy according to the terminal capability tag in the label. The adaptation strategy includes at least one of the following: the degree of performing model LOD degradation processing, the degree of performing texture compression, the degree of performing bone number limit clipping, the degree of performing material merging, the conversion of motion format, and performance testing. The rendering strategy includes adopting real-time rendering driven mode or pre-rendered playback mode.

[0067] Specifically, the adaptation strategy is used to lightweight or resize the original data of digital assets to match the hardware performance of the target terminal; the rendering strategy is used to determine how the digital assets are presented on the target terminal. The adaptation strategy includes several adjustable processing operations. The degree of model LOD downgrading refers to the level to which the original high-precision model is simplified, such as retaining 30% of the polygons for Snapdragon 8155 and 50% for Snapdragon 8295. The degree of texture compression determines the resolution and compression format of the texture map. For example, for the Snapdragon 8155, a 4K texture is compressed to 1024x1024, while for the Snapdragon 8295 it is only compressed to 2048x2048. The degree of bone number limitation and cropping is for digital humans with skeletal animation. The original character has 150 bones, which is cropped to 60 for the Snapdragon 8155 and to 100 for the Snapdragon 8295. The degree of material merging refers to merging the textures of multiple independent materials into a single atlas. For example, for low-end chips, all materials are forcibly merged, while for high-end chips, individual textures of the main materials are allowed to be retained. The converted motion format refers to the encoding method of the animation file. For example, skeletal animation is converted from float precision to half precision, or from full keyframes to differential compression format. Performance testing is a simulated run test of the resource package after adaptation processing to confirm whether the preset frame rate standard can be achieved on the target chip.

[0068] The rendering strategy is divided into two modes. The real-time rendering-driven mode requires the terminal to dynamically calculate lighting, shadows, and animations at runtime. The resource package only contains model, texture, and animation data, and the specific visual effects are generated in real time by the terminal's graphics computing power, which is suitable for interactive scenarios. The pre-rendered playback mode pre-renders the digital human's movements and lighting into video files. The terminal only needs to display it like playing a movie, without performing 3D calculations. This mode is suitable for terminals with extremely weak computing power or those that only require fixed display.

[0069] The asset processing and rendering strategies are selected based on the terminal capability tags in the labels. The terminal capability tags record the device's capability information in multiple dimensions, including the computing power threshold, memory capacity, graphics interface support, and real-time rendering capability level of the terminal chip (such as Qualcomm 8155, 8295, MTK8676, 8675, etc.).

[0070] For example, a virtual reality headset might have capability labels including "Snapdragon XR2 chip", "3840x2160 resolution for both eyes", "supports 90Hz refresh rate", and "requires separate rendering of left and right eye views". Another terminal is a regular large screen connected to 3D glasses, and its capability labels might include "RTX3060 graphics card", "supports polarized 3D", and "output format is interlaced frames".

[0071] In one example, a terminal capability model is first established. The system pre-stores the terminal capability model, which includes performance parameters for different chips (such as Qualcomm 8155, 8295, MTK8676, 8675, etc.) and vehicle configurations (such as high-end / low-end), including but not limited to: GPU floating-point computing power (TFLOPS), texture fill rate (GPixel / s), memory bandwidth (GB / s), real-time rendering frame rate limit (fps), maximum supported model face count, and maximum supported texture resolution. For example, as shown in Table 1: Table 1

[0072] The system parses the digital assets to obtain their raw performance consumption metrics, including: total face count, total texture resolution, number of bones, number of materials, and motion file size. Then, it calculates the adaptation target. Based on the asset's terminal capability tag (e.g., "Qualcomm 8155"), the system queries the terminal capability model to obtain the performance ceiling for that terminal. Next, it compares the asset's raw metrics with the terminal's ceiling, for example, calculating various adaptation parameters using the following formula: LOD downgrade target number of faces = min(original number of faces, terminal recommended maximum number of faces × safety factor) For example: if the original number of faces is 1 million, the terminal recommends a maximum number of faces of 300,000, and the safety factor is 0.8, then the target number of faces = 300,000 × 0.8 = 240,000, which means it needs to be downgraded to 24% of the original number of faces.

[0073] Texture compression target resolution: The system gradually reduces the resolution of each texture until the total memory usage of all textures does not exceed the terminal's memory budget. The compression algorithm prioritizes the most efficient format supported by the terminal (such as ASTC, ETC2, JPEG).

[0074] Skeleton trimming count: The system retains the main skeleton (root skeleton, limbs, head) and trims auxiliary skeletons (such as finger details, clothing ribbons) until the number of bones does not exceed the terminal's limit. Trimming ratio = max(0, original number of bones - terminal limit) / original number of bones.

[0075] Material merging: When the number of materials exceeds the terminal recommendation value, the system will merge materials with the same shader type and the same texture channel into a single material.

[0076] Action format conversion: The system converts FBX action files in batches to the target format (such as Metal binary for iOS and Vulkan-specific format for Android) based on the graphical interface support in the terminal model.

[0077] Rendering mode decision: If, after the above adaptation, the estimated performance consumption (number of faces × frame rate × coefficient) still exceeds the terminal's computing power limit, or if the terminal is a low-computing-power chip (such as MTK8675), then the pre-rendered video playback mode will be automatically switched.

[0078] Finally, iterative fine-tuning is performed. The system checks the performance budget of the adapted resources. If the estimated consumption still exceeds the limit, the degradation is further increased (e.g., continuing to reduce the number of faces or continue to compress textures) until the budget requirements are met or the minimum acceptable threshold is reached. The above processing method is only an example and is not limited to this.

[0079] This invention employs the aforementioned mechanism to select capability tags from the labels to choose an adaptation strategy. It automatically associates the terminal capability model with the tags. After querying the specific performance parameters corresponding to the chip model, the system performs quantitative adaptation calculations on the digital assets. The model's face count, texture resolution, number of bones, material merging degree, and motion format are all dynamically determined by the ratio of the original consumption to the terminal's upper limit, avoiding the tedious manual parameter tuning. The adaptation process repeatedly performs performance budget checks; if the estimated consumption exceeds the terminal's capacity, it automatically increases the degradation level or switches to pre-rendered video mode, ensuring that each resource package runs stably on the target terminal. The entire mechanism forms a closed loop from tag reading, model matching, parameter calculation to iterative fine-tuning, preserving the visual performance of high-end terminals while ensuring the basic usability of low-end terminals. It also covers multiple capability dimensions such as chips, glasses, and vehicle system configurations, improving the automation and robustness of multi-terminal deployment.

[0080] In one optional implementation, step b3 above includes: Step b31: Generate a resource file directory, action and skeleton mapping files, dependency description files, loading configuration JSON and integrity verification code based on the adapted assets, and encapsulate them into a differentiated resource package.

[0081] Specifically, based on the adapted assets, a resource file directory is first generated. This directory is a folder structure that stores all processed files according to their type, such as model folders, texture folders, animation folders, audio folders, etc. The directory hierarchy and naming rules are fixed, allowing the terminal to quickly locate the required files after receiving the resource package.

[0082] Next, motion and skeleton mapping files are generated. The bone naming and animation data in the original digital human assets may use a set of internal naming rules, while the rendering engines on different terminals may require different bone names or index orders. The motion and skeleton mapping files record the correspondence between the original bones and the bones required by the terminal. For example, "LeftArm" in the original model is mapped to "arm_L" in the terminal engine, and it also marks which bones have been clipped.

[0083] Then, a dependency description file is generated. This file lists the external resources required for the resource package to run. For example, a texture might depend on a shared material library, or an animation clip might depend on a specific physics configuration file. Dependency description files are typically in JSON or XML format, and each dependency includes the resource name, version number, and how it was obtained (e.g., a cloud address or a local relative path). When loading the resource package, the terminal first reads the dependency description file to ensure all dependencies are ready; otherwise, rendering will not begin.

[0084] Then, a loading configuration JSON is generated. This JSON is a lightweight configuration file that records the resource package's entry information, default scene settings, rendering strategy parameters, etc. For example, for a digital human resource package for an in-vehicle terminal, the loading configuration JSON will specify the path to the model file, the name of the first animation segment, the initial camera position, and whether shadows are enabled. The loading configuration JSON has a universal format, which can be parsed by any loader on any terminal, thus launching the digital human in the preset manner.

[0085] Finally, an integrity checksum is generated. This checksum is typically a string calculated using a hash algorithm (such as MD5 or SHA-256) on all files within the resource packet. This checksum is written to a separate file or appended to the end of the resource packet. Upon receiving the resource packet, the terminal also calculates the hash value of its local files and compares it with the received checksum. If they match, the files have not been corrupted or tampered with during transmission; if they do not match, the terminal will refuse to load the file and request a resend from the cloud. These five files together constitute a complete, verifiable, and independently deployable resource packet.

[0086] This invention generates a standardized resource file directory and accompanying description files, making each differentiated resource package an independently parsable, verifiable, and loadable deployment unit. The resource file directory fixes the storage location of models, textures, animations, and other files, allowing the terminal loader to index content by path without additional configuration. Motion and skeleton mapping files resolve inconsistencies in skeleton naming across different engines, ensuring animation data is correctly bound to the model. Dependency description files list external resources and their versions, preventing runtime errors due to missing material libraries or configuration files. Loading configuration JSON standardizes startup parameters, allowing any terminal to initialize the digital human in the same way by reading the same JSON. Integrity checksums provide a self-checking mechanism for transmission correctness; the terminal performs hash comparisons before loading to prevent corrupted or tampered packages from entering the rendering process. These five file types work together to make the entire process of resource package adaptation and terminal loading predictable and verifiable, reducing the risk of deployment failure due to chaotic file structures or missing dependencies.

[0087] In one optional implementation, step S203 includes: Step c1: In response to the full-terminal deployment command, distribute the corresponding differentiated resource packages to all configured target terminals.

[0088] Step c2, in response to the deployment of a specified terminal, distributes the corresponding differentiated resource package only to the target terminal specified by the user.

[0089] Specifically, after receiving the full-terminal deployment instruction, the system will identify all target terminals that have been tagged and send the corresponding differentiated resource packages to each terminal. For example, terminals that have been tagged include exhibition hall screens, in-vehicle screens, mobile applications, and smartwatches. After the full-terminal deployment instruction is issued, the exhibition hall screens receive the full version of the resource package, the in-vehicle screens receive the simplified version, the mobile applications receive the mobile version, and the smartwatches receive the ultra-simplified version, with each terminal receiving the resource package it needs.

[0090] When the system receives a deployment instruction for a specified terminal, it only sends resource packages to the terminals explicitly selected by the user. For example, if a user only wants to push a new digital human to the in-vehicle system of a certain exhibition vehicle, the deployment instruction will list the identifiers of these specific terminals.

[0091] This invention provides two command response methods: full-terminal deployment and designated terminal deployment, enabling flexible distribution of digital assets to adapt to different scenarios. When a full-terminal deployment command is issued, the system automatically identifies all target terminals with configured tags and sends the corresponding differentiated resource package to each terminal. For example, a large screen in a showroom receives the full resource package, a vehicle screen receives a simplified version, a mobile phone receives a mobile version, and a smartwatch receives a minimalist version. This completes a global update in a single operation, suitable for scenarios involving unified version upgrades or the initial launch of new assets. When a designated terminal deployment command arrives, the system only sends resource packages to the specific terminals listed by the user. For example, it might only push a new digital human to the in-vehicle system of a particular show vehicle, while other terminals remain unchanged. This is suitable for scenarios involving gray-scale testing, targeted repairs, or individual on-demand updates. The two methods are independent of each other, avoiding the waste of network and computing resources caused by traversing all terminals for each deployment, and reducing the risks introduced by excessively large update scopes, thus improving the overall flexibility and controllability of multi-terminal deployment.

[0092] This embodiment provides a multi-terminal digital asset deployment method, which can be used for the aforementioned terminals. Figure 3 This is a flowchart of a multi-terminal digital asset deployment method according to an embodiment of the present invention, such as... Figure 3 As shown, the process includes the following steps: Step S301: Receive a differentiated resource package generated by any one of the embodiments of the present invention and the corresponding optional implementation methods distributed by the cloud. The differentiated resource package corresponds to the rendering capability of the terminal.

[0093] Step S302: Perform integrity verification and version comparison on the received differentiated resource packages.

[0094] In step S303, if the verification passes, the differentiated resource package is loaded into the local rendering engine, and the digital image is displayed according to the corresponding rendering configuration called by the terminal.

[0095] In step S304, if the verification fails or the loading is abnormal, the system will automatically revert to the previous asset version.

[0096] Specifically, firstly, after receiving the resource package distributed from the cloud, the terminal performs an integrity check on the package body to check whether the files have been damaged or tampered with during transmission. At the same time, it compares the version number carried in the resource package with the version number currently deployed on the terminal. If the versions are the same, there is no need to load them again. Then, it performs a dependency check to confirm that all external files required for the resource package to run are complete, such as whether the shared texture library or physical configuration file that a certain material depends on exists.

[0097] The resource package itself contains digital human model files, motion and behavior data files, texture and material resources, as well as asset configuration files and version description files. The entire resource package automatically generates the resource directory structure, dependency descriptions, and integrity verification information according to the target terminal's loading specifications. Therefore, after receiving the package, the terminal can directly index the content according to the preset path without manually adjusting the file positions.

[0098] After all verifications pass, the terminal transfers the resource package to the local rendering engine for loading. The rendering engine calls the corresponding rendering configuration based on the terminal type. For example, the in-vehicle screen uses a lightweight rendering configuration to disable some effects, while the large screen in the exhibition hall uses a high-quality configuration to enable ray tracing. Once loading is complete, the new digital human avatar is immediately displayed in the exhibition hall scene or the in-vehicle interactive interface.

[0099] If any anomalies are detected during verification or loading, such as integrity verification failure, missing dependency files, or the rendering engine's inability to parse the model format, the terminal will automatically revert to the previous stable version. The terminal will not be unable to display digital images due to issues with the new resource package; instead, it will continue to use the previously working older version, ensuring system continuity and security.

[0100] The multi-terminal digital asset deployment method provided in this embodiment eliminates the need for manual adaptation by receiving differentiated resource packages corresponding to the rendering capabilities of the terminal. The terminal first performs integrity checks, version comparisons, and dependency checks on the resource packages to ensure that files are not corrupted, versions are correct, and all external resources are complete, avoiding loading failures due to transmission errors or missing dependencies. The resource packages themselves have a pre-organized directory structure and configuration files according to the target terminal's loading specifications. Upon receiving them, the terminal can directly transfer them to the local rendering engine without manual file location adjustments. The rendering engine calls the corresponding rendering configuration based on the terminal type; for example, disabling some effects on in-vehicle screens and enabling ray tracing on large exhibition hall screens, ensuring the same digital asset achieves suitable presentation effects in different hardware environments. When verification or loading anomalies occur, the terminal automatically reverts to the previous stable version, preventing interruption of digital image display due to issues with the new package. The entire process, from receiving, verifying, loading to anomaly rollback, forms a closed loop, improving the automation level of deployment and ensuring the continuity and security of system operation.

[0101] As a specific embodiment of the present invention, for example Figure 4As shown, the first step is to collect and manage digital human assets. The collected raw materials include 3D models, motion libraries, clothing, and sound packs, all of which are uniformly entered into the asset management module. At the same time, the tag management module is used to configure channel tags and terminal capability tags for digital human assets. For example, the exhibition hall scene is tagged with "exhibition hall" and "RTX4060" capability tags, and the in-vehicle scene is tagged with "in-vehicle" and "Snapdragon 8155" capability tags.

[0102] After data collection and tagging, the digital human assets enter the cloud-based automated asset adaptation engine. This engine selects adaptation strategies based on pre-configured tags, automatically determining the processing method required for each target terminal. For the showroom terminal, the adaptation engine decides to maintain high polygon count, 4K textures, and a fully dynamic model, generating a high-specification resource package. For the in-vehicle terminal, the engine automatically performs LOD downgrading, converts textures to ETC2 or ASTC format, simplifies the number of bones, and merges materials, thereby generating a lightweight resource package. The entire process requires no manual intervention and is completed automatically based on the tags.

[0103] After resource packages from different channels are generated, the system triggers a one-click deployment command, and the cloud distributes each resource package to the corresponding target terminal. The showroom terminal receives the high-specification package, while the vehicle-mounted terminal receives the lightweight package. Upon receiving the resource package, the terminal performs deployment and verification, sequentially checking the package integrity, executing dependencies (such as confirming that the material library and configuration files are complete), and comparing the version number (with the existing local version). Once all checks pass, the resources are transferred to the local rendering engine for loading.

[0104] Successfully loaded resources will automatically display the updated digital human image on the showroom or in-vehicle interface. The showroom uses a high-definition rendering configuration, while the in-vehicle system uses a lightweight rendering configuration. The digital human will immediately appear on the showroom screen or in-vehicle interactive interface. If an error occurs during verification or loading, the version and rollback module will trigger a rollback operation. The terminal will automatically revert to the previous stable version and report the failure information to the cloud, ensuring that the system is always operational.

[0105] This embodiment also provides a multi-terminal digital asset deployment device, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0106] This embodiment provides a multi-terminal digital asset deployment device, such as... Figure 5 As shown, it includes: The configuration tag module 501 is used to configure the tag module to acquire digital assets and to configure at least one tag for the digital assets. The tag is used to identify the target terminal of the digital asset support agency.

[0107] The differentiated resource package module 502 is used to generate differentiated resource packages for different terminals based on tags and digital assets.

[0108] The deployment module 503 is used to distribute the resource packages corresponding to each target terminal in the differentiated resource package to the corresponding target terminal in response to the deployment command.

[0109] The multi-terminal digital asset deployment device provided in this embodiment of the invention can execute the multi-terminal digital asset deployment method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects for executing the method. Further functional descriptions of the various modules and units described above are the same as in the corresponding embodiments described above, and will not be repeated here.

[0110] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

[0111] The following is a detailed reference. Figure 6 This diagram illustrates a suitable structural design for implementing an electronic device according to embodiments of the present invention. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 601, which can perform various appropriate actions and processes based on a program stored in read-only memory (ROM) 602 or a program loaded from memory 608 into random access memory (RAM) 603. RAM 603 also stores various programs and data required for the operation of the electronic device. The processor 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0112] Typically, the following devices can be connected to I / O interface 605: input devices 606 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 607 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 608 including, for example, magnetic tapes, hard disks, etc.; and communication devices 609. Communication device 609 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 6 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0113] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 609, or installed from a memory 608, or installed from a ROM 602. When the computer program is executed by the processor 601, it performs the functions defined in the multi-terminal digital asset deployment method of the embodiments of the present invention.

[0114] Figure 6 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0115] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the multi-terminal digital asset deployment method shown in the above embodiments is implemented.

[0116] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0117] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for deploying digital assets across multiple terminals, characterized in that, Applied to the cloud, the method includes: Acquire digital assets and configure at least one tag for the digital assets, the tag being used to identify the target terminal for which the digital assets are deployed; Based on the tags, the digital assets are used to generate differentiated resource packages for different terminals; In response to the deployment command, the resource packages in the differentiated resource packages corresponding to each target terminal are distributed to the corresponding target terminals.

2. The method according to claim 1, characterized in that, The process of acquiring digital assets and configuring at least one tag for the digital assets, wherein the tag is used to identify the target terminal for deployment of the digital assets, includes: Create digital assets according to preset methods; After creation, configure basic information for the digital asset. The basic information includes at least one of the following: asset identifier, asset type, version number, creation time, dependencies, and initial availability status. Configure at least one tag for digital assets with configured basic information.

3. The method according to claim 1, characterized in that, The process of configuring at least one tag for digital assets with pre-configured basic information includes: Configure channel tags, which are used to identify the terminal type to which the digital asset is to be deployed; Configure a terminal model label, which is used to identify the specific terminal model to which the digital asset is to be deployed; Configure terminal capability tags, which are used to identify the performance of the terminal to which the digital asset is to be deployed; Configure a resource version label, which is used to identify the version information of the digital asset itself.

4. The method according to claim 3, characterized in that, The step of generating differentiated resource packages for different terminals using the digital assets based on the tags includes: An adaptation strategy is determined for the digital asset based on the tag, and the adaptation strategy is used to differentiate the digital asset according to the terminal capabilities. The digital assets are adapted according to the adaptation strategy. The adapted digital assets are then used to generate differentiated resource packages for each terminal.

5. The method according to claim 4, characterized in that, The step of determining the adaptation strategy to be applied to the digital asset based on the tag includes: Based on the terminal capability tags in the tags, select the asset processing strategy and rendering strategy; The asset processing strategy includes at least one of the following: the degree of performing model LOD degradation processing, the degree of performing texture compression, the degree of performing bone number limit clipping, the degree of performing material merging, the conversion of motion format, and performance testing. The rendering strategy includes adopting a real-time rendering driven mode or a pre-rendered playback mode.

6. The method according to claim 4, characterized in that, The process of generating differentiated resource packages for each terminal from the adapted digital assets includes: Based on the adapted assets, a resource file directory, action and skeleton mapping files, dependency description files, loading configuration JSON, and integrity verification codes are generated and packaged into the differentiated resource package.

7. The method according to claim 1, characterized in that, The step of responding to a deployment command by distributing the resource packages corresponding to each target terminal in the differentiated resource package to the respective target terminals includes: In response to the full-terminal deployment command, the corresponding differentiated resource packages are distributed to all configured target terminals; In response to deployment on a specified terminal, the corresponding differentiated resource package is distributed only to the target terminal specified by the user.

8. A method for deploying digital assets across multiple terminals, characterized in that, Applied to terminals, including: Receive a differentiated resource package generated as described in any one of claims 1-7, distributed from the cloud, wherein the differentiated resource package corresponds to the rendering capability of the terminal; Perform integrity checks and version comparisons on the received differentiated resource packages; If the verification passes, the differentiated resource package is loaded into the local rendering engine, and the digital image is displayed according to the corresponding rendering configuration called by the terminal. If the verification fails or loading fails, the system will automatically revert to the previous asset version.

9. A multi-terminal digital asset deployment device, characterized in that, The device includes: A tag configuration module is used to acquire digital assets and configure at least one tag for the digital assets, the tag being used to identify the target terminal of the digital asset support agency; The differentiated resource package module is used to generate differentiated resource packages for different terminals based on the tags and the digital assets. The deployment module is used to distribute the resource packages corresponding to each target terminal in the differentiated resource package to the corresponding target terminal in response to the deployment command.

10. An electronic device, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the computer instructions to perform the multi-terminal digital asset deployment method according to any one of claims 1 to 7.

Images