Binary Action File Construction Method and System

Abstract

This application provides a method and system for constructing binary action files. The method includes: decomposing the original action file into multiple action fragment data, establishing metadata for each action fragment data, and constructing an action fragment library and a global index based on the metadata; acquiring and parsing runtime action file construction requests to generate standardized construction instructions; retrieving and matching corresponding action fragment data from the action fragment library according to the standardized construction instructions through the global index, and performing splicing and fusion processing on the matched action fragment data to generate a complete action data sequence; and performing binary serialization and compression optimization on the action data sequence to generate a binary action file. This application achieves high flexibility in action performance, reduces resource consumption, and simplifies the update process by decomposing complete actions into reusable atomic fragments and establishing a global index, dynamically combining and constructing binary action files according to business needs at runtime.

Description

Technical Field

[0001] This invention relates to the fields of computer graphics and game development technology, and in particular to a method and system for constructing binary action files. Background Technology

[0002] With the rapid development of game development, virtual simulation, and digital human interaction, the demand for character motion performance is becoming increasingly diverse and complex. Current technologies primarily rely on pre-made static motion files when processing motion data. These files typically store complete skeletal animation data in formats such as FBX, BVH, or custom binary formats. A typical architecture of existing systems includes: in the motion production stage, animators create complete motion files and export them as standard format files; in the resource packaging stage, all motion files are packaged into a resource package and released with the application; in the runtime loading stage, all required motion files are fully loaded into memory upon program startup or during runtime; and in the motion playback stage, the corresponding pre-made motions are triggered and played according to the game logic. The key processes of this traditional method are complete motion pre-production, static packaging, full loading, and direct playback.

[0003] The core drawbacks of existing technologies are that traditional static action file solutions suffer from insufficient flexibility, excessive resource consumption, and high update and maintenance costs when handling large-scale and diverse action requirements. Specifically, the need to pre-create all possible action combinations makes it impossible to adapt to dynamic runtime requirements, resulting in rigid action performance. To cover various scenario requirements, a large number of pre-created action files are needed, causing a sharp increase in storage space and memory consumption, which is particularly prominent on mobile and web platforms. Each action adjustment requires exporting, packaging, and publishing the complete action file again, resulting in low development iteration efficiency and difficulty in dynamically adjusting action performance based on real-time factors such as user interaction and environmental changes, thus affecting user experience and immersion.

[0004] Therefore, how to dynamically construct binary action files at runtime according to actual needs, while ensuring execution efficiency, improving the flexibility of action performance, reducing resource consumption, and simplifying the update process, has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0005] The technical problem to be solved by this invention is to provide a binary action file construction method and system to solve the technical problem of how to dynamically construct binary action files according to actual needs at runtime, while ensuring execution efficiency, improving the flexibility of action performance, reducing resource consumption, and simplifying the update process.

[0006] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: A method for constructing a binary action file, comprising: The original action file is broken down into multiple action fragment data, and metadata is created for each action fragment data. An action fragment library and a global index are built based on the metadata. Obtain and parse runtime action file build requests to generate standardized build instructions; According to the standardized construction instructions, the corresponding action fragment data is retrieved and matched from the action fragment library through the global index, and the matched action fragment data is spliced ​​and fused to generate a complete action data sequence. The action data sequence is binary serialized and compressed to generate a binary action file.

[0007] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is: a binary action file construction system, including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the various steps in the binary action file construction method described above.

[0008] The beneficial effects of this invention are as follows: By decomposing the original action file into multiple independently storable and retrievalable action fragment data and establishing a global index, it changes the traditional approach of relying on static pre-built complete actions. By acquiring and parsing runtime build requests and generating standardized build instructions, the controllability and efficiency of the runtime build process are ensured. Based on the standardized build instructions, action fragments are retrieved and matched from the fragment library, intelligently spliced ​​and smoothly fused to generate a complete action data sequence. Finally, the sequence is binary serialized and compressed to generate a binary action file. In this way, the problem of dynamically building binary action files according to actual needs at runtime is solved, achieving high flexibility in action performance, significantly reducing resource consumption, simplifying the update process, and supporting personalized action performance. Attached Figure Description

[0009] Figure 1 This is a flowchart of a binary action file construction method according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating the specific steps of a binary action file construction method according to an embodiment of the present invention. Figure 3 This is a flowchart illustrating the initialization and index construction process of the action fragment library according to an embodiment of the present invention. Figure 4 This is a flowchart illustrating the process of receiving a dynamic build request and parsing parameters according to an embodiment of the present invention. Figure 5 This is a flowchart illustrating the cache management and version control process according to an embodiment of the present invention. Figure 6This is a flowchart of the action segment retrieval and matching process according to an embodiment of the present invention; Figure 7 This is a flowchart of the motion segment splicing and fusion processing according to an embodiment of the present invention; Figure 8 This is a flowchart illustrating the binary serialization and optimization process according to an embodiment of the present invention. Figure 9 This is a flowchart illustrating the action file output and execution feedback process according to an embodiment of the present invention. Figure 10 This is a schematic diagram of a binary action file construction system according to an embodiment of the present invention. Detailed Implementation

[0010] Definitions:

[0011] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0012] In existing technologies, the demands for character motion performance in fields such as game development, virtual simulation, and digital human interaction are becoming increasingly diverse and complex. Current technologies primarily rely on pre-made static motion files when processing motion data, employing a process of complete motion pre-production, static packaging, full loading, and direct playback. This traditional method suffers from insufficient flexibility, excessive resource consumption, and high update and maintenance costs when handling large-scale, diverse motion requirements. Specifically, the need to pre-produce all possible motion combinations fails to adapt to dynamic runtime demands, resulting in stiff motion performance. The requirement to pre-produce a large number of motion files to cover various scenario needs leads to a sharp increase in storage and memory usage. Each motion adjustment requires re-exporting, packaging, and publishing the complete motion file, resulting in low development iteration efficiency. Furthermore, it is difficult to dynamically adjust motion performance based on real-time factors such as user interaction and environmental changes, impacting user experience and immersion.

[0013] To at least address the aforementioned problems, this invention provides a binary action file construction method. Through dynamic construction, a complete action is broken down into atomic fragments, and an action fragment library is established. At runtime, requests are parsed to generate standardized instructions, which are then used to retrieve matching fragments, splice and fuse them, and finally, the action file is output through serialization and compression. This approach achieves high flexibility in action performance, significantly reduces resource consumption and storage space, and supports rapid iteration and personalized customization.

[0014] The following describes in detail a binary action file construction method of the present invention. Please refer to [link / reference]. Figure 1 as well as Figure 2 The method 100 includes steps 101 to 104: Step 101: Decompose the original motion file into multiple motion fragment data, and establish metadata for each motion fragment data. Based on the metadata, construct an motion fragment library and a global index, including: Step 1011: Obtain the original action file, parse the original action file according to a preset format to obtain a complete action sequence; identify the action boundary points in the complete action sequence, and divide the complete action sequence into multiple action segment data according to the action boundary points. The action segment data includes action duration, segment type, action type and action weight.

[0015] Specifically, please refer to Figure 3 In action game development, developers created a complete sword combo animation, including the starting stance, three slashes, a heavy attack finisher, and a recovery animation, and exported it as an FBX format file. After obtaining this raw animation file, the system parses its skeletal structure, keyframe data, timeline information, and additional attributes such as event markers and curve data to obtain a complete action sequence. Then, according to preset fragmentation rules, it identifies natural boundary points in the action, such as the starting stance end point, the start and end points of each slash, the heavy attack start point, and the recovery animation start point. Based on these boundary points, the complete action sequence is divided into independent action segment data. After segmentation, the starting segment, slash segment, heavy attack segment, and recovery segment are obtained. Each fragmented atomic segment contains skeletal data, a start frame, an end frame, duration, and segment type (e.g., the starting segment is type "start," the slash segment is type "loop," the heavy attack segment is type "transition," and the recovery segment is type "end"), as well as action type tags such as sword attack, heavy attack, etc., and action weight information.

[0016] In this way, a complete combo animation is broken down into multiple independent segments, which can then be reassembled into a new sequence of actions based on different combo counts and combinations.

[0017] Step 1012: Generate metadata for each action segment data; perform integrity verification on the segmented action segment data; store the verified action segment data in a preset action segment library; and update the global index corresponding to the action segment data according to the metadata.

[0018] Specifically, please refer to Figure 3 The motion segment data itself is raw skeletal transformation data, containing frame-by-frame bone position, rotation, and scaling values, used for actual motion playback, and the data volume is large. To support fast runtime retrieval and matching, the system generates lightweight metadata for each extracted motion segment. Metadata is a descriptive summary of the motion segment, much smaller in size than the motion segment data itself, and does not contain specific frame-by-frame skeletal transformation values.

[0019] The system generates metadata for each extracted motion segment and then performs integrity checks. The checks are divided into two levels: field-level and consistency-level. Field-level checks ensure that all required fields are complete and of the correct type, including segment identifier, skeleton identifier, segment type, tag, start frame, end frame, frame rate, duration, version, checksum, etc. Consistency-level checks ensure consistency between fields, such as whether the end frame is greater than the start frame, whether the duration is approximately equal to the difference between the end and start frames divided by the frame rate, whether the tag is within the allowed set, whether the weight is within the range of zero to one, whether the referenced skeleton or curve channel exists, and whether the storage path is accessible.

[0020] Taking a slashing clip as an example, at a frame rate of 30 frames per second, the system verifies that its start frame is frame 120, its end frame is frame 180, its duration is approximately 2 seconds, its clip type is loop, and its action type label is slashing. If all these fields are complete and consistent, the verification passes. Clips that fail verification are logged and skipped, and are not added to the clip library. After successful verification, the system generates a unique identifier for the clip, which can be a universally unique identifier or a content hash value obtained by hashing the standardized clip binary. The clip data is then converted into a compact binary format and stored in the preset action clip library, with each clip saved as an independent file.

[0021] Simultaneously, the system updates the global index based on the fragment's metadata. The global index includes a main table with the fragment identifier as the primary key, and auxiliary structures built according to retrieval dimensions. For example, an inverted index built by action type tags maps slash tags to a list of identifiers for all slash fragments; a bucketed list by fragment type groups loop-type fragments together; and a range index built by duration facilitates the retrieval of fragments with similar durations. The global index is serialized into an index file and records the index version number for subsequent incremental updates and rollbacks.

[0022] In this way, the same action fragment can be reused by different build requests without having to store a complete file for each action combination separately; the required fragment can be quickly located through indexing; when a fragment needs to be modified, only the fragment and its index entry need to be updated, without having to regenerate the entire fragment library.

[0023] Step 102: Obtain and parse the runtime action file build request to generate standardized build instructions, including: Step 1021: Obtain the runtime action file construction request; extract parameters from the action file construction request to obtain construction request parameters, which include: action type, constraints, optimization parameters, and runtime parameters.

[0024] Specifically, please refer to Figure 4When a player triggers an attack command in the game, the game logic module sends a runtime build request to the system. This request carries parameters including: the action type is a sword combo; constraints include skeleton compatibility (skeleton identifiers must match), a combo count of three hits, the inclusion of a starting and ending animation, and a maximum transition frame count of 10 frames; duration or rhythm constraints (total duration between 3 and 5 seconds); semantic constraints (combining slashing and blocking animations is prohibited); physical or contact constraints (foot contact points must not overlap); business state constraints (current character stance must be standing and weapon type must be a longsword); performance constraints (decoding budget must be within 10 milliseconds); optimization parameters prioritize quality; and runtime parameters include an attack speed multiplier of 1.2x and normal action amplitude. The system extracts these parameters to obtain the build request parameters.

[0025] In this way, the game logic only needs to send a request containing the action type and constraints, without worrying about how to retrieve and splice the fragments; the subsequent construction process is completed automatically by the system.

[0026] Step 1022: Perform format validation on the build request parameters according to preset format validation rules. If the format validation passes, convert the build request parameters into standardized build instructions. Specifically, generate search conditions based on the action type and constraints in the build request parameters; generate concatenation rules based on the runtime parameters in the build request parameters; generate optimization targets based on the optimization parameters in the build request parameters; generate standardized build instructions containing the search conditions, the concatenation rules, and the optimization targets, and generate a cache key corresponding to the standardized build instructions; otherwise, return an error message.

[0027] Specifically, please refer to Figure 4 The system performs format validation on the extracted build request parameters. First, it verifies whether the request body follows the agreed-upon format and is deserializable. Then, it checks if required fields exist, such as the action type field being present and not empty, and the combo count in the constraints being a numeric type. Next, it checks the numerical range, such as the attack speed multiplier being within a reasonable range of 0.5 to 2.0 (e.g., 1.2x is within a reasonable range). Finally, it checks consistency; for example, the constraint requiring the inclusion of a start and finish animation segments is semantically consistent with the action type being a combo, and the validation passes. If the validation fails, an error message is returned.

[0028] After successful verification, the system generates search criteria based on action type and constraints. For example, the search tag is "sword attack" and includes segments with starting, slashing, heavy strike, and finishing moves, and the duration must match the combo rhythm. It generates splicing rules based on runtime parameters. For example, the sequence template is set to a starting segment followed by three slashing segments, then a heavy strike segment, and finally a finishing move segment, with a splicing point strategy requiring a 5-frame transition window. It generates optimization goals based on optimization parameters. For example, a quality-first goal requires selecting high-precision segments as much as possible, with relatively lenient requirements on compression ratio. Finally, a standardized build instruction containing search criteria, splicing rules, and optimization goals is generated. This instruction can use JSON or Protobuf structure, including: a `query` field recording action semantic tags, segment type requirements, duration range, skeleton identifier, and quality threshold; a `stitch` field recording the sequence template, splicing point strategy, and transition window; a `runtimeParams` field recording parameters such as speed, amplitude, and weight; an `optimize` field recording target size, compression ratio, and whether performance or quality is prioritized; and a `versioning` field recording the index version and segment version strategy. The system generates a cache key corresponding to the instruction. The process of generating the cache key is as follows: first, the instruction is normalized, including field sorting, default value filling, and floating-point normalization. Then, a hash function is applied to generate a unique cache key of fixed length. The skeleton identifier and instruction version are also included to avoid false hits due to different configurations.

[0029] In this way, diverse business requirements are transformed into a stable, versionable, structured instruction set, which facilitates cache key generation and replay debugging.

[0030] Step 102 further includes querying whether a binary action file built by the corresponding standardized build instruction already exists in the preset cache according to the cache key of the standardized build instruction; if it exists and the parameter version in the binary action file matches the current preset version, then the binary action file in the preset cache is returned.

[0031] Specifically, please refer to Figure 5 The system queries the preset cache based on the generated cache key. If another player has previously built an action file using the same sword combo commands and the parameter versions match, the cache is hit, and the system directly returns the binary action file, avoiding duplicate construction and reducing response time from seconds to milliseconds. If the cache is not hit, the system continues with subsequent steps.

[0032] After writing new cache entries, the system performs a cache space check. When the cache space exceeds a preset limit, the system executes an LRU (Least Recently Used) eviction policy, cleaning up cache entries that have not been accessed for a long time and prioritizing the retention of recently used cache entries to balance memory usage and cache hit rate. Simultaneously, the system records the version history of each build, including build parameters, generated file version numbers, build time, and other information, supporting subsequent version rollback and comparison, facilitating quick revert to previous stable versions in case of problems.

[0033] In this way, the same build request does not need to repeat the build process, and the generated file is returned directly, which greatly improves the response speed; the cache eviction policy ensures the rational use of memory resources; and the version history facilitates problem location and version rollback.

[0034] Step 103: According to the standardized construction instructions, retrieve and match corresponding motion fragment data from the motion fragment library through the global index, and perform splicing and fusion processing on the matched motion fragment data to generate a complete motion data sequence, including: Step 1031: Based on the retrieval conditions in the standardized construction instruction, retrieve a list of candidate action fragment data from the action fragment library using the global index; evaluate the fit of each action fragment data in the candidate action fragment data list to obtain multiple candidate adapted action fragment data that have reached a preset threshold and are sorted according to their fit, wherein the fit evaluation includes constraint filtering and score sorting; select fragment data from the multiple candidate adapted action fragment data and combine them according to the optimization objectives and splicing rules in the standardized construction instruction to obtain candidate combined action fragment data.

[0035] Specifically, please refer to Figure 6 The system retrieves a list of candidate motion clips from the motion clip library using a global index based on the search criteria in the standardized construction instructions. For example, if the search criteria require starting clips, slashing clips, heavy attack clips, and finishing clips, the global index returns multiple candidate starting clips, multiple candidate slashing clips, multiple candidate heavy attack clips, and multiple candidate finishing clips. Then, the system evaluates the fit of each clip in the candidate list.

[0036] The evaluation employs a combination of hard constraint filtering and soft scoring ranking. Hard constraint filtering includes skeleton identifier compatibility checks, whether the segment type matches the starting requirements, and whether the duration is within a reasonable range. Soft scoring comprehensively considers factors such as tag matching degree (the degree of matching between semantic tags and sword attack techniques), duration difference (deviation from the target combo rhythm), quality indicators such as segment sampling density and noise level or historical playback rating, splicing cost (pose difference or root bone offset with adjacent segments and estimated number of transition frames), and performance cost such as number of skeletons, number of channels, or estimated decoding time. A weighted calculation yields the fit score for each segment, calculated as the fit score equal to the sum of the scores of each indicator multiplied by their corresponding weights. The weights can be adjusted according to the optimization objective; for example, increasing the weight of tag matching degree and quality indicators when prioritizing quality, and increasing the weight of performance cost when prioritizing performance. A candidate list is selected based on the scores of segments that meet a preset threshold. Based on the optimization objective of prioritizing quality, the system first selects the segments with the highest quality scores for combination to obtain candidate combination action segment data. For example, it selects a high-precision initiation segment, three high-precision slashing segments, one high-precision heavy strike segment, and one high-precision finishing move segment. If no perfectly matching segment can be found according to the search criteria, the system will trigger a degradation strategy, relaxing some constraints, selecting similar segments, and marking them as requiring additional adjustments.

[0037] In this way, the system can still provide usable action results even in the absence of ideal segments.

[0038] Step 1032: Determine the splicing points between each action segment data in the candidate combined action segment data, and calculate the difference in skeletal state data before and after the splicing point; generate transition curve parameters based on the skeletal state data differences, and generate transition frame data based on the transition curve parameters; perform smoothness detection on the generated transition frame data, and if it does not meet the preset smoothness requirements, adjust the transition curve parameters and regenerate the transition frame data; splice the action segment data that meet the preset smoothness requirements in a preset order, and adjust the spliced ​​action segment data according to the runtime parameters to generate a complete action data sequence.

[0039] Specifically, please refer to Figure 7The system determines the splicing point positions between segments in the candidate combination, such as the end frame of the starting segment and the start frame of the first slashing segment. It then calculates the state differences of the corresponding bones before and after the splicing point, including the positional offset of the wrist bones and the rotational angle difference of the arm bones. Based on these bone state differences, transition curve parameters are generated, including setting the fusion window length to 5 frames, using cubic splines for interpolation or easing functions, setting higher weights for the upper body and lower weights for the lower body in the weight mask for each bone, setting the root bone alignment parameters to maintain the continuity of root bone positions, and setting the time warp coefficient. Then, transition frame data is generated based on the transition curve parameters. Specifically, the starting posture of the slashing segment is first aligned to the ending posture of the starting segment in the root bone space. Then, rotational spherical linear interpolation and displacement linear interpolation are performed on the corresponding bones in each frame within the window, and the results are blended according to bone weights. Inverse dynamic constraints are superimposed on the hand bones to reduce weapon clipping.

[0040] The generated transition frame data undergoes smoothness testing, evaluated from three aspects: continuity, contact error, and visual threshold. Continuity testing checks for spikes in the velocity and acceleration of key bones such as the heel, pelvis, feet, hands, and head before and after the splicing point; exceeding the threshold indicates a lack of smoothness. Contact error testing checks for excessive sliding distance and insertion depth of contact points such as the soles of the feet or palms within the transition window. The visual threshold sets upper limits on the angular velocity and angular acceleration of key bones; exceeding these limits indicates a lack of smoothness. If the preset smoothness requirements are not met, the transition curve parameters are adjusted, for example, expanding the fusion window from 5 frames to 8 frames, and the transition frame data is regenerated until the requirements are met. Finally, the motion segment data that meets the smoothness requirements is spliced ​​in a preset order: starting segment, slashing segment, slashing segment, slashing segment, heavy attack segment, and finishing segment are connected sequentially. The motion data sequence is then scaled according to the runtime parameter attack speed multiplier of 1.2 times to generate a complete motion data sequence. The sequence includes a skeletal hierarchy such as bone names, parent-child relationships, and initial poses; a skeletal transformation sequence such as bone positions, rotations, and scaling data for each frame on the timeline; and metadata such as total action duration, frame rate, keyframe markers, and event markers such as attack detection points and hit effect trigger points.

[0041] In this way, through closed-loop adjustment of fusion and smoothness detection, the transition of movements at the splicing point is ensured to be natural and smooth, eliminating jump and slip problems.

[0042] Step 104: Perform binary serialization and compression optimization on the action data sequence to generate a binary action file, including: The data characteristics of the motion data sequence are analyzed, and a serialization protocol and compression algorithm are selected according to the optimization target in the standardized construction instructions. The skeletal layer information, keyframe data, and curve parameters in the motion data sequence are encoded sequentially according to the serialization protocol, and the selected compression algorithm is applied to compress the encoded motion data sequence. The compression rate of the compressed motion data sequence is detected; if the compression rate does not meet the optimization target, the compression algorithm is adjusted and recompressed. A binary file header containing a version number and file checksum is generated and combined with the compressed motion data sequence to generate the binary motion file.

[0043] Specifically, please refer to Figure 8 The system first reads the generated complete motion data sequence and analyzes its data characteristics, such as 50 bones, a frame rate of 30 frames per second, and relatively even distribution of keyframes. Prioritizing quality, a serialization protocol with fixed frame rate encoding is selected to ensure playback accuracy. A lightweight compression algorithm with minimal impact on accuracy is chosen. Bone hierarchy information is encoded once as a static structure in the file header, recording bone identifiers, parent indices, default poses, etc. Keyframe data is stored frame-by-frame at a fixed frame rate, recording the rotation and displacement information of all bones in each frame. Curve interpolation parameters are encoded as curve type enumerations and control points, with values ​​processed using 16-bit fixed-point quantization and stored in the file header along with a scaling factor to balance size and accuracy. After encoding, the selected compression algorithm is applied for compression. The compressed data undergoes compression ratio detection, calculating the ratio of the compressed size to the original size. If the compression ratio does not meet the optimization target (e.g., exceeding 40%), the compression algorithm parameters are adjusted, such as appropriately increasing quantization precision, and recompression is performed until the compression ratio target or accuracy lower limit is reached. Finally, a binary file header containing the version number and file checksum is generated and combined with the compressed action data sequence to generate a binary action file. The file checksum is obtained by calculating the cyclic redundancy check (CRC) on the file byte stream excluding the checksum field itself after the file is written, and then filled back into the file header.

[0044] In this way, the generated binary action files take up less storage space than text format, are parsed and loaded faster during playback, and the compression process can be automatically adjusted according to accuracy requirements and size targets. At the same time, a checksum ensures that the file is not damaged after transmission or storage.

[0045] Step 104 and thereafter includes outputting the generated binary action file to a preset execution engine for playback and collecting performance metrics during playback; evaluating whether the performance metrics meet the preset performance standards; if they do not meet the standards, generating corresponding optimization suggestions and triggering a new round of action file construction requests.

[0046] Specifically, please refer to Figure 9The system outputs the completed binary motion file and its metadata to the game engine. Depending on the application scenario, it selects the memory output mode and directly passes the memory pointer to the execution engine (such as Unreal Engine or Unity3D). The engine plugin decodes the binary motion data into animation clips, driving the character skeleton to play combo actions, while simultaneously calling back event markers, such as attack judgment points, to the game logic. The system collects execution performance metrics, including a build time of 30 milliseconds, a decoding and loading time of 5 milliseconds, a memory usage increase of 15 megabytes, a file size of 200 kilobytes, a stable playback frame rate of 60 frames per second, no stuttering, and a passed smoothness test. These metrics all meet the preset performance standards and do not require adjustment. If any metric fails to meet the standard, such as a build time exceeding 100 milliseconds, the system generates optimization suggestions, such as adjusting the compression strategy to reduce encoding time or optimizing the fragment combination to reduce complexity, and triggers a new round of build requests, forming a closed-loop optimization mechanism.

[0047] In this way, the system can select file output, memory output or network output modes according to different application scenarios. By collecting performance data during actual playback, it can automatically adjust the building strategy when the target is not met, so as to continuously optimize the performance.

[0048] As described above, this invention first breaks down a complete character animation into multiple independently storable and retrievalable action fragments, and establishes an index library for these fragments. During game operation, when a specific action needs to be generated, the system generates corresponding construction instructions based on the current request, retrieves matching fragments from the fragment library, splices and merges these fragments into a continuous action sequence, converts it to binary format and compresses it, ultimately obtaining a directly usable binary action file. In this way, game developers do not need to pre-create all possible action combinations; action performance can be generated in real time based on player actions, storage space usage is significantly reduced, and after action adjustments, there is no need to repackage the complete resources; only the relevant fragments need to be updated.

[0049] Please refer to Figure 10 The present invention also provides a binary action file construction system 200, including a memory 201, a processor 202, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the various steps of a binary action file construction method as described above.

[0050] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for constructing a binary action file, characterized in that, include: The original action file is broken down into multiple action fragment data, and metadata is created for each action fragment data. An action fragment library and a global index are built based on the metadata. Obtain and parse runtime action file build requests to generate standardized build instructions; According to the standardized construction instructions, the corresponding action fragment data is retrieved and matched from the action fragment library through the global index, and the matched action fragment data is spliced ​​and fused to generate a complete action data sequence. The action data sequence is binary serialized and compressed to generate a binary action file.

2. The binary action file construction method according to claim 1, characterized in that, The original motion file is broken down into multiple motion fragment data, and metadata is created for each motion fragment data. Based on the metadata, a motion fragment library and a global index are constructed, including: Obtain the original action file, parse the original action file according to the preset format, and obtain the complete action sequence; Identify action boundary points in the complete action sequence, and divide the complete action sequence into multiple action segment data based on the action boundary points. The action segment data includes action duration, segment type, action type, and action weight. Generate metadata for each of the aforementioned action segment data; The integrity of the segmented motion fragment data is verified, and the verified motion fragment data is stored in a preset motion fragment library. The global index corresponding to the motion fragment data is updated according to the metadata.

3. The binary action file construction method according to claim 2, characterized in that, Obtain and parse the runtime action file build request to generate standardized build instructions, including: Obtain the runtime action file build request; The action file construction request is subjected to parameter extraction to obtain construction request parameters, which include: action type, constraints, optimization parameters and runtime parameters; The build request parameters are validated according to preset format validation rules. If the format validation passes, the build request parameters are converted into standardized build instructions. Otherwise, return an error message.

4. The binary action file construction method according to claim 3, characterized in that, If the format validation passes, the build request parameters are converted into standardized build instructions, including: Generate search criteria based on the action type and constraints in the construction request parameters; Generate splicing rules based on the runtime parameters in the build request parameters; Generate optimization targets based on the optimization parameters in the construction request parameters; Generate a standardized construction instruction that includes the search conditions, the concatenation rules, and the optimization objectives, and generate a cache key corresponding to the standardized construction instruction.

5. The binary action file construction method according to claim 4, characterized in that, According to the standardized construction instructions, the corresponding action fragment data is retrieved and matched from the action fragment library through a global index, including: Based on the search criteria in the standardized construction instructions, a list of candidate action fragment data is retrieved from the action fragment library using the global index; The fitness evaluation is performed on each action segment data in the candidate action segment data list to obtain multiple candidate fit action segment data that have reached a preset threshold and are sorted in order of fitness. The fitness evaluation includes constraint filtering and score sorting. Based on the optimization objectives and splicing rules in the standardized construction instructions, segment data is selected from multiple candidate adaptive action segment data and combined to obtain candidate combined action segment data.

6. The binary action file construction method according to claim 5, characterized in that, The matched motion fragment data is then spliced ​​and fused to generate a complete motion data sequence, including: Determine the splicing points between each action segment data in the candidate combined action segment data, and calculate the difference in skeletal state data between the action segment data before and after the splicing point; Based on the differences in the bone state data, transition curve parameters are generated, and transition frame data is generated based on the transition curve parameters. The smoothness of the generated transition frame data is checked. If the preset smoothness requirement is not met, the transition curve parameters are adjusted and the transition frame data is regenerated. The motion segment data that meets the preset smoothness requirements are spliced ​​together in a preset order, and the spliced ​​motion segment data is adjusted according to the runtime parameters to generate a complete motion data sequence.

7. The binary action file construction method according to claim 1, characterized in that, The action data sequence is binary serialized and compressed to generate a binary action file, including: Analyze the data characteristics of the action data sequence, and select a serialization protocol and compression algorithm according to the optimization objectives in the standardized construction instructions; According to the serialization protocol, the skeletal hierarchical information, keyframe data and curve parameters in the motion data sequence are encoded sequentially, and the selected compression algorithm is applied to compress the encoded motion data sequence. The compression ratio of the compressed action data sequence is detected. If the compression ratio does not meet the optimization target, the compression algorithm is adjusted and the data is recompressed. A binary file header containing a version number and a file checksum is generated and combined with the compressed action data sequence to generate the binary action file.

8. A binary action file construction method according to claim 4, characterized in that, It also acquires and parses runtime action file build requests, generates standardized build instructions, and includes: Based on the cache key of the standardized build instruction, query whether the binary action file built by the corresponding standardized build instruction already exists in the preset cache; If the parameter version in the binary action file exists and matches the current preset version, then the binary action file in the preset cache is returned.

9. A binary action file construction method according to claim 1, characterized in that, Also includes: The generated binary action file is output to the preset execution engine for playback, and performance metrics are collected during the playback process; The system evaluates whether the performance indicators meet the preset performance standards. If they do not meet the standards, it generates corresponding optimization suggestions and triggers a new round of action file construction requests.

10. A binary action file construction system, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the various steps of the binary action file construction method according to any one of claims 1 to 9.

Images