GPU collision detection acceleration method based on logic group filtering and load balancing
By employing a logic group filtering and load balancing approach, parallel screening and accurate collision detection are performed on the GPU, solving the problem of low CPU collision detection efficiency in large-scale robot simulations and achieving highly efficient parallel collision detection results.
Patent Information
- Application Number
- CN202511668663.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-14
- Publication Date
- 2026-02-13
AI Technical Summary
In large-scale robot simulation scenarios, existing technologies struggle to meet the high real-time requirements of traditional CPU collision detection schemes, while GPU acceleration schemes fail to fully utilize parallel characteristics, resulting in unsatisfactory acceleration effects when processing dynamic, ultra-large-scale simulation scenarios.
A GPU collision detection method based on logical group filtering and load balancing is adopted. Unnecessary geometric pairs are pre-removed through logical group filtering rules, and bounding ball testing and load group key value sorting are performed on the GPU to achieve parallel filtering and accurate collision detection.
It significantly improves the efficiency of collision detection, reduces unnecessary computation, solves the problem of uneven load in traditional methods, and achieves efficient parallel collision detection.
Smart Images
Figure CN121523896A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of robot simulation technology, and in particular relates to a GPU collision detection acceleration method based on logic group filtering and load balancing. Background Technology
[0002] Collision detection is one of the core foundational technologies in fields such as robot simulation, computer graphics (CG), and virtual reality (VR). Its purpose is to determine whether two or more objects in a scene overlap in space. In robot simulation, the accuracy, real-time performance, and reliability of collision detection directly affect the performance, stability, and final training effect of the entire simulation system. Especially in large-scale cluster simulations or training scenarios containing numerous complex geometries, the collision detection processing often becomes the performance bottleneck of the entire system.
[0003] Traditional collision detection solutions primarily rely on central processing units (CPUs). Typical CPU implementations employ a two-phase architecture: a broad phase and a narrow phase. In the broad phase, algorithms such as bounding box hierarchy (BVH), spatial partitioning trees (e.g., KD-Tree, Octree), or sweep and pruning are used to quickly eliminate obviously disjoint geometric pairs, generating a list of potential collision pairs. In the narrow phase, each pair in this list undergoes a precise intersection test; common algorithms include the Gilbert–Johnson–Keerthi (GJK) algorithm and the Extended Polygon Algorithm (EPA). While CPU solutions are mature and stable, their inherent serial processing characteristics struggle to cope with the computational pressure brought about by a rapid increase in the number of objects. When handling large-scale simulation scenarios, computational latency increases significantly, making it difficult to meet the requirements of high real-time simulations.
[0004] In recent years, with the development of graphics processing unit (GPU) computing power and the maturity of its general-purpose computing ecosystem, leveraging the massively parallel computing capabilities of GPUs to accelerate collision detection has become an important research direction. Some existing GPU acceleration solutions attempt to port wide-stage bounding box traversal, overlap testing, and narrow-stage precision calculation tasks to GPUs for parallel execution. While these solutions have improved throughput to some extent, they remain constrained by traditional CPU solutions and fail to fully utilize the parallel characteristics of GPUs. Their acceleration performance is not ideal when facing ultra-large-scale simulation scenarios with dynamic business requirements. Summary of the Invention
[0005] The purpose of this invention is to solve the problems existing in the prior art and to provide a GPU collision detection acceleration method based on logical group filtering and load balancing.
[0006] To achieve the above-mentioned objectives, the present invention specifically adopts the following technical solution: In a first aspect, the present invention provides a GPU collision detection acceleration method based on logical group filtering and load balancing, which includes the following steps: S1. Import and parse the simulation scene to obtain all robots in the scene. Design logical group filtering rules based on the logical group attributes of the robots. According to the rules, perform collision pre-removal on geometric pairs that do not conform to the rules. Then, pre-calculate all possible geometric pairs that may collide from the removed geometric pairs. Finally, store the pre-calculated geometric pairs as candidate geometric pairs in a static buffer and upload them to the GPU memory. S2. During the robot's movement, collision detection is performed continuously: In the wide phase of each simulation step, combined with the robot's spatial position information in the current frame, all candidate geometric pairs are quickly pre-screened using a bounding sphere approach. Candidate geometric pairs whose bounding spheres do not intersect in the current frame are eliminated, thus obtaining a dynamic candidate array for accurate collision detection. In the narrow phase of each simulation step, based on the geometric type identifiers of each possible collision pair in the dynamic candidate array, the load group key value is calculated, and the dynamic candidate array is sorted in parallel to form a computational load bucket that is continuously distributed according to the load group key value. The capacity and offset of each computational load bucket are calculated, and a dedicated output memory area is pre-allocated for it. For each computational load bucket, GPU execution resources are dynamically configured, a dedicated GPU kernel function is started, and accurate collision detection of possible collision pairs with the same geometric type combination within the bucket is performed. The collision detection results are written to the corresponding output memory area.
[0007] Based on the above scheme, each step can be implemented in the following preferred manner.
[0008] As a preferred embodiment of the first aspect mentioned above, in S1, the imported simulation scene consists of a simulation environment and several robots; each robot contains a unique identifier, a logical group identifier, and a tree structure composed of several geometries, joints, and actuators; the simulation environment is a special simulation object with a unique identifier of 0 and a logical group identifier of 0; each geometry has its own unique identifier and type identifier; the geometry types include planes, spheres, capsules, ellipsoids, cylinders, and cuboids.
[0009] As a preferred embodiment of the first aspect mentioned above, in S1, the logic group filtering rule requires collision detection between the geometry of the same robot, between robots belonging to different logic groups, and between any robot and the simulation environment, while collision detection is not required between robots belonging to the same logic group.
[0010] As a preferred embodiment of the first aspect mentioned above, the specific process of S1 is as follows: S11. Traverse all logical group identifiers, form a tuple from two different logical group identifiers, and store it in the logical group collision table; S12. For each tuple in the logical group collision table, the two logical group identifiers in the tuple are denoted as the first logical group identifier and the second logical group identifier, respectively. The first set is composed of all the geometries in the robots belonging to the first logical group identifier, and the second set is composed of all the geometries in the robots belonging to the second logical group identifier. Calculate the Cartesian product of the first set and the second set to generate all possible pairs of geometries that may collide between the two robots. S13. Traverse each robot except the simulation environment. For each robot, first extract all the geometry it contains to form a third set. Two different geometries in this set constitute a pair of geometries that may collide inside the same robot. S14. Perform type normalization on all possible geometry pairs that may collide between two robots and within the same robot. If the type identifier value of the first geometry in a geometry pair is greater than the type identifier value of the second geometry, then swap their positions. The normalized geometry pair is then stored in the static buffer and uploaded to the GPU memory as a candidate geometry pair.
[0011] As a preferred embodiment of the first aspect mentioned above, the specific processing flow for each simulation step in S2 is as follows: S21. At the start of each simulation step, calculate and update the geometric bounding sphere parameters of each robot in the world coordinate system on the GPU based on the pose information of all robots; S22. After completing the bounding sphere parameter update, start a dedicated first GPU kernel function to perform the bounding sphere intersection test; S23. Record the unique identifier and type identifier of each geometry identified as a possible collision pair in S22 on the GPU, and generate a dynamic candidate array; S24. Perform a sorting operation based on geometry type identifiers on the dynamic candidate array on the GPU, start a classification kernel with the same number of threads as the length of the dynamic candidate array; each thread processes a possible collision pair in the dynamic candidate array and calculates the corresponding load group key value based on the type identifiers of the two geometry in the possible collision pair; then, using the load group key value as the key, perform parallel sorting on the GPU on the dynamic candidate array so that all possible collision pairs with the same load group key value are continuously distributed in memory, thereby forming different computational load buckets; S25. Perform a parallel prefix sum operation on the sorted dynamic candidate array, and count the starting offset and the number of possible collision pairs contained in each computing load bucket; based on the statistical information of each computing load bucket, pre-allocate an exclusive and contiguous output memory area in the GPU memory for each computing load bucket to store the collision detection results of each computing load bucket. S26. Traverse all non-empty computational load buckets, calculate the required GPU mesh and thread block dimensions based on the number of possible collision pairs contained in the bucket, and dynamically start a dedicated, highly optimized second GPU kernel function; the second GPU kernel function only processes possible collision pairs with the same geometric type combination in the current computational load bucket, performs collision detection, and writes the collision detection results to the pre-allocated output memory area; the collision detection results include: collision state, contact point coordinates, contact normal vector, and penetration depth.
[0012] As a preferred embodiment of the first aspect mentioned above, in S22, each thread in the first GPU kernel function performs the following operations: based on its global thread index i, it reads the i-th candidate geometry pair from the static collision pair buffer of the GPU memory; using the unique identifier of each geometry in the i-th candidate geometry pair, the thread queries the bounding sphere parameters of each geometry in the world coordinate system of the current frame from the memory index; then it calculates the Euclidean distance between the centers of the two bounding spheres and performs an intersection judgment: if the sum of the radii of the two bounding spheres is greater than or equal to the Euclidean distance between the centers of the two bounding spheres, then the candidate geometry pair is determined to be a possible collision pair in the current frame; if not, it is determined to be an impossible collision pair.
[0013] Secondly, the present invention provides a GPU collision detection acceleration system based on logical group filtering and load balancing, comprising: The preprocessing module is used to import and parse the simulation scene to obtain all robots in the scene. Based on the logical group attributes of the robots, logical group filtering rules are designed, and geometric pairs that do not conform to the rules are pre-removed for collision. Then, all possible geometric pairs that may collide are pre-calculated from the removed geometric pairs. Finally, the pre-calculated geometric pairs are stored as candidate geometric pairs in a static buffer and uploaded to the GPU memory. The collision detection module performs continuous collision detection during the robot's movement. In the wide phase of each simulation step, combining the robot's spatial position information from the current frame, all candidate geometric pairs are quickly pre-screened using a bounding sphere approach. Candidate geometric pairs whose bounding spheres clearly do not intersect in the current frame are eliminated, resulting in a dynamic candidate array for precise collision detection. In the narrow phase of each simulation step, based on the geometric type identifiers of each possible collision pair in the dynamic candidate array, load group keys are calculated, and the dynamic candidate array is sorted in parallel to form computational load buckets continuously distributed according to the load group keys. The capacity and offset of each computational load bucket are calculated, and a dedicated output memory area is pre-allocated for it. For each computational load bucket, GPU execution resources are dynamically configured, a dedicated GPU kernel function is launched, and precise collision detection is performed on possible collision pairs with the same geometric type combination within that bucket. The collision detection results are then written to the corresponding output memory area.
[0014] Thirdly, the present invention provides a computer program product, including a computer program / instruction, which, when executed by a processor, can implement the GPU collision detection acceleration method based on logical group filtering and load balancing as described in any of the solutions of the first aspect above.
[0015] Fourthly, the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the GPU collision detection acceleration method based on logical group filtering and load balancing as described in any of the solutions of the first aspect above.
[0016] Fifthly, the present invention provides a computer electronic device, which includes a memory and a processor; The memory is used to store computer programs; The processor is configured to, when executing the computer program, implement the GPU collision detection acceleration method based on logical group filtering and load balancing as described in any of the solutions of the first aspect above.
[0017] Compared with the prior art, the present invention has the following advantages: This invention innovatively introduces a business-based logical group identifier. During simulation scenario initialization, it filters out a large number of geometric pairs that do not need to be detected due to specific business rules, and pre-calculates all remaining candidate geometric pairs that may collide, storing them in a dedicated buffer. In the wide phase, leveraging the high-speed parallel computing capabilities of the GPU, it performs bounding sphere testing on the pre-stored candidate geometric pairs in the buffer within each simulation step, quickly filtering out all possible collision pairs within that simulation step, avoiding time-consuming processes such as real-time BVH (hierarchical bounding box) testing. In the narrow phase, it adds a collision type-based grouping and sorting step, processing geometric pairs with different computational complexities separately, solving the severe load unevenness problem caused by the traditional single general-purpose kernel. Attached Figure Description
[0018] Figure 1 This is a schematic diagram of the steps of the method of the present invention; Figure 2 This is a schematic diagram of a Humanoid 20×20 scene in an embodiment of the present invention; Figure 3 This is a schematic diagram of a Humanoid 300 scene in an embodiment of the present invention; Figure 4 This is a system block diagram of the present invention. Detailed Implementation
[0019] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Many specific details are set forth in the following description to provide a thorough understanding of the present invention. However, the present invention can be practiced in many other ways different from those described herein, and those skilled in the art can make similar modifications without departing from the spirit of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below. Technical features in the various embodiments of the present invention can be combined accordingly without mutual conflict.
[0020] In the description of this invention, it should be understood that the terms "first" and "second" are used only for descriptive purposes and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined with "first" and "second" may explicitly or implicitly include at least one of those features.
[0021] like Figure 1 As shown, in a preferred embodiment of the present invention, the GPU collision detection acceleration method based on logical group filtering and load balancing includes the following S1-S2 steps. The specific implementation process of each step will be described in detail below.
[0022] I. Logical Group Filtering and Preprocessing S1. Import and parse the simulation scene to obtain all robots in the scene. Design logical group filtering rules based on the logical group attributes of the robots. Perform collision pre-removal on geometric pairs that do not conform to the rules according to the rules. Then, pre-calculate all possible geometric pairs that may collide from the removed geometric pairs. Finally, store the pre-calculated geometric pairs as candidate geometric pairs in a static buffer and upload them to the GPU memory.
[0023] It should be noted that step S1 is pre-executed on the CPU before the simulation begins. Its purpose is to solidify the collision rules based on logical groups into an efficient query data structure, thereby reducing runtime computational overhead. The imported simulation scene consists of a simulation environment and several robots. Each robot contains a unique identifier (Id), a logical group identifier (Group), and a tree structure composed of several geometries, joints, and actuators. The simulation environment is a special simulation object with Id=0 and Group=0. Furthermore, each geometry has its own unique identifier (GeomId) and type identifier (GeomType). Geometry types include plane, sphere, capsule, ellipsoid, cylinder, and box, etc.
[0024] It should be noted that in step S1, the logic group filtering rule requires collision detection between the geometry of the same robot, between robots belonging to different logic groups, and between any robot and the simulation environment (whose logic group identifier Group=0). However, collision detection is not required between robots belonging to the same logic group (i.e., Group_A==Group_B). Here, Group_A represents the logic group identifier of the first robot, and Group_B represents the logic group identifier of the second robot.
[0025] The design of the above-mentioned logical group filtering rules stems from the practical needs of large-scale robot simulation training: in such scenarios, the training objective typically requires individual robots to interact only with the environment and heterogeneous objects, without dealing with theoretically possible but practically meaningless collisions with other robots of the same class. This rule eliminates a large number of unnecessary collision pairs in the earliest stages of computation, thereby significantly improving simulation efficiency.
[0026] It should be noted that, in this embodiment, the specific process of step S1 is as follows: S11. Traverse all logical group identifiers, form a tuple from two different logical group identifiers, and store it in the logical group collision table.
[0027] It should be noted that in S11, it is necessary to first traverse all logical group identifiers, generate all pairs (Group_A, Group_B) that satisfy Group_A!=Group_B. This pair is used to indicate that the two corresponding robots in this group need to perform collision detection. At the same time, this pair is used as an element and stored in the logical group collision relationship table in the list structure. Here,!= means not equal.
[0028] S12. For each pair in the logical group collision relationship table, the two logical group identifiers in this pair are respectively denoted as the first logical group identifier and the second logical group identifier. The geometric bodies of all robots belonging to the first logical group identifier form the first set, and the geometric bodies of all robots belonging to the second logical group identifier form the second set; calculate the Cartesian product of the first set and the second set to generate all possible pairs of geometric bodies that may collide between two robots.
[0029] It should be noted that S12 is to find pairs of geometric bodies that may cause collisions between two robots. For each pair (Group_A, Group_B) in the logical group collision relationship table determined in S11, collect the geometric bodies of all robots belonging to Group_A to form the above-mentioned first set Geom_Set_A, and at the same time collect the geometric bodies of all robots belonging to Group_B to form the above-mentioned second set Geom_Set_B, and then calculate the Cartesian product of Geom_Set_A and Geom_Set_B to generate all possible pairs of geometric bodies (Geom_A, Geom_B) that may collide.
[0030] S13. Traverse each robot except the simulation environment. For each robot, first extract all the geometric bodies it contains to form a third set, and form pairs of geometric bodies that may collide within the same robot from two different geometric bodies in this set.
[0031] It should be noted that S13 is to find pairs of geometric bodies that may cause collisions within a robot. First, traverse each robot except the simulation environment (whose logical group identifier Group = 0); for each robot, extract all the geometric bodies it contains to form the above-mentioned third set Internal_Geoms, and then generate all pairs of geometric bodies (Geom_i, Geom_j) that satisfy the condition i < j within this set, that is, pairs of geometric bodies that may collide within the same robot.
[0032] S14. Perform type normalization on all possible geometry pairs that may collide between two robots and within the same robot. If the type identifier value of the first geometry in a geometry pair is greater than the type identifier value of the second geometry, then swap their positions. The normalized geometry pair is then stored in the static buffer and uploaded to the GPU memory as a candidate geometry pair.
[0033] It should be noted that S14 of this invention is type normalization. For the geometry pair (Geom_A, Geom_B) obtained in S12, if the type identifier GeomType_A of the first geometry (representing the type of geometry A) is greater than the type identifier GeomType_B of the second geometry (representing the type of geometry B), then their positions are swapped to ensure that GeomType_A ≤ GeomType_B, and the normalized geometry pair information is stored in a static buffer located in CPU memory. The geometry pair information includes the unique identifier GeomId_A of geometry A, the unique identifier GeomId_B of geometry B, and the normalized type identifiers GeomType_A and GeomType_B. For the geometry pair (Geom_i, Geom_j) obtained in S13, the same type normalization operation is performed to ensure that GeomType_i ≤ GeomType_j, and finally, the normalized geometry pair obtained in this process is appended to the static buffer. After all robots have been processed, the total number of geometry pairs recorded in the static buffer is denoted as N. All geometry pairs in the static buffer are then uploaded to the GPU memory to provide ordered basic data for the subsequent wide-stage and narrow-stage collision detection processes executed on the GPU.
[0034] II. Wide-stage initial screening of bounding spheres and narrow-stage computational load-aware scheduling and precise collision detection S2. During the robot's movement, collision detection is performed continuously: In the wide phase of each simulation step (Step) of collision detection, the robot's spatial position information in the current frame is combined with the bounding sphere method to quickly perform preliminary screening of all candidate geometry pairs, and candidate geometry pairs whose bounding spheres are obviously not intersecting in the current frame are eliminated, thereby obtaining a dynamic candidate array (ConList) for accurate collision detection. In each narrow phase of the simulation step, the load group key value is calculated based on the geometric type identifier of each possible collision pair in the dynamic candidate array, and the dynamic candidate array is sorted in parallel to form a computational load bucket that is continuously distributed according to the load group key value. The capacity and offset of each computational load bucket are calculated, and a dedicated output memory area is pre-allocated for it. For each computational load bucket, GPU execution resources are dynamically configured, a dedicated GPU kernel function is launched, and accurate collision detection of possible collision pairs with the same geometric type combination in the bucket is performed. The collision detection results are written to the corresponding output memory area.
[0035] It should be noted that the specific processing flow for each simulation step is as follows: S21. At the start of each simulation step, calculate and update the geometric bounding sphere parameters of each robot in the world coordinate system on the GPU based on the pose information (including position and rotation) of all robots.
[0036] It should be noted that the bounding sphere parameters in S21 include the center coordinates x, y, and z, and the radius r, which represent the position and size of the bounding sphere in three-dimensional space, respectively. Step S21 is implemented by launching a GPU kernel function. The total number of threads in this kernel is equal to the total number of geometries in the simulation scene, ensuring that each thread is independently responsible for calculating the bounding sphere parameters of one geometry.
[0037] S22. After completing the bounding sphere parameter update, start a dedicated first GPU kernel function to perform the bounding sphere intersection test.
[0038] It should be noted that in S22, the mesh and thread block configuration of the first GPU kernel function is determined according to the number N of candidate geometry pairs in the static buffer, so as to achieve complete parallelism of one thread corresponding to one candidate geometry pair.
[0039] It should be noted that in S22, each thread in the first GPU kernel function performs the following operations: Based on its global thread index i, it reads the i-th candidate geometry pair from the static collision pair buffer in GPU memory. Using the unique identifier of each geometry in the i-th candidate geometry pair, the thread queries the memory to retrieve the bounding sphere parameters Sphere_A(center_A, radius_A) and Sphere_B(center_B, radius_B) of each geometry in the world coordinate system of the current frame. Here, center_A and center_B are the three-dimensional coordinate vectors of the centers of the bounding spheres of geometry A and geometry B in the i-th candidate geometry pair in the world coordinate system, respectively, and radius_A and radius_B are the radii of the bounding spheres of geometry A and geometry B, respectively. Then, it calculates the Euclidean distance d between the centers of the two bounding spheres and performs an intersection check: if the condition d <= (radius_A + ... If the sum of the radii of the two bounding spheres (radius_B) is greater than or equal to the Euclidean distance between the centers of the two bounding spheres, then the candidate geometry pair is determined to be a possible collision pair in the current frame; if the condition is not met, it is determined to be an impossible collision pair.
[0040] It should be noted that in step S22, the intersection test of the enclosing spheres is a conventional spatial distance determination algorithm in the field, which can be implemented in any equivalent way, so it will not be described in detail in this invention.
[0041] S23. Record the unique identifier (GeomId) and type identifier (GeomType) of each geometry identified as a possible collision pair in S22 on the GPU, and generate a dynamic candidate array (ConList).
[0042] It should be noted that ConList is used to compactly store all geometric pairs that pass the initial screening of the bounding sphere and their logical group information, enabling accurate collision detection in subsequent narrow stages. This array is stored in GPU memory, and its size can be dynamically allocated based on the actual number of collision pairs in the previous frame or a certain proportion (e.g., N / 2) of the static collision pair buffer size N to avoid memory overflow.
[0043] In addition, a global atomic counter NCon is set in the GPU memory, initially set to 0, to assign a unique write index to each geometry pair that passes the bounding sphere test. When each thread detects that the current geometry pair is a potential collision pair, it calls the GPU's atomicAdd operation to increment the value of NCon and obtains the old value write_idx before the increment. This old value is the unique write position index for the current thread. The thread then writes the information of the current geometry pair to the ConList[write_idx] position.
[0044] The above method enables conflict-free parallel writing of all possible colliding geometry pairs on the GPU, forming a compact and efficient dynamic candidate array in video memory. This dynamic candidate array serves as input data in subsequent narrow-stage collision detection, providing a foundation for accurate collision calculation. In the narrow-stage, the GPU uses a computational load-aware scheduling strategy to transform heterogeneous tasks with varying computational complexities into homogeneous task groups based on the type characteristics of the possible collision pairs, thereby resolving uneven GPU thread load and thread dispersion issues and improving the parallel efficiency of accurate collision detection. The narrow-stage includes the following three sub-steps: geometry type sorting, computational load bucket offset statistics and output region allocation, and load-aware accurate collision detection execution, as detailed in S24-S26 below.
[0045] S24. Perform a sorting operation on the dynamic candidate array based on geometry type identifiers on the GPU. Start a classification kernel with the same number of threads as the length of the dynamic candidate array. Each thread processes a possible collision pair in the dynamic candidate array and calculates the corresponding load group key value LoadGroupKey based on the type identifiers of the two geometry in the possible collision pair. Then, using the load group key value as the key, perform parallel sorting on the GPU on the dynamic candidate array so that all possible collision pairs with the same load group key value are continuously distributed in memory, thereby forming different computational load buckets.
[0046] It should be noted that in S24, the LoadGroupKey value is calculated as follows: LoadGroupKey = GeomType_A * GeomTypeCount + GeomType_B Here, GeomType_A and GeomType_B represent the type identifiers of the two geometries in the geometry pair, respectively, and GeomTypeCount represents the total number of all geometry types. This mapping ensures that each type combination corresponds to a unique key value.
[0047] It should also be noted that in S24, the sorting can be performed using a stable sorting algorithm known in the art (such as radix sort) or an equivalent implementation, and no restrictions are imposed in this invention.
[0048] S25. Perform a parallel prefix sum operation on the sorted dynamic candidate array to count the starting offset and the number of possible collision pairs contained in each computational load bucket; based on the statistical information of each computational load bucket, pre-allocate an exclusive, contiguous output memory area in the GPU memory for each computational load bucket to store the collision detection results of each computational load bucket.
[0049] S26. Traverse all non-empty computational load buckets, calculate the required GPU mesh and thread block dimensions based on the number of possible collision pairs contained in the bucket, and dynamically start a dedicated, highly optimized second GPU kernel function; the second GPU kernel function only processes possible collision pairs with the same geometric type combination in the current computational load bucket (e.g., all are sphere-sphere pairs), performs collision detection, and writes the collision detection results to the pre-allocated output memory area; the collision detection results include: collision state, contact point coordinates, contact normal vector, and penetration depth.
[0050] It should be noted that in S26, the contact point coordinates represent the contact position of the geometry surfaces when a collision occurs; the contact normal vector represents the normal direction of the collision point; and the penetration depth represents the depth to which the geometry intrudes into each other. Since the geometry pairs processed within each kernel function are of completely identical type, all threads execute the same instruction path, eliminating the thread divergence problem and achieving efficient parallel and accurate collision detection.
[0051] It should be noted that in S26, the precise collision detection algorithm inside the second GPU kernel function can employ GJK / EPA or equivalent techniques known in the art. The load group key-value mapping method ensures that tasks with similar computational complexity are grouped into the same bucket. When writing collision results, atomic variables are used to ensure the uniqueness of the write position for each thread's result.
[0052] Thus, the detailed flowchart of the GPU collision detection acceleration method based on logic group filtering and load balancing of the present invention has been given. Testing has shown that this method achieves significant acceleration in the collision detection part of robot simulation while ensuring the efficiency and correctness of parallel computing. Specifically, to verify the technical effect of this embodiment, the present invention implements the GPU collision detection method based on logic group filtering and load balancing in a physics simulator, replacing the original collision detection module in the simulation.
[0053] In two high-density robot scenarios, Humanoid 20×20 and Humanoid 300, the collision detection performance of the method of this invention was compared with that of the original simulator. The experimental results are shown in Table 1. The Humanoid 20×20 scenario is shown below. Figure 2 As shown, the Humanoid 300 scene is as follows: Figure 3 As shown.
[0054] Table 1. Average collision detection speed of the present invention in two simulation scenarios As shown in Table 1, the method of the present invention significantly reduces unnecessary collision calculations in high-density robot simulation, maintains accuracy and physical correctness, improves the utilization of GPU computing resources, and achieves efficient parallel collision detection.
[0055] It should also be noted that the GPU collision detection acceleration method based on logical group filtering and load balancing in the above embodiments can essentially be executed by a computer program or module. Therefore, similarly, based on the same inventive concept, another preferred embodiment of the present invention also provides a GPU collision detection acceleration system based on logical group filtering and load balancing, corresponding to the GPU collision detection acceleration method based on logical group filtering and load balancing provided in the above embodiments, such as... Figure 4 As shown, it includes: The preprocessing module is used to import and parse the simulation scene to obtain all robots in the scene. Based on the logical group attributes of the robots, logical group filtering rules are designed, and geometric pairs that do not conform to the rules are pre-removed for collision. Then, all possible geometric pairs that may collide are pre-calculated from the removed geometric pairs. Finally, the pre-calculated geometric pairs are stored as candidate geometric pairs in a static buffer and uploaded to the GPU memory. The collision detection module performs continuous collision detection during the robot's movement. In the wide phase of each simulation step, combining the robot's spatial position information from the current frame, all candidate geometric pairs are quickly pre-screened using a bounding sphere approach. Candidate geometric pairs whose bounding spheres clearly do not intersect in the current frame are eliminated, resulting in a dynamic candidate array for precise collision detection. In the narrow phase of each simulation step, based on the geometric type identifiers of each possible collision pair in the dynamic candidate array, load group keys are calculated, and the dynamic candidate array is sorted in parallel to form computational load buckets continuously distributed according to the load group keys. The capacity and offset of each computational load bucket are calculated, and a dedicated output memory area is pre-allocated for it. For each computational load bucket, GPU execution resources are dynamically configured, a dedicated GPU kernel function is launched, and precise collision detection is performed on possible collision pairs with the same geometric type combination within that bucket. The collision detection results are then written to the corresponding output memory area.
[0056] It is understood that the GPU collision detection acceleration method based on logical group filtering and load balancing described in S1~S2 above can essentially be implemented by a computer program. Therefore, based on the same inventive concept, another preferred embodiment of the present invention also provides a computer program product corresponding to the GPU collision detection acceleration method based on logical group filtering and load balancing provided in the above embodiments, which includes a computer program / instruction. When the computer program / instruction is executed by a processor, it can implement the GPU collision detection acceleration method based on logical group filtering and load balancing as described in the above embodiments.
[0057] Similarly, based on the same inventive concept, another preferred embodiment of the present invention also provides a computer electronic device corresponding to the GPU collision detection acceleration method based on logical group filtering and load balancing provided in the above embodiment, which includes a memory and a processor; The memory is used to store computer programs; The processor is configured to implement the GPU collision detection acceleration method based on logical group filtering and load balancing in the above embodiments when executing the computer program.
[0058] Furthermore, the logical instructions in the aforementioned memory can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.
[0059] Therefore, based on the same inventive concept, another preferred embodiment of the present invention also provides a computer-readable storage medium corresponding to the GPU collision detection acceleration method based on logical group filtering and load balancing provided in the above embodiments. The storage medium stores a computer program, which, when executed by a processor, can realize the GPU collision detection acceleration method based on logical group filtering and load balancing in the above embodiments.
[0060] Specifically, in the computer-readable storage medium of the above three embodiments, the stored computer program is executed by a processor, which can perform the aforementioned steps S1 to S2.
[0061] It is understood that the aforementioned storage media may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Furthermore, the storage media may also be various media capable of storing program code, such as USB flash drives, external hard drives, magnetic disks, or optical discs.
[0062] It is understood that the processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.
[0063] It should also be noted that those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the system described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here. In the embodiments provided in this application, the division of steps or modules in the system and method is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple modules or steps may be combined or integrated together, and a module or step may also be split.
[0064] The embodiments described above are merely preferred embodiments of the present invention and are not intended to limit the invention. Those skilled in the art can make various changes and modifications without departing from the spirit and scope of the invention. Therefore, all technical solutions obtained through equivalent substitution or transformation fall within the protection scope of the present invention.
Claims
1. A GPU collision detection acceleration method based on logical group filtering and load balancing, characterized in that, Includes the following steps: S1. Import and parse the simulation scene to obtain all robots in the scene. Design logical group filtering rules based on the logical group attributes of the robots. According to the rules, perform collision pre-removal on geometric pairs that do not conform to the rules. Then, pre-calculate all possible geometric pairs that may collide from the removed geometric pairs. Finally, store the pre-calculated geometric pairs as candidate geometric pairs in a static buffer and upload them to the GPU memory. S2. During the robot's movement, collision detection is performed continuously: In the wide phase of each simulation step, combined with the robot's spatial position information in the current frame, all candidate geometric pairs are quickly pre-screened using a bounding sphere approach. Candidate geometric pairs whose bounding spheres do not intersect in the current frame are eliminated, thus obtaining a dynamic candidate array for accurate collision detection. In the narrow phase of each simulation step, based on the geometric type identifiers of each possible collision pair in the dynamic candidate array, the load group key value is calculated, and the dynamic candidate array is sorted in parallel to form a computational load bucket that is continuously distributed according to the load group key value. The capacity and offset of each computational load bucket are calculated, and a dedicated output memory area is pre-allocated for it. For each computational load bucket, GPU execution resources are dynamically configured, a dedicated GPU kernel function is started, and accurate collision detection of possible collision pairs with the same geometric type combination within the bucket is performed. The collision detection results are written to the corresponding output memory area.
2. The GPU collision detection acceleration method based on logical group filtering and load balancing as described in claim 1, characterized in that, In S1, the imported simulation scene consists of a simulation environment and several robots; each robot contains a unique identifier, a logical group identifier, and a tree structure composed of several geometries, joints, and actuators; the simulation environment is a special simulation object with a unique identifier of 0 and a logical group identifier of 0; each geometry has its own unique identifier and type identifier; geometry types include plane, sphere, capsule, ellipsoid, cylinder, and cuboid.
3. The GPU collision detection acceleration method based on logical group filtering and load balancing as described in claim 2, characterized in that, In S1, the logic group filtering rule requires collision detection between the geometry of the same robot, between robots belonging to different logic groups, and between any robot and the simulation environment, while collision detection is not required between robots belonging to the same logic group.
4. The GPU collision detection acceleration method based on logical group filtering and load balancing as described in claim 3, characterized in that, The specific process of S1 is as follows: S11. Traverse all logical group identifiers, form a tuple from two different logical group identifiers, and store it in the logical group collision table; S12. For each tuple in the logical group collision table, the two logical group identifiers in the tuple are denoted as the first logical group identifier and the second logical group identifier, respectively. The first set is composed of all the geometries in the robots belonging to the first logical group identifier, and the second set is composed of all the geometries in the robots belonging to the second logical group identifier. Calculate the Cartesian product of the first set and the second set to generate all possible pairs of geometries that may collide between the two robots. S13. Traverse each robot except the simulation environment. For each robot, first extract all the geometry it contains to form a third set. Two different geometries in this set constitute a pair of geometries that may collide inside the same robot. S14. Perform type normalization on all possible geometry pairs that may collide between two robots and within the same robot. If the type identifier value of the first geometry in a geometry pair is greater than the type identifier value of the second geometry, then swap their positions. The normalized geometry pair is then stored in the static buffer and uploaded to the GPU memory as a candidate geometry pair.
5. The GPU collision detection acceleration method based on logical group filtering and load balancing as described in claim 1, characterized in that, The specific processing flow for each simulation step in S2 is as follows: S21. At the start of each simulation step, calculate and update the geometric bounding sphere parameters of each robot in the world coordinate system on the GPU based on the pose information of all robots; S22. After completing the bounding sphere parameter update, start a dedicated first GPU kernel function to perform the bounding sphere intersection test; S23. Record the unique identifier and type identifier of each geometry identified as a possible collision pair in S22 on the GPU, and generate a dynamic candidate array; S24. Perform a sorting operation based on geometry type identifiers on the dynamic candidate array on the GPU, start a classification kernel with the same number of threads as the length of the dynamic candidate array; each thread processes a possible collision pair in the dynamic candidate array and calculates the corresponding load group key value based on the type identifiers of the two geometry in the possible collision pair; then, using the load group key value as the key, perform parallel sorting on the GPU on the dynamic candidate array so that all possible collision pairs with the same load group key value are continuously distributed in memory, thereby forming different computational load buckets; S25. Perform a parallel prefix sum operation on the sorted dynamic candidate array, and count the starting offset and the number of possible collision pairs contained in each computing load bucket; based on the statistical information of each computing load bucket, pre-allocate an exclusive and contiguous output memory area in the GPU memory for each computing load bucket to store the collision detection results of each computing load bucket. S26. Traverse all non-empty compute load buckets, calculate the required GPU mesh and thread block dimensions based on the number of possible collision pairs contained in the bucket, and dynamically start a dedicated, highly optimized second GPU kernel function; the second GPU kernel function only processes possible collision pairs with the same geometry combination in the current compute load bucket, performs collision detection, and writes the collision detection results to the pre-allocated output memory area; The collision detection results include: collision state, contact point coordinates, contact normal vector, and penetration depth.
6. The GPU collision detection acceleration method based on logical group filtering and load balancing as described in claim 5, characterized in that, In S22, each thread in the first GPU kernel function performs the following operations: based on its global thread index i, it reads the i-th candidate geometry pair from the static collision pair buffer in the GPU memory; using the unique identifier of each geometry in the i-th candidate geometry pair, the thread queries the bounding sphere parameters of each geometry in the world coordinate system of the current frame from the memory index; then it calculates the Euclidean distance between the centers of the two bounding spheres and performs an intersection judgment: if the sum of the radii of the two bounding spheres is greater than or equal to the Euclidean distance between the centers of the two bounding spheres, then the candidate geometry pair is determined to be a possible collision pair in the current frame; otherwise, it is determined to be an impossible collision pair.
7. A GPU collision detection acceleration system based on logical group filtering and load balancing, characterized in that, include: The preprocessing module is used to import and parse the simulation scene to obtain all robots in the scene. Based on the logical group attributes of the robots, logical group filtering rules are designed, and geometric pairs that do not conform to the rules are pre-removed for collision. Then, all possible geometric pairs that may collide are pre-calculated from the removed geometric pairs. Finally, the pre-calculated geometric pairs are stored as candidate geometric pairs in a static buffer and uploaded to the GPU memory. The collision detection module performs continuous collision detection during the robot's movement. In the wide phase of each simulation step, combining the robot's spatial position information from the current frame, all candidate geometric pairs are quickly pre-screened using a bounding sphere approach. Candidate geometric pairs whose bounding spheres clearly do not intersect in the current frame are eliminated, resulting in a dynamic candidate array for precise collision detection. In the narrow phase of each simulation step, based on the geometric type identifiers of each possible collision pair in the dynamic candidate array, load group keys are calculated, and the dynamic candidate array is sorted in parallel to form computational load buckets continuously distributed according to the load group keys. The capacity and offset of each computational load bucket are calculated, and a dedicated output memory area is pre-allocated for it. For each computational load bucket, GPU execution resources are dynamically configured, a dedicated GPU kernel function is launched, and precise collision detection is performed on possible collision pairs with the same geometric type combination within that bucket. The collision detection results are then written to the corresponding output memory area.
8. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instruction is executed by the processor, it can implement the GPU collision detection acceleration method based on logical group filtering and load balancing as described in any one of claims 1 to 6.
9. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the GPU collision detection acceleration method based on logical group filtering and load balancing as described in any one of claims 1 to 6.
10. A computer electronic device, characterized in that, Including memory and processor; The memory is used to store computer programs; The processor is configured to implement, when executing the computer program, the GPU collision detection acceleration method based on logical group filtering and load balancing as described in any one of claims 1 to 6.