A complex scene graph rendering method, system and medium

Abstract

The application relates to the technical field of graphic rendering, and discloses a complex scene graphic rendering method, a system and a medium, which comprise the following steps: three-dimensional scene data is divided into logical data and rendering data, the logical data at least comprises state data of dynamic entities, collision detection data and process logic data, and the rendering data at least comprises model vertex data, texture data and mesh data; a control end performs multi-thread parallel calculation on the logical data based on a graphic processor, and generates a synchronization data packet according to a view volume clipping judgment result of dynamic entities needing synchronization; a plurality of rendering ends receive the synchronization data packet; and the logical data is separated from the rendering data, the control end focuses on logical calculation, the plurality of rendering ends perform rendering tasks in parallel, the cluster computing advantages are fully brought into play, the logical data is combined with GPU multi-thread parallel calculation, CPU load is effectively released, and the system frame rate is increased from about 22 fps of a traditional single-machine scheme to above 60 fps.

Description

Technical Field

[0001] This invention relates to the field of graphics rendering technology, specifically to a method, system, and medium for rendering graphics in complex scenes. Background Technology

[0002] With the development of fields such as digital twins, intelligent manufacturing, and military simulation, the scale of 3D scenes is becoming increasingly large, often containing tens of thousands of dynamic entities and tens of millions of triangles, placing extremely high demands on real-time rendering performance. In the existing single-machine rendering architecture, the CPU handles logical calculations (state updates, collision detection, view frustum culling, etc.) and generates rendering instructions, while the GPU performs graphics rendering. When the number of dynamic entities is large, the CPU's serial calculations become the performance bottleneck, the GPU is in a waiting state for a long time, the frame rate is difficult to maintain above 30fps, and the screen stutters noticeably.

[0003] To address the aforementioned issues, existing solutions primarily include model lightweighting, multi-level detail simplification, and distributed cluster rendering. Lightweighting sacrifices model detail and affects scene realism. Traditional distributed rendering is mostly geared towards static scenes and lacks an effective synchronization mechanism for the dynamic behavior and states of entities, making it difficult to guarantee the consistency and coherence of the spliced ​​images from multiple rendering endpoints. Furthermore, in large-scale scenes, excessive rendering batches lead to huge CPU drawing overhead, while CPU-based ray intersection picking methods suffer from severe response latency when entities are dense, further deteriorating the interactive experience. Therefore, there is an urgent need for a parallel processing architecture that separates logic calculation and rendering calculation. By accelerating logic data calculation through GPU multi-threading, filtering dynamic entities that do not require synchronization to reduce communication load, and combining efficient batch merging and hardware acceleration picking technology, the rendering frame rate, synchronization accuracy and human-computer interaction smoothness of complex scenes can be significantly improved without reducing model accuracy. Summary of the Invention

[0004] The purpose of this invention is to provide a method, system, and medium for rendering graphics in complex scenes, so as to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, the present invention provides the following technical solution: The present invention provides a method for rendering graphics in complex scenes, comprising the following steps: Step S1: Data partitioning and distribution.

[0006] The 3D scene data is divided into logical data and rendering data. The logical data includes at least the state data of dynamic entities, collision detection data, and process logic data, which are held and managed by the control terminal. The rendering data includes at least the model vertex data, texture data, and mesh data, which are held and managed by multiple rendering terminals.

[0007] Step S2: Multi-threaded parallel computation of logical data.

[0008] The control end performs parallel calculations of the logical data using a multi-threaded GPU. Specifically, this includes: transferring the logical data to the video memory via a buffer; having multiple GPU threads concurrently perform motion state calculations and synchronization determination calculations; and implementing synchronization determination based on view frustum clipping. This involves calculating the normalized device coordinates (NDC) of the eight vertices of the bounding box of a dynamic entity after transformation by the projection matrix and the view matrix. If at least one vertex coordinate falls within the range of [-1,1], the entity is determined to require synchronization; otherwise, the entity is filtered out and not included in the synchronization data packet.

[0009] Step S3: Generate synchronization data packets.

[0010] The control terminal generates a synchronization data packet based on the judgment result. The synchronization data packet includes: a verification data area, which contains a verification identifier and a frame sequence number, used to verify the legality of the data packet and the matching of the frame; a fixed data area, which contains the observation matrix and projection matrix of the current frame, used to synchronize the rendering tasks of each rendering terminal; and a variable data area, which contains the state data type of the entity to be synchronized and the corresponding state change matrix. If no entity needs to be synchronized, this area is empty.

[0011] Step S4: Synchronize data transmission and parsing.

[0012] The control unit sends synchronization data packets to each rendering unit via the network transport layer. Upon receiving the packets, each rendering unit executes the parsing process: first, it verifies the identification and frame sequence number; if they do not match, the data packet is discarded; second, it reads the observation matrix and projection matrix and updates the view frustum parameters of the local camera; then, it triggers the corresponding state machine event based on the state data type to update the pose matrix of the dynamic entity.

[0013] Step S5: Parallel rendering and image stitching.

[0014] Each rendering end independently executes rendering pipeline processing based on the updated data, including frustum culling, vertex shading, geometry shading, rasterization, and pixel processing, and outputs a local rendering image. The local rendering images are stitched together according to the screen space division to form a complete frame image. The screen space division is implemented based on the scaling and translation transformation of the projection matrix. Each rendering end corresponds to a sub-region of the original single-machine frustum normalized view space.

[0015] Step S6: Graphics hardware acquisition.

[0016] In response to user interaction, a hardware picking method is used to determine the selected target object: a Render Target Texture (RTT) surface is created, and the geometric structure and pointer information of all primitives in the scene are encoded into RGB color values ​​and rendered to the RTT surface through a shader; the color value of the corresponding pixel on the RTT surface is read according to the mouse position, and the target object identifier is calculated in reverse, without the need for CPU-side traversal and intersection calculations.

[0017] Step S7: Merge rendering batches.

[0018] When submitting a drawing call, each rendering end uses graphics hardware instantiation technology to merge multiple instances of the same mesh model into a rendering batch and submit it to the GPU. The merging is based on texture transfer of the world matrix or vertex cache writing. After merging, vertex data and instantiation matrix array are submitted at once.

[0019] The present invention also provides a complex scene graphics rendering system, comprising: The control terminal is used to store and calculate logical data, generate synchronization data packets, and manage the allocation of rendering tasks. The control terminal is equipped with a graphics processor for multi-threaded parallel execution of logical data calculation and synchronization determination.

[0020] Multiple rendering ends are used to store and compute rendering data, receive and parse synchronization data packets, and execute the rendering pipeline in parallel. Each rendering end is equipped with a graphics processor and supports hardware instantiation rendering and hardware picking.

[0021] The transport layer is used to build a data communication network between the control end and the rendering end. It uses a local area network or a high-speed interconnected network to transmit synchronous data packets and control commands.

[0022] The display end is used to receive the local rendered images output by each rendering end and stitch them together for display, supporting multi-screen splicing to output high-resolution images.

[0023] The system operates based on the Sort-First parallel rendering mode, with the control terminal acting as the master node and each rendering terminal acting as a slave node, employing a master-slave synchronization mechanism.

[0024] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the complex scene graphics rendering method described in any of the preceding claims.

[0025] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. This invention separates logical data from rendering data, allowing the control end to focus on logical calculations while multiple rendering ends execute rendering tasks in parallel. This fully leverages the advantages of cluster computing, combining GPU multi-threaded parallel computation of logical data to effectively reduce CPU load. This increases the system frame rate from approximately 22fps in traditional single-machine solutions to over 60fps, achieving an optimization rate of over 200%. Furthermore, this improvement is particularly noticeable in large-scale scenarios (such as 60×10). 7 Even in triangular facets, it can still maintain a stable and smooth display of over 30fps; 2. Furthermore, by using view frustum clipping to predict whether dynamic entities fall into the screen space, a large number of objects that do not need to be synchronized are filtered out, significantly reducing network communication load. At the same time, a structured synchronization data packet (including verification identifier, frame number, observation / projection matrix and state data) is used in conjunction with a master-slave parsing mechanism to ensure a high degree of consistency in the behavior and state of dynamic models on multiple rendering ends, with no tearing or misalignment in the spliced ​​screen and the frame rate difference controlled within 2fps. 3. By adopting graphics hardware instantiation technology, multiple instances of the same mesh model are merged into a rendering batch and submitted to the GPU, avoiding frequent drawing calls and switching on the CPU side. In a scenario with 50,000 model instances, the rendering batch can be reduced from 50,000 to 1, significantly improving the frame rate while minimizing the increase in memory usage, thus balancing efficiency and resource consumption. 4. The present invention adopts a hardware picking method based on RTT texture, which encodes scene primitive information into color texture, and directly calculates the selected target based on the mouse position. It reduces the O(n) high-order operation of traditional CPU traversal and intersection to O(1) low-order operation, and the single picking time is reduced from 215ms to less than 86ms. It does not block the frame loop and the interactive experience is smooth. 5. This invention is compatible with various complex and dynamic scenarios such as digital twin workshops, smart mines, underwater warfare simulation, and large-scale situational awareness displays. It supports high-resolution splicing output and provides a highly efficient, stable, and scalable general rendering architecture for large-scale visualization systems. Attached Figure Description

[0026] Figure 1 This is a block diagram of the overall structure of the present invention; Figure 2 This is a diagram illustrating the steps of multi-threaded parallel computation of logical data in this invention. Figure 3 This is a diagram illustrating the steps of generating and parsing synchronization data packets in this invention; Figure 4 This is a diagram illustrating the screen space division and splicing rendering steps in this invention; Figure 5 This is a diagram illustrating the graphics hardware pickup steps in this invention. Detailed Implementation

[0027] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the following detailed description of the specific implementation methods, structures, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided below.

[0028] Please see Figure 1-5 As shown, a method for rendering graphics in a complex scene includes the following steps: Step S1: Data partitioning and distribution.

[0029] The 3D scene data is divided into logical data and rendering data. The logical data includes at least the state data of dynamic entities, collision detection data, and process logic data, which are held and managed by the control terminal. The rendering data includes at least the model vertex data, texture data, and mesh data, which are held and managed by multiple rendering terminals. Through data-level decoupling, computationally intensive tasks (logic calculations) and graphics-intensive tasks (rendering) can run independently on different hardware nodes, avoiding the problem of CPU and GPU competing for system bus and memory bandwidth in traditional single-machine architectures, and laying the architectural foundation for subsequent parallel processing. After separating logical data from rendering data, the control end can focus on logical operations such as dynamic entity state updates, collision detection, and synchronization determination, while the rendering end can focus on rendering pipeline operations such as vertex transformation, rasterization, and pixel output. The two do not interfere with each other, realizing the rational allocation and efficient utilization of computing resources and graphics resources. This data partitioning method gives the system good scalability. When the scene scale increases, the rendering capability can be linearly improved by adding rendering end nodes without major adjustments to the software architecture.

[0030] Step S2: Multi-threaded parallel computation of logical data.

[0031] The control end uses a multi-threaded parallel computation of the logical data based on the graphics processor. Specifically, this includes: transferring the logical data to the video memory via a buffer; having multiple GPU threads concurrently perform motion state calculations and synchronization determination calculations; and implementing synchronization determination based on view frustum clipping. This involves calculating the normalized device coordinates (NDC) of the eight vertices of the bounding box of a dynamic entity after transformation by the projection matrix and the view matrix. If at least one vertex coordinate falls within the range of [-1,1], the entity is determined to require synchronization; otherwise, the entity is filtered out and not included in the synchronization data packet. The control end uses a multi-threaded parallel computation of the logical data based on the GPU. By calculating the position of the vertices of the bounding box of the dynamic entity in the view space, it determines whether the entity falls within the view frustum range, thereby filtering out entities that do not need synchronization and only marking entities that need synchronization. Traditional CPUs serially process the state updates and view frustum clipping of thousands of dynamic entities, with frame times reaching tens of milliseconds. This invention utilizes hundreds or thousands of GPU computing cores for parallel processing, assigning the bounding box vertex transformation and synchronization determination of each entity to an independent thread for execution. This improves computational efficiency by more than 10 times, effectively freeing up CPU resources for scene management and rendering instruction generation. Through view frustum culling prediction, only dynamic entities located within or potentially entering the screen space are included in the synchronization data packet, filtering out a large number of entities outside the screen. In typical scenarios, approximately 60% to 80% of dynamic entities are outside the view frustum. After filtering, the amount of synchronization data is significantly reduced, effectively alleviating network bandwidth pressure in distributed systems. The bounding box-based determination method has the advantages of simple computation and accurate determination, ensuring that all dynamic entities that may affect the current frame are synchronized in a timely manner, avoiding screen logic errors caused by synchronization failures.

[0032] Step S3: Generate synchronization data packets.

[0033] The control terminal generates a synchronization data packet based on the judgment result. The synchronization data packet includes: a verification data area, containing a verification identifier and frame sequence number, used to verify the legality of the data packet and frame matching; a fixed data area, containing the observation matrix and projection matrix of the current frame, used to synchronize the rendering tasks of each rendering terminal; a variable data area, containing the state data type of the entity to be synchronized and the corresponding state change matrix. If no entity needs to be synchronized, this area is empty. The verification data area ensures the legality of data transmission and the consistency of frame order, preventing data corruption caused by network packet loss or out-of-order delivery; the fixed data area uniformly manages the observation matrix and projection matrix shared by all rendering terminals, ensuring consistent perspectives across terminals; the variable data area only contains the state data of the entity to be synchronized, with no redundant information, minimizing the data packet size.

[0034] Step S4: Synchronize data transmission and parsing.

[0035] The control terminal sends synchronization data packets to each rendering terminal via the network transport layer. Upon receiving the packets, each rendering terminal executes the parsing process: first, it verifies the identifier and frame sequence number; if they do not match, the data packet is discarded; second, it reads the observation matrix and projection matrix and updates the local camera's frustum parameters; then, it triggers the corresponding state machine event based on the state data type to update the pose matrix of the dynamic entity. The control terminal sends the synchronization data packets to each rendering terminal via the network, and each rendering terminal verifies and parses the data packets, updating the local camera parameters and the pose of the dynamic entity.

[0036] Step S5: Parallel rendering and image stitching.

[0037] Each rendering endpoint independently executes the rendering pipeline based on the updated data, including frustum culling, vertex shading, geometry shading, rasterization, and pixel processing, outputting local rendered images. These local rendered images are then stitched together according to screen space divisions to form a complete frame image. The screen space division is achieved based on scaling and translation transformations of the projection matrix. Each rendering endpoint corresponds to a sub-region of the original single-machine frustum normalized view space. Each rendering endpoint independently executes the rendering pipeline to output local images, which are then stitched together by the display endpoint according to screen space divisions to form a complete frame image.

[0038] Step S6: Graphics hardware acquisition.

[0039] In response to user interaction, a hardware picking method is used to determine the selected target object: a Render Target Texture (RTT) surface is created, and the geometric structure and pointer information of all primitives in the scene are encoded into RGB color values ​​and rendered to the RTT surface through a shader; the color value of the corresponding pixel on the RTT surface is read according to the mouse position, and the target object identifier is calculated in reverse. There is no need for the CPU to perform traversal and intersection operations. The control end uses GPU multi-threaded parallel execution of logical data calculation, and the logical data is transferred to the video memory through a buffer for concurrent calculation by multiple GPU threads.

[0040] Step S7: Merge rendering batches.

[0041] When submitting a drawing call, each rendering end uses graphics hardware instantiation technology to merge multiple instances of the same mesh model into a rendering batch and submit it to the GPU. The merging is based on texture transfer of the world matrix or vertex cache writing. After merging, vertex data and instantiation matrix array are submitted at once.

[0042] The present invention also provides a complex scene graphics rendering system, comprising: The control terminal is used to store and calculate logical data, generate synchronization data packets, and manage the allocation of rendering tasks. The control terminal is equipped with a graphics processor for multi-threaded parallel execution of logical data calculation and synchronization determination.

[0043] Multiple rendering endpoints are used to store and compute rendering data, receive and parse synchronization data packets, and execute the rendering pipeline in parallel. Each rendering endpoint is equipped with a graphics processor, supporting hardware instantiation rendering and hardware picking.

[0044] The transport layer is used to build a data communication network between the control end and the rendering end. It uses a local area network or a high-speed interconnected network to transmit synchronous data packets and control commands.

[0045] The display end is used to receive the local rendered images output by each rendering end and stitch them together for display, supporting multi-screen splicing to output high-resolution images.

[0046] The system operates based on the Sort-First parallel rendering mode, with the control terminal acting as the master node and each rendering terminal acting as a slave node, employing a master-slave synchronization mechanism.

[0047] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the complex scene graphics rendering method described in any of the preceding claims.

[0048] Example 1: Multi-threaded Parallel Computation of Logical Data and Synchronization of Dynamic Entities This embodiment uses a circuit breaker digital twin workshop as an application scenario. This scenario includes 6 production lines, 24 processes, 47,415 component models, and a total of approximately 6.71 × 102 triangular facets. 7 There are approximately 2,000 dynamic entities (such as moving circuit breakers and operating robotic arms); The control-end CPU first loads the model data of all dynamic entities in the scene, obtains their bounding box information (including the coordinates of the center point and the length of the half axis of length, width, and height) and motion state matrix Q, which is obtained by combining the translation matrix T, the scaling matrix S and the rotation matrix R: Q = S × R_x × R_y × R_z × T; The control unit allocates four buffers in the video memory: a bounds buffer (stores the bounding boxes of all entities), a VPMatrix buffer (stores the view matrix and projection matrix of the current frame), a WorldMatrixBuffer buffer (stores the motion state matrix of each entity), and a results buffer (stores the synchronization determination results). Then, it starts a multi-threaded GPU kernel, with the number of threads equal to the total number of dynamic entities. Each thread executes independently: reading the bounding box of the corresponding entity and calculating the coordinates of its eight vertices; multiplying each vertex sequentially by the motion state matrix Q, view matrix V, and projection matrix M, and performing perspective division to obtain normalized device coordinates (NDC); if the x, y, and z components of any vertex are all within the range [-1, 1], then the entity index is written to the results buffer to mark it as requiring synchronization. Testing showed that using the above GPU multi-threaded method, the synchronization determination calculation for 2000 dynamic entities takes approximately 2ms, while the traditional CPU serial method takes approximately 25ms. Each frame, the control end generates a synchronization data packet based on the judgment result: the verification data area contains a 4-byte verification identifier (0x5A5A5A5A) and a 4-byte frame sequence number; the fixed data area contains 64 bytes each of the observation matrix and projection matrix; the variable data area stores the state data type (1 byte) and state change matrix (16 bytes) of the entity to be synchronized in sequence. If no entity needs to be synchronized, the variable data area only contains the heartbeat command (0xFF). After receiving the data packet, the rendering end verifies the verification identifier and frame sequence number, reads the observation matrix and projection matrix to update the local camera parameters, traverses the variable data area to trigger state machine events according to the state data type, and updates the position and pose of the specified entity. Experiments show that the frame rate difference Δf between the four rendering ends does not exceed 2fps, and the dynamic model state in the stitched image is completely consistent, without tearing or misalignment.

[0049] Example 2: Multi-screen rendering task allocation and hardware instantiation batch merging This embodiment uses a large-scale aircraft formation scene displayed by stitching together four rendering ends as an example to illustrate the rendering task division and batch optimization method. The scene contains 50,000 aircraft models of the same model, each with approximately 800 triangles. Based on the normalized view space (NDC) coordinate range [-1,1], the screen is uniformly divided into four 2×2 sub-regions: top left (x∈[-1,0], y∈[0,1]), top right (x∈[0,1], y∈[0,1]), bottom left (x∈[-1,0], y∈[-1,0]), and bottom right (x∈[0,1], y∈[-1,0]). For each rendering end, its own projection matrix is ​​obtained by translating and scaling the original single-machine system projection matrix P. Taking rendering end 1 (top left) as an example, let the left boundary l'=0, the right boundary r'=(rl) / 2, the lower boundary b'=0, and the upper boundary t'=(tb) / 2 of the near clipping plane, and substitute them into the projection matrix formula to obtain P1. Each rendering end only renders the model in the corresponding sub-region, and finally the four output images are seamlessly stitched into a complete picture, with a total resolution of 5464×3072; In terms of batch optimization, hardware instantiation (HW Instancing Basic) technology is adopted: each instance is allocated a texture coordinate channel in the vertex cache to store the four row vectors of its world matrix. The DrawIndexedInstanced() or glDrawElementsInstanced() interface is called to submit all instances at once. In the vertex shader, the current instance index is obtained through SV_InstanceID, and the corresponding world matrix is ​​read to complete the vertex transformation. After optimization, the rendering batch size is reduced from 50,000 to 1, the frame rate is increased from about 30fps to more than 60fps, and the memory usage is reduced from 1927MB to 315MB, saving about 84%.

[0050] Example 3: Graphics Hardware Acquisition and Complete System Operation Flow This embodiment takes the complete operation of a smart mine 3D visualization system as an example to illustrate the hardware acquisition method and the overall system process; After the system starts, the control terminal loads the mine surface DOM image, DEM elevation data, underground tunnel and equipment models, and divides the scene into logical data (equipment operating status, personnel location, sensor values) and rendering data (model mesh, texture). The IoT sensing layer collects data such as personnel location and gas concentration in real time and uploads it to the control terminal. The control terminal runs GPU multi-threaded logic calculations every frame, generates synchronous data packets and sends them to four rendering terminals via gigabit Ethernet multicast. After parallel rendering by each rendering terminal, the data is spliced ​​and output to a 4096×2160 spliced ​​large screen, with the frame rate stable at over 45fps. In terms of human-computer interaction, a hardware picking method is adopted to optimize target selection. An RTT texture (with the same size as the screen and format R32G32B32A32_FLOAT) is created in the video memory. Switching to the picking shader, each primitive's unique ID is encoded as an RGB color value and written to the RTT as pixel output. No lighting or texture calculations are performed. When the user clicks the screen coordinates (x,y), the CPU calls glReadPixels() to read the corresponding pixel color of the RTT and decodes it to obtain the primitive ID, directly locating the target. The traditional CPU ray intersection method takes about 215ms in a 50,000 model scene, while the hardware picking method only takes 86ms, reducing the time by more than 60%, and does not block the main rendering loop. When an administrator clicks on a device on the screen, the system can locate it and pop up the attribute panel within 32ms, resulting in smooth interaction.

[0051] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any indirect modifications, equivalent changes, and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A method for rendering graphics in complex scenes, characterized in that, include: The 3D scene data is divided into logical data and rendering data. The logical data includes at least the state data of dynamic entities, collision detection data, and process logic data. The rendering data includes at least the model vertex data, texture data, and mesh data. The control unit performs multi-threaded parallel computation of the logical data based on the graphics processor, and determines the dynamic entities that need to be synchronized based on the view frustum clipping, and generates synchronization data packets. Multiple rendering ends receive the synchronization data packets, parse and update the state of local dynamic entities, execute rendering pipeline processing in parallel, and output local rendered images. The local rendered images output by each rendering end are stitched together into a complete frame image according to the screen space.

2. The method for rendering graphics in a complex scene according to claim 1, characterized in that, The frustum clipping determination includes: Calculate the normalized device coordinates of the bounding box vertices of a dynamic entity after transformation by the projection matrix and the view matrix; If at least one vertex coordinate falls within the range of standardized device coordinates, the entity is determined to need synchronization; otherwise, the entity is filtered out.

3. The method for rendering graphics in a complex scene according to claim 1, characterized in that, The synchronization data includes: The verification data area contains the verification identifier and frame sequence number; A fixed data area containing the observation matrix and projection matrix of the current frame; The variable data area contains the state data types of the entities that need to be synchronized and the corresponding state change matrices.

4. The method for rendering graphics in a complex scene according to claim 1, characterized in that, Before the rendering end performs parallel rendering pipeline processing, it also includes: Update the frustum parameters of the local camera based on the observation matrix and projection matrix obtained from the analysis. Trigger the corresponding state machine event based on the state data type to update the pose matrix of the dynamic entity.

5. A method for rendering graphics in a complex scene according to claim 1, characterized in that, The screen space division is based on the scaling and translation transformation of the projection matrix. Each rendering end corresponds to a sub-region of the original single-machine view frustum normal view space. The sub-regions are stitched together to cover the entire screen.

6. The method for rendering graphics in a complex scene according to claim 1, characterized in that, When the control terminal uses a multi-threaded parallel computation of logic data by a graphics processor, the logic data is transmitted to the video memory through a buffer. Multiple GPU threads concurrently perform motion state calculations and synchronization determinations, and the calculation results are sent back to memory for packaging.

7. A complex scene graphics rendering system, characterized in that, include: The control unit is used to store and compute logical data, generate synchronization data packets, and manage the allocation of rendering tasks. Multiple rendering ends are used to store and compute rendering data, receive and parse synchronization data packets, and execute the rendering pipeline in parallel; The transport layer is used to build the data communication network between the control end and the rendering end. The display end is used to receive the local rendered images output by each rendering end and stitch them together for display.

8. A complex scene graphics rendering system according to claim 7, characterized in that, The rendering end uses graphics hardware instantiation technology to merge multiple instances of the same mesh model into a rendering batch and submit it to the GPU. The merging process is implemented based on texture transfer of the world matrix or vertex cache writing.

9. A complex scene graphics rendering system according to claim 7, characterized in that, The display or control terminal also supports graphics hardware picking, which renders scene primitive information as color textures and calculates the selected target based on the mouse position to avoid the CPU performing traversal and intersection calculations.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the program implements the steps of the complex scene graphics rendering method as described in any one of claims 1 to 6.

Images