Particle motion information processing method and device, equipment and medium

Abstract

The application relates to a particle motion information processing method and device, equipment and a medium. The method comprises the following steps: performing down-sampling on a particle original motion track to generate a corresponding simplified motion track; storing point data belonging to the same simplified motion track in a point data cache area, generating a curve data entry for the simplified motion track, and storing the curve data entry in a curve data cache area; establishing a curve mapping table based on the point data corresponding to the curve data entry at a starting index in the point data cache area; and loading the point data cache area, the curve data cache area and the curve mapping table into a graphics processor display memory to obtain state information of particles in a current frame. The application compresses the data volume by down-sampling, stores the data in a structured manner in the display memory and performs parallel sampling by the graphics processor, thereby significantly reducing the file size, releasing the central processing unit resources, and realizing independent regulation and control of particle emission and motion rhythm and real-time and efficient rendering of large-scale particle effects.

Description

Technical Field

[0001] This application relates to the field of data processing, and in particular to a method, apparatus, device, and medium for processing particle motion information. Background Technology

[0002] In the field of game development, particle systems are being used more and more widely. Especially with open worlds and high-fidelity graphics becoming industry trends, developers are demanding higher levels of complexity and realism in particle effects. To meet this demand, many development teams are using professional digital content creation tools to perform complex particle dynamics calculations to simulate natural phenomena such as smoke, flames, fluids, or large-scale cluster movements. However, how to import these complex particle movements calculated in external tools into a real-time rendering engine and recreate them as interactive real-time effects has always been a technical challenge.

[0003] Traditional solutions for storing and transmitting particle data typically involve exporting the complete state of all particles calculated for each frame into a massive sequence of frames. When played back in a real-time engine, all particle data from each frame is read sequentially to reconstruct the original motion trajectory. While this frame-by-frame full-data storage method ensures accuracy, it suffers from extremely high data redundancy. This is particularly problematic for long-duration, high-precision particle simulations, where the exported files are often enormous. This not only increases the burden of storage and transmission but also poses challenges to version management and team collaboration.

[0004] Furthermore, traditional caching solutions, because the cached data is fixed frame by frame, prevent developers from independently controlling the particle emission rate or the movement rhythm of individual particles in real time within the engine. Once the data is generated, the particle's lifecycle and movement speed are fixed. To achieve slow motion, time reversal, or speed-up effects, multiple caches with different speeds must be pre-calculated, which greatly limits the flexibility of later debugging and the controllability of artistic creation. Secondly, from the perspective of computing resource allocation, traditional caching solutions require loading massive amounts of particle data from disk into memory during real-time operation, and then the CPU parses and transmits it frame by frame. This mechanism leads to high CPU memory usage, and the CPU has to bear heavy data unpacking and scheduling tasks, easily creating a performance bottleneck, which in turn affects the overall frame rate and smoothness of the game. As the number of particles increases and the simulation duration lengthens, these problems become increasingly prominent, becoming a key obstacle restricting the implementation of complex particle effects in games. Summary of the Invention

[0005] The purpose of this application is to solve the above-mentioned problems by providing a particle motion information processing method and corresponding apparatus, devices, non-volatile readable storage media, and computer program products.

[0006] According to one aspect of this application, a particle motion information processing method is provided, comprising: The original motion trajectory of each pre-acquired particle is downsampled to generate a simplified motion trajectory corresponding to each particle, wherein each simplified motion trajectory consists of multiple point data arranged in chronological order; The point data belonging to the same simplified motion trajectory are stored continuously in the point data cache according to age order. A curve data entry containing the particle generation time is generated for each simplified motion trajectory. The curve data entries are stored continuously in the curve data cache according to the particle generation time order. Based on the point data of the simplified motion trajectory corresponding to each curve data entry, a curve mapping table is established using the starting index in the point data cache. The point data cache, the curve data cache, and the curve mapping table are loaded into the graphics processor memory to obtain the particle's state information in the current frame based on the graphics processor memory.

[0007] According to another aspect of this application, a particle motion information processing device is provided, comprising: The trajectory generation module is configured to downsample the original motion trajectory of each pre-acquired particle to generate a simplified motion trajectory corresponding to each particle, wherein each simplified motion trajectory consists of multiple point data arranged in chronological order; The entry storage module is configured to continuously store the point data belonging to the same simplified motion trajectory in the point data cache according to age order, generate a curve data entry containing the particle generation time for each simplified motion trajectory, and continuously store the curve data entries in the curve data cache according to the particle generation time order. The mapping establishment module is configured to establish a curve mapping table based on the point data of the simplified motion trajectory corresponding to each curve data entry, using the starting index in the point data cache. The information acquisition module is configured to load the point data cache, the curve data cache, and the curve mapping table into the graphics processor memory, so as to acquire the state information of the particle in the current frame based on the graphics processor memory.

[0008] According to another aspect of this application, a particle motion information processing device is provided, including a central processing unit and a memory, wherein the central processing unit is used to invoke and run a computer program stored in the memory to perform the steps of the method described in this application.

[0009] According to another aspect of this application, a non-volatile readable storage medium is provided, which stores a computer program implemented according to the particle motion information processing method in the form of computer-readable instructions, wherein the computer program, when invoked by a computer, executes the steps included in the method.

[0010] According to another aspect of this application, a computer program product is provided, comprising a computer program / instructions that, when executed by a processor, implement the steps of the method.

[0011] This application generates a simplified motion trajectory by downsampling the original motion trajectory, which greatly reduces the amount of point data that needs to be stored. Compared with the traditional technology of storing the complete state information of each particle frame by frame, this application eliminates a large amount of redundant data while ensuring that the core shape of the particle motion trajectory is preserved, thereby significantly reducing the overall size of the data file and effectively alleviating the pressure of storage, transmission and version management caused by the large file size.

[0012] Furthermore, this application directly loads the point data cache area, curve data cache area, and curve mapping table into the graphics processor's video memory, and completes the particle state calculation for each rendering frame based on the graphics processor. This completely decouples the storage and processing of particle data from the CPU's memory space and computational burden, avoiding the resource occupation caused by the CPU needing to read, parse, and transmit massive amounts of particle data frame by frame in traditional technologies. This frees up the CPU's memory resources, reduces the CPU's computational load, and ensures the smooth operation of the game as a whole.

[0013] Furthermore, this application constructs a separation mechanism for emission control and motion sampling by generating curve data entries containing particle generation time for each simplified motion trajectory and storing them continuously in chronological order. At the same time, point data belonging to the same trajectory are continuously stored in the point data buffer in chronological order. Based on this data structure, the emission rate of particles can be independently controlled according to the current time in each rendering frame, and the motion speed of each particle on the trajectory can be independently controlled according to its own age. This enables flexible and independent control of particle emission rhythm and motion rhythm, overcoming the limitation of traditional technology where particle life cycle and motion speed are fixed by data and cannot be adjusted in real time. Attached Figure Description

[0014] Figure 1 This application provides an exemplary network architecture; Figure 2 This is a flowchart illustrating one embodiment of the particle motion information processing method of this application; Figure 3 This is a schematic block diagram of the particle motion information processing device of this application; Figure 4 This is a schematic diagram of the structure of a particle motion information processing device used in this application. Detailed Implementation

[0015] The technical solution presented in this application can be widely deployed in computing architectures that support large-scale interactive virtual worlds. In a typical implementation environment, such as... Figure 1 As shown, the player's client electronic device 80 connects to a service cluster 81 consisting of multiple server nodes via a network. The service cluster 81 primarily handles the unified management and distribution of particle motion data. It centrally stores particle motion data assets generated after preprocessing by digital content creation tools, including point data caches, curve data caches, and curve mapping tables, forming a resource library accessible to multiple clients. When a client needs to display a specific particle effect, the service cluster 81 determines the target particle motion data to be invoked based on scene events reported by the client or triggering conditions determined by server logic, and then distributes it to the corresponding client electronic device 80. Furthermore, in a shared virtual environment, the service cluster 81 can coordinate the synchronization of particle states between multiple clients, ensuring that the start time and progress of particle effects presented on different devices remain consistent across timelines. The client electronic device 80 is responsible for the local loading and real-time rendering of particle motion data. After receiving particle motion data from the service cluster 81, the client electronic device 80 loads the point data cache, curve data cache, and curve mapping table into the graphics processor's video memory. Based on the parallel computing capabilities of the graphics processor, it performs particle generation judgment, state sampling, and interpolation calculation, ultimately driving the real-time rendering output of the particle system. The client electronic device 80 can also receive local input from the player, requesting corresponding particle motion data from the service cluster 81 based on virtual events triggered by player interaction, or triggering a pre-configured particle effect playback process locally, thereby achieving real-time linkage between player actions and particle effect performance.

[0016] The technical solution of this application can be deployed in various interactive virtual environment systems that require real-time rendering of complex particle effects. Typical application scenarios include, but are not limited to, 3D game clients, film and television-level pre-show platforms, digital twin simulation systems, and virtual reality interactive environments. In the above application scenarios, particle systems, as the core technical means to represent natural phenomena such as smoke, flames, fluids, and cluster movements, can affect the visual realism and system performance of the final presentation due to their data scale and motion complexity.

[0017] In an exemplary implementation architecture, the data processing flow involved in this application can be divided into two stages: offline preprocessing and real-time rendering. The offline preprocessing stage is typically completed in digital content creation tools, such as high-precision simulation of particle motion in dynamics software like Houdini, generating raw data describing the spatial trajectory of each particle. This raw data is converted into an optimized cache format using the downsampling and structured storage methods defined in this application, and imported into the resource management system of the real-time rendering engine as resource assets. The real-time rendering stage is mainly executed within the particle system framework of a game engine. For example, in the Niagara particle system of Unreal Engine, by loading the preprocessed cached data into the graphics processor's video memory, the graphics processor executes particle generation judgment, state sampling, and interpolation calculation in parallel, ultimately driving the real-time rendering output of millions of particles.

[0018] The fundamental concepts involved in this application include particle motion trajectories, downsampling processing, a hierarchical storage structure for point and curve data, an age-based temporal sampling mechanism, and parallel initialization by the graphics processor. Particle motion trajectories refer to the sequence of positions of a single particle in three-dimensional space over time, forming the basic material for particle effects. Downsampling processing refers to the technique of reducing data volume by selecting key sample points while preserving the core shape of the trajectory. The hierarchical storage structure for point and curve data refers to a data organization method that separates and stores the state information of each frame of the particle from its lifecycle metadata, and establishes a correlation through a mapping table. The age-based temporal sampling mechanism refers to the technical process of interpolating and calculating the particle state at any given moment from continuously stored point data, using the particle's relative time position within its lifecycle as an index. Parallel initialization by the graphics processor refers to the use of the graphics processor's massive number of threads to perform particle-data binding operations in parallel when the particle system starts, laying the foundation for real-time sampling for each frame.

[0019] This application can be configured and executed according to the following process as one implementation method. First, during the digital content creation stage, artists or technical artists can simulate particle effects in dynamics software such as Houdini, for example, simulating complex phenomena such as smoke diffusion, flame combustion, or fish movement, and exporting the position information and corresponding time information of each particle in each frame to form the original motion trajectory data. Then, the original trajectory of each particle is simplified through downsampling processing defined in this application, eliminating redundant sample points and generating a simplified motion trajectory composed of key points. In this process, each key point is converted into point data containing position information and age information corresponding to the time information of that point. After downsampling is completed, the point data of all particles are continuously written into a point data buffer in age order, where the point data of the same particle are stored continuously in the buffer and arranged in ascending or descending order of age; at the same time, a curve data entry containing the generation time of the particle is generated for each particle, and all curve data entries are continuously written into another curve data buffer in generation time order. In addition, a curve mapping table is established, which records the starting index of the particle corresponding to each curve data entry in the point data buffer. These three data files together constitute a complete point cloud cache resource.

[0020] Next, import the point cloud cache resource into the game engine's project resource manager. For example, in Unreal Engine's Niagara particle system, developers can create a new particle emitter or open an existing emitter, add a point cloud cache type parameter to the emitter's user parameters, and specify the imported point cloud cache resource to that parameter.

[0021] Specifically, a custom generation control module is added during the particle emitter update phase. This module is responsible for traversing the curve data buffer based on the current simulation time and identifying particles corresponding to curve data entries whose generation time is earlier than the current time as the particles to be generated. During the particle generation phase, a custom particle initialization module is added to bind each newly generated particle to its corresponding curve data entry and establish the association between particles and data. During the particle update phase, a custom sampling module is added. This module locates the corresponding position in the point data buffer based on the particle's current age in each rendering frame using a curve mapping table, finds two point data adjacent to the current age, and calculates the particle's position information in the current frame through interpolation, thereby driving the particle's rendering performance in the scene.

[0022] To improve operational efficiency, the method of this application can transfer the data of the point data buffer, curve data buffer, and curve mapping table from the system memory to the video memory of the graphics processor when the engine starts or the particle system is initialized. This allows all sampling calculations for each subsequent frame to be completed within the graphics processor without the intervention of the central processing unit. At the same time, multiple execution threads corresponding to a preset maximum number of particles can be pre-allocated in the graphics processor. Each thread is bound to a particle identifier and accesses the curve mapping table and curve data buffer in the video memory based on the identifier. It reads the generation time of the corresponding particle and determines whether the particle needs to be activated by comparing it with the current simulation time, thereby realizing the parallel initialization of the particle system.

[0023] In multiplayer online games, the aforementioned point cloud cache resources can be centrally stored in the resource management system of the service cluster. When a player's client electronic device enters a specific area or triggers a specific event, the client requests the corresponding point cloud cache resources from the service cluster. The service cluster then distributes the resources to the client. Upon receiving the resources, the client loads them into the graphics processor's video memory and renders them according to the aforementioned process. Multiple clients can coordinate the start and end times of the same particle effect through the service cluster, ensuring that the particle effects displayed on different players' screens are synchronized and consistent. Player actions on the client, such as adjusting the time scaling factor or triggering loop playback, can be directly controlled by the particle emitter parameters through the client's local logic, without requiring real-time interaction with the service cluster, thus achieving rapid response.

[0024] After providing a general overview of the exemplary network architecture and application scenarios of this application, as well as some basic concepts, the following will continue to describe several specific embodiments of this application.

[0025] Please see Figure 2 The particle motion information processing method of this application, in some embodiments, includes the following steps: Step S3100: Downsample the original motion trajectory of each pre-acquired particle to generate a simplified motion trajectory corresponding to each particle, wherein each simplified motion trajectory consists of multiple point data arranged in chronological order.

[0026] The technical solution of this application can be divided into two interconnected stages: offline preprocessing and real-time rendering. The offline preprocessing stage can be primarily completed within digital content creation tools. Its input data comes from particle simulation results generated through dynamics calculations, such as the particle position information and corresponding time information exported for each frame when simulating smoke diffusion or fluid motion in Houdini. This raw data describes the complete motion path of each particle in three-dimensional space, but often contains a large number of redundant sample points, making it unsuitable for direct application in real-time rendering. Therefore, downsampling processing is required on the original motion trajectory to generate a simplified motion trajectory with smaller data volume but retaining the core form of the original motion, thus laying the foundation for structured storage and efficient sampling. After downsampling, the simplified motion trajectory is further organized into three interconnected data structures: a point data cache, a curve data cache, and a curve mapping table. The point data cache centrally stores the frame-by-frame state of all particles, the curve data cache stores the lifecycle metadata of each particle, and the curve mapping table establishes an index relationship between the two. The data resources obtained after the above preprocessing are exported in file form and imported into the game engine's resource management system as input data for the particle system. During the real-time rendering stage, the game engine loads the preprocessed data into the graphics processor's memory, and the graphics processor executes particle generation judgment, state sampling and interpolation calculation in parallel, ultimately driving the real-time rendering performance of particles in the virtual scene. At this point, this step can be implemented as a core step in the offline preprocessing stage.

[0027] In this embodiment, the pre-acquired original motion trajectory of each particle refers to a data set pre-calculated and generated by an external digital content creation tool, which describes the motion path of a single particle in three-dimensional space over time. This original motion trajectory typically records the particle's motion state at an extremely high temporal density. For example, in Houdini, the position information of each particle in each frame is derived at a sampling rate of 24 frames per second or higher, forming a dense sequence composed of a large number of sample points. Each sample point contains at least the particle's position information and time information at the corresponding moment, where the position information describes the particle's coordinates in three-dimensional space, and the time information identifies the specific moment of the sample point on the entire simulation timeline.

[0028] Downsampling refers to selecting representative key sample points from the dense original motion trajectory to construct a simplified motion trajectory with less data but maintaining the core form and rhythm of the original motion. Downsampling can be implemented based on various preset strategies. One implementation is based on uniform time interval downsampling, which extracts sample points from the original sample points according to a fixed time step, such as retaining one frame every two frames or one sample point every 0.1 seconds. Another implementation is based on adaptive downsampling of motion changes, which dynamically adjusts the sampling density according to the intensity of particle motion. More sample points are retained in areas of rapid motion change to ensure trajectory accuracy, while fewer sample points are retained in areas of gentle motion to compress the data volume. The amount of motion change can be measured by indicators such as the position offset between adjacent sample points, the rate of change of velocity, or curvature. Another implementation method is downsampling based on weighting factors. Each sample point is assigned a weight value; a higher weight value indicates greater importance of the sample point in the motion rhythm or visual representation. During sampling, sample points with higher weights are prioritized for retention. The weight value can be determined based on the acceleration change of the sample point at the corresponding moment, its temporal distance from key events, or the importance level manually marked by the user in the creation tools. Yet another implementation method combines several of the above strategies. For example, initial downsampling can be performed at uniform time intervals, followed by the retention of additional sample points in areas of drastic motion change to balance data compression rate and trajectory reconstruction accuracy.

[0029] The simplified motion trajectory in this application can be a data sequence composed of multiple point data arranged in chronological order. Each point data is a structured data unit converted from a selected key sample point. The point data includes at least a position attribute and an age attribute. The position attribute is directly derived from the position information of the key sample point and describes the spatial coordinates of the particle at a certain moment on the simplified trajectory. The age attribute is a relative time value converted from the time information of the key sample point, representing the time progress of the particle corresponding to that point data throughout its entire life cycle. The age attribute is determined by normalizing the entire life cycle of the particle to the range of 0 to 1, or by retaining the original time value but offsetting it with the particle's generation time as 0. For example, for a particle with a life cycle of 2 seconds, the point data age corresponding to its birth moment is 0, the point data age corresponding to its death moment is 1, and the age of the point data at intermediate moments is calculated proportionally to the time. The multiple point data arranged in chronological order means that the storage order of the point data in the simplified motion trajectory is consistent with its corresponding original time order, i.e., an increasing age value arrangement, so that the simplified motion trajectory can be traversed and sampled in chronological order.

[0030] Step S3200: Store the point data belonging to the same simplified motion trajectory continuously in the point data cache according to age order, generate a curve data entry containing particle generation time for each simplified motion trajectory, and store the curve data entry continuously in the curve data cache according to the particle generation time order.

[0031] After downsampling the original motion trajectory of each particle and generating the corresponding simplified motion trajectory, all simplified motion trajectories are organized and stored, enabling efficient access and sampling during the corresponding real-time rendering process. Specifically, point data belonging to the same simplified motion trajectory are first stored sequentially in a point data cache according to age. The point data cache in this application is a contiguous storage space allocated in memory, used to centrally store all point data on the simplified motion trajectories of all particles. The contiguous storage of point data belonging to the same simplified motion trajectory in this cache means that for each particle, its corresponding multiple point data are adjacent in physical storage address, forming a continuous data block. Meanwhile, within this continuous data block, the point data is arranged in ascending or descending order of its age attribute. The age attribute represents the relative time position of the particle corresponding to the point data in its life cycle. For example, an age of 0 means that the particle has just been generated, and an age of 1 means that the particle is about to die. The purpose of arranging the data by age is to keep the storage order of the point data consistent with the time order, providing a basis for sequential traversal and binary search based on the time axis. For example, for a particle with 10 point data in its life cycle, its age is 0.0, 0.1, 0.2 up to 0.9. These point data are stored sequentially in the point data cache. When accessing, it is only necessary to know the starting position of the particle's point data to read all the point data in order.

[0032] The construction of the point data buffer can be done by processing each particle sequentially. First, allocate contiguous storage space for all point data of one particle and write it in age order. Then, allocate contiguous space for the next particle's point data and write it, until all particle point data is written. Alternatively, it can be done by first collecting all point data from all particles, then grouping them according to particle identifiers, sorting the point data within each group by age, and finally concatenating all sorted grouped point data into a complete point data buffer. During the writing process to the point data buffer, the starting index and number of point data for each particle within that buffer can also be recorded for use when building the curve mapping table.

[0033] While allocating storage space for the point data of each particle and writing it into the point data cache, or subsequently, it is necessary to generate a curve data entry containing the particle's generation time for each simplified motion trajectory. A curve data entry can be a data record describing the particle's lifecycle metadata, with each particle corresponding to a unique curve data entry. The curve data entry must at least contain the particle's generation time attribute. Generation time refers to the point in time when the particle begins to appear and move in the original simulation. It can be expressed as an absolute time value or an offset relative to the simulation's start time. For example, in an explosion effect, the central spark is generated at time 0, while the outer sparks are generated 0.2 seconds later. These generation time values ​​will be recorded separately in their respective curve data entries.

[0034] In one implementation, in addition to the particle generation time, which is mandatory, the curve data entries may also include other attributes related to the overall life cycle of the particle, such as the initial color, initial size, and life cycle length of the particle, depending on actual needs.

[0035] In this embodiment, the curve data cache is another contiguous storage space allocated in memory, specifically used to store the curve data entries for all particles. All curve data entries in this cache are sorted and stored contiguously according to the numerical value of the particle generation time, with earlier generation times listed first and later generation times listed last. For example, for three particles with generation times of 0.0 seconds, 0.1 seconds, and 0.3 seconds, their corresponding curve data entries in the curve data cache are arranged in the order of generation time (0.1 seconds, 0.1 seconds, and 0.3 seconds). This design of storing data contiguously in generation time order allows for rapid location of all particles that have reached their generation time during real-time rendering by sequentially traversing the curve data cache from the beginning based on the current time. For example, at 0.2 seconds, only the first two entries in the curve data cache need to be traversed to determine that two particles need to be generated, without needing to traverse all entries or perform complex search operations.

[0036] Step S3300: Based on the point data of the simplified motion trajectory corresponding to each curve data entry, establish a curve mapping table at the starting index in the point data cache.

[0037] In this embodiment, the purpose of establishing the curve mapping table is to associate each curve data entry with the starting index of its corresponding simplified motion trajectory point data in the point data cache. The curve mapping table can be an independent data structure, and its core function is to provide the ability to quickly locate the specific storage location from the curve data entry to the point data cache. Each curve data entry corresponds to a particle, and the point data of this particle occupies a contiguous storage area in the point data cache. The starting position of this area is the starting index. The starting index can be the sequence number of the first point data in the point data cache, or it can be a byte offset starting from the starting address of the cache. For example, if the point data cache is organized in the form of an array, with each point data occupying a fixed-size storage unit, the starting index is the subscript of the first point data of the particle in the array.

[0038] The process of building the curve mapping table requires recording the starting position of each particle's point data when constructing the point data buffer. During the process of writing point data belonging to the same simplified motion trajectory into the point data buffer in age order, whenever storage space is allocated for a new particle's point data, the offset or sequence number of the current write position relative to the start of the point data buffer is recorded; this value is the starting index of that particle. After writing the point data for all particles, a series of starting index values ​​corresponding one-to-one with each particle are obtained.

[0039] Associating these starting index values ​​with curve data entries in the curve data buffer can be achieved by maintaining the consistency of the particle order. That is, the order in which the curve data entries in the curve data buffer are arranged is the same as the writing order of the particle point data in the point data buffer. In this case, a starting index array with the same length as the curve data buffer can be created. The i-th element of the array stores the starting index of the point data of the particle corresponding to the i-th curve data entry. This array itself constitutes a curve mapping table. When it is necessary to find the corresponding point data based on a certain curve data entry, it is only necessary to access the starting index array using the index position of the entry in the curve data buffer to obtain the starting index.

[0040] Another way to associate the starting index value with the curve data entry is to directly embed the starting index field in the curve data entry. In addition to the particle generation time, each curve data entry also contains a starting index field. When generating the curve data entry, this field is assigned the starting index of the point data of the corresponding particle. At this time, each entry in the curve data cache already carries the positioning information, and the curve mapping table is implicitly contained in the curve data entry, without the need for an additional independent data structure.

[0041] Another related implementation method is suitable for scenarios that require random access via particle identifiers. Specifically, each particle can be assigned a unique identifier. When constructing the point data cache and curve data cache, the correspondence between the identifier of each particle and the starting index is recorded. Subsequently, a hash table or dictionary with the particle identifier as the key and the starting index as the value is established as the curve mapping table. When searching for point data based on the particle identifier, the starting index can be quickly obtained through the hash table.

[0042] Therefore, the curve mapping table can accurately reflect the starting position of the particle point data corresponding to each curve data entry in the point data cache area. This mapping table, together with the point data cache area and the curve data cache area, constitutes a complete data organization system, providing a necessary foundation for traversing curve data entries according to particle generation time, and then locating and sampling point data during real-time rendering. Furthermore, the curve mapping table can be constructed in the offline preprocessing stage and stored and transmitted together with the point data cache area and the curve data cache area as part of the final exported point cloud cache resource.

[0043] Step S3400: Load the point data cache, the curve data cache, and the curve mapping table into the graphics processor memory to obtain the state information of the particle in the current frame based on the graphics processor memory.

[0044] After the point data cache, curve data cache, and curve mapping table are constructed, these data structures are initially stored in system memory for data organization and persistent storage during the offline preprocessing stage. However, to achieve efficient particle state calculations during real-time rendering, these three data structures also need to be loaded into the graphics processor's video memory. This allows all subsequent access to and calculations of particle data to be completed within the graphics processor, thereby avoiding data transfer between the central processing unit and the graphics processor, reducing system load, and improving processing efficiency.

[0045] Specifically, the process of loading the point data buffer, curve data buffer, and curve mapping table into the graphics processor's video memory first requires obtaining the storage addresses of these three data structures in system memory and the data size they occupy. The graphics processor's application programming interface provides dedicated memory allocation and data transfer functions to request contiguous storage space in the graphics processor's video memory and copy data from system memory to the corresponding storage area in video memory. For example, in Direct3D, data upload can be achieved by creating a buffer resource and calling the update sub-resource method; in OpenGL, data loading can be achieved by generating a buffer object and calling the buffer data storage method; and in Vulkan, the transfer is completed by allocating device memory and binding the buffer data to the device memory.

[0046] During loading, the point data buffer is transferred as a whole to a separate contiguous storage area in the graphics processor's video memory, maintaining the original contiguous storage structure and age order of all point data. Similarly, the curve data buffer is transferred as a whole to another separate contiguous storage area, maintaining the contiguous storage structure and generation time order of all curve data entries. The curve mapping table, depending on its specific implementation, can be transferred to video memory as an independent buffer or as part of the curve data buffer. When the curve mapping table uses an independent starting index array, the array is transferred separately to a third contiguous storage area in video memory. When the curve mapping table is implicit in the curve data entries, it is transferred along with the curve data buffer.

[0047] Once the loading is complete, the graphics processor's video memory stores three copies of the data that are completely identical to those in the system memory. The storage addresses of these data in the video memory are recorded as access handles for the graphics processor resources, which can be referenced by subsequent shader programs or computation shaders at runtime. When the graphics processor performs each frame of particle simulation calculations, it binds these video memory resources so that each execution thread can directly access the point data buffer, curve data buffer, and curve mapping table without the central processing unit intervening in data reading and distribution.

[0048] Obtaining particle state information in the current frame based on the graphics processor's video memory refers to the graphics processor using three data structures loaded into video memory to calculate the current state of each particle in parallel in each rendering frame. This process is completed by the particle simulation shader or computation shader executed in the graphics processor. The shader program first traverses the curve data buffer according to the current time. By comparing the particle generation time recorded in each curve data entry with the current time, it determines which particles should be active in the current frame. For each active particle, the shader program accesses the curve mapping table based on its index position in the curve data buffer to obtain the starting index of the particle's point data in the point data buffer. Subsequently, the shader program traverses the point data buffer from the starting index backward according to the particle's current age, searching for two point data adjacent to the current age. The current age can be calculated from the particle generation time and the current time, or it can be obtained from the independent particle age attribute. After finding two adjacent point data, the shader program performs linear interpolation or higher-order spline interpolation on the position attributes of these two point data to calculate the precise position of the particle in the current frame. At the same time, it can interpolate and calculate rotation, scaling or other custom attributes as needed. The final particle state information can be written to the output buffer for subsequent rendering.

[0049] During the execution of the above operations in the graphics processor's memory, the particle generation judgment, data positioning, neighbor point search and interpolation calculation for each frame are completely completed inside the graphics processor. There is no need for the central processing unit to traverse the particle list frame by frame or update the particle data frame by frame. The central processing unit only needs to update the current time parameter and assign the graphics processor's calculation tasks at the beginning of each frame. All other work is completed in parallel by the graphics processor. Thus, this architecture makes full use of the graphics processor's massive parallel computing capabilities and high-bandwidth memory access characteristics, making it possible to drive complex effects of millions or even tens of millions of particles at the same time, while significantly reducing the demand on central processing unit resources.

[0050] As demonstrated by the above embodiments, this application achieves efficient compression and structured organization of complex particle motion data, significantly reducing the storage size of data files and solving the problem that traditional frame-by-frame caching schemes are difficult to apply in practical projects due to excessive data volume. Furthermore, by directly loading the point data cache, curve data cache, and curve mapping table into the graphics processor's memory, this application enables the sampling and interpolation calculation of particle states to be completed in parallel within the graphics processor. The central processing unit (CPU) only needs to handle task distribution and does not need to participate in frame-by-frame data processing, thereby significantly freeing up CPU memory resources and computational load. In addition, by separating the particle generation time from the age information of the point data, independent control of particle emission rhythm and motion rhythm is achieved, providing a technical foundation for flexible control such as time scaling and loop emission in post-production. Therefore, this application comprehensively optimizes the real-time rendering capabilities of the particle system from three dimensions: data volume, operational performance, and control flexibility, while ensuring the accuracy of particle motion reconstruction.

[0051] Based on any embodiment of the method in this application, obtaining the state information of the particle in the current frame based on the graphics processor's video memory includes: Step S3110: Based on the current timestamp, in each rendering frame, traverse the curve data buffer according to the particle generation time order, and determine the particles corresponding to the curve data entries whose particle generation time is earlier than the current timestamp as the currently generated particles.

[0052] In this embodiment, after the corresponding data has been loaded into the graphics processor's video memory, the current timestamp is obtained at the beginning of each rendering frame as a judgment criterion. All curve data entries stored in the curve data buffer are arranged continuously in ascending order of particle generation time. Based on this ordered structure, the traversal operation can start from the beginning of the buffer and read each curve data entry sequentially, comparing the particle generation time recorded in the entry with the current timestamp. If the generation time recorded in a curve data entry is earlier than the current timestamp, it means that the particle has entered its life cycle at the current moment, so the particle corresponding to that entry is marked as a currently generated particle.

[0053] The traversal continues until the first curve data entry with a generation time greater than or equal to the current timestamp is encountered, because the particles corresponding to subsequent entries have not yet reached their generation time. This traversal method based on ordered storage allows each frame to access only the first few entries in the curve data buffer without scanning all the data to accurately determine the set of particles that need to be activated.

[0054] Step S3120: Locate the corresponding point data cache area in the curve mapping table according to the age of each generated particle in the current rendering frame.

[0055] In the current rendering frame, each particle identified as generated has a current age value calculated based on its lifecycle. This age value reflects the particle's time progress from birth to the present moment. The core function of the curve mapping table is to establish a relationship between the particle identifier and its storage location in the point data buffer. The corresponding positioning operation first searches the curve mapping table for the corresponding mapping entry based on the particle's identifier. This entry records the particle's starting index in the point data buffer. The starting index could be the sequence number of the point data in the buffer, or it could be an offset from the buffer's starting address. Using this starting index, the entry point of the contiguous storage area belonging to that particle in the point data buffer can be directly located, preparing for subsequent reading of the specific point data corresponding to the particle's current age. This allows each particle to quickly find its own segment of point data without needing a global search within the vast point data buffer.

[0056] Step S3130: Based on the age order of the point data in the point data cache, find two adjacent point data that are adjacent to the age of the particle corresponding to the current timestamp, so as to obtain the state information of the particle based on the adjacent point data.

[0057] During the real-time rendering of the particle system, each point data stored in the point data cache is accompanied by an age attribute. This age attribute is essentially a numerical marker used to indicate the specific progress position of the particle corresponding to that point data throughout its entire life cycle. Since point data on the same simplified motion trajectory are not only stored contiguously in the cache but also strictly arranged in ascending order of age value, this creates conditions for fast time-based lookups. The goal of searching for two adjacent point data is to be able to reconstruct the particle's state that most closely approximates its actual motion at any given point in time. In the current rendering frame, each generated particle has a current age value calculated by the system. This age value reflects the proportion of time elapsed since the particle's birth. To find the two point data that best match this current age, the search operation starts from the particle's starting index position in the point data cache and accesses the point data one by one along the direction of continuous storage. Each time a point data is read, its age is compared with the current particle's age.

[0058] In one implementation, two scenarios may occur during the comparison process. If the current particle age is exactly equal to the age of a certain data point, then that data point itself is an exact match, and its state information can be used directly without interpolation. However, in more cases, the current particle age will fall between the ages of two data points. For example, if the current particle age is 0.35, and two consecutively stored data points have ages of 0.30 and 0.40, the search operation will locate the point with age 0.30 as its forward neighbor and the point with age 0.40 as its backward neighbor.

[0059] After obtaining the data from these two adjacent points, the interpolation weight is calculated based on the specific position of the current particle's age within the age interval of the two neighboring points. Taking the aforementioned 0.35 as an example, it falls at the 50th percentile within the interval of 0.30 to 0.40. This weight can be used to weight and fuse the various attributes stored in the two point data. Position attribute interpolation can use linear interpolation to obtain a smooth motion trajectory, while rotation attribute interpolation requires quaternion spherical linear interpolation to ensure the correctness of the rotation direction. Scaling attribute interpolation can also use linear interpolation. If the point data also contains color, velocity, or other custom attributes, interpolation calculations can be performed using the same weights.

[0060] Therefore, by using neighboring point interpolation, even if the original point data becomes relatively sparse after downsampling in the time dimension, the final rendered particle motion can still maintain visual continuity and smoothness. The efficiency of the search process benefits from the continuous storage of point data in the cache and the regular structure sorted by age, so that each particle only needs to perform a few comparisons within its own continuous data block to complete the positioning, avoiding the performance overhead caused by unordered search in the entire cache.

[0061] Through the above implementation, the particle system can quickly and accurately reconstruct the real-time state of each particle from massive cached data in each rendering frame. Based on the ordered storage structure of the curve data cache, the active particle set can be determined simply by comparing the particle generation time with the current timestamp, avoiding redundant operations of traversing all particles frame by frame. Furthermore, by establishing a direct association between particle identifiers and storage locations using a curve mapping table, each active particle can instantly locate its own segment of point data, eliminating the need for a global search within the vast point data cache. Moreover, by utilizing the age-ordered nature of the point data, interpolation can be performed by finding two point data points adjacent to the current particle's age, achieving smooth motion reconstruction while maintaining sampling accuracy. Even if the original point data becomes sparse after downsampling, the interpolation calculation still provides a continuous and smooth visual effect. Thus, this embodiment constitutes a complete and efficient link from particle activation to data localization to state reconstruction, achieving an ideal balance between computational overhead and data access efficiency in the real-time rendering of large-scale particle effects.

[0062] Based on any embodiment of the method in this application, the original motion trajectory of each pre-acquired particle is downsampled to generate a simplified motion trajectory corresponding to each particle, wherein each simplified motion trajectory consists of multiple point data arranged in chronological order, including: Step S3210: Obtain multiple sample points arranged in chronological order from the original motion trajectory of each particle, wherein each sample point includes the position information and time information of the particle at the corresponding moment.

[0063] The preprocessing stage of particle motion data first requires acquiring raw simulation data. This raw simulation data can come from external digital content creation tools such as Houdini, a dynamics solution software. In these tools, artists or technical artists can generate particle effects that conform to the laws of real motion through physical simulation. After the simulation is completed, the corresponding software will export the motion state of each particle as raw motion trajectory data frame by frame. The raw motion trajectory of each particle consists of sample points corresponding to each sampling moment of the particle on the simulation time axis. These sample points are arranged in chronological order, forming a discretized description of the complete motion process of the particle. The core components of each sample point include at least two parts. The first part is position information, which records the specific coordinates of the particle in three-dimensional space at the corresponding moment, usually represented in the form of a three-dimensional vector, such as the x-axis, y-axis, and z-axis values ​​in the world coordinate system. The second part is the time information, which identifies the specific position of the sample point on the overall simulation timeline. This is usually expressed as an absolute time value from the start of the simulation, such as 0.0 seconds, 0.04 seconds, and 0.08 seconds, or as frame numbers, such as frame 1, frame 2, and frame 3. This method of binding spatial location with time labels allows each sample point to be a snapshot of the particle's motion at a specific moment. Connecting all sample points in chronological order constitutes a complete description of the particle's motion path from birth to death. The resulting raw simulation data has the characteristics of high sampling density and large data volume.

[0064] Step S3220: Select corresponding key sample points from the plurality of sample points according to a preset simplification strategy, and convert the key sample points into the simplified motion trajectory composed of point data in chronological order, wherein the point data includes the location information of the corresponding key sample points and the age information determined according to the time information.

[0065] By obtaining multiple sample points arranged in chronological order from the original motion trajectory of each particle, representative key sample points can be selected from these dense sample points, and a simplified motion trajectory with a smaller data volume can be constructed. Thus, while preserving the original motion characteristics as much as possible, the amount of data that needs to be stored and transmitted can be greatly reduced.

[0066] In this application, the simplification strategy can be a pre-defined set of rules used to determine which sample points in the original sample point sequence should be retained as key sample points. This set of rules can be flexibly selected according to different application requirements and motion characteristics. One simplification strategy is based on uniform time interval filtering, i.e., setting a fixed time step, such as retaining one sample point every 0.1 seconds or every two frames, and discarding all other sample points. This strategy is simple to implement and suitable for scenarios with uniform motion rhythm and no drastic changes. The simplification strategy can also be based on spatial distance filtering, i.e., calculating the positional offset between adjacent sample points. When the offset exceeds a preset threshold, the next sample point is retained; when the offset is less than the threshold, it is discarded. This automatically reduces the sample point density in areas of gentle motion and automatically retains more details in areas of intense motion. For example, when a particle moves at a constant speed in a straight line, the positional offset between adjacent sample points is basically constant. By setting an appropriate distance threshold, the number of sample points can be significantly reduced. When the particle suddenly turns or accelerates, the offset increases, resulting in more retained sample points, which can capture key details of motion changes. Another strategy is curvature-based selection, which determines whether to retain a sample point by calculating the curvature of the motion path at that point. A higher curvature indicates a more drastic change in motion direction, making the sample point more likely to be retained. Alternatively, a hybrid strategy can be used: first, sampling at uniform time intervals, then supplementing and retaining additional sample points in areas of drastic motion change to balance data compression ratio and trajectory reconstruction accuracy.

[0067] After identifying key sample points, during the process of converting these key sample points into point data and organizing them into simplified motion trajectories in chronological order, the positional information of each key sample point needs to be directly extracted as the positional attribute of the point data. Simultaneously, the temporal information of the key sample points also needs to be converted into an age attribute. The age attribute can often be determined by normalizing the entire lifespan of the particle to a range of 0 to 1. For example, if a particle's lifespan is 2 seconds, its age is 0 for a birth time of 0 seconds and 1 for a death time of 2 seconds. The age at any intermediate moment is calculated using a time ratio.

[0068] Through the above embodiments, the dense and redundant sample points in the original particle simulation data are transformed into simplified motion trajectories composed of key sample points. First, by acquiring the position and time information of each sample point, a complete data foundation is provided for subsequent filtering. Based on this, the sample points are filtered according to a preset simplification strategy, retaining only the key sample points that can reflect the core form of motion, which can significantly reduce the total amount of data that needs to be stored and transmitted. Each retained key sample point is converted into point data containing position and age attributes, where the age attribute is calculated based on the original time information. This ensures that the simplified trajectory not only retains spatial position information but also fully records the temporal progress relationship of the particle in its life cycle. This downsampling processing method significantly reduces the data file size while ensuring that the core form and rhythmic characteristics of the motion trajectory are preserved, providing a compact and sufficient data source for efficiently reproducing particle motion in real-time rendering.

[0069] Based on any embodiment of the method in this application, the point data belonging to the same simplified motion trajectory are continuously stored in a point data buffer in age order, and a curve data entry containing particle generation time is generated for each simplified motion trajectory. The curve data entries are then continuously stored in the curve data buffer in the order of particle generation time, including: Step S3310: Assign a corresponding trajectory identifier to each of the simplified motion trajectories, and extract multiple point data belonging to the same trajectory identifier into a corresponding point data set.

[0070] Since the simplified trajectory of each particle, generated by downsampling, consists of multiple point data arranged in chronological order, organizing these discrete point data allows for continuous storage and fast access at the particle level. First, each simplified trajectory is assigned a corresponding trajectory identifier. This identifier is a unique marker distinguishing different particles, and can take various forms such as integer numbers, string names, or globally unique identifiers. In practice, given the potentially millions of particles, using integer numbers starting from 0 and incrementing is a common and efficient choice. For example, the simplified trajectory of the first particle is assigned trajectory identifier 0, the second particle is assigned trajectory identifier 1, and so on. This trajectory identifier persists throughout the entire data processing flow, serving as the particle's identity credential in all subsequent data structures.

[0071] After assigning trajectory identifiers, it is necessary to extract multiple point data belonging to the same trajectory identifier to form corresponding point data sets. A point data set is a logical grouping concept; it gathers all point data of the same particle together without changing the content of the point data itself. The extraction process is an operation of classifying and summarizing point data. By traversing all point data, according to the particle to which each point data belongs, it is placed into the corresponding set. For example, a particle with trajectory identifier 0 contains 5 point data on its simplified motion trajectory, and these 5 point data are extracted to form the point data set of that particle; a particle with trajectory identifier 1 contains 8 point data, and these 8 point data are extracted to form another point data set. The purpose of this extraction is to separate the point data of all particles that were originally mixed together according to the particle identity, creating conditions for the independent processing of each particle's point data in the future.

[0072] In one implementation, the point data set can be constructed by creating multiple dynamic arrays in memory corresponding to the number of particles, traversing all point data, and appending each point data to the dynamic array of its respective particle. In another implementation, the point data set can be constructed by first sorting all point data according to trajectory identifiers, ensuring that point data belonging to the same particle are adjacent in storage location, and then implicitly defining the point data set by recording the starting position and quantity of each particle's point data, thereby clarifying which point data each particle possesses.

[0073] Step S3320: Based on the age information, write multiple point data in each point data set into the point data cache in age order, and determine the starting index of each point data set in the point data cache.

[0074] The core of building a point data cache lies in how to organize the discrete point data of each particle into a continuous structure that can be accessed efficiently. Although the point data set of each particle has been built, these point data may currently be scattered in different locations in memory or, although logically belonging to the same set, have not yet formed a physically continuous storage. Therefore, these logical sets need to be transformed into physically continuous and ordered data blocks.

[0075] The write operation begins with the first particle. The system maintains a pointer to the currently writable position in the point data buffer. Initially, this pointer points to the beginning address of the buffer. For the currently processed particle, its point data set is first retrieved. This set contains all the point data of the particle, each point data having an age attribute. Before writing, it needs to be confirmed that the point data in the set is sorted in ascending order of age. If the set was constructed with the order guaranteed, the write phase can proceed directly. If it is not yet sorted, a sorting operation needs to be performed on the point data in the set to ensure that the youngest point data is at the beginning and the oldest point data is at the end. After sorting, all the point data of this particle is written sequentially to a contiguous space starting from the currently writable position. After writing is complete, the write pointer is updated to point to the position where the next particle can begin writing.

[0076] Before writing the first data point of a particle, it's necessary to record the offset or index value of the currently writable position relative to the starting address of the data point buffer. This value is the starting index of the particle. The starting index can take two forms: element-based indexing, which starts counting from 0. The index of the first data point of the first particle in the buffer is 0. If the first particle has 5 data points, then the index of the first data point of the second particle is 5. The other form is byte-based offseting. Assuming each data point occupies a fixed number of bytes, for example, each data point contains two floating-point numbers (position and age) occupying a total of 24 bytes, then the starting offset of the first particle is 0 bytes, and the starting offset of the second particle is 120 bytes. These two forms can be chosen based on subsequent access needs. If subsequent accesses require frequent random reading of data points based on the index, element-based indexing is more intuitive; if low-level memory operations on the buffer are required, byte-based offseting is more direct.

[0077] The writing process determines the layout of the final point data buffer. After the first particle is processed, the first part of the buffer is filled with the point data of that particle. Then the second particle is processed, and its point data is written immediately after the end of the first particle's point data. This continues until all the point data of all particles has been written. This sequential appending writing method makes the point data buffer present a compact spliced ​​structure without any gaps or fragments. The point data of each particle occupies a continuous sub-region, and the sub-regions are closely adjacent to each other.

[0078] Throughout the writing process, the age order must be maintained. After the point data buffer is built, the data within each particle is sorted according to its life cycle progress. When sampling is performed subsequently based on the particle's current age, a sequential search or binary search can be performed within the corresponding continuous region of the particle to quickly locate two point data points with adjacent ages. The starting index record establishes a precise entry point for each particle, enabling the jump from curve data entries to specific point data to be completed in constant time, without needing to search the entire buffer.

[0079] Step S3330: Based on the starting index corresponding to each simplified motion trajectory and the generation time of the particle corresponding to the simplified motion trajectory, generate a curve data entry containing the correlation between the particle generation time and the starting index, and write the curve data entry into the curve data cache area.

[0080] After writing each particle's point data to the point data buffer and recording its starting index, each particle is ready with point data information describing its specific trajectory in space and time, stored in the point data buffer, along with its corresponding starting index, which points to the entry point of that particle's point data in the buffer. However, simply having the starting index is insufficient to support subsequent time-based particle generation judgments, because the starting index itself does not contain any information about when the particle was born. Therefore, it is necessary to bind the particle's generation time and the starting index together to form complete curve data entries, and write these entries into the curve data buffer in the order of their generation time.

[0081] The generation time refers to the moment when a particle first appears and begins to move in the original simulation. This information is already included in the sample points of each particle when the original motion trajectory is initially acquired; specifically, it is the time information extracted from the first sample point of that particle. The starting index is a predetermined value, which can be used as a key to locate the data points using array subscripts. The process of generating curve data entries combines these two pieces of information into a single data record. Curve data entries can be designed as a compact data structure, containing at least a particle generation time field storing the particle's generation time value and a starting index field storing the particle's starting index. In some implementations, other elements related to the overall lifecycle of the particle, such as the total lifecycle length, initial color, or initial size, can be added as needed. After generating curve data entries, these entries need to be written to the curve data buffer. A key requirement for writing is that they must be stored consecutively in the order of particle generation time. Therefore, before writing, all particle curve data entries need to be sorted in ascending order of their generation time values. After sorting, starting from the beginning of the buffer, the first sorted curve data entry is written, followed by the second, and so on, until all entries are written.

[0082] In each frame of real-time rendering, it is also necessary to quickly determine which particles have reached their generation time at the current moment. Since the entries in the curve data buffer are already sorted by generation time, it is only necessary to traverse sequentially from the beginning of the buffer, comparing the generation time of each entry with the current time, until the first entry with a generation time greater than the current time is encountered. The particles corresponding to all the entries before this are the particles that need to be generated now. The time complexity of this traversal method is proportional to the number of particles that need to be generated now and is independent of the total number of particles, thus achieving efficient particle generation judgment.

[0083] After the writing is completed, the curve data buffer stores an ordered set of curve data entries for all particles. Each entry contains the correlation between the particle's generation time and the starting index. This correlation forms the bridge for subsequent jumps from the curve data entry to the point data buffer. When it is determined that a particle needs to be activated based on the generation time, the starting index in the particle's curve data entry is read directly, and the entry of the particle's point data in the point data buffer can be located immediately, thus starting the sampling of the particle's motion trajectory.

[0084] Through the synergistic effect of the above embodiments, the originally scattered and disordered particle point data is systematically organized into a highly structured storage format. Specifically, this embodiment can establish clear boundaries for subsequent data processing by particle unit. On this basis, the point data within each point data set is continuously written to the point data cache in age order, so that the states of the same particle at different times are physically adjacent, creating conditions for sequential access based on the time axis. At the same time, the recorded starting index of each set provides a precise entry point for subsequent quick jumps from curve entries to specific point data. On the other hand, this embodiment enables all particles that need to be activated to be quickly filtered according to the current time through simple sequential traversal during real-time rendering, and the storage location of their point data can be directly obtained. This tightly couples the particle's identity, time attributes, and storage location, making the corresponding particle state sampling more efficient and parallel.

[0085] Based on any embodiment of the method in this application, a curve mapping table is established based on the point data of the simplified motion trajectory corresponding to each curve data entry, using the starting index in the point data buffer, including: Step S3410: Traverse each curve data entry in the curve data buffer area and extract the particle generation time and the starting index recorded in each curve data entry.

[0086] In this application, the curve data cache can essentially be a contiguous data array, where each element is a curve data entry. Each entry contains at least two fields: one is the particle generation time, and the other is the starting index of the particle point data in the point data cache. The traversal operation starts from the first entry in the cache and accesses each entry one by one according to the physical order of the entries in memory. Each time an entry is accessed, the values ​​of the two fields are read from it. Since the curve data entries are already sorted in ascending order of particle generation time when they are written, the generation time sequence read during the traversal is also increasing.

[0087] The extracted particle generation time and starting index are either temporarily stored or used directly to generate mapping table entries. The particle generation time is usually used as the index key of the mapping table, while the starting index is used as the value of the mapping table. This is used to establish a mapping relationship from particle identity to point data storage address. Thus, the entire extraction process only involves reading operations and does not modify the original content in the curve data buffer.

[0088] Step S3420: Determine the mapping table index value of each curve data entry based on the particle generation time, generate the corresponding mapping table entry using the mapping table index value as the key and the starting index as the value, and construct the curve mapping table based on the mapping table entry using the mapping table index value.

[0089] By utilizing the extracted particle generation time and starting index, a curve mapping table capable of fast lookup can be constructed. The process of building this table requires determining the index value for each particle, which is directly related to its generation time. One implementation method is to directly use the particle generation time as the key of the mapping table. In this approach, each particle's generation time is itself a unique identifier. Thus, using the generation time as the key and the starting index as the value, a key-value pair mapping table entry is constructed. For example, a particle with a generation time of 0.0 seconds corresponds to a starting index of 0, a particle with a generation time of 1.2 seconds corresponds to a starting index of 128, and a particle with a generation time of 2.5 seconds corresponds to a starting index of 256. These key-value pairs together constitute the mapping table. The advantage of this method is that the particle's generation time can be directly used for lookup, making it suitable for scenarios where particles need to be accessed directly based on their time value.

[0090] Another approach is to leverage the ordered nature of particle generation times to determine the index value. Since the entries in the curve data buffer are already sorted by generation time, the position of each entry in the buffer itself serves as a natural index. In this method, when traversing the curve data buffer, each encountered curve data entry is assigned an incrementing sequence number, which becomes the particle's mapping table index. For example, the first entry has an index of 0, the second entry has an index of 1, and so on. Then, using this index value as the key and the starting index extracted from that entry as the value, mapping table entries are generated. The resulting curve mapping table is essentially an array. The 0th element of the array stores the starting index of the first particle, the 1st element stores the starting index of the second particle, and so on. The advantage of this method is its extremely high search efficiency. When it's necessary to find the starting index of a particle based on its index value later, it can be accessed directly through the array index, resulting in a constant time complexity.

[0091] Another approach is to map particle generation time to a custom index space. If particle generation time is distributed within a fixed time range, the minimum generation time can be subtracted from the generation time and then divided by the time precision to obtain an integer index value. This approach is more suitable for scenarios where time values ​​need to be aligned to a specific time grid, but it requires that particle generation time distribution be uniform and without conflicts.

[0092] The final curve mapping table is a set of mapping relationships from particle identifiers to point data storage locations. This mapping table, along with the point data cache and curve data cache, becomes a key index structure for quickly locating particle point data in real-time rendering. When the particle to be activated is determined based on the current time in a certain rendering frame, the corresponding starting index can be found in the curve mapping table by the particle's index value or generation time, and then the motion state data of the particle can be read from the point data cache.

[0093] Through the above embodiments of this application, the particle generation time and starting index extracted from the curve data cache can be transformed into a structured curve mapping table. This transformation process reorganizes the two pieces of information originally scattered in the curve data entries into a mapping relationship with the index value as the key and the starting index as the value, so that the identity of each particle and the physical entry of its point data in the point data cache are directly and efficiently mapped. The constructed curve mapping table essentially acts as a fast navigation tool from particles to their motion data. Thus, once it is determined that a particle needs to be activated during real-time rendering, the starting index of its point data can be instantly located in the mapping table by the particle's index value or generation time, without having to traverse and search within the huge point data cache. The establishment of this index structure can reduce the time complexity of looking up the particle identity and data storage location to the constant level, thereby providing a key efficiency guarantee for the real-time operation of large-scale particle systems.

[0094] Based on any embodiment of the method in this application, loading the point data cache, the curve data cache, and the curve mapping table into the graphics processor's video memory includes: Step S3510: Obtain the storage capacity occupied by the point data cache, the curve data cache and the curve mapping table in the system memory respectively, and allocate the corresponding storage area in the graphics processor video memory according to the storage capacity.

[0095] Before migrating the corresponding data from system memory to graphics processor memory, it is necessary to accurately assess the total amount of data to be transferred. The size of the point data buffer is determined by the product of the number of point data and the number of bytes occupied by each point data. The size of the curve data buffer is determined by the product of the number of curve data entries and the number of bytes occupied by each entry. The size of the curve mapping table is determined by the product of the number of particles and the number of bytes occupied by each mapping entry. These three values ​​can be obtained by querying the metadata recorded during memory allocation.

[0096] After obtaining the storage capacity, the next step is to allocate corresponding storage regions in the graphics processor's video memory. Using the video memory allocation interface provided by the graphics API, three independent, contiguous storage spaces are requested based on the three capacity values. The size of each space is exactly the same as the corresponding system memory buffer. Hardware alignment requirements must be considered during allocation; for example, some architectures require the buffer's starting address to be aligned to 256 bytes or 4096 bytes. Therefore, the actual allocated size can be adjusted appropriately based on the original capacity to meet alignment constraints. After successful allocation, the graphics API returns the base address handle for each video memory region. These handles will be used for subsequent data transfer and shader binding. Thus, after the storage capacity allocation is completed, a one-to-one mapping relationship is established between the three buffers in system memory and the three newly allocated regions in video memory.

[0097] Step S3520: Transfer the point data in the point data cache, the curve data entries in the curve data cache, and the mapping table entries in the curve mapping table to the corresponding storage areas in the graphics processor's video memory.

[0098] Once the three data structures in system memory are ready and the corresponding storage areas in video memory are allocated, the data transfer phase officially begins. The three independent data blocks are transferred separately, ensuring that each data structure is completely moved to its pre-allocated location in video memory. The point data buffer contains the point data of all particles. This data is represented as a continuous sequence of bytes in memory. During transfer, the buffer reads its entire length from the starting address and copies these bytes verbatim to the starting address of the corresponding area in video memory via the data transfer interface provided by the graphics processor. Since the data in the point data buffer is already arranged in age order, no modification or rearrangement of the data content is required during transfer; only the original storage order needs to be maintained. The same operation is applied to the curve data buffer and the curve mapping table. The sequence of curve data entries in the curve data buffer is transferred as a whole to the curve data storage area in video memory, and the sequence of mapping table entries in the curve mapping table is transferred as a whole to the mapping table storage area in video memory.

[0099] The transfer process can be performed using direct memory access. After initiating the transfer command, the CPU can continue executing other tasks without needing to participate in data movement byte by byte. By using a graphics processor interface that supports asynchronous transfer, the transfer operations of the three data blocks can be placed in a command queue for parallel processing, or executed serially in a specified order. After the transfer is complete, the original data in system memory can be retained or released as needed, while the three copies in video memory become the data source for all subsequent rendering operations. At this point, the graphics processor has obtained full data access rights, and particle state calculations for each subsequent frame will be completed within video memory, without the need for CPU or system memory intervention.

[0100] Step S3530: Establish an address index for the graphics processor to access the storage area, so that the graphics processor can locate the curve data entry according to the mapping table entry, and obtain the point data according to the starting index recorded in the curve data entry.

[0101] Establishing address indexes for the graphics processor's access to memory regions essentially involves configuring a mechanism for parallel threads to locate and address the three data regions in video memory. The core function of this mechanism is to link particle identifiers, curve data, and point data into a clear access chain. The process of establishing address indexes involves assigning a unique identifier to each data region within the graphics processor's execution environment and binding these identifiers to subsequent access instructions. When the graphics processor starts a particle simulation task, each execution thread obtains the identifier of the currently processed particle; this identifier becomes the starting point of the entire access chain. The thread first finds the mapping entry corresponding to the particle using the address index of the curve mapping table, reads the starting index (which is itself an address index pointing to a specific curve data entry in the curve data buffer), and then uses this location to jump to the curve data buffer to obtain metadata such as the particle's generation time. Simultaneously, it parses another starting index, which points to the entry point of the particle's point data sequence in the point data buffer. The thread jumps again, ultimately locating the specific point data in the point data buffer.

[0102] Throughout the process, the address index can be represented as a series of pointers or offsets stored in video memory. These pointers act like road signs, guiding threads to delve deeper into the data. The curve mapping table is the first-level road sign, pointing to the curve data based on the particle identifier. The curve data entries are the second-level road signs, pointing to the point data sequence based on the starting index. This allows each thread to independently locate and read all the data simply by holding the particle identifier, without the intervention of the central processing unit. Furthermore, all threads execute their respective addressing paths in parallel, creating a large-scale concurrent access scenario in video memory, which together supports the efficient operation of the particle system.

[0103] Through the embodiments described above, the point data cache, curve data cache, and curve mapping table are completely migrated from system memory to the graphics processor's video memory (GPU). An address index system is established in the GPU that allows direct access by the GPU, enabling all subsequent particle state sampling and calculations to be completed entirely within the GPU. The central processing unit (CPU) no longer needs to participate in data reading and parsing for each frame, thus freeing up CPU memory resources and computational load. Simultaneously, because the data resides in GPU memory and the access path is guided by a pre-built index structure, tens of thousands of parallel threads in the GPU can independently and quickly jump between the three data regions, fully leveraging the GPU's large-scale parallel computing capabilities and high-bandwidth GPU memory access advantages. This lays the data-level foundation for the efficient real-time operation of the particle system and promotes the smooth rendering of large-scale complex particle effects.

[0104] Based on any embodiment of the method in this application, an initialization process for particle simulation is further included in the graphics processor, including: Step S3610: Allocate multiple execution threads in the graphics processor corresponding to a preset maximum number of particles, and bind a corresponding thread identifier to each execution thread, wherein the thread identifier is associated with a particle identifier.

[0105] In this implementation, the graphics processor (GPU) establishes a correspondence between the basic units of parallel computing and the particles to be processed before starting particle simulation. In the GPU programming model, the execution thread is the smallest unit of parallel computing. Each thread can independently execute the same instructions but process different data. The preset maximum number of particles is a pre-defined upper limit that determines the maximum number of active particles the particle system can support simultaneously. For example, setting it to one million means the system allows a maximum of one million particles to exist concurrently. The GPU starts the corresponding number of execution threads based on this number. Each thread is assigned a unique thread identifier, which can exist in the form of a thread index, such as thread 0, thread 1, thread 2, up to thread N-1. The association between the thread identifier and the particle identifier means that the thread index is directly mapped to the particle index; that is, thread 0 is responsible for processing particle 0, thread 1 is responsible for processing particle 1, and so on. This one-to-one mapping relationship allows each thread to clearly know which particle it is responsible for. All subsequent data access and calculations for that particle are completed independently by the corresponding thread. After thread allocation, these N threads in the GPU will execute the subsequent particle state update logic in parallel.

[0106] Step S3620: Each execution thread accesses the curve mapping table according to the thread identifier to obtain the corresponding mapping table entry, locates the corresponding curve data entry in the curve data buffer according to the mapping table entry, and reads the particle generation time recorded in the curve data entry.

[0107] Since each execution thread is assigned a unique thread identifier at startup, which directly corresponds to the index of the particle to be processed, the thread can begin to perform data access operations based on this index.

[0108] The thread first uses its thread identifier as the address offset to access the curve mapping table stored in video memory. The curve mapping table can be understood as an array structure with particle indices as keys and storage locations as values. The thread directly reads the element at the corresponding position in the array using the index; this element is the starting index of the particle in the curve data buffer. After obtaining the starting index, the thread uses it as the new access address to jump to the corresponding position in the curve data buffer and begins reading data from that position. The curve data buffer stores curve data entries sorted by generation time. Each entry contains at least a particle generation time field. The thread extracts the particle's generation time from the read curve data entry and temporarily stores this value in the thread's register for subsequent activation judgment. This forms a two-level addressing path from the thread identifier to the mapping table entry and then to the curve data entry, allowing each thread to independently complete its access.

[0109] Step S3630: Based on the comparison between the starting value of the current simulation time and the particle generation time, determine whether the particle corresponding to the execution thread needs to be activated within the current simulation cycle.

[0110] After each execution thread finishes reading the curve data entry, it has obtained the generation time of the particle it is responsible for. At the same time, it passes the start time value of the current simulation cycle to all threads. This start time can be a value on the global timeline, such as the time accumulated since the particle system started, or it can be the local time for a specific cycle.

[0111] Each thread compares these two values. If the particle's generation time is less than or equal to the starting value of the current simulation time, it means the particle has reached or exceeded its birth time at this moment. Therefore, the thread determines that the particle needs to be activated within the current simulation cycle, and will continue to process the particle's state update. If the particle's generation time is greater than the starting value of the current simulation time, it means the particle's birth time has not yet arrived. The thread determines that the particle will not be activated for the time being, and can skip the subsequent processing of the particle within this cycle, or mark it as a waiting state. After the judgment is completed, each thread can decide whether to continue executing the subsequent point data sampling process based on the result.

[0112] Step S3640: Establish the association between the particle to be activated and the curve data entry, so that the corresponding particle can access the point data in the point data cache according to the starting index recorded in the curve data entry in each subsequent rendering frame.

[0113] When a thread determines that a particle needs to be activated, it needs to establish a persistent association between the particle and its corresponding curve data entry. This association involves maintaining a reference or index to the curve data entry within the thread's execution context. Specifically, the thread saves the starting index of the previously located curve data entry, or its index value in the curve data cache, in a thread-private register or local memory, serving as a fixed data anchor point for the particle throughout its lifecycle. In subsequent rendering frames, when the same thread processes the particle again, it no longer needs to perform two-level addressing through the curve mapping table. Instead, it directly uses this saved anchor point to quickly jump to the location of the curve data entry, extract the starting index, and then access the point data sequence in the point data cache.

[0114] This corresponding relationship accompanies the entire process of a particle from activation to extinction, simplifying the data access path for each frame from the initial multi-level addressing to a single direct jump, significantly reducing the overhead of repeated address calculations. At the same time, since each thread independently maintains the association information of the particles it is responsible for, all particles can also maintain their own data access channels in parallel without interfering with each other.

[0115] Through the synergistic effect of the above embodiments, this application achieves parallel initialization and data binding of the particle system within the graphics processor. By assigning an independent execution thread to each potentially generated particle and directly associating the thread identifier with the particle identifier, the state management of millions of particles can be performed in a large-scale parallel manner, fully leveraging the parallel computing capabilities of the graphics processor. Each thread independently accesses the curve mapping table and locates the corresponding curve data entry, reads the particle generation time and compares it with the current simulation time. This process is completed entirely within the video memory without the intervention of the central processing unit (CPU), avoiding the performance bottleneck of the CPU traversing the particle list frame by frame in traditional solutions. Furthermore, by establishing a persistent association between the particles that need to be activated and the curve data entries, particles in each subsequent rendering frame can directly and quickly access the point data cache through this association, eliminating repeated addressing overhead. Thus, this embodiment ensures that the large-scale particle system can complete particle selection and data binding for each frame with extremely low computational overhead during runtime, laying a solid foundation for parallel processing for the corresponding real-time sampling requirements.

[0116] Please see Figure 3 According to one aspect of this application, a particle motion information processing device includes a trajectory generation module 4100, an entry storage module 4200, a mapping establishment module 4300, and an information acquisition module 4400. The trajectory generation module 4100 is configured to downsample the original motion trajectory of each pre-acquired particle to generate a simplified motion trajectory corresponding to each particle. Each simplified motion trajectory consists of multiple point data arranged in chronological order. The entry storage module 4200 is configured to continuously store the point data belonging to the same simplified motion trajectory in a point data buffer in chronological order. For each simplified motion trajectory, a curve data entry containing particle generation time is generated, and the curve data entries are stored continuously in the curve data cache according to the particle generation time order. The mapping establishment module 4300 is configured to establish a curve mapping table based on the point data of the simplified motion trajectory corresponding to each curve data entry and the starting index in the point data cache. The information acquisition module 4400 is configured to load the point data cache, the curve data cache and the curve mapping table into the graphics processor memory to acquire the state information of the particle in the current frame based on the graphics processor memory.

[0117] Based on any embodiment of the device in this application, the information acquisition module 4400 includes: a particle determination unit, configured to traverse the curve data cache area in each rendering frame according to the particle generation time order based on the current timestamp, and determine the particles corresponding to curve data entries whose particle generation time is earlier than the current timestamp as the currently generated particles; a region positioning unit, configured to locate the corresponding point data cache area in the curve mapping table according to the age of each generated particle in the current rendering frame; and an information acquisition unit, configured to search for two adjacent point data adjacent to the age of the particle corresponding to the current timestamp based on the age order of the point data in the point data cache area, so as to acquire the state information of the particle based on the adjacent point data.

[0118] Based on any embodiment of the device in this application, the trajectory generation module 4100 includes: a sample acquisition unit, configured to acquire a plurality of sample points arranged in chronological order included in the original motion trajectory of each particle, wherein each sample point includes the position information and time information of the particle at a corresponding moment; and a trajectory conversion unit, configured to select corresponding key sample points from the plurality of sample points according to a preset simplification strategy, and convert the key sample points into the simplified motion trajectory composed of point data in chronological order, wherein the point data includes the position information of the corresponding key sample point and age information determined according to the time information.

[0119] Based on any embodiment of the device in this application, the entry storage module 4200 includes: a set extraction unit, configured to assign a corresponding trajectory identifier to each simplified motion trajectory, and extract multiple point data belonging to the same trajectory identifier into a corresponding point data set; a position determination unit, configured to write multiple point data in each point data set into the point data cache in age order based on the age information, and determine the starting index of each point data set in the point data cache; and an entry generation unit, configured to generate a curve data entry containing the correlation between the particle generation time and the starting index according to the starting index corresponding to each simplified motion trajectory and the generation time of the particle corresponding to the simplified motion trajectory, so as to write the curve data entry into the curve data cache.

[0120] Based on any embodiment of the device in this application, the mapping establishment module 4300 includes: an entry traversal unit, configured to traverse each curve data entry in the curve data buffer, and extract the particle generation time and the starting index recorded in each curve data entry; and a mapping construction unit, configured to determine the mapping table index value of each curve data entry according to the particle generation time, generate a corresponding mapping table entry using the mapping table index value as the key and the starting index as the value, and construct the curve mapping table based on the mapping table index value.

[0121] Based on any embodiment of the device in this application, the information acquisition module 4400 further includes: a region allocation unit, configured to acquire the storage capacity occupied by the point data cache, the curve data cache, and the curve mapping table in the system memory, and allocate a corresponding storage region in the graphics processor's video memory according to the storage capacity; an information transmission unit, configured to transmit the point data in the point data cache, the curve data entries in the curve data cache, and the mapping table entries in the curve mapping table to the corresponding storage regions in the graphics processor's video memory; and an index establishment unit, configured to establish an address index for the graphics processor to access the storage region, so that the graphics processor can locate the curve data entries according to the mapping table entries, and acquire the point data according to the starting index recorded in the curve data entries.

[0122] Based on any embodiment of the device in this application, it further includes: a thread allocation module, configured to allocate multiple execution threads corresponding to a preset maximum number of particles in the graphics processor, and bind a corresponding thread identifier to each execution thread, wherein the thread identifier is associated with a particle identifier; a time reading module, configured to have each execution thread access the curve mapping table according to the thread identifier to obtain a corresponding mapping table entry, locate the corresponding curve data entry in the curve data buffer according to the mapping table entry, and read the particle generation time recorded in the curve data entry; an activation determination module, configured to determine whether the particle corresponding to the execution thread needs to be activated in the current simulation cycle based on the comparison result between the starting value of the current simulation time and the particle generation time; and an association establishment module, configured to establish an association relationship between the particle that needs to be activated and the curve data entry, so that the corresponding particle accesses the point data in the point data buffer according to the starting index recorded in the curve data entry in each subsequent rendering frame.

[0123] Another embodiment of this application provides a particle motion information processing device. For example... Figure 4The diagram shows the internal structure of a particle motion information processing device. This device includes a processor, a computer-readable storage medium, a memory, and a network interface connected via a system bus. The computer-readable, non-volatile storage medium stores an operating system, a database, and computer-readable instructions. The database can store information sequences, and when executed by the processor, these computer-readable instructions enable the processor to implement a particle motion information processing method.

[0124] The processor of this particle motion information processing device provides computational and control capabilities, supporting the operation of the entire device. The device's memory can store computer-readable instructions, which, when executed by the processor, cause the processor to perform the particle motion information processing method of this application. The device's network interface is used for communication with a terminal.

[0125] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the particle motion information processing device to which the present application is applied. A specific particle motion information processing device may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0126] In this embodiment, the processor is used to execute... Figure 3 The specific functions of each module are described, and the memory stores the program code and various data required to execute the above modules or sub-modules. The network interface is used to realize data transmission between user terminals or servers. In this embodiment, the non-volatile readable storage medium stores the program code and data required to execute all modules in the particle motion information processing device of this application, and the server can call the server's program code and data to execute the functions of all modules.

[0127] This application also provides a non-volatile readable storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the particle motion information processing method of any embodiment of this application.

[0128] This application also provides a computer program product, including a computer program / instructions that, when executed by one or more processors, implement the steps of the method described in any embodiment of this application.

[0129] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a computer-readable storage medium such as a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM).

Claims

1. A method for processing particle motion information, characterized in that, include: The original motion trajectory of each pre-acquired particle is downsampled to generate a simplified motion trajectory corresponding to each particle, wherein each simplified motion trajectory consists of multiple point data arranged in chronological order; The point data belonging to the same simplified motion trajectory are stored continuously in the point data cache according to age order. A curve data entry containing the particle generation time is generated for each simplified motion trajectory. The curve data entries are stored continuously in the curve data cache according to the particle generation time order. Based on the point data of the simplified motion trajectory corresponding to each curve data entry, a curve mapping table is established using the starting index in the point data cache. The point data cache, the curve data cache, and the curve mapping table are loaded into the graphics processor's video memory. The state information of the particles in the current frame is obtained based on the graphics processor's video memory. This process includes: according to the current timestamp, traversing the curve data cache in each rendering frame based on the particle generation time order, identifying particles corresponding to curve data entries whose generation time is earlier than the current timestamp as currently generated particles; locating the corresponding point data cache in the curve mapping table based on the age of each generated particle in the current rendering frame; and searching for two adjacent point data points adjacent to the particle age corresponding to the current timestamp based on the age order of the point data in the point data cache, to obtain the particle's state information based on the adjacent point data.

2. The particle motion information processing method according to claim 1, characterized in that, The process involves downsampling the original motion trajectory of each pre-acquired particle to generate a simplified motion trajectory corresponding to each particle. Each simplified motion trajectory consists of multiple point data points arranged in chronological order, including: The original motion trajectory of each particle is obtained by acquiring multiple sample points arranged in chronological order, wherein each sample point includes the position information and time information of the particle at the corresponding moment; According to a preset simplification strategy, corresponding key sample points are selected from the plurality of sample points, and the key sample points are converted into the simplified motion trajectory composed of point data in chronological order. The point data includes the location information of the corresponding key sample points and the age information determined according to the time information.

3. The particle motion information processing method according to claim 2, characterized in that, The step of storing point data belonging to the same simplified motion trajectory consecutively in a point data cache according to age order, generating a curve data entry containing particle generation time for each simplified motion trajectory, and storing the curve data entries consecutively in a curve data cache according to the particle generation time order includes: Assign a corresponding trajectory identifier to each of the simplified motion trajectories, and extract multiple point data belonging to the same trajectory identifier into a corresponding point data set; Based on the age information, multiple point data in each point data set are written into the point data cache in age order, and the starting index of each point data set in the point data cache is determined. Based on the starting index of the point data set in the point data cache and the generation time of the corresponding particle, a curve data entry containing the correlation between the particle generation time and the starting index is generated, and the curve data entry is written into the curve data cache.

4. The particle motion information processing method according to claim 3, characterized in that, The step of establishing a curve mapping table based on the point data of the simplified motion trajectory corresponding to each curve data entry, using the starting index in the point data cache, includes: Traverse each curve data entry in the curve data cache area and extract the particle generation time and the starting index recorded in each curve data entry; The mapping table index value of each curve data entry is determined based on the particle generation time. The mapping table index value is used as the key and the starting index is used as the value to generate the corresponding mapping table entry. The mapping table entry is then used to construct the curve mapping table based on the mapping table index value.

5. The particle motion information processing method according to claim 4, characterized in that, The step of loading the point data cache, the curve data cache, and the curve mapping table into the graphics processor's video memory includes: Obtain the storage capacity occupied by the point data cache, the curve data cache and the curve mapping table in the system memory respectively, and allocate the corresponding storage area in the graphics processor video memory according to the storage capacity; The point data in the point data cache, the curve data entries in the curve data cache, and the mapping table entries in the curve mapping table are respectively transferred to the corresponding storage areas in the graphics processor's video memory. An address index is established for the graphics processor to access the storage area, so that the graphics processor can locate the curve data entry according to the mapping table entry, and obtain the point data according to the starting index recorded in the curve data entry.

6. The particle motion information processing method according to any one of claims 1-5, characterized in that, It also includes the initialization process for performing particle simulations in the graphics processor, which includes: Multiple execution threads corresponding to a preset maximum number of particles are allocated in the graphics processor, and a corresponding thread identifier is bound to each execution thread, wherein the thread identifier is associated with a particle identifier; Each execution thread accesses the curve mapping table according to the thread identifier to obtain the corresponding mapping table entry, locates the corresponding curve data entry in the curve data buffer according to the mapping table entry, and reads the particle generation time recorded in the curve data entry; Based on the comparison between the current simulation time's starting value and the particle generation time, determine whether the particle corresponding to the execution thread needs to be activated within the current simulation cycle; Establish an association between the particles that need to be activated and the curve data entries, so that the corresponding particles can access the point data in the point data cache in each subsequent rendering frame according to the starting index recorded in the curve data entries.

7. A particle motion information processing device, characterized in that, include: The trajectory generation module is configured to downsample the original motion trajectory of each pre-acquired particle to generate a simplified motion trajectory corresponding to each particle, wherein each simplified motion trajectory consists of multiple point data arranged in chronological order; The entry storage module is configured to continuously store the point data belonging to the same simplified motion trajectory in the point data cache according to age order, generate a curve data entry containing the particle generation time for each simplified motion trajectory, and continuously store the curve data entries in the curve data cache according to the particle generation time order. The mapping establishment module is configured to establish a curve mapping table based on the point data of the simplified motion trajectory corresponding to each curve data entry, using the starting index in the point data cache. The information acquisition module is configured to load the point data cache, the curve data cache, and the curve mapping table into the graphics processor's video memory, and acquire the particle's state information in the current frame based on the graphics processor's video memory. The acquisition of the particle's state information in the current frame based on the graphics processor's video memory includes: according to the current timestamp, traversing the curve data cache in each rendering frame according to the particle generation time order, and identifying particles corresponding to curve data entries whose generation time is earlier than the current timestamp as currently generated particles; locating the corresponding point data cache in the curve mapping table according to the age of each generated particle in the current rendering frame; and searching for two adjacent point data points adjacent to the particle's age corresponding to the current timestamp based on the age order of the point data in the point data cache, to acquire the particle's state information based on the adjacent point data.

8. The particle motion information processing device according to claim 7, characterized in that, The trajectory generation module includes: The sample acquisition unit is configured to acquire multiple sample points arranged in chronological order from the original motion trajectory of each particle, wherein each sample point includes the position information and time information of the particle at the corresponding moment. The trajectory conversion unit is configured to select corresponding key sample points from the plurality of sample points according to a preset simplification strategy, and convert the key sample points into the simplified motion trajectory composed of point data in chronological order, wherein the point data includes the location information of the corresponding key sample points and age information determined according to the time information.

9. A particle motion information processing device, comprising a central processing unit and a memory, characterized in that, The central processing unit is used to invoke and run a computer program stored in the memory to perform the steps of the method as described in any one of claims 1 to 6.

10. A non-volatile readable storage medium, characterized in that, It stores, in the form of computer-readable instructions, a computer program implemented according to any one of claims 1 to 6, which, when invoked by a computer, executes the steps included in the corresponding method.

Images