Dynamic three-dimensional data conversion method based on open dynamic asset format

Abstract

The invention discloses a dynamic three-dimensional data conversion method based on an open dynamic asset format, which solves the defects of the existing animation format in the aspects of compatibility, expansibility, file volume and dynamic support through a modularized layered structure, a dynamic animation system, physical and animation fusion, cross-medium compatibility, safety cooperation and efficient analysis technology. The converted data supports hierarchical compression, nodal program logic, real-time physical interaction and multi-platform efficient decoding, is suitable for the fields of games, movies and televisions, VR / AR and the like, and has remarkable technical advantages.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of computer graphics, animation and real-time rendering, and in particular to a dynamic three-dimensional data conversion method based on an open dynamic asset format (ODAF). BACKGROUND

[0002] Currently, in the field of computer graphics, game development and virtual reality, the exchange and application of dynamic three-dimensional data (three-dimensional digital assets) mainly rely on mainstream formats such as FBX and glTF. However, with the development of technology and the complexity of application scenarios, these existing formats have exposed many limitations in practical applications: Data exchange vulnerability: When importing and exporting data between different three-dimensional software or platforms, the existing formats often cause loss or confusion of key information such as models, bone binding or animation curves due to version incompatibility or differences in private data extensions, reducing collaboration efficiency.

[0003] Performance bottleneck of network transmission: High-precision geometric models, high-resolution textures and long animation sequences result in huge asset file sizes. In applications such as streaming media or mobile devices that are sensitive to bandwidth and loading speed, this causes excessive waiting time, severely affecting user experience.

[0004] Rigid functionality extension: The architecture design of existing formats is relatively fixed, making it difficult to natively support and extend emerging graphics technologies such as neural rendering, real-time physics simulation, procedural animation generation, etc., limiting the dynamic interaction capabilities and expressiveness of assets.

[0005] Limitations of animation expression: Animation systems generally rely on traditional linear keyframe interpolation, which can express preset actions, but for complex dynamic behaviors that require real-time response and non-linear changes, the expression efficiency is low and lacks flexibility, making it difficult to meet the needs of high-fidelity real-time interaction.

[0006] Therefore, the industry urgently needs a new type of dynamic digital asset format to overcome the above-mentioned deficiencies and meet the future needs of high-performance and high-interactive three-dimensional applications. SUMMARY

[0007] The present application mainly solves the technical problems of low compatibility, large file size, insufficient extensibility and limited animation expression of existing technologies, and provides a dynamic three-dimensional data conversion method based on an open dynamic asset format (ODAF) with high compatibility, small size, good extensibility and expression ability.

[0008] The present application mainly solves the above technical problems through the following technical solution: a dynamic three-dimensional data conversion method based on an open dynamic asset format (ODAF), comprising the following steps: S1: Read the basic configuration, obtain the basic requirements of data processing, such as the information of subsequent compression level, etc. S2: Data preprocessing: classify, optimize and format convert the original data; the original data mainly includes three types: geometry data, animation data and texture data; Geometry Data: defines the shape of an object. It contains vertex coordinates, normals, UV coordinates, vertex colors, triangle indices, etc., which is the "skeleton"; Animation Data: defines how an object moves, which contains bone structure, keyframes, animation curves or procedural animation graph logic, which is the "action"; Texture Data: defines the appearance of an object's surface, which contains image information such as diffuse maps, normal maps, and metallicity maps, which is the "skin"; S3: Compression and serialization: compress each type of data using a specific algorithm and serialize it into a binary block; this step aims to significantly reduce the file size and convert the processed data into a binary format suitable for storage and transmission; S4: Security processing: encrypt sensitive data partition and embed dynamic watermark; S5: Packaging: generate file packages and build the complete open dynamic asset format file structure.

[0009] As preferred, in the data preprocessing, the optimization process is specifically: S201: Vertex caching for triangle indices of geometry data, aiming to reduce the vertex processing overhead of GPU during rendering and improve rendering efficiency; S202: Process the geometry data into several levels of detail and divide the space using octree, preparing for subsequent on-demand loading and streaming rendering; S203: Use Lanczos algorithm to generate a series of low-resolution images with half size step by step from the original full-size texture (LOD 0), i.e. MIPMAP chain (LOD 1, LOD 2,...), effectively preventing moire and flicker of distant textures and improving texture sampling efficiency. LOD 0: original precision (1M faces). LOD 1~N: step-by-step simplification (e.g. reduce 50% faces per level). Storage structure: [BlockHeader][LOD 0 Data][LOD 1 Data]...[LOD N Data]. The block header contains spatial position, size and offset of each level LOD.

[0010] As preferred, in the data compression and serialization process, the processing flow of geometry data is: S301: Scene Bounding Box Calculation: First, calculate the minimum three-dimensional bounding box containing all vertex data, which will determine the range of all vertex coordinates (min and max values); S302: Quantization of floating-point coordinates: Map the original 32-bit floating-point vertex coordinates (raw_value) to 16-bit unsigned integers (quantized_value) through the following formula. This step is lossy compression, but by preserving the bounding box information, approximate original coordinates can be recovered during decoding, greatly reducing data volume; quantized_value = round((raw_value - min) / (max - min) x 65535); S303: Normal data quantization: For vertex normal vectors, direction is more important than length, so it is mapped from three 32-bit floating-point numbers to 8-bit signed integers; S304: Topology data compression: Use the lossless mode of Draco algorithm to compress the topology structure of the model (i.e. the vertex index connection relationship of triangles); Draco can very efficiently compress index data through prediction and entropy coding techniques; S305: Vertex data compression: Use the lossy mode of Draco algorithm to compress the quantized vertex attribute data (coordinates, normals, UV, etc.); Draco will utilize the spatial correlation between vertices to encode the offset of each vertex relative to its neighbors, thereby achieving extremely high compression ratio. A geometry error threshold (such as 0.1mm) can be set to control the compression accuracy; S306: Vertex cache optimization: Use Meshopt to perform vertex cache optimization (Vcache) on triangle indices; After Draco compression (or before), apply Meshopt's Vcache optimization, which rearranges the order of triangle indices so that continuously referenced vertices are physically as close as possible, maximizing GPU vertex cache hit rate and significantly reducing vertex shader recalculation during rendering, improving rendering performance; S307: Data block serialization: Pack the Draco-compressed topology and vertex data blocks, Meshopt-optimized index buffer, and quantization-required metadata (such as bounding box min / max values) into a binary block (e.g. geometry.bin).

[0011] Geometry data defines the shape of the model, and its core is a large number of vertex coordinates and connection relationships. The goal of processing is high compression ratio and fast decoding.

[0012] As preferred, the processing flow of animation data during data compression and serialization is: S311: Delta encoding (difference encoding): Calculate the difference value of the adjacent key frame's bone transform data (translation, rotation, scaling); Animation data has high continuity in time, for the transform (translation, rotation, scaling) of each bone, the absolute value of each frame is not stored, but the difference (Delta) between the current frame and the previous frame is calculated and stored, since the bone changes very small most of the time, these differences are usually close to zero, which is very suitable for subsequent compression; Example: Frame 1: Position (1.0, 2.0, 3.0); Frame 2: Position (1.1, 2.0, 3.0); Delta: (0.1, 0.0, 0.0); S312: Rotation quantization: Bone rotation is usually represented by a quaternion (Quaternion), which quantizes each component (x, y, z, w) from a 32-bit floating-point number to a 16-bit signed integer; When decoding, the unit quaternion is restored by normalization operation, which compresses the rotation data by 50% without losing visual quality; S313: General data stream compression: Treat the data stream (a series of difference values and quantization values) after Delta encoding and quantization as a normal binary data stream, divide this data stream into blocks according to the time axis (for example, one group every 100 frames), and then compress each block using the Zstandard (Zstd) algorithm; Zstd provides excellent compression ratio and decompression speed; S314: Structure definition: Abstract the node-based animation graph (Animation Graph, including mathematical operation nodes, state machine nodes, IK solver nodes, etc.) into a directed graph structure.

[0013] S315: Binary serialization: Convert this graph structure into a compact binary format, format: [Header][Node List][Connection List][WASM Plugins][Keyframe Data]; Its content includes: Header: Version number, total number of nodes, number of connections, and plugin size meta information; Node List: Type of each node (such as input / processing / output) and its internal parameters (such as IK weight, state machine condition); Connection List: Directed connection relationship between nodes (source node, target node, port number); Describes the connection between nodes, that is, which node's output port is connected to which node's input port; WASM Plugins: Pre-compiled WebAssembly modules for runtime dynamic logic extension. Keyframe Data: Skeleton animation keyframe data.

[0014] Animation data defines the changes of a model over time, mainly including skeleton keyframes and procedural logic. The processing goal is to remove temporal redundancy and support dynamic logic.

[0015] As a preferred, the processing flow of texture data in data compression and serialization process is: S321: Separate RGBA channels for textures with transparency requirements; compress RGB channels for opaque textures; S322: Generate intermediate format through Basis Universal compression module; select UASTC (Universal ASTC) mode during compression, which is a high-quality intermediate block compression format. Its advantage is versatility: a UASTC format file can be quickly transcoded into almost any modern GPU supported block compression format (such as ASTC, BC7, ETC2) at runtime; this step has achieved significant compression and laid the foundation for cross-platform GPU compatibility; S323: Convert intermediate format data to ASTC 6x6 block format; to achieve extreme compression rate, this scheme selects to further convert UASTC output to ASTC 6x6 block format; ASTC (Adaptive Scalable Texture Compression) is a very flexible and efficient GPU texture compression format that supports non-power-of-two sizes and different block sizes; 6x6 block size provides higher compression ratio than standard 4x4; this scheme can also dynamically select block size according to texture content (such as 4x4 for detailed areas, 6x6 or 8x8 for smooth areas), achieving adaptive compression rate; For high-level (large size) MIPMAP, lossless mode or high-quality settings of Basis Universal can be used to preserve the most details; For low-level (small size) MIPMAP, more aggressive lossy compression (such as ASTC 6x6 or higher compression ratio settings) can be used because they have fewer pixels displayed on the screen; S324: Pack all compressed level data into a binary block, and the metadata of the file records the compression format used and the existence of MIPMAP.

[0016] Texture is the largest part of 3D assets. The processing goal is to achieve extremely high compression rate while maintaining visual quality and support GPU direct decoding.

[0017] As a preference, the partition encryption is specifically: Mark the data block to be encrypted in the JSON file; Encrypt the marked data block using the AES-GCM algorithm to generate ciphertext and authentication tag; Replace the original plaintext data block with the encrypted ciphertext and store the authentication tag; The key is managed by a hardware security module (HSM), which means that the key itself will not be stored in plaintext form in the file or code, but will be kept by a secure hardware device and only called by authorized programs during encryption / decryption.

[0018] The dynamic watermark embedding is specifically: Convert the watermark information into a binary stream, for example, use ASCII or UTF-8 encoding to get 0100001110010100... Iterate through the vertex coordinates of the model, take the least significant bit of each coordinate component (x, y, z) in its floating-point representation; the modification of this position has a negligible effect on the actual position of the vertex (such as 12.3456 to 12.3456001), which is completely imperceptible to the naked eye; Embed the binary stream of the watermark bit by bit into the LSB of the vertex coordinates in order; for example, the first vertex's x-coordinate LSB embeds the first bit of the watermark, the y-coordinate embeds the second bit, and the z-coordinate embeds the third bit, then the second vertex, and so on.

[0019] Mark the existence of the watermark in the security section of the JSON descriptor, such as "watermark":"vertex_lsb", which can prompt special tools to find and verify the watermark.

[0020] When decoding, special shaders or tools can read the LSB of the vertex coordinates, recombine the binary stream into a string, and compare it with the original watermark information to verify the copyright.

[0021] As preferred, when there is already an old version of the file, the changes of the new version file relative to the old version file are also found out by the BSDiff algorithm to generate the difference package. The difference package is very small, including: copy instructions (Control Block): "copy a piece of data from a certain position of the old version file to the current position of the new version file"; difference data (Diff Block): for those data blocks that are only modified, store the difference (XOR result) between them and the old data blocks; new data (Extra Block): for the completely new data in the new file, directly store this piece of new data. Users only need to download the difference package combined with the old version file to complete the update, greatly reducing the download amount.

[0022] As preferred, a Merkle root hash is also generated when packaging, which is stored in the JSON file.

[0023] The Merkle root hash is used to ensure the integrity of the file and the correctness of the incremental update, preventing data corruption or malicious tampering. This process consists of two parts: construction and verification.

[0024] A. Construction process (performed when generating each complete version file) Execution timing: at the last stage of generating any complete file (including difference package).

[0025] Input: complete ODAF file content.

[0026] Specific process: Chunking: divide the entire file into a series of data blocks according to a fixed size (e.g. 4KB).

[0027] Calculate leaf hash: for each 4KB data block, calculate its hash value using SHA-256 algorithm. These hash values constitute the "leaf nodes" of the Merkle tree.

[0028] Layer-by-layer merging: connect two adjacent hash values, and calculate a hash for this combination to generate their "parent node". Repeat this process until only one hash value is left.

[0029] Get root hash: this final hash value is the Merkle root hash (Merkle Root).

[0030] Output: store this unique Merkle root hash in the manifest.json file corresponding to the version.

[0031] B. Verification process Execution timing: when the client has the old version file and the difference package, ready to update.

[0032] Specific process: Apply patch: Client uses bspatch tool to combine a new file based on the old version file according to the instructions of the difference package. In theory, this file is the new version file.

[0033] Block-by-block verification: The client does not need to download the complete new version file for verification. It can only download the Merkle tree data of v1.1 (or the root hash is included in manifest.json).

[0034] Recalculate: The client calculates the Merkle root hash of the new file synthesized locally according to the same method (4KB block, SHA-256 hash).

[0035] Compare: Compare the root hash calculated by itself with the standard root hash of the new version file obtained from the official server.

[0036] Result: If the two hash values are completely consistent, it proves that the incremental update is successful and the file is complete and correct. If they are not consistent, it means that there is an error or tampering in the download or synthesis process, and it needs to be downloaded again.

[0037] When decoding the file, the Merkle root hash can also be verified to ensure that the entire file has not been tampered with.

[0038] The final obtained file contains a JSON descriptor and binary data block organization. The JSON descriptor is generally independent of manifest.json or packaged into the file. The JSON descriptor is the core of the data structure definition, which declares in text format which data modules (such as geometry, animation, texture) are included in the entire ODAF asset, the dependency relationship between modules (dependencies), and the specific compression algorithm and parameters used by each module (compression, quantization_bits, etc.). The parser first reads it to know how to process the subsequent binary data.

[0039] Binary data block organization defines the physical storage method of data. It specifies that data should be stored in blocks according to modules (geometry, animation, etc.), and the JSON descriptor indexes these binary blocks through the offset and length fields, which together complete the complete definition of the entire file structure.

[0040] One of the core advantages of the invention is "modular hierarchical structure" and "on-demand loading". Users may only want to load the basic geometry of the model for preview first, and then load high-definition textures and animations later.

[0041] The JSON descriptor makes this possible. The application can first parse the JSON descriptor, and when the geometry data is needed, it can read only the needed bytes from the network or hard disk according to the offset and length recorded in the JSON descriptor, without loading the entire file.

[0042] The ODAF solves the problem of lack of extensibility through the JSON descriptor. If a new kind of physics simulation data (e.g. soft_body_physics) is invented in the future, only the following steps are needed: 1. Define a new module type in the JSON descriptor.

[0043] 2. Specify its compression algorithm and parameters.

[0044] 3. Attach the corresponding binary data block to the file.

[0045] Existing decoders can safely skip this new module even if they do not recognize it, without causing the entire file parsing to fail. This guarantees the forward and backward compatibility of the format.

[0046] The life cycle of the JSON descriptor is divided into three stages: Initial stage (template and configuration): Before the encoding process begins, there is a template of the JSON descriptor. This template defines the target parameters for this conversion, such as "use Draco to compress geometry", "set the quantization precision to 16 bits", "use BasisU+ASTC for textures". This can be seen as a "instruction set" given to the encoding tool.

[0047] Processing stage (information collection and filling): When the encoding tool is performing "data preprocessing" and "compression and serialization", it dynamically collects information and fills it into the in-memory structure of the JSON descriptor.

[0048] For example, when the compression and optimization process is completed, the tool knows the exact size of the compressed geometry data block (geometry.bin). This size is recorded.

[0049] When the Merkle tree version verification is completed, the tool calculates the final root hash value, which is also filled into the JSON descriptor.

[0050] However, at this time, the absolute offset of each data block in the final file may not be determined, because all blocks have not been packed together.

[0051] Final construction stage (finalization and writing): After all the data blocks (geometry, animation, texture, etc.) are processed and compressed, the final "packing" step is entered. At this time, the encoder determines the arrangement order of all binary data blocks and calculates the exact offset and length of each block in the final file. At this point, all fields of manifest.json are finally filled in.

[0052] Finally, the encoder serializes the final draft JSON descriptor (usually as the header of the file or a special data block), and then attaches all the processed binary data blocks (geometry.bin, animation.bin, etc.) in sequence to form a complete and independent ODAF file.

[0053] The open dynamic asset format adopted by this scheme has the following specific advantages: (1) Modular hierarchical structure: Data separation and compression: For geometry data, Draco algorithm is used to compress vertex coordinates (supporting lossless / lossy mode), combined with Meshopt to optimize triangle index, and quantize floating-point coordinates to 16-bit fixed-point numbers; For animation data, node-based animation graphs are stored in binary, keyframes use Delta Encoding and Zstandard compression, and bone rotation quaternions are quantized to 16 bits; For texture data: based on Basis Universal (UASTC mode) and ASTC 6x6 adaptive encoding, pre-generate multi-level MIPMAP.

[0054] Incremental update: generate binary difference package through BSDiff, use Merkle tree hash chain to ensure version consistency.

[0055] (2) Dynamic animation system: Node-based execution engine: animation graph nodes support mathematical operations, physical simulation, state machine logic, and embedded WASM plugins for dynamic loading. Keyframe interpolation uses Hermite curves, and physical data uses Verlet integration algorithm.

[0056] Multi-source fusion technology: align motion capture data based on DTW (Dynamic Time Warping), use SVD decomposition to realize bone reorientation. Integrate lightweight Transformer model to complete action style transfer.

[0057] (3) Physics and animation fusion: Unified physics description language: define constraint types such as hinges and springs, and associate friction and elasticity properties through node editing in the material network. Heterogeneous solver: XPBD (Extended Position Dynamics) is used on the CPU side, and CUDA particle system is deployed on the GPU side.

[0058] Bidirectional coupling mechanism: Skeletal motion drives the physical system through Jacobian transpose, and physical deformation feeds back to the skeleton through inverse kinematics.

[0059] (4) Security and collaboration: Partition encryption: AES-GCM encryption is used for sensitive data such as skeletal weights and normal maps, and the key is managed by a hardware security module (HSM).

[0060] Dynamic watermarking: Invisible watermarking is embedded in the low-order bits of vertex coordinates, and verification is performed through a dedicated shader.

[0061] Collaboration support: Real-time collaborative editing based on operation transformation (OT), supporting semantic Diff and asset traceability.

[0062] (5) Efficient runtime parsing: WebAssembly parser: Pre-compiled for multi-architecture (x86 / ARM), supporting SIMD instruction acceleration for matrix operations. Dynamic hot reloading: Monitor incremental update packages and replace WASM instances to achieve non-interruptible updates.

[0063] GPU-accelerated decoding: Geometry data is parallel decompressed from Draco encoding by a compute shader, and vertex data is directly transferred to the GPU buffer through shared memory. Animation interpolation and physical simulation are processed in parallel by GPU threads, and skeletal transformation matrices are calculated in real time. BRIEF DESCRIPTION OF DRAWINGS

[0064] Figure 1 is a dynamic three-dimensional data conversion method flowchart based on an open dynamic asset format. DETAILED DESCRIPTION

[0065] The technical solutions of the present application will be further specifically described below through examples and in combination with the drawings.

[0066] Embodiment: A dynamic three-dimensional data conversion method based on an open dynamic asset format, as shown in Figure 1 , includes the following steps: S1: Read the basic configuration to obtain the basic requirements for data processing, such as subsequent compression level information, etc. S2: Data preprocessing: classify, optimize and format convert the original data; the original data is mainly divided into three categories: geometry data, animation data and texture data; Geometry data (Geometry Data): defines the shape of an object. It contains vertex coordinates, normals, UV coordinates, vertex colors, triangle indices, etc., which is the "skeleton"; Animation Data: defines how an object moves, it contains skeletal structure, keyframes, animation curves or procedural animation graph logic, this is "Motion"; Texture Data: defines the appearance of an object's surface, it contains diffuse map, normal map, metallic map and other image information, this is "Skin"; S3: Compression and Serialization: compress various types of data using specific algorithms, and serialize them into binary blocks; this step aims to greatly reduce file size, and convert the processed data into binary format suitable for storage and transmission; S4: Security Processing: encrypt sensitive data partition, embed dynamic watermark; S5: Packaging: generate file package, build complete open dynamic asset format file structure.

[0067] In data preprocessing, the optimization process is as follows: S201: Vertex caching for triangle index of geometry data, the purpose is to reduce the vertex processing overhead of GPU in rendering, and improve rendering efficiency; S202: Process geometry data into several levels of detail, and divide the space with octree, prepare for subsequent on-demand loading and streaming rendering; S203: Use Lanczos algorithm to generate a series of low-resolution images with size halved step by step from the original full-size texture (LOD 0), that is, MIPMAP chain (LOD 1, LOD 2,...), thus effectively preventing moire and flicker of distant textures, and improving texture sampling efficiency. LOD 0: original precision (1M faces). LOD 1~N: step-by-step simplification (e.g. reduce 50% faces per level). Storage structure: [BlockHeader][LOD 0 Data][LOD 1 Data]...[LOD N Data]. Block header contains spatial position, size and offset of each LOD.

[0068] In data compression and serialization process, the processing flow of geometry data is as follows: S301: Scene Bounding Box Calculation: First, calculate the minimum three-dimensional bounding box (Bounding Box) containing all vertex data, which will determine the range of all vertex coordinates (min and max values); S302: Quantization of floating-point coordinates: map the original 32-bit floating-point vertex coordinates (raw_value) to 16-bit unsigned integers (quantized_value) through the following formula, this step is lossy compression, but by preserving the bounding box information, the approximate original coordinates can be restored during decoding, greatly reducing the data volume; quantized_value = round((raw_value - min) / (max - min) x 65535); S303: Normal data quantization: For vertex normal vectors, direction is more important than length, so it is mapped from three 32-bit floating-point numbers to 8-bit signed integers; S304: Topology data compression: Use the lossless mode of Draco algorithm to compress the topology structure of the model (i.e. the vertex index connection relationship of the triangle); Draco can very efficiently compress the index data through techniques such as prediction and entropy coding; S305: Vertex data compression: Use the lossy mode of Draco algorithm to compress the quantized vertex attribute data (coordinates, normals, UV, etc.); Draco will take advantage of the spatial correlation between vertices to encode the offset of each vertex relative to its neighbors, thereby achieving very high compression ratio. The geometry error threshold (such as 0.1mm) can be set to control the compression accuracy; S306: Vertex cache optimization: Use Meshopt to optimize the vertex cache (Vcache) of the triangle index; After (or before) Draco compression, apply Meshopt's Vcache optimization, which rearranges the order of the triangle index so that the vertices referenced consecutively are physically as close as possible, which maximizes the hit rate of the GPU vertex cache, significantly reducing the repeated calculation of vertex shaders during rendering, and improving rendering performance; S307: Data block serialization: Pack the topology and vertex data blocks compressed by Draco, the index buffer optimized by Meshopt, and the metadata required for quantization (such as bounding box min / max values) into a binary block (e.g. geometry.bin).

[0069] Geometry data defines the shape of the model, and its core is a large number of vertex coordinates and connection relationships. The goal of processing is high compression ratio and fast decoding.

[0070] During data compression and serialization, the processing flow of animation data is as follows: S311: Delta encoding (difference encoding): Calculate the difference between the adjacent keyframe bone transform data (translation, rotation, scaling); Animation data has high continuity in time, for each bone transform (translation, rotation, scaling), instead of storing the absolute value of each frame, the difference (Delta) between the current frame and the previous frame is calculated and stored, since most of the time the bone changes very little, these differences are usually close to zero, which is very suitable for subsequent compression; Example: Frame 1: Position (1.0, 2.0, 3.0); Frame 2: Position (1.1, 2.0, 3.0); Delta: (0.1, 0.0, 0.0); S312: Rotation Quantization: Skeletal rotations are usually represented using Quaternions, which are 32-bit floating-point numbers. Each component (x, y, z, w) is quantized to a 16-bit signed integer. When decoding, the unit quaternion is restored through a normalization operation, which compresses the rotation data by 50% without significantly compromising visual quality. S313: General Data Stream Compression: The data stream (a series of differences and quantized values) after Delta encoding and quantization is treated as a normal binary data stream. This data stream is divided into blocks along the time axis (e.g., one group per 100 frames), and then each block is compressed using the Zstandard (Zstd) algorithm. Zstd provides excellent compression ratio and decompression speed. S314: Structure Definition: The node-based Animation Graph (including mathematical operation nodes, state machine nodes, IK solver nodes, etc.) is abstracted as a directed graph structure.

[0071] S315: Binary Serialization: The graph structure is converted into a compact binary format: [Header][Node List][Connection List][WASM Plugins][Keyframe Data]. Its contents include: Header: Version number, total number of nodes, number of connections, and plugin size meta-information; Node List: Type of each node (such as input / processing / output) and its internal parameters (such as IK weight, state machine condition); Connection List: Directed connection relationship between nodes (source node, target node, port number); describes the connection between nodes, i.e., which node's output port is connected to which node's input port; WASM Plugins: Pre-compiled WebAssembly modules for runtime dynamic logic extension; Keyframe Data: Skeletal animation keyframe data.

[0072] Animation data defines the changes of the model over time, mainly including skeletal keyframes and programmatic logic. The processing goal is to remove temporal redundancy and support dynamic logic.

[0073] The processing flow of the texture data in the data compression and serialization process is as follows: S321: separating the RGBA channel for the texture with the requirement of transparency, and compressing the RGB channel for the opaque texture; S322: generating an intermediate format through the Basis Universal compression module; the UASTC (Universal ASTC) mode is selected during compression, and the UASTC is a high-quality intermediate block compression format, and the advantage of the UASTC is universality: a UASTC format file can be quickly transcoded into almost any modern GPU supported block compression format (such as ASTC, BC7, ETC2) at runtime; this step has achieved significant compression and laid the foundation for cross-platform GPU compatibility; S323: converting the data in the intermediate format into the ASTC 6x6 block format; in order to achieve the extreme compression rate, the output of the UASTC is further converted into the ASTC 6x6 block format in the scheme; the ASTC (Adaptive Scalable Texture Compression) is a very flexible and efficient GPU texture compression format, which supports non-power-of-two size and different block sizes; the block size of 6x6 provides a higher compression ratio than the standard 4x4; the scheme can also dynamically select the block size according to the texture content (such as using 4x4 for detailed areas and using 6x6 or 8x8 for smooth areas), to achieve adaptive compression rate; For high-level (large size) MIPMAP, the lossless mode or high-quality setting of the Basis Universal can be used to retain the most details; For low-level (small size) MIPMAP, more aggressive lossy compression (such as ASTC 6x6 or higher compression ratio setting) can be used because they have fewer pixels displayed on the screen; S324: packaging all the compressed level data into a binary block, and the metadata of the file records the compression format and the existence of MIPMAP.

[0074] The texture is the largest part of the 3D asset. The processing goal is to achieve extremely high compression rate while maintaining visual quality, and support GPU direct decoding.

[0075] The partition encryption specifically includes: Marking the data block to be encrypted in the JSON file; Encrypting the marked data block by using the AES-GCM algorithm to generate ciphertext and an authentication tag; Replacing the original plaintext data block with the encrypted ciphertext, and storing the authentication tag; The key is managed by a hardware security module (HSM), which means that the key itself is not stored in plaintext in a file or code, but is kept by a secure hardware device and is only called by authorized programs during encryption / decryption.

[0076] The dynamic watermark embedding is specifically: Convert the watermark information into a binary stream, for example, using ASCII or UTF-8 encoding to get 0100001110010100... Traverse the vertex coordinates of the model, take the least significant bit of each coordinate component (x, y, z) in its floating-point representation; the modification of this position has a negligible effect on the actual position of the vertex (such as 12.3456 to 12.3456001), which is completely imperceptible to the naked eye; Embed the binary stream of the watermark bit by bit into the LSB of the vertex coordinates in order; for example, the first vertex's x-coordinate LSB embeds the first bit of the watermark, the y-coordinate embeds the second bit, and the z-coordinate embeds the third bit, then the second vertex, and so on.

[0077] Mark the presence of the watermark in the security section of the JSON descriptor, such as "watermark":"vertex_lsb", which can prompt special tools to find and verify the watermark.

[0078] When decoding, special shaders or tools can read the LSB of the vertex coordinates, recombine the binary stream into a string, and compare it with the original watermark information to verify the copyright.

[0079] When there is already an old version of the file, the BSDiff algorithm is also used to find the changes of the new version file relative to the old version file, and a difference package is generated. The difference package is very small and includes: copy instructions (Control Block): "copy a segment of data from a certain position in the old version file to the current position in the new version file"; difference data (Diff Block): for those data blocks that are only modified, store the difference value (XOR result) with the old data block; new data (Extra Block): for completely new data in new_file, store this new data directly. Users only need to download the difference package combined with the old version file to complete the update, greatly reducing the download volume.

[0080] A Merkle root hash is also generated when packaging, and the Merkle root hash is stored in the JSON file.

[0081] The Merkle root hash is used to ensure the integrity of the file and the correctness of the incremental update, preventing data corruption or malicious tampering. This process consists of two parts: construction and verification.

[0082] A. Construction process (performed when generating each full version file) Timing: At the final stage of generating any full file (including the diff package).

[0083] Input: The full ODAF file content.

[0084] Specific process: Chunking: Split the entire file into a series of data chunks of fixed size (e.g., 4KB).

[0085] Compute leaf hashes: For each 4KB data chunk, use the SHA-256 algorithm to calculate its hash value. These hash values constitute the "leaf nodes" of the Merkle tree.

[0086] Layer-by-layer merging: Connect two adjacent hash values, and then calculate a hash for this combination to generate their "parent node". Repeat this process until only one hash value remains.

[0087] Get root hash: This final hash value is the Merkle root hash.

[0088] Output: Store this unique Merkle root hash in the manifest.json file corresponding to the version.

[0089] B. Verification process Timing: When the client has the old version file and the diff package, and is ready to update.

[0090] Specific process: Apply patch: The client uses the bspatch tool to synthesize a new file based on the old version file according to the instructions in the diff package. In theory, this file is the new version file.

[0091] Chunk-by-chunk verification: The client does not need to download the complete new version file for verification. It can only download the v1.1 Merkle tree data (or the root hash is included in the manifest.json).

[0092] Recalculate: The client calculates the Merkle root hash of the new file it synthesized locally in the same way (4KB chunking, SHA-256 hashing).

[0093] Compare: Compare the root hash calculated by the client with the standard root hash of the new version file obtained from the official server.

[0094] Result: If the two hash values are exactly the same, it proves that the incremental update is successful and the file is intact. If not, it means that there is an error or tampering in the download or synthesis process, and it needs to be downloaded again.

[0095] The Merkle root hash can also be verified when decoding the file to ensure that the entire file has not been tampered with.

[0096] The final resulting file contains a JSON descriptor and a binary data block organization. The JSON descriptor is usually a separate manifest.json or packaged into the file. The JSON descriptor is the core of the data structure definition, which declares in text format what data modules (such as geometry, animation, texture) the entire ODAF asset contains, the dependencies between modules (dependencies), and the specific compression algorithm and parameters used by each module (compression, quantization_bits, etc.). The parser first reads it to know how to process the subsequent binary data.

[0097] The binary data block organization defines the physical storage of data. It specifies that the data should be stored in blocks according to the module (geometry, animation, etc.), and the JSON descriptor indexes these binary blocks through the offset and length fields, which together complete the complete definition of the entire file structure.

[0098] One of the core advantages of the invention is "modular hierarchical structure" and "on-demand loading". Users may only want to load the basic geometry of the model for preview first, and then load high-definition textures and animations later.

[0099] The JSON descriptor makes this operation possible. The application can first parse the JSON descriptor, and when the geometry data is needed, it can only read the required bytes from the network or hard disk according to the offset and length recorded in it, without the need to load the entire file.

[0100] ODAF solves the problem of lack of scalability through the JSON descriptor. If a new type of physical simulation data (for example, soft_body_physics) is invented in the future, only: 1. Define a new module type in the JSON descriptor.

[0101] 2. Specify its compression algorithm and parameters.

[0102] 3. Attach the corresponding binary data block to the file.

[0103] Existing decoders can safely skip this new module even if they do not recognize it, without causing the entire file parsing to fail. This guarantees the forward and backward compatibility of the format.

[0104] The life cycle of a JSON descriptor is divided into three stages: Initial stage (template and configuration): Before the encoding process begins, there is a template for the JSON descriptor. This template defines the target parameters for this conversion, such as "geometry to be compressed with Draco", "quantization precision set to 16 bits", "texture to be compressed with BasisU+ASTC". This can be seen as a "instruction set" given to the encoding tool.

[0105] Processing stage (information collection and filling): When the encoding tool is performing "data preprocessing" and "compression and serialization", it dynamically collects information and fills it into the memory structure of the JSON descriptor.

[0106] For example, when the compression and optimization process is completed, the tool knows the exact size of the compressed geometry data block (geometry.bin). This size will be recorded.

[0107] When the Merkle tree version verification is completed, the tool calculates the final root hash value, which will also be filled into the JSON descriptor.

[0108] However, at this time, the absolute offset of each data block in the final file may not be determined, because all blocks have not been packed together.

[0109] Final construction stage (finalization and writing): After all data blocks (geometry, animation, texture, etc.) are processed and compressed, enter the final "packing" link. At this time, the encoder will determine the arrangement order of all binary data blocks, and calculate the exact offset and length of each block in the final file. At this point, all fields of manifest.json are finally filled in completely.

[0110] Finally, the encoder serializes the final JSON descriptor (usually as the header of the file or a special data block), and then attaches all processed binary data blocks (geometry.bin, animation.bin, etc.) in sequence to form a complete and independent ODAF file.

[0111] Through performance verification, the advantages of this scheme can be more clearly seen: 1. Compression efficiency test: Data Type Test Model ODAF Volume GlTF 2.0 Volume Compression Ratio Geometry Data 100k Vertex Character Model 8.2MB 19.5MB 58% Animation Data 5 Minute Skeletal Animation 3.7MB 13.2MB 72% Texture Data 4K PBR Texture Set 22MB 63MB 65% 2. Encoding speed index: Geometry processing: Draco compresses a 100,000-vertex model in 120 ms (Intel i7-12700K).

[0112] Animation compression: Delta+Z standard processes a 5-minute animation in 45 ms.

[0113] Texture compression: Basis Universal+ASTC compresses a 4K texture in 1.8 seconds.

[0114] The specific embodiments described herein are merely illustrative of the spirit of the present application. Various modifications or supplements or replacements of the specific embodiments described or similar ways can be made by those skilled in the art to which the present application belongs, without departing from the spirit of the present application or exceeding the scope defined by the appended claims.

[0115] Although the terms compression, serialization, packaging, etc. are used more frequently herein, the possibility of using other terms is not excluded. The use of these terms is only for the convenience of describing and explaining the essence of the present application; any interpretation of them as any kind of additional limitation is contrary to the spirit of the present application.

Claims

1. A dynamic three-dimensional data conversion method based on an open dynamic asset format, characterized by, Comprising the following steps: S1: reading the basic configuration; S2: data preprocessing: classifying, optimizing and format converting the original data; S3: compression and serialization: compressing various types of data using specific algorithms and serializing them into binary blocks; S4: security processing: encrypting sensitive data partitions and embedding dynamic watermarks; S5: packaging: generating file packages and building complete open dynamic asset format file structures.

2. The dynamic three-dimensional data conversion method based on the open dynamic asset format according to claim 1, characterized in that, In data preprocessing, the optimization process is as follows: S201: vertex caching for triangle indexing of geometry data; S202: processing geometry data into several levels of detail and dividing the space using octrees; S203: using the Lanczos algorithm to generate a series of low-resolution images with half-size reduction at each level, i.e., MIPMAP chain, from the original full-size texture.

3. The dynamic three-dimensional data conversion method based on the open dynamic asset format according to claim 2, characterized in that, In data compression and serialization, the processing flow for geometry data is as follows: S301: calculating the minimum three-dimensional bounding box containing all vertex data; S302: quantizing floating-point coordinates: mapping original 32-bit floating-point vertex coordinates to 16-bit unsigned integers; S303: normal data quantization: mapping vertex normal vectors from three 32-bit floating-point numbers to 8-bit signed integers; S304: topology data compression: using the lossless mode of Draco algorithm to compress the topology structure of the model; S305: vertex data compression: using the lossy mode of Draco algorithm to compress the quantized vertex attribute data; S306: vertex caching optimization: using Meshopt to optimize vertex caching for triangle indexing; S307: data block serialization: packaging the Draco compressed topology and vertex data blocks, Meshopt optimized index buffer, and metadata required for quantization into a binary block.

4. The method of claim 2, wherein, In data compression and serialization, the processing flow for animation data is as follows: S311: Delta encoding: calculating the difference between adjacent keyframe bone transformation data; S312: rotation quantization: quantizing each component from 32-bit floating-point to 16-bit signed integer; S313: general data stream compression: treating the Delta encoded and quantized data stream as a normal binary data stream, dividing it into blocks along the time axis, and then compressing each block using the Zstandard algorithm; S314: structure definition: abstracting the node-based animation graph as a directed graph structure; S315: binary serialization: converting this graph structure into a compact binary format, which is: [Header][Node List][Connection List][WASM Plugins][Keyframe Data]; Its content includes: Header: version number, total number of nodes, number of connections, and plugin size meta information; Node List: type and internal parameters of each node; Connection List: directed connection relationship between nodes; WASM Plugins: Pre-compiled WebAssembly modules; Keyframe Data: Skeleton animation keyframe data.

5. The method of claim 2, wherein, In the process of data compression and serialization, the processing flow of texture data is as follows: S321: Separate the RGBA channel for textures with transparency requirements; compress the RGB channel for opaque textures; S322: Generate intermediate format through the Basis Universal compression module; S323: Convert the intermediate format data into ASTC 6x6 block format; S324: Package all compressed hierarchical data into a binary block, and record the metadata of the file in the format of the compression format and the existence of MIPMAP.

6. The dynamic 3D data conversion method based on the open dynamic asset format according to any one of claims 1-5, characterized in that, The partition encryption specifically includes: Marking the data block to be encrypted in the JSON file; Encrypting the marked data block using the AES-GCM algorithm to generate ciphertext and an authentication tag; Replacing the original plaintext data block with the encrypted ciphertext and storing the authentication tag; The dynamic watermark embedding specifically includes: Converting the watermark information into a binary stream; Iterating through the vertex coordinates of the model to take the least significant bits of each coordinate component represented by a floating-point number; Embedding the binary stream of the watermark into the LSB of the vertex coordinates in order; Marking the existence of the watermark in the security section of the JSON descriptor.

7. The method of claim 1, wherein, When there is already an old version of the file, the BSDiff algorithm is also used to find the changes of the new version of the file relative to the old version of the file to generate a difference package.

8. The dynamic 3D data conversion method based on the open dynamic asset format according to claim 1 or 7, characterized in that, A Merkle root hash is also generated during packaging, which is stored in the JSON file.

Images