Collision detection processing method and device, equipment and medium

Abstract

The invention relates to a collision detection processing method and device, equipment and a medium. The method comprises the following steps: in response to a collision detection event triggered in a game scene, determining a first time window corresponding to the event based on a first thread; on the basis of a first timestamp corresponding to the first time window, acquiring spatial geometric information corresponding to all colliders contained in a detection range corresponding to the collision detection event; the second thread performs collision detection on each collision body according to the spatial geometric information, and returns a corresponding collision detection result to the first thread; and in response to a trigger event that the first time window reaches the second time stamp, the first thread determines whether collision occurs between the colliders based on the collision detection result. According to the method and the device, the collision detection calculation task is separated to the independent threads to be executed at the first timestamp, and the collision detection result is uniformly processed at the second timestamp, so that the accuracy and the stability of collision judgment logic are ensured while the game running efficiency is remarkably improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of game interaction, and in particular to a collision detection processing method and device, equipment and medium. BACKGROUND

[0002] In the field of games, collision detection is a basic and crucial technology. Its performance and logical correctness are directly related to the smoothness of the application and the user experience. The traditional collision detection scheme is usually integrated by default in the main execution thread of the application during game development. In each update cycle, after updating the positions and states of the collision bodies in the scene, the thread immediately calls the physics engine or detection module to calculate the spatial geometric relationship of the collision bodies that may have intersections to determine whether they have collided, and immediately executes the corresponding logical processing such as triggering damage calculation, playing sound effects, or changing the motion trajectory of the object according to the detection results.

[0003] However, collision detection itself is a computationally intensive task, especially when there are a large number of collision bodies in the scene and the geometric shapes are complex, the computational overhead will significantly occupy the resources of the thread, causing the time used by the thread to process user input, rendering, and other game logic to be compressed, which may cause problems such as a decrease in game frame rate or slow application response, affecting overall smoothness. And in a single collision detection cycle, the object may experience continuous displacement, and the traditional instant detection and processing mechanism will capture and respond to all collision states that occur during the displacement of the object. If the initial collision state and the final collision state of each object are the same in the interval between the game engine's processing of the front-end game scene based on background data, even if all the intermediate collision changes are calculated, it will not cause the game engine to update the corresponding game screen and background data processing, so this not only increases unnecessary computational burden, but also affects the stability and smoothness of the game.

[0004] Therefore, there is an urgent need for a collision detection processing method that can solve the above problems. SUMMARY

[0005] The present application aims to solve the above problems and provide a collision detection processing method and its corresponding device, equipment, non-volatile readable storage medium, and computer program product.

[0006] According to one aspect of the present application, a collision detection processing method is provided, comprising: In response to a collision detection event triggered in a game scene, determining a first time window corresponding to the event based on a preset first thread; Based on the first timestamp corresponding to the first time window, obtaining the spatial geometric information corresponding to all collision bodies contained in the detection range of the collision detection event; After a preset second thread performs collision detection on each of the colliders based on the spatial geometry information, the corresponding collision detection results are returned to the first thread. In response to the triggering event that the first time window reaches the second timestamp, the first thread determines whether a collision has occurred between each of the colliders based on the collision detection results.

[0007] According to another aspect of this application, a collision detection processing apparatus is provided, comprising: The event response module is configured to respond to collision detection events triggered in the game scene and determine the first time window corresponding to the event based on a preset first thread. The information acquisition module is configured to: acquire the spatial geometric information of all colliders included within the detection range of the collision detection event based on the first timestamp corresponding to the first time window; The collision detection module is configured such that: a preset second thread performs collision detection on each of the colliders based on the spatial geometry information, and then returns the corresponding collision detection result to the first thread; The result determination module is configured to: in response to a trigger event that the first time window reaches the second timestamp, the first thread determines whether a collision has occurred between each of the colliders based on the collision detection result.

[0008] According to another aspect of this application, a collision detection 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 collision detection 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] First, this application effectively solves the technical problem of excessive single-thread resource consumption by computationally intensive tasks in traditional solutions by separating the collision detection calculation task from the first thread and executing it asynchronously by an independent second thread. The second thread can be dedicated to processing spatial geometry information calculations, freeing the first thread from the heavy workload of real-time collision detection, thus significantly reducing its processing burden. This allows the first thread to have more resources to respond to user input, execute rendering tasks, and perform other core game logic in a timely manner, fundamentally improving the application's response speed and overall frame rate, and ensuring the smooth operation of the system. Second, this application innovatively solves the problem of logical redundancy and errors caused by responding to instantaneous intermediate states in traditional real-time processing mechanisms by setting a first time window and having the first thread uniformly process the collision detection results at a second timestamp. This ensures that logical judgment is only performed on the final collision state at the end of the first time window, automatically filtering out intermediate collision information that is invalid from the overall window perspective, generated during continuous object displacement. This not only eliminates unnecessary calculations and error triggers but also ensures the consistency between the collision processing logic and the final state of the frame cycle, thereby enhancing the stability of the application and the accuracy of its operating logic. Furthermore, the combination of the above-mentioned technical means also realizes the efficient collaboration and optimized allocation of computing resources within the game system. The first thread can be responsible for organization, coordination and final decision-making, while the second thread can focus on parallel computing. The two work closely together through a clear time window and result feedback mechanism. This architecture not only improves the processing efficiency of collision detection itself, but also provides a foundation for maintaining high performance and high logical reliability in complex dynamic scenarios, thereby optimizing the overall system performance and improving the user experience. Attached Figure Description

[0012] Figure 1 This application provides an exemplary network architecture; Figure 2 This is a schematic flowchart of one embodiment of the collision detection processing method of this application; Figure 3 This is a schematic block diagram of the collision detection and processing device of this application; Figure 4 This is a schematic diagram of the structure of a collision detection and processing device used in this application. Detailed Implementation

[0013] The technical solution of this application can be widely applied to various network architectures to adapt to different types and scales of game applications. In a network architecture such as... Figure 1In the typical network architecture shown, the player's terminal device accesses the game service cluster via the network. This cluster consists of multiple game servers 81. A microservice architecture manages and maintains the operational resources of these game servers 81, providing multiple service instances. Each service instance is responsible for a different service. For example, some service instances can be used to maintain the front-end service for the terminal device 80 to access the game, while others can each be responsible for the gameplay service of one or more maps in the game's world map, providing players with corresponding map dungeon gameplay. The player's terminal device 80 has a computer program product installed and running according to the character interaction control method of this application, or the terminal device can be connected to a cloud server container, where the computer program product runs. After the computer program product runs, it accesses the game service cluster, enabling the player to control their in-game character through the terminal device, interact with various service instances of the game, and explore and interact with different maps.

[0014] Each service instance can maintain a real-time connection with the player's terminal device 80 via the network, handling various events and interactions in the game, such as player character movement, attacks, and item usage. The server provides necessary data support to the terminal device to ensure smooth game operation. This data includes, but is not limited to, map model datasets, which contain map model data for each map and resource model data for its scene resources, such as buildings, player character models, non-player character models, and various other creature or non-creature models, used by the terminal device 80 to render and generate corresponding real-time images. Based on the received map model dataset, the terminal device 80 can generate high-quality real-time images and display them in the graphical user interface, presenting the corresponding game scene to the player. Players obtain visual information about the game through real-time images of the game scene, thereby implementing gameplay.

[0015] This application not only applies to the gaming experience for single players but can also be extended to multiplayer online game environments. In multiplayer games, multiple players' (users') terminal devices simultaneously connect to the game service cluster. Each service instance needs to handle interaction requests from multiple players and update the game status in real time. This application ensures that each player receives consistent and high-quality character interaction control in multiplayer game scenarios, while optimizing the resource utilization of servers and terminal devices and improving the overall operational efficiency of the game system.

[0016] In an exemplary application scenario of this application, consider a massively multiplayer online role-playing game (MMORPG) where players can freely explore a vast open-world map and control their character to enter various specific dungeon maps to complete quests. In this game, the player character can frequently switch between different maps, such as switching from a bustling city map to a mysterious dungeon map, or from one room to another.

[0017] The technical solutions involved in this application can be deployed in various virtual environment systems requiring real-time physical interaction, including but not limited to video games, virtual reality applications, simulation training platforms, and interactive 3D visualization systems. In these systems, collision detection is a core technical component ensuring the realism and logical correctness of the interaction. A typical system relies on one or more execution threads to collaboratively complete tasks such as scene updates, logical calculations, and rendering output during runtime. The main logic flow, responsible for handling user input, maintaining scene state, and driving screen rendering, typically runs in an execution context called the first thread or main thread. To optimize performance, the system can allocate specific computationally intensive tasks, such as complex spatial geometric calculations, to a separate second thread for asynchronous execution. This division of labor and collaboration among threads provides the basic operating environment for the implementation of the technical solutions in this application.

[0018] In the exemplary implementation scenario of this application, all entities within the virtual environment capable of participating in collision interactions can define their physical extent in space through their associated colliders. The spatial geometry information of the collider typically includes its position coordinates, rotational orientation, and volume data describing its boundary shape. This information is determined at the beginning of each logical update cycle and remains stable until the end of the cycle. The game system's time management module is responsible for driving these discrete logical update cycles. For example, the frame loop mechanism commonly used in game applications can be considered as a typical logical update cycle. Each cycle has a definite start and end time, thereby providing a timing reference for precisely controlling the triggering of collision detection and the timing of result processing.

[0019] The fundamental concepts involved in this application mainly include inter-thread cooperation mechanisms, logical update cycles, colliders and their spatial geometric information. Inter-thread cooperation mechanisms refer to a model where different execution threads are responsible for data preparation, calculation, and result processing respectively, and data is transmitted through a communication mechanism. The logical update cycle is a discrete-time unit for the state evolution of the game system, with its boundaries marked by specific timestamps. A collider is an abstract representation of a virtual object participating in physical interactions, while spatial geometric information is a snapshot of its spatial attributes at a certain moment. These concepts together constitute an exemplary basic framework for implementing the various steps of the technical solution in the embodiments of this application.

[0020] 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.

[0021] Please see Figure 2 The collision detection processing method of this application, in some embodiments, includes the following steps: Step S3100: In response to a collision detection event triggered in the game scene, determine the first time window corresponding to the event based on a preset first thread.

[0022] During gameplay, especially in large-scale role-playing games, players typically control their characters to move, attack, or interact with various objects in a virtual game environment using input devices. From the game's visual perspective, players observe smooth movement of characters and objects in the environment. However, at the backend logic level, every movement of the character, every bullet fired, every item picked up, and even game entities with colliders in the game environment, requires determining whether they have come into contact with other collideable elements in the game scene. This determination process can be called collision detection. When the game logic determines that such a contact check is required, a collision detection event is triggered. For example, when a player presses a button to make the character jump, it is necessary to continuously check whether the character has made contact with the ground to determine when to play the landing animation; or when a projectile fired by the player is flying, it is necessary to check at regular intervals whether it has hit an enemy or obstacle. These needs for contact checks, directly driven by gameplay logic, are typical triggers for collision detection events.

[0023] In this implementation, the first thread is the main logical execution flow of the game program. It is responsible for coordinating and processing the core loop of the game, including but not limited to receiving real-time input from the player, updating the state of all game objects, and finally submitting the updated scene to the graphics rendering pipeline to be drawn on the screen. Therefore, it can be understood as the command center for the operation of the game world. When a collision detection event is triggered, this command center needs to allocate a processing time period for it; this time period can be considered the first time window. Therefore, the first time window can be configured as a logical time interval that defines the data validity boundaries and processing time limits related to this collision detection event.

[0024] Because the game engine continuously monitors the current game scene interactions during gameplay, the first thread acts as the core logic scheduler in the real-time interaction system. It maintains a regular timer based on a high-precision timer or system clock. This timer divides the continuous flow of time into a series of discrete yet coherent logical update intervals. Each interval marks a cycle in which the system reviews and evolves its global state. When a collision detection event is triggered, the first thread immediately sets a processing time limit for the event based on its current logical update timer; this time limit is the first time window.

[0025] In one implementation, the first time window can be determined by pre-setting a first thread to capture the start point of the current logical update interval where the event triggers, and defining the entire time period from this start point to the end point of the interval as the first time window for processing the event. For collision detection events that require continuous monitoring, such as a long-term existing region trigger, the pre-set first thread will identify the persistence attribute of the event and extend the end point of the first time window to the end points of several subsequent logical update intervals, thus forming a longer composite time window covering multiple intervals. Therefore, whether the collision detection event is transient or persistent, all related data acquisition, calculation, and decision-making are anchored within a clear time frame synchronized with system logical updates, ensuring temporal consistency of the scene state upon which the relevant data processing depends.

[0026] Step S3200: Based on the first timestamp corresponding to the first time window, obtain the spatial geometric information of all colliders included within the detection range of the collision detection event.

[0027] From a purely visual perspective, players are unaware of the data preparation work done in the background to determine object contact when controlling their characters in the scene. However, when collision detection events are triggered, such as a character trying to push open a door, a bullet flying towards a target, or a character about to fall to the ground, accurate snapshot data needs to be collected for this determination. The snapshot data must be frozen at a specific and consistent moment to ensure that the position and shape information of all detected objects correspond to the same instant, avoiding temporal errors caused by continuous object movement. This selected moment can be configured as the first timestamp corresponding to the first time window. The determination of the first timestamp serves as the timing reference for all subsequent data collection. In one implementation, the starting point of the first time window can be directly defined as the first timestamp; in another implementation, considering that the first thread needs to fine-tune the state of all relevant colliders, such as completing the initial calculation of the physics simulation, the first timestamp can also be determined as the moment when all involved colliders within the first time window complete their current state update and reach a logically static state. The time corresponding to the first timestamp may be slightly later than the start of the window, but it must be earlier than the end of the window. This allows us to establish a globally unified and logically consistent current time for this collision detection event.

[0028] In this implementation, after determining the first timestamp, it is also necessary to specify which spatial region in the scene is of interest in this collision detection event. This spatial region is the detection range. The determination of the detection range is directly related to the source of the triggering event. For example, if the collision detection event is triggered by a bullet fired by a player, the detection range can be a narrow spatial region with a certain tolerance radius centered on the predicted trajectory of the bullet. If the event is triggered by a treasure chest trigger in a fixed location, the detection range is usually the space defined by the shape of the chest itself. In some cases, the detection range can also be dynamically calculated. For example, based on the character's movement speed and direction, the area that the character may reach in the next moment can be predicted, and a three-dimensional spatial boundary can be calculated as the detection range corresponding to the current first time window according to preset rules or parameters attached to the event.

[0029] In one implementation, a spatial filtering process can be performed on all active colliders in the scene based on the detection range. The spatial filtering process is usually accomplished by querying the scene management data structure of the game engine, such as a spatial segmentation tree or a hierarchical bounding box tree. This can efficiently find all colliders that have potential spatial intersection with the detection range. These filtered colliders constitute the target set that needs to be specifically calculated and analyzed for this collision detection event.

[0030] For each selected collider, its spatial geometric information at the first timestamp is further collected. This spatial geometric information can be a set of data precisely describing the space occupied by the collider in the three-dimensional world. It can be configured to include the position and volume information of all colliders. The position information includes at least the center coordinates of the collider in the world coordinate system and may also include its rotation orientation. The volume information defines the spatial contour of the collider; for simple shapes such as spheres, cubes, or capsules, it records parameters such as radius and side length; for complex mesh colliders, it points to a data structure defining its surface vertices and triangular faces. By reading the state snapshot of each collider at the first timestamp, or by interpolating its motion trajectory with the first timestamp, these corresponding geometric data can be obtained. Thus, the spatial geometric information corresponding to all the colliders can collectively constitute a time-consistent and well-defined set of spatial geometric information.

[0031] Step S3300: After the preset second thread performs collision detection on each of the colliders based on the spatial geometry information, the corresponding collision detection results are returned to the first thread.

[0032] In the game's background system, once the first thread completes the determination of the first timestamp and the acquisition of spatial geometric information of the relevant colliders, the spatial geometric information is ready for substantive contact judgment calculations. However, placing this computationally intensive task directly in the first thread can block it from processing other critical logic in complex game scenes, especially if the first thread also has tasks requiring high-precision rendering. This can lead to game stuttering or delayed operation response, significantly reducing the player's gaming experience. Therefore, the game system needs to be able to utilize a dedicated second thread to handle this calculation.

[0033] In this embodiment, the second thread is one or more worker threads dynamically allocated from the general computing thread pool maintained by the game system or game engine. These worker threads are temporarily allocated and specifically used to execute the computing tasks for this collision detection event, forming a high-priority computing unit that runs independently of the first thread. When the second thread acts as a computing unit, it can be an independent thread or a thread group in which multiple threads work together. It can be given a high computing priority and is used to specifically handle background computing tasks such as physics simulation, path planning, animation skeleton calculation, particle system updates, texture loading, audio decoding, or collision detection as in this embodiment. Through the above-mentioned dynamic allocation and specialized execution, the second thread can achieve efficient parallel work with the first thread, which is responsible for the main loop and real-time response, thereby significantly improving the overall resource utilization and computing throughput of the system.

[0034] After preparing a complete set of spatial geometry information, the first thread will pass this data to the second thread through an inter-thread communication mechanism. In a common implementation, the first thread will put the data packet containing all relevant collider identifiers and their corresponding spatial geometry information into a memory queue or buffer that is shared by both threads and has thread-safe characteristics. In another implementation, the first thread can directly call an asynchronous computing interface provided by the second thread and pass the data packet as a parameter to ensure that the second thread can safely and completely obtain the spatial geometry information required for this collision detection.

[0035] In one implementation, upon receiving spatial geometric information, the second thread immediately begins executing a collision detection algorithm. The second thread iterates through the set of colliders selected by the first thread, determining pairwise whether there is geometric overlap or contact between them in three-dimensional space based on their position and volume information. The detection algorithm can be selected based on the shape complexity of the colliders. For simple colliders such as spheres or cubes, for example, calculating whether the distance between the centers of two spheres is less than the sum of their radii, the second thread can directly use mathematical formulas to solve the problem. For complex mesh colliders, a more accurate but computationally more computationally intensive separating axis theorem can be used for facet-by-face detection, or a simplified bounding box can be used for rapid coarse elimination. Thus, the second thread can systematically perform calculations on all collider pairs that need to be detected.

[0036] After completing all necessary calculations, the second thread generates a structured collision detection result. This result identifies at least which colliders occurred at the corresponding time point of the first timestamp and records the collider pair identifiers in a list. More specifically, the collision detection result may also include additional information such as the collision depth, collision point location, and normal direction between game entities, which can be used for subsequent collision response processing such as dodging, bouncing, or blocking. After generating the collision detection result, the second thread needs to send it back to the first thread. This can be configured to be similar to the data transfer process but in the opposite direction. For example, the second thread writes the result to another shared safe buffer, or notifies the first thread that the data is ready by setting a flag and a callback function. Thus, the first thread can directly obtain and use this collision detection result asynchronously calculated by the second thread, thereby achieving separation of computational load and optimized utilization of system resources.

[0037] Step S3400: In response to the trigger event that the first time window reaches the second timestamp, the first thread determines whether a collision has occurred between each of the colliders based on the collision detection result.

[0038] In this embodiment, during the game system's runtime sequence, since the first time window defines the complete cycle from the issuance of the collision detection task to the final result being processed, the second timestamp is the critical moment at the end of this cycle, marking the last point in time when the first thread must begin processing the collision result. The determination of the second timestamp is closely related to the boundary of the first time window. In one embodiment, the second timestamp is directly set as the preset end time of the first time window, such as the cutoff point of the current logic update interval defined by the game engine's main loop. In another embodiment, considering that the actual completion time of the second thread's calculation task may fluctuate, the second timestamp can also be supplemented with a short, forgiving delay based on the end of the first time window, but this delay is strictly controlled to ensure real-time processing.

[0039] When the system time or the internal timer of the first thread reaches the second timestamp, a specific trigger event is generated. The first thread continuously monitors this trigger condition, and once the condition is met, it responds to the event and begins processing the collision detection results. This ensures the deterministic timing of the result processing actions and avoids introducing additional logical delays or unstable frame rates due to arbitrary processing timing. After responding to the corresponding trigger event, the first thread first attempts to obtain the collision detection results generated by the second thread. Since the two use asynchronous communication, the first thread needs to check predetermined interaction areas such as shared memory areas, thread-safe queues, or specific result flags to confirm whether the results are ready. If the results are ready, the first thread reads them completely. If the results have not yet returned, the first thread can poll and wait within a very short timeout period according to a preset strategy, or directly perform subsequent processing based on the current default state of no collisions, ensuring that the main loop is not blocked.

[0040] After successfully acquiring the structured collision detection results data, the first thread can begin parsing it and making a final judgment. The corresponding detection results data includes a snapshot of the spatial relationships between all detected colliders at a previously determined and unified first timestamp. The first thread then interprets this snapshot, determining one by one whether there is geometric overlap between the entities corresponding to each pair of collider identifiers in the list. For example, the parsing program reads each entry in the results list; if an entry indicates that two colliders have collided, the first thread determines that the game objects represented by these two colliders have made contact; otherwise, if the entry does not exist, it is determined that there is no contact.

[0041] Based on the above analysis and judgment, the first thread ultimately determines whether a collision has occurred between each colliding entity. This determination can be more than just a Boolean value judgment; it can also be transformed into game logic driving signals. The first thread sets a corresponding logic trigger flag for each pair of entities determined to have collided, or adds them to the list of pending collision events. The corresponding logic trigger flags and collision event lists will be consumed by the gameplay system, such as the damage calculation module, sound effect trigger module, or physics response module, during the remaining time of the current logic update cycle, thereby driving specific game behaviors such as character health deduction, playing hit effects, and changing the direction of object movement. Thus, by centralizing the final result processing power in the first thread and executing it uniformly at the second timestamp, the game system naturally filters out all transient and intermediate collision states that may occur during the movement of objects within the first time window, only adopting and responding to the final spatial relationship at the end of the window, thereby ensuring the consistency and efficiency of the logic.

[0042] In an exemplary game scenario, if a fast-moving object and another object are not in contact at the beginning of a time period, geometrically overlap at a certain instant within that period, and then separate again at the end of the period, and if this corresponding time period is less than or equal to the minimum interval for game visuals and data processing, especially if a large number of colliding objects collide multiple times within this time period, then before and after this minimum interval, the game system does not need to update the game visuals or process collision data for the corresponding object collisions. Therefore, the collision detection data generated during this period does not need to be used by the game engine. Consequently, if the game engine performs real-time detection of all entity collisions, not all of the calculated collision detection data will be usable. This can be considered useless, which not only wastes the game engine's computing resources but also creates unnecessary data redundancy, thus affecting game system performance and reducing the user's gaming experience.

[0043] As demonstrated by the above examples, by separating the collision detection calculation process into the first thread and the result processing process into the second thread, the efficiency degradation caused by the main thread performing a large amount of computation in traditional methods can be effectively solved. By having the second thread specifically responsible for traversing and calculating the spatial geometry information of all colliders, the first thread is not blocked by potentially heavy computational tasks, allowing more resources to be devoted to processing user input, game logic, and screen rendering, ultimately improving the game's frame rate and responsiveness. Furthermore, by setting a clear first time window and a second timestamp, this embodiment uniformly arranges the final processing time of the collision result at the end of the first time window. This ensures that the game logic only reacts based on the final collision state at the moment the window ends. As a result, the brief and invalid intermediate collision states caused by the continuous movement of objects within the same window can be naturally omitted. If a fast-moving object makes a momentary geometric overlap with the target during the process but eventually leaves, the technical solution of this application will only judge the final non-collision state and will not make any unnecessary logical response to the intermediate overlap state. This avoids the erroneous game logic caused by these invalid states, such as incorrect damage judgment or sound effect triggers, and also saves the computing resources required to process these invalid logics. Thus, while improving performance, it further enhances the stability of game operation and the accuracy of logic.

[0044] Based on any embodiment of the method in this application, in response to a collision detection event triggered in a game scene, a first time window corresponding to the event is determined based on a preset first thread, including: Step S3110: In response to the game engine's logic update operation on the game scene, the collision detection event is triggered.

[0045] In this embodiment, the game engine serves as the core driving system of the entire game program. According to its internal timing mechanism or external vertical synchronization signal, it periodically initiates the recalculation and advancement of the states of all objects in the game scene. This process is the logical update operation of the game scene. Each such operation marks a discrete step forward in the game world's simulated time. In this step, the game engine processes user input, executes script code, updates the positions, rotations, and scaling transformations of objects, and calculates intermediate states of the physical simulation.

[0046] During this logic update operation, the game logic itself determines whether to initiate one or a series of spatial contact checks based on the latest scene state. This judgment can serve as a direct cause for triggering a collision detection event. For example, after updating the positions of all characters, a game logic module responsible for managing the combat system will check if any characters are performing attack actions. Or, after updating the flight trajectories of all bullets, a module responsible for managing bullet trajectories will determine whether these bullets have reached the point where a hit detection is required. Alternatively, it may simply be a cause for triggering a collision detection event at the beginning of each game frame, according to the game's frame rate configuration. This judgment logic can be embedded in the gameplay rules. When a pre-defined condition, such as an attack animation playing to a specific frame, a bullet having moved a certain distance since the last detection, or the current arrival at a new game frame, is met, the corresponding logic module will proactively generate a collision detection event. A collision detection event can essentially be a data structure containing the detection intent, contextual information, and necessary parameters, which can be submitted to subsequent collision processing flows, announcing that a specific collision detection requirement has been generated. Therefore, the triggering of collision detection events closely follows the core logic update rhythm of the game engine, and is initiated proactively by the gameplay logic at a precise time, thereby ensuring the synchronization of collision detection and the evolution of the game state.

[0047] Step S3120: The first thread determines the corresponding logical update period based on the logical update operation, and sets the logical update period as the first time window.

[0048] In this implementation, the first thread is the execution sequence within the game application responsible for coordinating and driving the core game loop. It handles key decision-making and scheduling tasks throughout the entire process, from receiving external input to finally submitting rendering data. This includes processing user commands, calling game logic scripts, and managing collaboration between subsystems. Logic update operations are a set of periodically executed instructions initiated by the game engine. Essentially, they serve as discrete steps driving the evolution of the game's virtual world state. Each logic update operation represents a comprehensive recalculation and update of the current position, state attributes, and internal logic of all dynamic entities within the game, such as characters, objects, and effects.

[0049] When the first thread detects or is performing a logical update operation, it defines a complete time period based on the start and end times of this operation. This time period is called the logical update cycle. The logical update cycle precisely corresponds to the total processing time that the game world state undergoes from one stable snapshot to the next stable snapshot. The first thread can determine this cycle in several ways, such as directly reading the engine's global timer at the two points in time when the update operation begins and is marked as complete, or obtaining the fixed time slice span allocated to this update by the engine's core scheduler.

[0050] After clearly defining the start and end times of the current logic update cycle, the first thread immediately sets this entire time period as the first time window for processing the current collision detection event. All data collection and final result processing related to the corresponding collision detection event based on a specific moment within the window are limited and arranged to be completed within the time boundary covered by this logic update operation. Thus, by binding the first time window with the logic update cycle, it is ensured that the triggering, calculation and response phases of collision detection can be strictly aligned with the atomic steps of game state updates, thereby maintaining the consistency of the game world in terms of physical interaction judgment and overall logical evolution in terms of timing.

[0051] Through the above implementation, the generation of collision detection events can be precisely anchored within the logical update operations driven by the game engine. This ensures that the generation of any collision detection request is strictly aligned with the refresh of the game world state, fundamentally avoiding improper detection timing caused by external random timing or rendering loops. It guarantees that each detection request is based on the latest and consistent scene data, thereby reducing unnecessary detection attempts and timing errors. Furthermore, by having the first thread directly set the complete cycle corresponding to the logical update operation as the first time window, the processing of the collision detection task is constrained to a discrete time unit matching the game frame or logical step size. This establishes a clear time boundary for the entire detection process, ensuring that subsequent data acquisition and result processing clearly correspond to the same logical update state. This not only guarantees that the scene state upon which collision judgment is based is a snapshot at the same moment, avoiding contradictory judgments caused by data time misalignment, but also allows the collision processing logic to be coordinated with other core modules of the game, such as animation and skill systems, within the same cycle. This improves the synchronization and predictability of the overall game logic, providing a foundation for the stable operation of complex interactions.

[0052] Based on any embodiment of the method in this application, and based on the first timestamp corresponding to the first time window, spatial geometric information corresponding to all colliders included within the detection range of the collision detection event is obtained, including: Step S3210: Determine the time when all colliders complete state synchronization within the logical update cycle as the first timestamp.

[0053] Because the logic update cycle during game system operation is a complete processing period driven by the game engine to advance the virtual world state from the current moment to the next, it can be regarded as a basic time unit for discretized simulation. During this period, the internal logic and external behavior of all game objects are recalculated. A collider is a logical component attached to a game object, defining the spatial shape and extent occupied by the object in physical interactions, such as a sphere, a cuboid, or a more complex mesh profile. The collider itself is not directly responsible for drawing, but is specifically used to participate in the calculation of spatial relationships. State synchronization refers to the process by which the first thread coordinates various subsystems, such as the animation system, physics simulator, and script logic, to update the attributes of all active colliders in the scene within a single logic update cycle. The corresponding state attributes mainly include its position and rotation angle in world space, and sometimes its shape parameters. The goal of state synchronization is to ensure that at a specific moment within the cycle, each collider calculates its final and consistent spatial attributes based on the logic of the current frame, without some colliders still using data from the previous frame while others have been updated to the new data.

[0054] In this implementation, the first thread monitors and waits for the state synchronization processing of all relevant colliders to be completed within the current logical update cycle. A stable point in time is reached when the spatial attributes such as position and rotation of all colliders have been calculated and updated to a unified new state. The first thread captures and records this instant, determining it as the first timestamp corresponding to this collision detection event. This moment typically occurs after the start of the logical update cycle and before its end. By using this synchronization completion moment, rather than the cycle start point, as the timestamp, it ensures that the data collected for each collider accurately reflects the world state at the same instant, based on the same round of logical calculations.

[0055] Step S3220: Determine the target space range to be detected based on the interactive object associated with the collision detection event, and filter out all colliders within the range from the scene management system based on the target space range.

[0056] In game logic, each collision detection event is triggered by one or more game entities interacting in the current game scene. The corresponding game entities can be identified as interaction objects. Based on these specific interaction objects, the physical space area requiring collision detection can be further defined. First, the interaction objects associated with the collision detection event are analyzed. Based on the object's type and state, the target space range to be detected is calculated. The target space range is a region in three-dimensional space. For example, for a melee attack, the target space range might be defined as a fixed-dimensional fan-shaped or cubic region in front of the attacker, its position and orientation entirely determined by the attacker's current state. For a missile in flight, the target space range might be a spherical region with a certain radius centered on its current position, used to detect the instantaneous impact range of its explosion. In some cases, the target space range can also be set as a circular region at a certain distance around the current player character. That is, the target space range is determined as a static, predefined shape region within the first time window, thereby determining the parameters based on the preset skill, weapon, or effect configuration data associated with the interaction object.

[0057] Once the geometry and spatial location of the target space are clearly defined, all colliders that may come into contact with that space can be identified. The game engine's scene management system maintains a spatial index of all active colliders. This spatial index can be implemented using a tree structure such as a boundary volume hierarchy tree, a spatial quadtree, or an octree, which can quickly answer queries about which objects exist within a given spatial region. The calculated target spatial range is then submitted to the scene management system as a query condition. The scene management system uses its spatial index structure to efficiently traverse and compare the spatial locations and boundaries of all registered colliders, ultimately filtering and returning a list containing all colliders whose boundary volumes intersect with or may come into contact with the target spatial range. These filtered colliders constitute the specific target set requiring precise collision calculations. This avoids the overhead of traversing all colliders in the scene, instead concentrating computational resources on objects within the local spatial regions where interaction is most likely.

[0058] Step S3230: Collect the spatial geometric information of each selected collider at the first timestamp, wherein the spatial geometric information includes position coordinate data and boundary volume data.

[0059] Once all colliders within the target space are selected from the scene management system, a complete spatial state description of each collider at a specific instant needs to be obtained. This specific instant is the previously determined first timestamp. The obtained description information is called the spatial geometry information of the collider, which includes position coordinate data for location and boundary volume data for shape description.

[0060] In this embodiment, the position coordinate data records the spatial orientation of the collider in the global coordinate system of the game world. It can be a three-dimensional coordinate value representing its center point or a specific anchor point. For asymmetric or oriented colliders, the position coordinate data will also include a value representing its rotational attitude, such as a quaternion or a set of Euler angles, thus fully defining its placement position and orientation. The boundary volume data defines the spatial outline and size occupied by the collider itself. Its composition depends on the preset geometry of the collider. For basic shapes, such as spheres, the boundary volume data can be a single radius value; for cuboids, it can be three scalars: length, width, and height; and for capsules, it can be two parameters: radius and height. For more complex colliders defined using polygonal meshes, its boundary volume data can also be associated with a set of vertices and faces that define its surface shape, or a simplified bounding box parameter for fast calculation.

[0061] For each selected collider, its position coordinates and boundary volume data at the first timestamp are actively acquired, thus obtaining the corresponding spatial geometric information. Since the state of the collider may change over time, it is necessary to obtain information based on a locked, unified time. After synchronizing the states of all colliders, the game engine stores their final positions and shape data at the first timestamp in a temporary structure. The acquisition program accesses this structure and retrieves the corresponding data based on the collider's unique identifier.

[0062] In one implementation, for an object in continuous motion, interpolation can be performed based on its recorded motion trajectory and first timestamp to calculate the position coordinate data at that precise moment in real time, while the boundary volume data is directly read from the object's static properties, so that all colliding bodies have accurate spatial geometric information based on the same moment.

[0063] The above embodiments construct an efficient and reliable pre-processing workflow for collision detection through precise timing control and data acquisition. First, by selecting the moment when all collider states are synchronized as a unified time reference, it ensures that all spatial information used for subsequent calculations corresponds to the same logical instant, effectively avoiding potential discrepancies in judgments caused by asynchronous data timing. The spatial boundaries for detection are defined based on specific interaction objects, and a highly efficient spatial indexing structure is used to quickly filter out relevant colliders, focusing calculations on local areas where events may occur, significantly reducing the number of irrelevant objects to be processed and improving overall computational efficiency. Finally, by acquiring the precise position and shape data of each selected collider at the same reference time, a complete and internally consistent set of spatial geometric information is formed, providing accurate input for subsequent precise collision calculations. This ensures both the timeliness of processing, the accuracy of calculations, and the rational utilization of system resources at the data source.

[0064] Based on any embodiment of the method in this application, after a preset second thread performs collision detection on each of the colliders according to the spatial geometry information, the corresponding collision detection result is returned to the first thread, including: Step S3310: The first thread sends the collected spatial geometric information to the second thread.

[0065] After the first thread completes the acquisition and encapsulation of the spatial geometry information of the relevant colliders, it needs to pass the input data required for these computational tasks to the second thread, which is specifically responsible for executing the computations. The first thread, acting as the scheduler of the entire process, can organize the spatial geometry information it has acquired into a structured dataset containing the identifiers of all selected colliders and their corresponding position coordinates and boundary volume data. To pass this dataset to the second thread, which runs in an independent execution flow, an inter-thread communication mechanism is required.

[0066] In one implementation, the first thread places the encapsulated data set into a thread-safe shared memory block or message queue provided by the operating system or game engine. This shared area is designed to allow multiple threads to access it in an orderly manner, ensuring that the data is not corrupted due to concurrent operations during writing and reading. The completion of the write operation by the first thread is considered the completion of the send operation.

[0067] In another implementation, the second thread can provide an asynchronous processing interface. The first thread passes this dataset as a parameter to the interface through a function call. Thus, the interface call will not block the continued execution of the first thread, while the second thread will receive these parameters in its own execution context and begin processing.

[0068] Step S3320: When the second thread receives the spatial geometry information, the second thread executes a preset collision detection algorithm on the spatial geometry information to generate a corresponding collision detection result indicating whether there is geometric overlap between each collider based on the output result of the collision detection algorithm.

[0069] Once the second thread successfully obtains the spatial geometry information data packet sent by the first thread through mechanisms such as shared memory areas, message queues, or asynchronous interface callbacks, the second thread can then process the spatial geometry data accordingly. In this embodiment, the second thread first parses the received data packet to reconstruct a list of all colliders participating in the detection, as well as the position coordinates and boundary volume data corresponding to each collider. Subsequently, the second thread calls its internally pre-built collision detection algorithm. The collision detection algorithm can be a set of optimized mathematical calculation processes designed to determine whether two 3D geometric objects are in contact or penetrating each other in space. The specific execution process of the collision detection algorithm is adapted according to the boundary volume data type of the collider. For basic geometric shapes such as spheres or axially aligned bounding boxes, efficient analytical formulas can be used directly for calculation, such as comparing the sum of the distance between the centers of two spheres and their radii. For slightly more complex shapes such as oriented bounding boxes and capsules, a fast verification method based on the separating axis theory is used. For the most complex convex mesh shapes, the algorithm can perform more time-consuming facet-by-face detection, but in practice, its simple outer bounding body can be used for rapid culling to improve efficiency. The second thread will execute the collision detection algorithm on all the collider combinations in the list that need to be detected, according to the predetermined pairing rules.

[0070] Each pairwise collision detection calculation produces a clear Boolean conclusion: overlap or no overlap. The second thread collects all these binary conclusions, recording all collision pairs determined to overlap in a structured list. This list serves as part of the collision detection result. Furthermore, according to pre-defined detailed development requirements, the collision detection algorithm can calculate additional geometric information such as penetration depth, contact point location, and contact surface normal direction while calculating overlap. The second thread associates this additional information with the corresponding collision pairs, encapsulating them into a complete collision detection result output.

[0071] Step S3330: When the second thread obtains the collision detection result, the second thread sends the collision detection result to the first thread.

[0072] After the second thread completes the collision detection calculation and generates a structured collision detection result, it returns this result to the first thread for subsequent logical processing. This can be accomplished through inter-thread communication in the opposite direction of data transmission. The second thread writes the encapsulated result data into a pre-negotiated thread-safe storage area accessible to the first thread. This area can be the same shared memory area or message queue used when sending data, or it can be a separate channel dedicated to returning results to avoid read-write confusion. The corresponding write operation marks the completion of the transmission action. In another implementation, the second thread can also notify the first thread that the result is ready by setting an atomic flag or triggering a synchronization event, and store the result data in a specified memory location accessible to the first thread.

[0073] The synergistic effect of the above embodiments ensures data transfer and computational collaboration between the first and second threads, bringing clear technical benefits. By asynchronously sending the prepared spatial geometry information to the second thread from the first thread, the main logic flow can immediately continue executing other critical tasks without waiting for time-consuming detection calculations, thereby reducing the blocking time of the main thread and ensuring the smoothness and responsiveness of the game. The second thread executes the preset collision detection algorithm in a dedicated computing environment, which can make full use of the parallel computing capabilities of multi-core processors to complete complex geometric overlap analysis more efficiently, increasing the amount of data processed per unit time. Finally, the second thread sends the calculated collision detection results back to the first thread, so that accurate physical interaction judgments can be integrated into the main game logic in a timely manner, ensuring a reliable connection between asynchronous calculations and the main logic loop. Thus, this embodiment not only optimizes system resource allocation by transferring computational load, but also ensures the stability and efficiency of the data processing flow through standardized inter-thread communication, thereby improving collision detection processing capabilities while maintaining the integrity and timing correctness of the overall game logic.

[0074] Based on any embodiment of the method in this application, in response to a triggering event that the first time window reaches the second timestamp, the first thread determines whether a collision has occurred between each of the colliders based on the collision detection result, including: Step S3410: When the logical update cycle of the first time window reaches its end time, the second timestamp is determined based on that time.

[0075] The first time window can be configured to be associated with a logical update cycle. A logical update cycle is a complete time unit for the game engine to advance the virtual world state, with a clearly defined start and end point. This end point is the end time of the logical update cycle, which can be defined and notified by the engine's core scheduler or timing module. It signifies that a complete state calculation and synchronization has been completed, and the processing of the next cycle is about to begin. During the first thread's response and transformation to this end time, the first thread continuously monitors the game engine's scheduling signals or internal timers. When it is notified or detected that the current logical update cycle has reached its preset end point, it immediately captures this moment. Subsequently, the first thread formally establishes this captured moment value as the second timestamp required to process this collision detection event.

[0076] One specific implementation for determining the second timestamp is that the first thread directly uses the end time of the logical update cycle itself as the second timestamp, so that the result processing is completely synchronized with the end of the cycle. In another implementation, considering that there may be a very short system scheduling delay between the end of the cycle and the start of result processing, the first thread will add a small, fixed time offset to the end time, and use the corrected time as the second timestamp. The corresponding offset is strictly controlled to ensure that the processing is still considered to be completed within the same logical cycle.

[0077] Step S3420: In response to the triggering event, the first thread obtains the collision detection result returned by the second thread, performs collision parsing based on the collision detection result, and performs logical processing corresponding to the collision detection event based on the geometric overlap between the colliders.

[0078] When the game engine indicates that the current logic update cycle has been completed, that is, when its preset end time has been reached, the second timestamp determined based on that time will take effect and immediately generate a clear trigger event. The first thread can continuously listen for the trigger event, and when it confirms that the second timestamp has been reached, it will first obtain the calculation result. At this time, the first thread will turn to the data interaction area agreed with the second thread, such as a thread-safe queue or shared memory buffer dedicated to storing results, and read the structured collision detection results previously written by the second thread from it to ensure that the main logic thread can reliably obtain all the output of the asynchronous calculation.

[0079] After successfully acquiring the relevant data, the first thread begins to parse the collision detection results. The parsing process first identifies all the pairs of colliders that have geometrically overlapped recorded in the results. For each pair of identifiers, the first thread maps them back to the corresponding game entity objects, thereby clarifying which specific game characters, bullets, or scene objects have made contact. If the collision detection results contain more detailed geometric information such as the collision point or normal direction, the parsing process will also extract this information to provide data support for logic that requires high-precision response.

[0080] After completing the analysis and determining all overlapping relationships, the first thread immediately drives the game logic processing corresponding to the collision detection event. The game logic processing can be the direct reaction of the gameplay to physical contact. If the analysis finds that the collision object of a bullet overlaps with the collision object of an enemy character, the first thread will call the combat logic to calculate the damage and deduct the enemy's health, while triggering the hit animation and sound effect. If the analysis finds that the player character overlaps with the collision object of a pushable box, the first thread will call the physics response logic to calculate a thrust and change the movement state of the box. In this way, the physical collision data in the background is finally transformed into the game rule execution and state changes that can be perceived in the front end, thus completing the closed loop from collision detection to game interaction.

[0081] The embodiments described above strictly bind the final processing time of collision results to the end of the logic update cycle, establishing a clear and unified result processing time point. This ensures that the operation to respond to asynchronously calculated collision results is always executed at the end of the same discrete logic cycle, thereby eliminating random delays in result processing and guaranteeing a stable rhythm for game logic progression. Under this premise, the first thread uniformly acquires and parses all collision results at the end of the cycle, enabling the game system to drive subsequent logic based on the final determined spatial overlap state within that cycle. This filters out the instantaneous intermediate collision states that may occur during the movement of objects within the cycle, responding only to the stable results at the end of the cycle, effectively avoiding logical errors and resource waste caused by responding to invalid intermediate states. Simultaneously, since the processing of results is limited to a very short time after the end of the cycle, the main thread can quickly transform the physical collision conclusions into specific gameplay responses, such as damage calculation or changes in object movement, ensuring immediate feedback for player interaction. The entire process of this embodiment can further enhance the temporal controllability, logical consistency, and overall smoothness of game event processing while improving the efficiency of physical calculations.

[0082] Based on any embodiment of the method in this application, it further includes: Step S3510: Obtain the current frame timing parameters based on the time management system contained in the game engine, determine the corresponding game frame period according to the frame timing parameters, and determine each game frame period as the first time window.

[0083] In this embodiment, within the game engine's internal structure, the time management system is a core component specifically responsible for maintaining and advancing the application's runtime sequence. It obtains precise time flow information by querying a high-precision hardware clock or following the timing services provided by the operating system, and drives the game loop accordingly. The first thread can thus utilize the time management system to define the basic time units of game execution. The first thread first requests the current frame timing parameters from the time management system. Frame timing parameters are key data describing the execution status of the previous time unit or the planned duration of the next time unit, including the total running time since game startup, the incremental time interval since the previous frame, and the ideal duration per frame corresponding to the target frame rate set by the game engine. The first thread then determines the corresponding game frame cycle based on these frame timing parameters. If the game engine uses a fixed target frame rate, the game frame cycle will be a fixed length of time; for example, when the current game screen refresh rate is 60 frames per second, each frame cycle is approximately 16.67 milliseconds. If the game engine uses an adaptive frame rate, the game frame cycle will be determined by the actual time consumed by the previous frame or a smoothed predicted time.

[0084] After determining the start and end times of the current or next game frame cycle, the first thread formally sets the corresponding cycle of each game frame as the first time window for processing game state updates. All game logic triggered within a corresponding cycle, including but not limited to collision detection events, will have its data acquisition, calculation, and result processing timeframe aligned with the boundary of this game frame cycle. By establishing a one-to-one equivalent mapping between the first time window and the game frame cycle, it is possible to further ensure that the evolution of the game world's state, physics calculations, and the final visual presentation maintain strict synchronization, without requiring additional data logic settings for the first time window, thus providing a unified and stable time reference for all real-time interactions.

[0085] Step S3520: Based on the game frame period, determine the first timestamp as the start time of the current game frame, and determine the second timestamp as the end time of the current game frame.

[0086] Since a game frame cycle defines the continuous time period from the start of all logic in the current frame to the start of logic in the next frame, different timestamp nodes in the collision detection process can be specifically set based on this determined game frame cycle.

[0087] The first thread first obtains the exact start time based on the current game frame cycle. This start time can be marked by the engine's time management system at the initial stage of each frame's logic processing. It represents the starting point of a brand new logic update iteration. The first thread then officially determines this start time as the first timestamp corresponding to this collision detection event. The validity of all subsequent data acquisition of spatial geometry information of colliders will be traced back to and locked at this moment. The game system will record the position and shape of all colliders at this moment as a snapshot of the world state of this detection.

[0088] The first thread then obtains the preset end time of the same game frame cycle. This end time can be an expected time point calculated based on a fixed frame rate, or it can be a cutoff point dynamically determined according to the actual logic execution progress. The first thread officially determines this end time as the second timestamp corresponding to this collision detection event. This moment marks the deadline for processing the collision result. All asynchronous calculations must be completed before this time, and the result processing logic will be triggered afterward.

[0089] By binding the first and second timestamps to the start and end times of the same game frame, the entire collision detection process is strictly limited to the lifecycle of a single frame. This ensures that data acquisition based on the initial state of the frame and result processing performed at the end of the frame share the same stable and discrete time reference system. For example, the position used for detecting a fast-moving object in this frame is a snapshot of the initial frame, while the final determination of whether a collision has occurred and the logical response are uniformly performed at the end of the frame based on the result calculated from that snapshot. This ensures complete synchronization between physical calculations and game logic updates in terms of rhythm.

[0090] The embodiments described above in this application precisely align the key time nodes of the collision detection process with the inherent frame cycle of the game engine, thereby bringing further stability and efficiency improvements to the entire game system. By obtaining frame timing parameters from the time management system and determining the logic update cycle accordingly, it ensures that the processing rhythm of collision detection events is completely synchronized with the core beat of game state refresh. This eliminates the risk of state inconsistency caused by different timing benchmarks and provides a unified and reliable time framework for all subsequent calculations.

[0091] Furthermore, by explicitly setting the first timestamp as the start time of the current game frame and the second timestamp as the end time of the same frame, the data acquisition and result processing of collision detection are strictly limited to the lifecycle of a single frame. This allows the game system to perform all calculations based on a consistent world state snapshot at the beginning of the frame, and to uniformly drive the game logic response based on the final calculation result of that snapshot at the end of the frame. This not only ensures the compactness and controllability of the process from detection to processing in terms of timing, but more importantly, it naturally ensures that the game system will only react to the final collision state at the end of each frame cycle, thereby automatically ignoring and filtering out all transient and invalid intermediate collision states that may occur during the movement of an object within that frame. Therefore, the steps in this embodiment not only optimize the processing timing in implementation, but also fundamentally enhance the determinism and logical correctness of the game's physical interaction, while ensuring the smoothness and stability of the game's operation.

[0092] Based on any embodiment of the method in this application, it further includes: Step S3610: The first thread extracts collider instances associated with the detection range from the scene data of the game engine, and encapsulates the current transformation matrix parameters and collider parameters of each collider instance into a spatial geometry data packet.

[0093] After the spatial area to be checked for collision detection events, i.e. the detection range, has been determined, the first thread needs to find all objects with physical interaction capabilities within this range in the current scene managed by the game engine. These objects are represented as entities with collider components inside the game engine. Each such entity is called a collider instance. For example, in a battle scene where a game character is within a specific range, the detection range can be the space occupied by this battle scene with a specific range on the game map, and the collider instance is the internal data object corresponding to all local characters or obstacles in this area.

[0094] The first thread queries the game engine's scene management system, quickly retrieving a list containing all relevant collider instances based on the spatial boundaries of the detection range. Next, it retrieves specific information for each instance in the list. One piece of information could be the real-time transformation matrix parameters of the collider instance, which accurately describes its current position coordinates, rotation angle, and overall scaling in the game world. Another could be its collider parameters, which define the inherent geometry and size of the collider. For example, a collider parameter representing a shield would specify that it is a cuboid with its length, width, and height, while a collider parameter representing a mine would specify that it is a sphere with its radius.

[0095] After obtaining these two sets of parameters for each collider instance, the first thread integrates them. Specifically, it generates a small data block for each collider instance, which contains both the transformation matrix parameters describing the position and the collider parameters describing the shape. Then, the first thread combines these small data blocks corresponding to all the collider instances to be detected, along with the identification information of this detection task, into a complete and independent data set. This final data set is the spatial geometry data package. The purpose of the spatial geometry data package is to capture and solidify information that is originally scattered in the game engine's scene data structure and may change at any time into a unified and read-only data snapshot at a specific moment. In this way, the first thread completes the data preparation work before calculation. This spatial geometry data package can then be safely and efficiently passed to the second thread for pure mathematical calculations without the second thread having to directly access complex scene data or scene data that may be modified by the main thread, thus ensuring data consistency and thread safety.

[0096] Step S3620: Store the encapsulated spatial geometry data packet into a concurrent and secure data structure shared by the first thread and the second thread, so that the spatial geometry data packet corresponds to the spatial geometry information that can be obtained.

[0097] Since the first thread has encapsulated the spatial information of all collider instances to be detected into a single data packet, namely the spatial geometry data packet, this data packet needs to be safely handed over to the second thread responsible for computation. Because the first and second threads run independently and concurrently, directly operating on the same memory region without protection could lead to data being read before it is fully written, resulting in data races, which could then cause computational errors or program crashes. Therefore, a specially designed data structure can be used as a safe intermediary between the two threads; this data structure can be configured as a thread-safe data structure. The concurrency safety characteristic of a thread-safe data structure means that its internal mechanisms, such as mutexes, atomic operations, or lock-free programming, ensure that only one thread can modify it at a time, or that its read and write operations are atomic, thus eliminating data races. Specifically, this can manifest as a thread-safe queue, a circular buffer, or a memory region protected by a mutex.

[0098] After encapsulating the spatial geometry data packet, the first thread does not directly hand it over to the second thread. Instead, it calls the write or push interface of the concurrent-safe data structure to store the entire data packet. Once this storage operation is successfully completed, the first thread's task in this step is finished. At this point, the stored data packet, because its carrier, the concurrent-safe data structure, can also be accessed by the second thread, becomes a resource that the second thread can obtain at any time, i.e., it becomes the spatial geometry information that can be acquired. Thus, through the design of this embodiment, the direct dependency between the first and second threads is decoupled. After storing the data, the first thread does not need to wait and can immediately continue executing other main loop tasks; while the second thread can, within its running loop, perform read or pop operations on the same data structure at appropriate times to obtain the data packet.

[0099] Through the synergistic effect of the structured data preparation and exchange mechanisms described in the above embodiments, a solid and efficient foundation is further provided for parallel collision detection computation. Specifically, by encapsulating the real-time state and static attributes of the selected collider instances in the scene into a unified data packet, the originally scattered and potentially changing scene information is solidified into a complete and consistent snapshot at a critical moment. This effectively avoids the inconsistency problem caused by the main thread modifying the original data when the computation thread reads the data, ensuring the accuracy of the computational foundation. Furthermore, by storing the encapsulated data packet in a concurrent and safe data structure designed specifically for inter-thread communication, safe and decoupled data handover between the main thread and the computation thread is achieved. This not only completely eliminates the risk of data competition that may occur when multiple threads access the same data area simultaneously, ensuring the stability of the program, but also allows the main thread to immediately return to process other core logic without waiting after submitting data, while the computation thread can obtain data and perform computation within its appropriate scheduling cycle. Moreover, this asynchronous handover method can also reduce mutual blocking between threads, improving the overall system's resource utilization and responsiveness. Therefore, this embodiment constructs a reliable and efficient data preprocessing and supply pipeline, enabling the heavy geometric calculation tasks to be safely and orderly separated from the main logic, creating the necessary conditions for fully leveraging parallel computing performance while ensuring data accuracy and thread safety.

[0100] Please see Figure 3According to one aspect of this application, a collision detection processing apparatus includes an event response module 4100, an information acquisition module 4200, a collision detection module 4300, and a result determination module 4400. The event response module 4100 is configured to respond to a collision detection event triggered in a game scene and determine a first time window corresponding to the event based on a preset first thread. The information acquisition module 4200 is configured to acquire spatial geometric information corresponding to all colliders within the detection range of the collision detection event based on a first timestamp corresponding to the first time window. The collision detection module 4300 is configured to perform collision detection on each collider according to the spatial geometric information by a preset second thread and return the corresponding collision detection result to the first thread. The result determination module 4400 is configured to respond to a trigger event where the first time window reaches a second timestamp, and the first thread determines whether a collision occurs between each collider based on the collision detection result.

[0101] Based on any embodiment of the device in this application, the event response module 4100 includes: an operation response unit, configured to trigger the collision detection event in response to a logical update operation of the game scene by the game engine; and a period determination unit, configured to have the first thread determine the corresponding logical update period based on the logical update operation, and set the logical update period as the first time window.

[0102] Based on any embodiment of the device in this application, the information acquisition module 4200 includes: a first time unit, configured to determine the moment when all colliders complete state synchronization within the logical update cycle as the first timestamp; an entity filtering unit, configured to determine the target spatial range to be detected based on the interactive object associated with the collision detection event, and filter all colliders located within the range from the scene management system based on the target spatial range; and an information acquisition unit, configured to acquire the spatial geometric information of each selected collider at the first timestamp, wherein the spatial geometric information includes position coordinate data and boundary volume data.

[0103] Based on any embodiment of the device in this application, the collision detection module 4300 includes: an information sending unit, configured to send the collected spatial geometric information to the second thread by the first thread; an algorithm execution unit, configured to execute a preset collision detection algorithm on the spatial geometric information by the second thread when the second thread receives the spatial geometric information, so as to generate a corresponding collision detection result indicating whether there is geometric overlap between each collider based on the output result of the collision detection algorithm; and a result return unit, configured to send the collision detection result to the first thread when the second thread obtains the collision detection result.

[0104] Based on any embodiment of the device in this application, the result determination module 4400 includes: a second time unit, configured to determine the second timestamp based on the end time when the logical update cycle of the first time window reaches the end time; and a collision parsing unit, configured to, in response to the triggering event, have the first thread obtain the collision detection result returned by the second thread, perform collision parsing based on the collision detection result by the first thread, and perform logical processing corresponding to the collision detection event based on the geometric overlap between each collider.

[0105] Based on any embodiment of the device in this application, it further includes: a game frame determination module, configured to obtain the current frame timing parameters based on the time management system included in the game engine, determine the corresponding game frame period according to the frame timing parameters, and determine each game frame period as the first time window; and a timestamp determination module, configured to determine the first timestamp as the start time of the current game frame based on the game frame period, and determine the second timestamp as the end time of the current game frame.

[0106] Based on any embodiment of the device in this application, it further includes: a data encapsulation module, configured to extract collider instances associated with the detection range from the scene data of the game engine by the first thread, and encapsulate the current transformation matrix parameters and collider parameters of each collider instance into a spatial geometry data packet; and a data storage module, configured to store the encapsulated spatial geometry data packet into a concurrent and secure data structure shared by the first thread and the second thread, so as to use the spatial geometry data packet as the spatial geometry information that can be obtained.

[0107] Another embodiment of this application also provides a collision detection processing device. For example... Figure 4 The diagram shows the internal structure of a collision detection 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 stores information sequences, and when executed by the processor, these computer-readable instructions enable the processor to implement a collision detection processing method.

[0108] The processor of the collision detection processing device provides computing and control capabilities to support 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 collision detection processing method of this application. The network interface of the device is used for communication with a terminal.

[0109] 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 solution of this application and does not constitute a limitation on the collision detection processing device to which the solution of this application is applied. The specific collision detection processing device may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0110] 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 collision detection processing device of this application, and the server can call the server's program code and data to execute the functions of all modules.

[0111] 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 collision detection processing method of any embodiment of this application.

[0112] 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.

[0113] 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 collision detection processing method characterized by comprising: The method comprises: in response to a collision detection event triggered in a game scene, determining a first time window corresponding to the event based on a preset first thread; based on a first timestamp corresponding to the first time window, acquiring spatial geometric information corresponding to all collision bodies contained in a detection range of the collision detection event; after performing collision detection on each of the collision bodies based on the spatial geometric information by a preset second thread, returning a corresponding collision detection result to the first thread; in response to a trigger event that the first time window reaches a second timestamp, determining whether collisions occur between each of the collision bodies based on the collision detection result by the first thread.

2. The collision detection processing method according to claim 1, characterized by, The method comprises: in response to a logical update operation of a game engine on the game scene, triggering the collision detection event; determining a corresponding logical update period based on the logical update operation by the first thread, and setting the logical update period as the first time window.

3. The collision detection processing method according to claim 2, characterized by, The method comprises: determining a moment when the states of all collision bodies in the logical update period are synchronized as the first timestamp; determining a target spatial range to be detected according to an interactive object associated with the collision detection event, and filtering all collision bodies located in the range from a scene management system based on the target spatial range; acquiring spatial geometric information of each of the filtered collision bodies corresponding to the first timestamp, wherein the spatial geometric information comprises position coordinate data and boundary volume data.

4. The collision detection processing method according to claim 3, characterized by, The method comprises: sending the acquired spatial geometric information to the second thread by the first thread; when the second thread receives the spatial geometric information, executing a preset collision detection algorithm on the spatial geometric information by the second thread to generate a corresponding collision detection result indicating whether there is geometric overlap between each collision body based on an output result of the collision detection algorithm; when the second thread acquires the collision detection result, sending the collision detection result to the first thread by the second thread.

5. The collision detection processing method according to claim 2, characterized by, The method comprises: when the logical update period of the first time window reaches an end moment, determining the second timestamp based on the moment; in response to the trigger event, acquiring the collision detection result returned by the second thread by the first thread, and performing collision analysis on the collision detection result by the first thread to execute logical processing corresponding to the collision detection event based on the geometric overlap between each collision body.

6. The collision detection processing method according to any one of claims 1 to 5, characterized by, The method further comprises: acquire a current frame timing parameter based on a time management system contained in the game engine, determine a corresponding game frame period according to the frame timing parameter, and determine each game frame period as the first time window; determine the first timestamp as a starting time of a current game frame and determine the second timestamp as an ending time of the current game frame based on the game frame period.

7. The collision detection processing method according to claim 6, characterized by, Further comprising: extract, by the first thread, a collision body instance associated with the detection range from scene data of the game engine, and encapsulate a current transformation matrix parameter of each collision body instance and a collision body parameter into a spatial geometry data packet; store the encapsulated spatial geometry data packet into a concurrent safe data structure shared by the first thread and the second thread, so as to correspondingly serve as the spatial geometry information available for acquisition.

8. A collision detection processing device characterized by comprising: Comprise: an event response module configured to determine a first time window corresponding to a collision detection event triggered in a game scene based on a preset first thread in response to the collision detection event; an information acquisition module configured to acquire spatial geometry information corresponding to all collision bodies contained in a detection range of the collision detection event based on a first timestamp corresponding to the first time window; a collision detection module configured to return a corresponding collision detection result to the first thread after performing collision detection on each collision body according to the spatial geometry information by a preset second thread; a result determination module configured to determine whether collisions occur between each collision body based on the collision detection result by the first thread in response to a trigger event that the first time window reaches the second timestamp.

9. A collision detection processing device comprising a central processing unit and a memory, characterized by The central processing unit is configured to call and run a computer program stored in the memory to perform the steps of the method according to any one of claims 1 to 7.

10. A non-volatile readable storage medium, characterized by The computer program is stored in the form of computer readable instructions and is implemented according to the method of any one of claims 1 to 7. When the computer program is called and run by a computer, the steps included in the corresponding method are performed.

Images