A rendering method and apparatus of a merged model

Abstract

The present disclosure relates to a rendering method and device of a merged model. The method comprises: obtaining a merged model indicated by a viewing instruction, and a single mapping table corresponding to the merged model, wherein the merged model is obtained by merging a plurality of single models, the single mapping table is used to indicate a mapping relationship between a geometry index range of the merged model and a single identifier of the single model, and the single identifier is used to indicate a unique identity of the corresponding single before merging; determining a rendering index range corresponding to rendering data of the merged model, and searching the single mapping table to write at least one single identifier corresponding to the rendering index range into the rendering data; rendering the rendering data to obtain a plurality of screen pixels, and matching a single identifier corresponding to a rendering index where the screen pixel is located with the screen pixel. The technical problem that the related art cannot identify the single model is solved, thereby realizing single-level independent visual control.

Description

Technical Field

[0001] This disclosure relates to the field of data processing technology, specifically to a rendering method and apparatus for a merged model. Background Technology

[0002] In modern smart city and digital twin applications, real-time rendering and individual unit-level interactive recognition of large-scale 3D scenes are core technological challenges. With the integration of city-level BIM (Building Information Modeling) and GIS (Geographic Information System) data, scenes often contain millions of independent units (such as buildings, roads, and vegetation). To improve rendering performance, the industry commonly uses mesh merging technology to merge and submit a large number of units, but this results in the inability to recognize the original units at runtime. In other words, while merging individual unit models to improve rendering performance, related technologies suffer from the technical problem of being unable to recognize individual unit models. Summary of the Invention

[0003] The purpose of this disclosure is to provide a rendering method and apparatus for merging models, which matches individual unit identifiers with pixels during the rendering stage to achieve the identification of individual unit models.

[0004] In a first aspect, embodiments of this disclosure provide a rendering method for a merged model, comprising: obtaining a merged model indicated by a viewing command, and a single-unit mapping table corresponding to the merged model, wherein the merged model is obtained by merging multiple single-unit models, the single-unit mapping table is used to indicate the mapping relationship between the geometric index range of the merged model and the single-unit identifier of the single-unit model, and the single-unit identifier is used to indicate the unique identity of the corresponding single-unit before merging; determining the rendering index range corresponding to the rendering data of the merged model, and searching the single-unit mapping table, and writing at least one single-unit identifier corresponding to the rendering index range into the rendering data; rendering the rendering data to obtain multiple screen pixels, and matching the single-unit identifier corresponding to the rendering index of the screen pixel with the screen pixel.

[0005] Optionally, before obtaining the individual entity mapping table corresponding to the merged model, the process includes: determining the original information of the individual entity model based on the type of the individual entity model, wherein the original information is used to indicate the information of the individual entity model; and generating the individual entity identifier corresponding to the individual entity model based on the original information of the individual entity model.

[0006] Optionally, the original information of the individual model is determined based on the type of the individual model, including at least one of the following: when the individual model originates from a building information modeling system, the original information is a building component identifier, wherein the building component identifier includes at least one of a professional code, floor number, component type, and component serial number; when the individual model originates from a 3D scene editor, the original information is a scene node identifier, wherein the scene node identifier includes hierarchical path information; when the individual model originates from a business management system, the original information is a business object identifier, wherein the business object identifier includes at least one of a database primary key, asset code, and Uniform Resource Locator.

[0007] Optionally, generating a single entity identifier corresponding to the single entity model based on the original information of the single entity model includes: determining multiple boundary points and hierarchical parameters of the single entity model based on the original information of the single entity model, wherein the hierarchical parameters are used to indicate the node hierarchy to which the single entity model belongs in the merged model; converting the point coordinates corresponding to the multiple boundary points into their respective index coordinates based on the hierarchical parameters; and obtaining the single entity identifier corresponding to the single entity model based on the hierarchical parameters and the multiple index coordinates.

[0008] Optionally, searching the individual unit mapping table and writing at least one individual unit identifier corresponding to the rendering index range into the rendering data includes: searching the individual unit mapping table, determining multiple individual unit identifiers, and individual unit index ranges corresponding to each of the multiple individual unit identifiers, wherein the rendering index range is the geometric index range of the rendering data, the individual unit index range is the geometric index range of the individual unit model, and the geometric index range of the merged model includes the rendering index range and the individual unit index range; determining the individual unit index ranges that intersect with the rendering index ranges, and determining the intersecting part as the rendering index sub-range; and writing the individual unit identifier corresponding to the rendering index sub-range into the rendering data based on the rendering index sub-range.

[0009] Optionally, writing the individual identifier corresponding to the rendering index sub-range into the rendering data based on the rendering index sub-range includes one of the following: when the rendering data is a sub-fragment of a merged model, writing the rendering index sub-range and the individual identifier corresponding to the rendering index sub-range into the rendering data; when the rendering data is rendering batch data, determining the individual identifier corresponding to each of the rendering batch data based on the rendering index sub-range, and writing the individual identifier into the rendering batch data.

[0010] Optionally, rendering the rendering data to obtain multiple screen pixels includes: writing the rendering data and at least one individual identifier into a graphics processor's buffer; obtaining at least one individual identifier from the buffer through a vertex shader, determining the individual identifier as a discrete attribute and sending it to a pixel shader, wherein the individual identifier is not interpolated; coloring the rendering data through the pixel shader to obtain multiple screen pixels corresponding to the rendering data, and writing the texture information and individual identifier corresponding to the screen pixels into a geometry buffer; wherein writing the rendering data and individual identifier into the graphics processor's buffer includes at least one of the following: when multiple rendering data included in the merged model all correspond to one individual identifier, writing the rendering data and individual identifier into a constant buffer of the graphics processor, wherein the constant buffer is used to store data that remains unchanged during a drawing process; writing at least one individual identifier into at least one graph data element of the rendering data, wherein the individual identifier corresponds one-to-one with the graph data element; when the rendering data is rendering batch data, writing the individual identifier into an instance buffer, wherein the instance buffer is used to store data corresponding to a single instance included in the rendering batch data.

[0011] Secondly, embodiments of this disclosure provide a rendering apparatus for a merged model, comprising: an acquisition module, configured to acquire a merged model indicated by a viewing command, and a single-unit mapping table corresponding to the merged model, wherein the merged model is obtained by merging multiple single-unit models, the single-unit mapping table is used to indicate the mapping relationship between the geometric index range of the merged model and the single-unit identifier of the single-unit model, and the single-unit identifier is used to indicate the unique identity of the corresponding single-unit before merging; a single-unit identifier determination module, configured to determine the rendering index range corresponding to the rendering data of the merged model, and search the single-unit mapping table, and write at least one single-unit identifier corresponding to the rendering index range into the rendering data; and a rendering module, configured to render the rendering data to obtain multiple screen pixels, and match the single-unit identifier corresponding to the rendering index of the screen pixel with the screen pixel.

[0012] Optionally, the acquisition module is further configured to: determine the original information of the single-unit model based on the type of the single-unit model, wherein the original information is used to indicate the information of the single-unit model; and generate the single-unit identifier corresponding to the single-unit model based on the original information of the single-unit model.

[0013] Optionally, the acquisition module is further configured to: when the individual unit model originates from a building information modeling system, the original information is a building component identifier, wherein the building component identifier includes at least one of a professional code, floor number, component type, and component serial number; when the individual unit model originates from a 3D scene editor, the original information is a scene node identifier, wherein the scene node identifier includes hierarchical path information; when the individual unit model originates from a business management system, the original information is a business object identifier, wherein the business object identifier includes at least one of a database primary key, asset code, and Uniform Resource Locator.

[0014] Optionally, the acquisition module is further configured to: determine multiple boundary points and hierarchical parameters of the individual model based on the original information of the individual model, wherein the hierarchical parameters are used to indicate the node hierarchy to which the individual model belongs in the merged model; convert the point coordinates corresponding to the multiple boundary points into their respective index coordinates based on the hierarchical parameters; and obtain the individual identifier corresponding to the individual model based on the hierarchical parameters and the multiple index coordinates.

[0015] Optionally, the single-unit identifier determination module is further configured to: look up a single-unit mapping table, determine multiple single-unit identifiers, and single-unit index ranges corresponding to each of the multiple single-unit identifiers, wherein the rendering index range is the geometric index range of the rendering data, the single-unit index range is the geometric index range of the single-unit model, and the geometric index range of the merged model includes the rendering index range and the single-unit index range; determine the single-unit index ranges that intersect with the rendering index ranges, and determine the intersecting part as a rendering index sub-range; and write the single-unit identifiers corresponding to the rendering index sub-ranges into the rendering data based on the rendering index sub-ranges.

[0016] Optionally, the individual identifier determination module is further configured to: when the rendering data is a sub-fragment of a merged model, write the rendering index sub-range and the individual identifier corresponding to the rendering index sub-range into the rendering data; when the rendering data is rendering batch data, determine the individual identifier corresponding to each of the rendering batch data based on the rendering index sub-range, and write the individual identifier into the rendering batch data.

[0017] Optionally, the individual identifier determination module is further configured to: write rendering data and at least one individual identifier into a buffer of the graphics processor; obtain at least one individual identifier from the buffer through the vertex shader, determine the individual identifier as a discrete attribute and send it to the pixel shader, wherein the individual identifier is not interpolated; color the rendering data through the pixel shader to obtain multiple screen pixels corresponding to the rendering data, and write the texture information and individual identifier corresponding to the screen pixels into a geometry buffer; when multiple rendering data included in the merged model correspond to one individual identifier, write the rendering data and individual identifier into a constant buffer of the graphics processor, wherein the constant buffer is used to store data that remains unchanged during a drawing process; write at least one individual identifier into at least one graph data element of the rendering data, wherein the individual identifier corresponds one-to-one with the graph data element; when the rendering data is rendering batch data, write the individual identifier into an instance buffer, wherein the instance buffer is used to store data corresponding to a single instance included in the rendering batch data.

[0018] Thirdly, embodiments of this disclosure provide a computer-readable storage medium having a computer program stored thereon, characterized in that the program, when executed by a processor, implements the method as described in the first aspect above.

[0019] Fourthly, embodiments of this disclosure provide a computing device, including: a memory for storing a computer program; and a processor for executing the computer program stored in the memory, wherein when the computer program is executed, it implements the method as described in the first aspect above.

[0020] In this embodiment of the disclosure, the merged model indicated by the viewing command and the individual unit mapping table corresponding to the merged model are obtained. The merged model is obtained by merging multiple individual unit models. The individual unit mapping table is used to indicate the mapping relationship between the geometric index range of the merged model and the individual unit identifier of the individual unit model. The individual unit identifier is used to indicate the unique identity of the corresponding individual unit before merging. The rendering index range corresponding to the rendering data of the merged model is determined, and the individual unit mapping table is searched. At least one individual unit identifier corresponding to the rendering index range is written into the rendering data. The rendering data is rendered to obtain multiple screen pixels, and the individual unit identifier corresponding to the rendering index of the screen pixel is matched with the screen pixel.

[0021] By introducing a single-unit mapping table, a mapping relationship is established between the merged geometric index range and the single-unit identifier. The single-unit identifier is then injected into the graphics processor along with the rendering data, ultimately achieving precise matching of single-unit identifiers at the screen pixel level. This resolves the inherent contradiction between merged rendering and single-unit recognition in large-scale 3D visualization scenes. The mapping table preserves the association between geometric range and single-unit identity, allowing each screen pixel to directly carry the single-unit identifier of its visible surface. During interaction, only constant-complexity texture sampling is required to obtain pixel-level precise single-unit identity. Furthermore, the recognition data comes directly from the rendering pipeline output and undergoes the same depth testing and filtering as color and depth, eliminating the inconsistency between the CPU's hit detection and the graphics processor's actual rejection of data. Based on the single-unit identifier carried by the pixel, the system can also perform conditional judgments on each pixel in the post-processing stage, enabling independent visualization control such as single-unit highlighting, outlining, hiding, and isolation without modifying the original geometry or adding drawing calls. This reduces system complexity and memory usage, achieving a balance between rendering performance and interactive functionality in large-scale scenarios such as smart cities and digital twins. Attached Figure Description

[0022] The accompanying drawings, which are included to provide a further understanding of this disclosure and form part of this disclosure, illustrate exemplary embodiments of the present disclosure and are used to explain the disclosure, but do not constitute an undue limitation of the disclosure. In the drawings: Figure 1 This is a schematic diagram of an optional merging model rendering method and its hardware environment according to an embodiment of the present disclosure; Figure 2 This is a flowchart of an optional rendering method for a merged model according to an embodiment of the present disclosure; Figure 3 This is a schematic diagram of an optional merging model rendering process according to an embodiment of the present disclosure; Figure 4 This is a schematic diagram of the interaction process of an optional merging model according to an embodiment of the present disclosure; Figure 5 This is a schematic diagram of an optional rendering interface according to an embodiment of the present disclosure; Figure 6 This is a schematic diagram of an optional merging model rendering apparatus according to an embodiment of the present disclosure; Figure 7 This is a schematic diagram of an optional electronic device according to an embodiment of the present disclosure. Detailed Implementation

[0023] The present disclosure will be further described in detail below with reference to the accompanying drawings and embodiments. Through these descriptions, the features and advantages of the present disclosure will become clearer and more apparent.

[0024] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments. Although various aspects of embodiments are shown in the accompanying drawings, the drawings are not necessarily drawn to scale unless specifically indicated otherwise.

[0025] Furthermore, the technical features involved in the different embodiments of this disclosure described below can be combined with each other as long as they do not conflict with each other.

[0026] According to one aspect of the embodiments of this disclosure, a rendering method for merging models is provided. As an optional implementation, the above-described rendering method for merging models can be applied, but is not limited to, to applications such as... Figure 1 The rendering system for the merged model is shown. This rendering system may include, but is not limited to, terminal device 101, network 105, and server 106. Terminal device 101 runs a target client. For example... Figure 1 In the illustrated embodiment, the target client is a client capable of viewing and interacting with a 3D model. The terminal device 101 includes a memory 102, a processor 103, and a display 104. The display 104 can be used to display text information, image information, etc., of the object, and also provides a human-computer interaction interface to receive human-computer interaction operations such as selecting objects in the object interaction platform and touching different controls. The processor 103 is used to generate interaction instructions in response to the aforementioned human-computer interaction operations, and sends the interaction instructions to the server 106 via the network 105 to obtain the model information of the 3D model. The memory is used to store information about the screen pixels obtained from rendering the 3D model.

[0027] In addition, server 106 includes database 107 and processing engine 108, which is used to perform store or read operations on database 107. Specifically, processing engine 108 reads 3D model data from database 107.

[0028] According to this embodiment, Figure 1 The terminal device 101 runs a client for interacting with the 3D model. When the client on the terminal device 101 receives a viewing command sent by the user to the terminal device 101, the specific process in this embodiment is as follows: In step S101, terminal device 101 sends a viewing command to server 106 via network 105; In step S102, server 106 sends the merged model and the corresponding individual unit mapping table to terminal device 101 via network 105. The merged model is obtained by merging multiple individual unit models. The individual unit mapping table is used to indicate the mapping relationship between the geometric index range of the merged model and the individual unit identifier of the individual unit model. The individual unit identifier is used to indicate the unique identity of the corresponding individual unit before merging. In step S103, after the terminal device 101 obtains the merged model indicated by the viewing instruction and the single-unit mapping table corresponding to the merged model, it determines the rendering index range corresponding to the rendering data of the merged model. In step S104, the terminal device 101 searches the single-unit mapping table and writes at least one single-unit identifier corresponding to the rendering index range into the rendering data. In step S105, the terminal device 101 renders the rendering data to obtain multiple screen pixels; In step S106, the terminal device 101 matches the individual identifier corresponding to the rendering index of the screen pixel with the screen pixel.

[0029] Optionally, in this embodiment, the terminal device 101 can be a terminal device configured with a target client, which may include, but is not limited to, at least one of the following: mobile phone (such as Android phone, iOS phone, etc.), laptop computer, tablet computer, PDA, MID (Mobile Internet Devices), PAD, desktop computer, smart TV, etc. The target client can be a social client, e-commerce client, browser client, or other client that supports rendering tasks that provide merged models. The network may include, but is not limited to, wired networks and wireless networks. The wired network includes local area networks (LANs), metropolitan area networks (MANs), and wide area networks (WANs). The wireless network includes Bluetooth, Wi-Fi, and other networks that enable wireless communication. The server may be a single server, a server cluster consisting of multiple servers, or a cloud server. The above is merely an example, and no limitations are imposed in this embodiment.

[0030] Optionally, in this embodiment, the above-mentioned rendering method for merging models can be applied, but is not limited to, to a smart city digital twin platform. The city-level digital twin platform loads a 3D model of the entire city, containing hundreds of thousands of buildings, roads, bridges, underground pipe networks, etc. To achieve smooth rendering, the system merges buildings in the same area into a few grid batches. City maintenance personnel need to quickly locate specific buildings for inspection. When a manager clicks on any building on the screen, the system uses pixel-level FID lookup to accurately identify that the clicked building is the "Central Building" rather than an adjacent building, and pops up an attribute panel displaying the building's area, floor height, construction year, property information, and occupant units. Managers can also select an area to statistically analyze the number of buildings, type distribution, and land area within that area, generating operational reports.

[0031] Optionally, in this embodiment, the above-mentioned rendering method for merging models can be applied, but is not limited to, to collaborative design and construction review of Building Information Modeling (BIM). Large-scale projects' BIM models contain over 50,000 components (walls, columns, beams, doors, windows, MEP lines, etc.). When designers, contractors, and owners conduct online collaborative reviews, they need to frequently switch between viewing components from different disciplines and floors, but fully loading all independent components results in a low frame rate. The system merges and renders components from the same floor and discipline, but retains the identity of each beam and window through component-level FID. When a reviewer selects a duct, the system can highlight the component and its upstream and downstream connecting equipment, while semi-transparently hiding other discipline layers, leaving only the MEP lines visible. Clicking on any component allows viewing its BIM attributes: material specifications, manufacturer, installation date, maintenance records, associated drawing numbers, etc.

[0032] Optionally, in this embodiment, the above-described merging model rendering method can be applied, but is not limited to, industrial digital twins and predictive maintenance of equipment. Digital twin platforms for industrial projects need to link physical devices with 3D models in real time. For example, in power scenarios, hundreds of transformers, circuit breakers, and disconnectors are densely arranged, making merging rendering a performance necessity. When a transformer's temperature sensor alarms, the platform needs to immediately locate the device in the 3D scene. The platform runs the above-described merging model rendering method. When the transformer temperature is abnormal, the platform automatically highlights the pixel area corresponding to the device's FID. Maintenance personnel can click on the device to view real-time telemetry curves for temperature, load, vibration, etc., as well as historical fault records, maintenance work orders, spare parts inventory, and other business information.

[0033] The above use cases are merely examples. The solution disclosed herein can be used in any scenario related to the rendering of merged models. This embodiment does not impose any limitations on it.

[0034] Figure 2This is a flowchart illustrating a rendering method for a merged model provided in this disclosure; such as Figure 2 As shown, this method can be applied to the above. Figure 1 In a terminal device within an architecture, the method may include the following steps: Step S201: Obtain the merged model indicated by the viewing command and the individual unit mapping table corresponding to the merged model. The merged model is obtained by merging multiple individual unit models. The individual unit mapping table is used to indicate the mapping relationship between the geometric index range of the merged model and the individual unit identifier of the individual unit model. The individual unit identifier is used to indicate the unique identity of the corresponding individual unit before merging. It should be noted that a view command can be a request issued by a user or an upper-layer application to load and display a specific 3D scene or model. This command typically includes information such as model identifier, view parameters, and loading range to drive the system to read the corresponding data resources from the storage medium.

[0035] Optionally, the merged model is a single mesh model formed by geometrically merging multiple independent individual models. During the merging process, the vertex data and index data of multiple individual models are continuously spliced ​​and stored, and the boundary information between the original individual models disappears at the geometric level. An individual model is the smallest three-dimensional object unit with independent business significance, such as a building, a road, a tree, or a building component. Each individual model has independent geometric data, material properties, and business identifiers before merging.

[0036] Optionally, during the process of merging individual models into a merged model, an individual model mapping table can be generated. This table is a data structure that records the correspondence between the geometric index range of the merged model and the original individual model identifiers. The geometric index range can be a set of parameters describing a continuous range of geometric data in the merged model, such as a vertex index range or a triangle index range, for example, from vertex 0 to vertex 999, or from index 0 to index 2999. The individual model identifier (Feature ID, FID) can be a unique numerical code assigned to each individual model, used to accurately distinguish different individual models in the merged model. This identifier remains unchanged before and after merging and serves as an index connecting rendered pixels and business attributes.

[0037] In an optional implementation, the system first responds to the view command, locates and reads the geometric data file of the merged model from the storage medium. This file contains core data required for rendering, such as the merged vertex buffer, index buffer, and material information. Simultaneously, the system reads the unit mapping table file associated with the merged model. After loading the above data, the system constructs runtime data structure associations in memory. For example, the geometric data of the merged model can be loaded into the rendering data structure, and the unit mapping table can be parsed into an index structure that can be queried by the rendering thread and interactive modules. The specific usage of the unit identifier will be explained later and will not be repeated here.

[0038] Step S202: Determine the rendering index range corresponding to the rendering data of the merged model, and look up the individual unit mapping table to write at least one individual unit identifier corresponding to the rendering index range into the rendering data. It's important to note that rendering data describes the complete data structure required for rendering the merged model on the graphics processor, including vertex buffers, index buffers, material references, and drawing parameters. The rendering index range is the actual geometric range involved in drawing within the current rendering frame; it's a subset of the merged model's geometric index range. Specific forms include vertex index ranges, triangle index ranges, and instance indexes. In other words, the index range can locate a continuous segment of geometric data. This set can be determined by visibility checks such as frustum culling and occlusion culling, representing the visible geometric range in the current frame that needs to be submitted to the graphics processor for rendering.

[0039] In an optional implementation, the system performs a visibility determination to define the rendering index range of the current frame. The rendering thread traverses all geometric ranges of the merged model, excluding portions outside the camera's field of view through view frustum culling, and optionally excluding portions completely occluded by other objects through occlusion culling, ultimately generating a list of visible geometric ranges for the current frame. Subsequently, for each geometric fragment in the rendering index range, the system queries a single-unit mapping table to determine the corresponding single-unit identifier.

[0040] Optionally, the query method depends on the storage structure of the mapping table. If the mapping table is organized by vertex index range, the geometric range of which individual unit the rendered fragment falls into is determined by comparing the starting index of the rendered fragment with the range boundary of the mapping table entry. If the mapping table is organized by rendering batch, the corresponding individual unit identifier is retrieved directly through the batch index. When the rendering index range spans the geometric boundaries of multiple individual units, the system splits the set into multiple subsets, each subset corresponding to an individual unit identifier.

[0041] After determining the individual unit identifier, it is written to the corresponding field in the rendering data structure. Optionally, an individual unit identifier field can be added to the sub-fragment data structure of the mesh, and the individual unit identifier of the current fragment can be assigned to this field; or, an individual unit identifier field can be added to the rendering batch data, so that each rendering batch carries the corresponding identifier; or, the individual unit identifier can be appended to the rendering batch as a custom constant parameter. After writing is completed, the rendering data contains all visible geometric fragments of the current frame and their corresponding individual unit identifier information, and the rendering thread can use this to generate drawing instructions carrying the individual unit identity.

[0042] Step S203: Render the rendering data to obtain multiple screen pixels, and match the individual identifier corresponding to the rendering index of the screen pixel with the screen pixel.

[0043] Rendering is the process of converting 3D geometric data into a 2D screen image through the graphics processing unit (GPU) pipeline, including stages such as vertex transformation, rasterization, and pixel shading. A screen pixel is the smallest image unit ultimately displayed on the screen, and each pixel has visual attributes such as color and transparency. The rendering index can be the actual geometric range involved in rendering in the current frame, corresponding to the pixel coverage area after rasterization by the GPU.

[0044] In an optional implementation, the system first synchronizes the rendering data and its contained individual unit identifiers to the graphics processor (GPU). The rendering thread binds the geometric data, index data, and individual unit identifier constants to the GPU resource slots and submits drawing commands. When the GPU executes the rendering pipeline, the vertex shader stage reads the individual unit identifiers for the current drawing batch from the bound constant buffer or custom data buffer. The vertex shader passes this identifier as a discrete attribute to the pixel shader stage. The pixel shader stage performs shading calculations, outputting regular geometry buffer information such as color, normals, and material parameters, while writing the received individual unit identifiers into the object identifier channel of the geometry buffer. At this point, the rendering pipeline is complete, and the geometry buffer output for each screen pixel location carries the individual unit identifiers of the visible surface at that location. The identifier buffer in the geometry buffer can be reserved as a texture resource, forming an identifier texture that is strictly consistent with the pixel locations of the depth buffer and color buffer. The specific rendering process will be described in detail for each sub-stage later; only a brief explanation is provided here.

[0045] By introducing a single-unit mapping table, a mapping relationship is established between the merged geometric index range and the single-unit identifier. The single-unit identifier is then injected into the graphics processor along with the rendering data, ultimately achieving precise matching of single-unit identifiers at the screen pixel level. This resolves the inherent contradiction between merged rendering and single-unit recognition in large-scale 3D visualization scenes. The mapping table preserves the association between geometric range and single-unit identity, allowing each screen pixel to directly carry the single-unit identifier of its visible surface. During interaction, only constant-complexity texture sampling is required to obtain pixel-level precise single-unit identity. Furthermore, the recognition data comes directly from the rendering pipeline output and undergoes the same depth testing and filtering as color and depth, eliminating the inconsistency between the CPU's hit detection and the graphics processor's actual rejection of data. Based on the single-unit identifier carried by the pixel, the system can also perform conditional judgments on each pixel in the post-processing stage, enabling independent visualization control such as single-unit highlighting, outlining, hiding, and isolation without modifying the original geometry or adding drawing calls. This reduces system complexity and memory usage, achieving a balance between rendering performance and interactive functionality in large-scale scenarios such as smart cities and digital twins.

[0046] The above scheme matches individual unit identifiers with screen pixels during the rendering process to identify individual unit identifiers and thus individual unit models. Therefore, a one-to-one correspondence between individual unit identifiers and individual unit models is necessary. The following section will explain the possible methods for generating individual unit identifiers: In an optional implementation, before obtaining the individual entity mapping table corresponding to the merged model, the process includes: determining the original information of the individual entity model based on the type of the individual entity model, wherein the original information is used to indicate the information of the individual entity model; and generating an individual entity identifier corresponding to the individual entity model based on the original information of the individual entity model.

[0047] The type of a single-unit model can refer to its data source or domain category, including Building Information Modeling (BIM) systems, 3D scene editors, business management systems, etc. Different types determine the encoding rules and semantic structure of the raw information. The raw information is the native identifier of the single-unit model within the source system, used to uniquely identify the object at the business level. The form of the raw information depends on the type of single-unit model, such as building component codes, scene node paths, or database primary keys.

[0048] It is important to note that before constructing the individual model mapping table, the system needs to assign a unique and standardized identity identifier to each individual model. Because 3D visualization projects involve diverse data sources, the original identifier formats generated by different systems vary, and directly mixing them can lead to conflicts or unresolved issues. Therefore, based on the data source type of the individual model, its original identity information is extracted and standardized to generate a unified individual identifier, providing a consistent identity encoding foundation for subsequent mapping table construction, rendering data writing, and pixel-level individual model matching.

[0049] In an optional implementation, the original information of the monomer model is determined based on the type of the monomer model, including at least one of the following: 1) When the individual building model originates from the building information modeling system, the original information is the building component identifier, which includes at least one of the following: professional code, floor number, component type, and component serial number; 2) When the individual model originates from the 3D scene editor, the original information is the scene node identifier, which contains hierarchical path information; 3) When the monolithic model originates from the business management system, the original information is the business object identifier, which includes at least one of the database primary key, asset code and Uniform Resource Locator.

[0050] It should be noted that building component identification can be a unique code assigned to each component in a building information modeling system. It typically consists of multiple semantic segments and is used to accurately identify and trace components throughout the entire lifecycle of a building project. The professional code can be an abbreviation of the engineering discipline to which the component belongs, such as architecture, structural engineering, mechanical and electrical engineering, etc. The floor number can identify the spatial floor location of the component. The component type can identify the geometric functional category of the component, such as wall, column, beam, slab, door, window, etc. The component sequence number can identify the sequential number of components of the same type within a specific range.

[0051] A scene node identifier is a unique identifier assigned to each scene object in a 3D scene editor. It is typically described as a hierarchical path representing the parent-child relationship of the node in the scene tree. Hierarchical path information describes the complete hierarchical chain of scene nodes from the root node to the current node, such as a nested structure of parent / child / grandchild nodes.

[0052] Business management systems are information systems used for enterprise asset management, facility operation and maintenance, production monitoring, and other business operations. These systems manage entity objects using database records. A business object identifier is a unique identifier assigned to each managed entity within the business management system, used for precise location and data association in business processes. A database primary key is an internal key value that uniquely identifies each record in a database table; it is typically an auto-incrementing integer or a globally unique identifier.

[0053] In an optional implementation, the system first determines the source type of the individual model and then extracts the original information according to the corresponding rules. For individual models originating from a Building Information Modeling (BIM) system, the system reads their building component identifiers. These identifiers are typically composed of multiple semantic segments, from which the system extracts at least one component as original information. For example, from ARC-03-W-015, the system extracts the professional code ARC (representing the architectural profession), the floor number 03 (representing the third floor), the component type W (representing a wall), and the component sequence number 015 (representing the fifteenth component of that type on that floor). All elements can be fully coded, or key elements can be selected for simplified coding based on the application scenario.

[0054] For single-unit models originating from the 3D scene editor, the system reads their scene node identifiers. These identifiers typically describe the node's position in the scene tree in the form of a hierarchical path, such as City / Block_03 / Building_12 / Floor_05 / Room_02 or L13. The system extracts this hierarchical path information as raw information; each level of node name in the path contains spatial or logical attribution semantics, which can be used to subsequently generate single-unit identifiers with hierarchical characteristics.

[0055] For monolithic models originating from the business management system, the system reads their business object identifiers. This identifier may be a purely numeric code in the form of a database primary key; it may also be a structured string in the form of an asset code; or it may be a network address in the form of a Uniform Resource Locator (URL). The system extracts at least one of these as raw information.

[0056] In an optional implementation, after extracting the original information, the system performs encoding conversion to generate standardized single-item identifiers. The conversion method depends on the form of the original information: if the original information is purely numeric and the numerical range is controllable, it is directly mapped to a single-item identifier; if the original information contains classification semantics, a segmented encoding strategy is adopted, combining the category code and the sequence number into a fixed-width integer; if the original information is in string form, it is converted into a numeric identifier through a hash algorithm or auto-incrementing mapping.

[0057] After generating the individual entity identifier, the system establishes a two-way mapping record between the original information and the individual entity identifier. This record is stored along with the individual entity model for reference when constructing the individual entity mapping table later. At this point, each individual entity model has a standardized identity that is consistent across the system and usable across the rendering pipeline.

[0058] Through the above-described embodiments of this disclosure, the system achieves standardized unification of multi-source heterogeneous data, enabling individual models from different systems such as Building Information Modeling (BIM), 3D engines, and business databases to participate in subsequent processes using a consistent identifier system. This standardization eliminates cross-system data conflicts and parsing ambiguities, improving the data integration capabilities and system compatibility of large-scale 3D visualization scenes.

[0059] It should be noted that while the raw information contains individual identifiers, it is typically in string or segmented encoding form, which cannot be directly used for graphics processor rendering pipelines and pixel-level matching. Therefore, the spatial hierarchy and geometric boundary features contained in the raw information are extracted and quantized, converting them into digital identifiers that can be efficiently processed by the graphics processor. By introducing hierarchy parameters and index coordinates, the individual identifiers not only possess uniqueness but also carry structured information about spatial hierarchy and geometric range, supporting subsequent large-scale scene management and rapid range queries.

[0060] In an optional implementation, generating a single entity identifier corresponding to the single entity model based on the original information of the single entity model includes: determining multiple boundary points and hierarchical parameters of the single entity model based on the original information of the single entity model, wherein the hierarchical parameters are used to indicate the node hierarchy to which the single entity model belongs in the merged model; converting the point coordinates corresponding to the multiple boundary points into their respective index coordinates based on the hierarchical parameters; and obtaining the single entity identifier corresponding to the single entity model based on the hierarchical parameters and the multiple index coordinates.

[0061] The original information refers to the native identity of the individual model within the source system, which has been extracted in the preceding steps according to its source type, such as building component identifiers, scene node identifiers, or business object identifiers. Boundary points are feature vertices on the geometric envelope of the individual model, used to describe the area occupied by the individual model in 3D space. Hierarchical parameters are encoded information describing the position of the individual model within the overall scene hierarchy, indicating which node level the individual model belongs to. The node hierarchy represents the depth of object organization in a 3D scene or data structure, typically represented by a tree structure. The root node is the highest level, leaf nodes are the lowest level, and intermediate nodes represent progressively refined spatial or logical divisions. Index coordinates can be discretized integer coordinates obtained by encoding and converting point coordinates through hierarchical parameters, used to locate the spatial index position of boundary points at a specific level.

[0062] In an optional implementation, the hierarchical parameters of the individual model are first determined based on its original information. The hierarchical path or classification prefix in the original information is parsed into a hierarchical code. In a 3D model, the hierarchy can indicate information such as its precision. For example, in L1-L15, the model at L15 is more refined than the model at L12. Hierarchy is commonly used information in 3D models and will not be discussed in detail here. Subsequently, multiple boundary points of the individual model are determined. The corner points of the bounding box aligned with the axis of the individual model are selected as boundary points, or key vertices of the geometric convex hull are selected. The coordinates of these boundary points in the 3D world coordinate system are extracted.

[0063] Next, the point coordinates of the boundary points are converted into index coordinates based on the hierarchical parameters. Optionally, the conversion process discretizes and quantizes according to the spatial granularity indicated by the hierarchical parameters. First, the spatial division precision of the current level is determined based on the hierarchical parameters; for example, kilometers are used for the city level, meters for the building level, and millimeters for the component level. Then, the floating-point coordinates of the boundary points are divided by the spatial granularity of the level and rounded to obtain integer index coordinates. This conversion maps continuous spatial coordinates to discrete grid indices, so that objects in close proximity at the same level have similar index coordinate prefixes.

[0064] Finally, the hierarchical parameters and index coordinates are combined into a fixed-width integer, with the hierarchical parameters occupying the high-order bits and the index coordinates occupying the low-order bits; or a hash operation is performed on the index coordinates of multiple boundary points to compress the spatial distribution characteristics into a fixed-length identifier. The resulting individual identifier is a unique numerical code that retains both hierarchical information and geometric location characteristics.

[0065] Through the above-described embodiments of this disclosure, the single-item identifier not only achieves uniqueness and uniformity across source systems but also embeds structured information on spatial hierarchy and geometric range. This feature enables subsequent processes to quickly perform hierarchical filtering and range queries based on the identifier prefix. For example, comparing only the higher few bits is sufficient to determine whether a single item belongs to the same city block, improving retrieval efficiency in large-scale scenarios. Simultaneously, the discretized encoding of the index coordinates aligns the single-item identifier with the digital processing mechanism of the rendering pipeline, providing an identifier foundation that combines semantic and performance advantages for efficient transmission of rendering data and accurate pixel-level matching.

[0066] The above section explained how to generate singleton identifiers. The following section will explain in detail the rendering process and how singleton identifiers are used during rendering: It should be noted that the above steps have determined the rendering index range of the current frame, but have not yet established a precise association between the rendering index and the individual unit identifiers. Therefore, for the actual visible rendering index range of the current frame, the individual unit mapping table is queried to determine which units are partially visible in the current frame, the specific geometric subset of each visible unit is calculated, and the corresponding unit identifier is written into the rendering data.

[0067] In an optional implementation, searching the individual unit mapping table and writing at least one individual unit identifier corresponding to the rendering index range into the rendering data includes: searching the individual unit mapping table, determining multiple individual unit identifiers, and individual unit index ranges corresponding to each of the multiple individual unit identifiers, wherein the rendering index range is the geometric index range of the rendering data, the individual unit index range is the geometric index range of the individual unit model, and the geometric index range of the merged model includes the rendering index range and the individual unit index range; determining the individual unit index ranges that intersect with the rendering index ranges, and determining the intersecting part as the rendering index sub-range; and writing the individual unit identifier corresponding to the rendering index sub-range into the rendering data based on the rendering index sub-range.

[0068] The rendering index range can be the actual area involved in rendering in the current frame, and is a subset (Section / SubMesh) of the merged model (Mesh) geometric index range. The individual unit index range, on the other hand, is the original geometric coordinate range recorded in the individual unit map table and bound to a specific individual unit identifier. This set represents the continuous geometric segment occupied by that individual unit before merging and is a component of the merged model's geometric index range. The merged model's geometric index range is the complete index range of the merged model and can contain the geometric data of all individual unit models.

[0069] In an optional implementation, a lookup operation of the individual entity mapping table is performed first. All entries in the individual entity mapping table are traversed, and the individual entity identifier and its bound individual entity index range are read from each entry. The individual entity index range describes the geometric extent of the individual entity in the merged model in the form of a starting index and an index number. Subsequently, each individual entity index range is compared with the rendering index range of the current frame for intersection determination. Intersection determination is achieved by comparing the index intervals of the two coordinate ranges: if the starting index of a certain individual entity index range is less than the ending index of the rendering index range, and the ending index of the individual entity index range is greater than the starting index of the rendering index range, then the two overlap and are determined to intersect. For intersecting individuals, the system calculates the specific range of the overlapping part, i.e., determines the rendering index sub-range. This subset is the index interval of the intersection of the two ranges, representing the geometric segment of the individual entity that is actually visible in the current frame.

[0070] When a rendering index range spans the boundaries of multiple individual units, the set is split into multiple rendering index sub-ranges, each corresponding to an intersecting individual unit. For example, if the rendering index range is from index 0 to 2000, and individual unit A occupies from 0 to 1000 and individual unit B occupies from 1000 to 2500, then the rendering index range is split into two rendering index sub-ranges: 0 to 1000 corresponds to individual unit A, and 1000 to 2000 corresponds to individual unit B.

[0071] After determining the rendering index sub-ranges, the corresponding individual unit identifiers for each sub-range are written into the rendering data. Once written, the rendering data contains all visible sub-ranges of the current frame and their precisely bound individual unit identifier information.

[0072] It's important to note that after determining the rendering index sub-range and its corresponding individual unit identifier, this information needs to be embedded into a data structure accessible to the rendering process. Therefore, based on the specific organization of the rendering data, an appropriate writing method should be selected to precisely bind the individual unit identifier and its geometric range to the rendering data structure, ensuring that the rendering thread can carry the correct individual unit identity when generating drawing instructions.

[0073] In an optional implementation, the single-unit identifier corresponding to the rendering index sub-range is written into the rendering data based on the rendering index sub-range, including one of the following: 1) When the rendered data is a sub-fragment of the merged model, write the rendering index sub-range and the individual unit identifier corresponding to the rendering index sub-range into the rendering data; 2) When the rendering data is rendering batch data, determine the individual unit identifier corresponding to each rendering batch data based on the rendering index sub-range, and write the individual unit identifier into the rendering batch data.

[0074] In this context, a section is a rendering sub-unit of the merged model (mesh), divided according to material, visibility, or original unit boundaries. Each section has independent geometric extent, material state, and drawing parameters. Render batch data, on the other hand, is a single-draw unit collected and organized by the rendering thread, ready to be submitted to the graphics processor. A rendering batch contains geometric data references, material states, drawing parameters, and unit identifiers written in this step, corresponding to a single draw call from the graphics processor.

[0075] In an optional implementation, the organization of the rendering data is first determined, and then the corresponding write operation is performed. For rendering data in the form of sub-fragments of a merged model, since sub-fragments are typically automatically divided by the merging algorithm according to the original unit boundaries or material changes, each sub-fragment already has a predefined geometric range. Therefore, the range parameters (starting index, number of indices) of the rendering index sub-range and the unit identifier corresponding to that subset are directly written into the sub-fragment's data structure. Specifically, a unit identifier portion is added to the existing fields of the sub-fragment, and the queried identifier value is assigned to this portion; simultaneously, the geometric range of the sub-fragment is updated to the intersection range of the rendering index sub-ranges, ensuring that the sub-fragment describes the actually visible part of the current frame rather than the complete geometry of the unit. After writing, the sub-fragment carries the precise unit identity and visible geometric range, and the rendering thread can directly read the identifier information when traversing the sub-fragments.

[0076] For rendering data in batch format, since rendering batches are dynamically collected and generated by the rendering thread and are not pre-bound to individual unit boundaries, the individual unit identifier corresponding to each rendering batch is determined based on the rendering index sub-range. Optionally, multiple rendering index sub-ranges belonging to the same individual unit are first aggregated to calculate the total visible range of that individual unit in the current frame; then, based on the size and position of the visible range, the number of rendering batches to be generated and their respective geometric parameters are determined; finally, the individual unit identifier is written into each corresponding rendering batch data. If the same rendering batch contains geometric fragments of multiple individual units, the batch is further split to ensure that each rendering batch corresponds to only a single individual unit identifier. After writing, the rendering batch data contains all visible geometry in the current frame and their precisely bound individual unit identifiers, which the rendering thread can carry when submitting drawing instructions by batch.

[0077] The above-described embodiments of this disclosure achieve precise matching between individual unit models and individual unit identifiers within the visible range of the current frame, passing only the identifiers of the individual units actually involved in rendering to subsequent processes, thus avoiding data redundancy and invalid transmission of invisible parts. Furthermore, it adapts to the data organization characteristics of different rendering pipelines, enabling individual unit identifiers to be flexibly embedded in either sub-fragments or rendering batches—two mainstream carriers. This improves the compatibility and execution efficiency of the rendering pipeline and the identification mechanism.

[0078] It should be noted that the implementation described above has written the individual unit identifier into the rendering data on the central processing unit side, but this identifier has not yet been passed to the graphics processor's rendering pipeline, nor has it reached the screen pixel level. Therefore, the rendering data carrying the individual unit identifier is submitted to the graphics processor for rendering. Through the collaborative processing of the vertex shader and pixel shader, the individual unit identifier is passed from the rendering batch level to the pixel level, and finally written into the geometry buffer along with visual information such as color and normals.

[0079] In an optional implementation, rendering the rendering data to obtain multiple screen pixels includes: writing the rendering data and at least one individual identifier into the buffer of the graphics processor; obtaining at least one individual identifier from the buffer through the vertex shader, determining the individual identifier as a discrete attribute and sending it to the pixel shader, wherein the individual identifier is not interpolated; coloring the rendering data through the pixel shader to obtain multiple screen pixels corresponding to the rendering data, and writing the texture information and individual identifier corresponding to the screen pixels into the geometry buffer.

[0080] The graphics processor's buffer is an area in the graphics processor's (GPU) video memory used to store rendering data, including vertex buffers, index buffers, constant buffers, etc. The central processing unit (CPU) uploads data here through the graphics interface for the graphics processor's shading program to access.

[0081] It should be noted that while the individual unit identifier has been determined in the preceding steps, it is still stored in the CPU's memory and cannot be directly accessed by the graphics processing unit's shader program. Therefore, based on the specific organization of the rendering data and the hardware characteristics of the graphics processing unit, an appropriate buffer type is selected to efficiently transmit the individual unit identifier to the graphics processing unit, ensuring that the vertex shader and pixel shader can correctly read the corresponding individual unit's identifier during rendering execution.

[0082] In an optional implementation, the rendering data and the individual unit identifier are written to the graphics processor's buffer, including at least one of the following: 1) When multiple rendering data included in the merged model correspond to a single unit identifier, the rendering data and the single unit identifier are written to the constant buffer of the graphics processor. The constant buffer is used to store data that remains unchanged during a drawing process. 2) Write at least one individual identifier into at least one graph data element in the rendering data, wherein the individual identifier corresponds one-to-one with the graph data element; 3) When the rendering data is rendering batch data, write the individual identifier to the instance buffer, where the instance buffer is used to store the data corresponding to the individual instance included in the rendering batch data.

[0083] The constant buffer (Uniform Buffer / Constant Buffer) is a graphics processor buffer used to store data that remains unchanged during a single draw. The draw process is the complete execution cycle from the submission of a draw call to the graphics processor completing the rendering of that batch of geometry. During this time, the data in the constant buffer remains constant, and all vertex shader instances can read the same value.

[0084] Primitive constants are custom data that are bound to a single primitive, such as a triangle, a mesh fragment, or a drawing instance.

[0085] An instance buffer is a graphics processor buffer used to store data corresponding to each independent instance in instantiated rendering. Instantiated rendering allows multiple copies of the same geometry to be rendered in a single draw call, with each instance obtaining independent transformation matrices, colors, labels, and other data through the instance buffer.

[0086] In an optional implementation, when the geometry of the same unit is split into multiple sub-fragments or multiple rendering batches, but these fragments or batches share the same unit identity, the rendering data and the unified unit identifier are written to the graphics processor's constant buffer. Specifically, before submitting each rendering batch, the CPU updates the unit identifier value to a specified field in the constant buffer, then binds the constant buffer and submits the rendering call. Because the constant buffer keeps the data constant during a single rendering process, all vertex shader instances within the batch read the exact same identifier value, which is suitable for rendering scenarios with single-batch units.

[0087] In an optional implementation, at least one individual identifier is written into at least one primitive data element in the rendering data. The primitive data element is supported by the engine's underlying mechanism, allowing custom data fields to be attached to each individual primitive. The primitives to be rendered are traversed, and the individual identifier corresponding to each primitive is assigned to its custom data field. The primitive data element is automatically passed to the graphics processor along with the primitives, and the vertex shader reads it directly through a built-in interface provided by the engine.

[0088] In an optional implementation, individual instance identifiers are written to an instance buffer, where each entry corresponds to an independent instance in the rendering batch. Before submitting the instantiation render call, the CPU sequentially fills the corresponding positions in the instance buffer with the individual instance identifiers for each instance. When the GPU performs instantiation render, each instance reads its own identifier value from the instance buffer and passes it to the shader along with other instance data (such as transformation matrices). The advantage of this approach is that it can render a large number of instances with the same geometry but different identities at once, such as thousands of identical tree models each having an independent individual instance identifier, which can be completed in a single render call, improving the rendering efficiency of large-scale scenes.

[0089] It's important to note that the vertex shader is the first stage of the graphics processor's rendering pipeline. It processes vertex data, performing coordinate transformations, attribute passing, and other operations, converting 3D geometric data into clip space coordinates. Discrete attributes are attribute data that are passed between the vertex and pixel shaders and are not subject to interpolation. Unlike continuous attributes such as color and position, which require smooth transitions, individual attribute identifiers remain constant during the rasterization stage and are not altered by linear interpolation between vertices.

[0090] The pixel shader is the second stage of the graphics processor's rendering pipeline. It is responsible for calculating the output values ​​such as color and material for each pixel, determining the final visual appearance of each pixel on the screen. Texture information can be visual attribute data such as color, normals, and material parameters output by the pixel shader, used to describe the appearance features of an object's surface. The geometry buffer (GBuffer) is a multi-pass rendering target used in the deferred rendering architecture to store geometric and material attributes, including color buffers, normal buffers, and material attribute buffers, for subsequent use.

[0091] In an optional implementation, the rendering data and its constituent unit identifiers are first synchronized to the graphics processor buffer. The central processing unit (CPU) performs a data upload operation through the graphics interface, copying vertex data to the vertex buffer, index data to the index buffer, and unit identifiers to the constant buffer or the data area. After the upload is complete, the CPU binds the corresponding buffer resources and prepares to submit drawing commands.

[0092] Optionally, when the graphics processor executes the rendering pipeline, it first enters the vertex shader stage. The vertex shader obtains the individual identifiers for the current batch of vertices from the bound constant buffer or metadata. Since this identifier is the same for all vertices in the current batch, the vertex shader outputs it as one of the attributes to be passed, along with vertex attributes such as position, normal, and texture coordinates. It also instructs that no interpolation processing be performed on the individual identifier attributes during the rasterization stage, ensuring that the individual identifiers maintain constant values ​​inside triangles and avoiding blended values ​​at boundaries due to different vertex identifiers.

[0093] Subsequently, the graphics pipeline enters the rasterization stage. The rasterizer converts triangle primitives into screen pixels, performing linear interpolation on continuous attributes such as position and color, but directly passing the original values ​​of the nearest vertex for discrete attributes such as unit identifiers, without performing any mixing calculations. After rasterization is complete, the graphics pipeline enters the pixel shader stage.

[0094] The pixel shader receives interpolated continuous attributes such as position, normals, and texture coordinates, as well as uninterpolated discrete attributes such as the individual pixel identifier. The pixel shader samples the color map from the texture coordinates to obtain the base color, calculates the illumination intensity from the normals, and determines the roughness and metallicity based on the material parameters, ultimately synthesizing the visual color of the pixel. Simultaneously, the pixel shader writes the individual pixel identifier as an independent output item, along with the color, normals, and material parameters, into the corresponding channel of the geometry buffer. If the geometry buffer has a dedicated identifier channel, it is written directly to that channel; otherwise, if the identifier reuses another channel, it is encoded and converted before being written.

[0095] Once the rendering pipeline is complete, the geometry buffer contains screen-space textures across multiple channels: the color channel stores the visual color of each pixel, the normal channel stores the surface orientation, the material channel stores physical parameters, and the identifier channel stores the unique identifier of the individual unit to which each pixel belongs. Each screen pixel location carries complete visual attributes and individual unit identity, forming a rendering output that is strictly consistent with the depth buffer.

[0096] Through the above-described embodiments of this disclosure, the individual entity identifier is transmitted from the rendering data structure on the central processing unit side to the screen pixel level via the vertex shader, rasterizer, and pixel shader of the graphics processing unit rendering pipeline, achieving precise binding of each pixel to its visible surface individual entity identity. The discrete attribute design eliminates identifier confusion of boundary pixels, ensuring consistency of identification within the individual entity and clarity of boundaries. The mechanism of synchronously writing the identifier and visual information into the geometric buffer allows the subsequent interaction stage to obtain the individual entity identity by performing texture sampling with constant complexity on the screen coordinates, without the need for complex geometric traversal or intersection calculations, thus improving the real-time performance and accuracy of identification.

[0097] The above text provides a detailed explanation of how to combine single-item identifiers for rendering the merged model. To more intuitively demonstrate how this merged model rendering method is implemented in the terminal, the following section will combine... Figure 3 The timing relationships of the important steps in the rendering process are explained.

[0098] Figure 3 This is a schematic diagram of an optional merging model rendering process according to an embodiment of the present disclosure; as shown... Figure 3 As shown, the central processing unit (CPU) side includes a game thread and a rendering thread. The game thread is the application logic thread on the CPU side, responsible for initiating data settings; the rendering thread is a dedicated rendering thread on the CPU side, responsible for preparing drawing commands. The graphics processing unit (GPU) is the hardware that performs the actual rendering calculations, containing vertex shaders and pixel shaders. In short, the game thread is the application logic layer, the rendering thread is the rendering preparation layer, and the graphics processing unit is the actual rendering calculation layer. Specifically: Step S301: Load the merged model and obtain the individual unit identifier; the game thread executes the application layer logic and loads the merged static mesh model. Simultaneously, the game thread synchronously reads the individual unit identifier data file or additional data corresponding to this model to obtain the unique identifier (Unit Identifier FID) for each original individual unit object. The individual unit identifier can be a building component ID, scene node ID, or business system object ID, used to represent the unique identity of the individual unit model before merging.

[0099] Step S302: Determine the binding relationship; the game thread establishes the unit identifier binding relationship on the central processing unit side based on the merge mapping table. For the merged model, determine which unit identifier corresponds to a certain sub-section of the merged model, or a certain triangle index range of the merged model, or a certain unit identifier corresponds to a certain instance. Thus, during the rendering resource construction stage, it can be determined which unit identifier should be carried when the rendering pipeline executes a certain rendering instruction (Draw Call).

[0100] Step S303: Write the individual identifier into the rendering data. When the game thread constructs the rendering data of the merged model, it adds an individual identifier field to the rendering data structure and writes the above binding relationship into the rendering data. The individual identifier field can be added to the model's sub-fragment data structure; or to the model's rendering batch data; or a custom constant parameter can be attached to each rendering batch. This allows the rendering thread to obtain the individual identifier corresponding to the current rendering batch when generating drawing instructions.

[0101] Step S304: The individual unit identifier is passed to the rendering proxy layer. The game thread can call the static mesh component class in Unreal Engine, such as using the `Set Feature Data` method of the `UStaticMesh Component`, to set feature data and thus set the individual unit identifier data at the mesh component level. This call is passed to the scene proxy class, such as using the `Set Feature Data` method of the `FStaticMeshScene Proxy` object, and then to the local vertex factory class, such as the `Set Feature Data` method of the `FLocalVertex Factory` object. At this point, the individual unit identifier data is passed from the application layer component level to the rendering proxy layer.

[0102] Step S305: Submit to the rendering thread; the game thread can execute Unreal Engine macros (such as ENQUEUE_RENDER_COMMAND) to encapsulate the singlet identifier update request into a rendering command and submit it to the rendering thread's command queue. This achieves asynchronous decoupling between the game thread and the rendering thread, allowing the game thread to continue processing the logic of the next frame without waiting for rendering to complete.

[0103] Step S306: Generate rendering instructions; the rendering thread retrieves rendering instructions from the command queue and performs merged model collection and rendering preparation. The rendering thread iterates through each rendering sub-fragment of the merged model and generates corresponding rendering instructions for each sub-fragment. When generating rendering instructions, the rendering thread writes the individual unit identifier corresponding to the sub-fragment into the rendering parameters associated with the rendering instruction, so that the graphics processor can obtain the individual unit identifier when executing the rendering instruction later.

[0104] Step S307: Synchronize to the graphics processor; before submitting the drawing command, the rendering thread synchronizes the individual unit identifier to the graphics processor side. An operation to update the constant buffer can be performed, for example, using RHIUpdate Uniform Buffer, to write the individual unit identifier data to the constant buffer. The constant buffer is used to store data that remains unchanged throughout a drawing process, ensuring that the graphics processor can read the corresponding individual unit identifier value when executing the shader.

[0105] Step S308: Execute the vertex shader stage; the graphics processor executes the rendering pipeline and enters the vertex shader stage. The vertex shader obtains intermediate data from the vertex factory, for example, by calling the `Get Vertex Factory Intermediates` function, and then reads the individual vertex identifier from the constant buffer, for example, through the `Get Feature From Buffer` function. If the scene uses instantiated rendering, it loads instance-custom data, for example, by calling the `Load Instance Custom Data Float` function. The vertex shader also obtains material vertex parameters, for example, by calling the `Get Material Vertex Parameters` function. After completing the reading, the vertex shader passes the individual vertex identifier as a discrete attribute that does not require interpolation to the pixel shader stage, ensuring that each pixel can obtain the individual vertex identifier of its belonging unit during shading calculations, and that the individual vertex identifier is not interpolated.

[0106] Step S309: Execute the pixel shader stage; the graphics processor executes the rendering pipeline and enters the pixel shader stage. The pixel shader prepares the five-channel output structure, for example, by calling the FFive Shader Out_MainPS instruction; obtains material pixel parameters, for example, by calling the Get Material Pixel Parameters instruction; and calculates material parameters, for example, by calling the CalcMaterial Parameters instruction. Subsequently, the pixel shader sets the output of the geometry buffer (GBuffer) corresponding to the shading model, for example, by calling the Set GBuffer For Shading Model instruction, and encodes the geometry buffer data to multiple rendering targets, for example, by executing the Encode GBuffer To MRT instruction. During this process, when outputting the geometry buffer, in addition to outputting regular information such as color, normals, and material parameters, the pixel shader writes the individual identifier to the object identifier storage area of ​​the geometry buffer. If an independent individual identifier buffer exists in the geometry buffer, the individual identifier is written to that individual identifier buffer; if the geometry buffer does not have an independent buffer configured, the individual identifier is encoded and written to an idle channel of the geometry buffer.

[0107] Step S310: Rendering completes. After the rendering pipeline completes the geometry buffer stage, the individual unit identifier buffer is retained as part of the geometry buffer output as a texture resource on the graphics processor side. The pixel shader outputs the final result to the rendering target. This individual unit identifier texture is strictly consistent with the current frame's depth buffer and color buffer in pixel position, forming an individual unit identifier texture consistent with the current frame's depth and color. This individual unit identifier texture has consistent visibility results with the depth buffer; ultimately, the individual unit identifier stored in the individual unit identifier texture of the pixels visible on the screen is the individual unit identifier of the individual unit to which the visible surface belongs.

[0108] The preceding steps have completed the rendering output, giving each screen pixel a unique identifier. However, a closed loop between user input and unique identifier recognition has not yet been established. Therefore, the following section will explain possible implementation methods for interacting with user commands after obtaining the rendering results: In an optional implementation, after matching the unit identifier corresponding to the rendering index where the screen pixel is located with the screen pixel, the process includes: upon receiving an interaction instruction and if the rendering frame indicated by the interaction instruction matches the rendering data, determining at least one interaction coordinate indicated by the interaction instruction; obtaining the depth information and unit identifier corresponding to the interaction coordinate in the geometry buffer; if the depth information is valid, determining at least one unit model based on the unit identifier; and performing an interaction operation on the at least one unit model based on the interaction instruction.

[0109] Interaction commands can be operation requests issued by users through input devices, including clicks, hovers, selection boxes, and touch selections, used to trigger the recognition or manipulation of specific objects in a 3D scene. Interaction commands can be commands generated from user actions received by the terminal, or commands automatically generated by system-triggered interaction logic (such as in-game interactions or automatic background model recognition).

[0110] Interaction coordinates are the positional parameters of an interaction command in screen space, typically represented by pixel coordinates or normalized coordinates, indicating the specific screen location where the user's action occurs. Interaction commands can be single-point selection operations such as clicks, hovers, and touch selections, or multi-point selection operations such as bounding boxes; therefore, interaction coordinates can be one or multiple. Depth information is the distance value from each pixel to the camera recorded in the geometry buffer, used to determine whether a pixel corresponds to the actual rendered object surface or belongs to an invalid area such as the background sky. Interaction operations can be visualization or business processing performed on a single model based on the recognition results, including highlighting, contour outlining, hiding and isolating, attribute querying, and information display.

[0111] In an optional implementation, user input events are captured, the interaction type and screen position are extracted, and an interaction command is generated. The system then checks whether the rendering frame indicated by the command matches the currently available rendering data. By comparing the frame identifier sequence number in the command with the frame identifier corresponding to the geometry buffer, it ensures that the rendered output of the screen currently seen by the user is being read, rather than a historical frame that has been overwritten or a future frame that has not yet been completed. If the frames do not match, the system waits for synchronization or refuses to process the data to avoid recognition errors caused by timing discrepancies.

[0112] Optionally, after frame matching verification passes, at least one interaction coordinate indicated by the interaction command is determined. For a single click operation, the interaction coordinate is the position of a single screen pixel; for a selection operation, the interaction coordinate is multiple sampling points within a rectangular area; for a hover operation, the interaction coordinate is a continuous coordinate stream of the current position. These coordinates are converted into sampling positions in the geometry buffer texture space to ensure that the sampling positions correspond precisely to the actual screen pixels.

[0113] Subsequently, the depth information and individual unit identifiers corresponding to the interaction coordinates are obtained from the geometry buffer. The geometry buffer resource of the current frame is bound, texture sampling is performed, and the floating-point value of the depth channel is read at the interaction coordinate position, while the integer value of the individual unit identifier channel is read at the same time.

[0114] Optionally, after obtaining the depth information, it can be determined whether the depth value is within a valid range: if the depth value is close to the extreme value of the far clipping plane, it indicates that the location corresponds to the sky or infinity, and no actual object has been hit; if the depth value is close to the extreme value of the near clipping plane or zero, it indicates that there is no valid rendering surface at that location; if the depth value is in the middle range, it is determined to be a valid depth, confirming that the interactive coordinates correspond to the actual rendered object surface. Only when the depth is valid, the individual identifier continues to be processed; if the depth is invalid, a miss result is returned, and subsequent operations are terminated.

[0115] Optionally, after deep validation passes, at least one individual entity model is determined based on the entity identifier. Using the read identifier value as an index key, the scene tree or business database is queried. First, the node reference corresponding to the identifier is located in the scene hierarchy to obtain the spatial location, geometric information, and hierarchical relationship of the entity. Then, the business attributes of the entity, such as name, type, area, number, and maintenance records, are retrieved from the external database. For cases where the selection operation involves multiple sampling points, all valid identifiers are collected, and after deduplication, a set of entities within the interactive area is obtained.

[0116] Optionally, after identifying the target unit, interactive operations are performed on at least one unit model based on interactive commands. For highlight commands, the unit's identifier is added to the selected set, and in the post-processing stage, it is determined whether the identifier of each pixel belongs to the set; if it does, the brightness is increased or the hue is changed. For stroke commands, the identifier differences between adjacent pixels are compared, and an outline is drawn at the point of identifier change. For hide commands, the identifier is added to the hide set, and the corresponding pixel is discarded or its transparency is set during post-processing. For attribute display commands, an information panel pops up in the user interface to display the business attribute details of the unit. All effects are executed based on the unit identifier of the pixels, affecting only the target unit without interfering with other objects.

[0117] Through the above-described embodiments of this disclosure, a complete interactive closed loop is established, from user screen operation to accurate individual unit recognition and then to visual feedback. The frame synchronization mechanism ensures strict consistency between the recognition result and the user's view, the depth verification mechanism filters out background misidentification, and pixel-level identifier reading enables fast lookup with constant complexity. This mechanism enables real-time, accurate, and reliable individual unit interaction under merged model conditions. Users can perform point selection, bounding selection, querying, and control on any individual unit in the merged scene as if operating an independent model, significantly improving the usability and interactive experience of large-scale 3D visualization scenes.

[0118] Figure 4 This is a schematic diagram of the interaction process of an optional merging model according to an embodiment of the present disclosure; as shown below. Figure 4As shown, the terminal device may include a pixel inspector and a rendering module. The pixel inspector is an interactive query module responsible for initiating query requests and processing query results. The rendering module is a rendering pipeline module responsible for performing post-processing and providing texture data reading. Specifically: Step S401-1: Determine the interaction coordinates; the pixel inspector module creates a pixel inspection request object. When the user performs a mouse click, hover, box selection, or touch selection in the 3D scene, the interaction module captures the operation event and obtains the corresponding screen coordinate information (x, y) pixel coordinates or screen normalized coordinates. These coordinates are used as input parameters for the query and encapsulated into a query request object.

[0119] Step S402-1, Create a buffer; the pixel inspector module creates a request data buffer to store the set of parameters required for the query.

[0120] Step S403-1: Prepare the rendering target object; the pixel inspector module prepares the 2D texture rendering target object as a data receiving carrier for subsequent reading operations. This object is used to receive pixel data read back from the rendering module and serves as a bridge for data interaction between the central processing unit (CPU) and the graphics processing unit (GPU).

[0121] Step S404-1, Initialization; the pixel inspector module performs initialization operations, configuring the internal state, cache structure, and query parameters of the pixel inspector. After initialization, the pixel inspector enters the ready state, waiting for specific query requests to be added.

[0122] Step S401-2: Add a post-processing channel; add a post-processing channel to the rendering module. The post-processing channel includes rendering pipeline configurations for effects such as individual highlighting, individual stroke, individual hiding / isolation, and crystal / transparency effects.

[0123] Step S402-2: Add a dedicated pixel inspection channel; add a dedicated pixel inspection channel to the rendering module. This channel is specifically used to handle query requests initiated by the pixel inspector, configure shader programs that read pixel data from the geometry buffer, and define the rendering state.

[0124] Step S403-2: Add a dedicated channel for feature inspection; add a dedicated channel for feature inspection to the rendering module. This channel is used to support feature query and attribute display functions based on single-item identifiers, and configure the pipeline logic for querying the scene tree, model metadata, and business database.

[0125] Step S404-2: Add a visualization channel; add a visualization channel to the rendering module. This channel is used to support the visualization debugging and verification of single-unit identifiers in high-density geometric scenes, ensuring the correctness of single-unit recognition under complex geometric conditions.

[0126] Step S405: Add the interaction command to the request queue; the pixel inspector module adds the created query request to the request queue. The interaction module then formally submits the query request to the rendering module's request queue, awaiting the rendering module's response and processing.

[0127] Step S406: Initiate a data readback request; the pixel inspector module initiates a data readback request to the rendering module.

[0128] Step S407: Return pixel data; the rendering module performs a read operation to obtain the pixel value of the single-unit identifier buffer at that coordinate position. After completing the read, the rendering module returns the result to the pixel inspector module.

[0129] Step S408, Feature Decoding: The pixel inspector module receives the pixel data returned by the rendering module and performs feature decoding. If the individual pixel identifier is stored using encoding, the pixel value is restored to its original value in this step. Finally, the individual pixel identifier corresponding to the target pixel is obtained.

[0130] Once the individual unit identifier is determined, the individual unit model can be identified, allowing for interactive operations based on interaction commands. These operations may include highlighting, color changing, outlining, hiding, and isolating. Specifically: In an optional implementation, a set of selected unit identifiers is maintained, containing all unit identifiers currently selected by the user. In the deferred rendering post-processing pass, the pixel shader reads the unit identifier channel from the geometry buffer to obtain the unit identifier value of the current pixel. This value is compared with the selected set: if the identifier exists in the selected set, highlighting is performed on the pixel's color output, specifically including increasing the luminance component, increasing saturation, and overlaying a specific hue; if the identifier does not exist in the selected set, the original color remains unchanged. Highlighting is performed in screen space, without modifying the original geometry data or material resources, only affecting the final pixel output.

[0131] In an optional implementation, in the post-processing pass of deferred rendering, the pixel shader samples the individual pixel identifier values ​​of its surrounding neighboring pixels (typically in the four directions of up, down, left, and right, or eight neighborhoods) centered on the current pixel. The identifier value of the current pixel is compared one by one with the identifier values ​​of its neighboring pixels: if any neighboring pixel has a different identifier value than the current pixel, the current pixel is determined to be located at the boundary of a single pixel, and a preset stroke color is output; if all neighboring pixels have the same identifier value as the current pixel, the current pixel is determined to be located inside a single pixel, and the original color is output. This edge detection is performed entirely in screen space, without accessing original geometric information or calculating geometric normals, relying solely on differences in pixel identifiers for judgment.

[0132] In an optional implementation, a set of hidden unit identifiers is maintained. During the post-processing stage of deferred rendering, the pixel shader reads the unit identifier of the current pixel and determines whether the identifier exists in the hidden set: if it exists, the pixel's opacity is set to zero or it is discarded, preventing the pixel from being written to the final color buffer; if it does not exist, the color is output normally. Alternatively, during the basic rendering pass, the pixel shader can perform the same identifier check earlier, directly skipping the color and depth writing of hidden units, reducing the unnecessary overhead of subsequent lighting calculations.

[0133] In an optional implementation, a set of effect unit identifiers is maintained. In the post-processing pass of deferred rendering, the pixel shader reads the unit identifier of the current pixel and determines whether the identifier exists in the effect set. If it exists, special material replacement logic is performed on the pixel, such as: increasing the transparency component to achieve a semi-transparent effect; calculating the angle between the viewpoint and the normal and overlaying Fresnel edge lighting where the angle is large; overlaying the pixel color onto the luminous buffer and blurring it to form a glow effect; or performing refraction offset sampling on the pixel coordinates to simulate the distortion effect of light passing through a transparent medium.

[0134] In an optional implementation, when a user interaction hits a pixel and reads a valid unit identifier, the system uses that identifier as an index key to initiate a business query. The query process includes: finding the unit node corresponding to the identifier in the scene hierarchy to obtain its spatial location and structural relationships; searching for the unit's geometric attributes, material configuration, and transformation parameters in the model metadata storage; and retrieving the unit's business attributes, including building name, function type, building area, number of floors, construction year, operation and maintenance status, pipeline information, and equipment list, from an external business database or asset management system. The query results drive the user interface display, specifically including pop-up information panels displaying detailed attributes, hanging labels in 3D space to indicate key information, triggering risk warnings and alarms based on operation and maintenance status, and performing statistical analysis and outputting reports for a certain type of unit.

[0135] In an optional implementation, when generating a single-unit identifier, the category information is encoded into the high-order segment of the identifier or associated with a separate category coding table. The system maintains a set of visible categories or filtering conditions. During the rendering or post-processing stage, the single-unit identifier of the current pixel is read, its associated category code is extracted, and it is determined whether the category belongs to the visible set: if it does, the pixel color is output normally; if it does not, the pixel is set to gray, its transparency is reduced, or it is discarded completely. The filtering conditions support dynamic updates; users can select or deselect specific categories, and the system adjusts the visible set in real time and reapplies the filtering to achieve selective display modes such as displaying only building objects, displaying only road objects, or graying out other categories.

[0136] Figure 5This is a schematic diagram of an optional rendering interface according to an embodiment of the present disclosure; as shown... Figure 5 The image shows the interface of a 3D city digital twin visualization platform, capable of displaying large urban building complexes, roads, and open spaces. In the lower right corner of the screen, a selected individual model is displayed. Once selected, the selected object's attribute information (such as ID, name, coordinates, color, etc.) is displayed in the information panel in the upper right corner. Function buttons (such as scene editing and setting AES entity outlines) are located below the information panel. Auto Entity Selection (AES) automatically identifies and selects individual models in the 3D scene. The upper left corner displays debugging information or performance statistics for the current terminal device. Figure 5 As can be seen, after rendering the merged model, you can receive interactive commands to perform interactive operations on the individual models in the merged model.

[0137] The above embodiments can be combined in any way to form other optional embodiments of this disclosure, which will not be described in detail here.

[0138] According to another aspect of the present disclosure, a rendering apparatus for a merged model is also provided for implementing the above-described rendering method for merging models. For example... Figure 6 As shown, the device includes: an acquisition module 601, used to acquire the merged model indicated by the viewing command, and the individual unit mapping table corresponding to the merged model, wherein the merged model is obtained by merging multiple individual models, the individual unit mapping table is used to indicate the mapping relationship between the geometric index range of the merged model and the individual unit identifier of the individual model, and the individual unit identifier is used to indicate the unique identity of the corresponding individual before merging; an individual unit identifier determination module 602, used to determine the rendering index range corresponding to the rendering data of the merged model, and search the individual unit mapping table, and write at least one individual unit identifier corresponding to the rendering index range into the rendering data; and a rendering module 603, used to render the rendering data to obtain multiple screen pixels, and match the individual unit identifier corresponding to the rendering index of the screen pixel with the screen pixel.

[0139] Optionally, the acquisition module 601 is further configured to: determine the original information of the single-unit model based on the type of the single-unit model, wherein the original information is used to indicate the information of the single-unit model; and generate the single-unit identifier corresponding to the single-unit model based on the original information of the single-unit model.

[0140] Optionally, the acquisition module 601 is further configured to: when the individual unit model originates from a building information modeling system, the original information is a building component identifier, wherein the building component identifier includes at least one of a professional code, floor number, component type, and component serial number; when the individual unit model originates from a 3D scene editor, the original information is a scene node identifier, wherein the scene node identifier includes hierarchical path information; when the individual unit model originates from a business management system, the original information is a business object identifier, wherein the business object identifier includes at least one of a database primary key, asset code, and Uniform Resource Locator.

[0141] Optionally, the acquisition module 601 is further configured to: determine multiple boundary points and hierarchical parameters of the individual model based on the original information of the individual model, wherein the hierarchical parameters are used to indicate the node level to which the individual model belongs in the merged model; convert the point coordinates corresponding to the multiple boundary points into their respective index coordinates based on the hierarchical parameters; and obtain the individual identifier corresponding to the individual model based on the hierarchical parameters and the multiple index coordinates.

[0142] Optionally, the single-unit identifier determination module 602 is further configured to: look up a single-unit mapping table, determine multiple single-unit identifiers, and single-unit index ranges corresponding to each of the multiple single-unit identifiers, wherein the rendering index range is the geometric index range of the rendering data, the single-unit index range is the geometric index range of the single-unit model, and the geometric index range of the merged model includes the rendering index range and the single-unit index range; determine the single-unit index ranges that intersect with the rendering index ranges, and determine the intersecting part as a rendering index sub-range; and write the single-unit identifiers corresponding to the rendering index sub-ranges into the rendering data based on the rendering index sub-ranges.

[0143] Optionally, the individual identifier determination module 602 is further configured to: when the rendering data is a sub-fragment of a merged model, write the rendering index sub-range and the individual identifier corresponding to the rendering index sub-range into the rendering data; when the rendering data is rendering batch data, determine the individual identifier corresponding to each of the rendering batch data based on the rendering index sub-range, and write the individual identifier into the rendering batch data.

[0144] Optionally, the individual identifier determination module 602 is further configured to: write rendering data and at least one individual identifier into a buffer of the graphics processor; obtain at least one individual identifier from the buffer through the vertex shader, determine the individual identifier as a discrete attribute and send it to the pixel shader, wherein the individual identifier is not interpolated; color the rendering data through the pixel shader to obtain multiple screen pixels corresponding to the rendering data, and write the texture information and individual identifier corresponding to the screen pixels into a geometry buffer; when multiple rendering data included in the merged model correspond to one individual identifier, write the rendering data and individual identifier into a constant buffer of the graphics processor, wherein the constant buffer is used to store data that remains unchanged during a drawing process; write at least one individual identifier into at least one metadata of the rendering data, wherein the individual identifier corresponds one-to-one with the metadata; when the rendering data is rendering batch data, write the individual identifier into an instance buffer, wherein the instance buffer is used to store data corresponding to a single instance included in the rendering batch data.

[0145] Optionally, the rendering apparatus for merging models further includes: an interaction module, configured to: upon receiving an interaction instruction and finding that the rendering frame indicated by the interaction instruction matches the rendering data; determine at least one interaction coordinate indicated by the interaction instruction; obtain depth information and individual unit identifiers corresponding to the interaction coordinates from the geometry buffer; if the depth information is valid, determine at least one individual unit model based on the individual unit identifiers; and perform interactive operations on the at least one individual unit model based on the interaction instruction.

[0146] Optionally, in this embodiment, the implementation of each of the above-mentioned unit modules can be referred to the above-mentioned method embodiments, which will not be repeated here.

[0147] According to another aspect of the present disclosure, an electronic device for implementing the above-described merging model rendering method is also provided, see [link to relevant documentation]. Figure 7 , Figure 7 This is a structural block diagram of an electronic device provided in an embodiment of this disclosure. Figure 7 As shown, the electronic device 700 may include a processor 701, a memory 702, and a program or instructions stored in the memory 702 and executable on the processor 701. When the program or instructions are executed by the processor 701, they implement the various processes of the above-described rendering method embodiment for the merged model and achieve the same technical effect. To avoid repetition, they will not be described again here. It should be noted that the electronic device in the embodiments of this disclosure includes mobile electronic devices and non-mobile electronic devices.

[0148] According to one aspect of this disclosure, a computer program product is provided, comprising a computer program / instructions containing program code for performing the methods shown in the flowchart. In such embodiments, the computer program can be downloaded and installed from a network via a communication component, and / or installed from a removable medium. When executed by a central processing unit, the computer program performs various functions provided by embodiments of this disclosure.

[0149] According to one aspect of this disclosure, a computer-readable storage medium is provided that stores a computer program that, when executed by a processor, implements the various processes of the above-described rendering method embodiment of the merged model and achieves the same technical effect. To avoid repetition, further details are omitted here.

[0150] The aforementioned readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0151] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device and system embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0152] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive labor. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only possible execution order. In actual device or client product execution, the methods shown in the embodiments or drawings can be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment).

[0153] In the description of this disclosure, it should be noted that the terms "upper", "lower", "inner", "outer", "front", "back", "left", "right", etc., indicate the orientation or positional relationship based on the orientation or positional relationship in the working state of this disclosure, and are only for the convenience of describing this disclosure and simplifying the description, and are not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this disclosure.

[0154] In the description of this disclosure, it should be noted that, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. Those skilled in the art can understand the specific meaning of these terms in this disclosure based on the specific circumstances.

[0155] The present disclosure has been described above with reference to preferred embodiments; however, these embodiments are merely exemplary and illustrative. Various substitutions and modifications can be made to the present disclosure based on these embodiments, all of which fall within the protection scope of the present disclosure.

Claims

1. A rendering method for merging models, characterized in that, include: Obtain the merged model indicated by the viewing command, and the individual unit mapping table corresponding to the merged model. The merged model is obtained by merging multiple individual unit models. The individual unit mapping table is used to indicate the mapping relationship between the geometric index range of the merged model and the individual unit identifier of the individual unit model. The individual unit identifier is used to indicate the unique identity of the corresponding individual unit before merging. Determine the rendering index range corresponding to the rendering data of the merged model, and look up the individual unit mapping table, and write at least one individual unit identifier corresponding to the rendering index range into the rendering data; The rendering data is rendered to obtain multiple screen pixels, and the individual identifier corresponding to the rendering index of the screen pixel is matched with the screen pixel.

2. The method according to claim 1, characterized in that, Before obtaining the individual mapping table corresponding to the merged model, the following steps are included: The original information of the single-unit model is determined based on the type of the single-unit model, wherein the original information is used to indicate the information of the single-unit model; The monomer identifier corresponding to the monomer model is generated based on the original information of the monomer model.

3. The method according to claim 2, characterized in that, The determination of the original information of the single-unit model based on the type of the single-unit model includes at least one of the following: When the individual building model originates from a building information modeling system, the original information is a building component identifier, wherein the building component identifier includes at least one of a professional code, a floor number, a component type, and a component serial number; When the single-unit model originates from a 3D scene editor, the original information is a scene node identifier, wherein the scene node identifier contains hierarchical path information; When the monolithic model originates from the business management system, the original information is a business object identifier, wherein the business object identifier includes at least one of a database primary key, an asset code, and a Uniform Resource Locator.

4. The method according to claim 2, characterized in that, The process of generating the monomer identifier corresponding to the monomer model based on the original information of the monomer model includes: Based on the original information of the single model, multiple boundary points and hierarchical parameters of the single model are determined, wherein the hierarchical parameters are used to indicate the node hierarchy to which the single model belongs in the merged model; Based on the hierarchical parameters, the point coordinates corresponding to each of the multiple boundary points are converted into their respective index coordinates. Based on the hierarchical parameters and multiple index coordinates, the individual identifier corresponding to the individual model is obtained.

5. The method according to claim 1, characterized in that, The step of searching the individual entity mapping table and writing at least one individual entity identifier corresponding to the rendering index range into the rendering data includes: The unit mapping table is searched to determine multiple unit identifiers and the unit index ranges corresponding to each of the multiple unit identifiers. The rendering index range is the geometric index range of the rendering data, the unit index range is the geometric index range of the unit model, and the geometric index range of the merged model includes the rendering index range and the unit index range. Determine the individual index ranges that intersect with the rendering index range, and define the intersecting portions as rendering index sub-ranges; Based on the rendering index subrange, the single-unit identifier corresponding to the rendering index subrange is written into the rendering data.

6. The method according to claim 5, characterized in that, The step of writing the single-unit identifier corresponding to the rendering index sub-range into the rendering data based on the rendering index sub-range includes one of the following: When the rendered data is a sub-fragment of the merged model, the rendered index sub-range and the individual identifier corresponding to the rendered index sub-range are written into the rendered data; When the rendering data is rendering batch data, the individual identifier corresponding to each of the rendering batch data is determined based on the rendering index sub-range, and the individual identifier is written into the rendering batch data.

7. The method according to claim 5, characterized in that, The rendering of the rendering data yields multiple screen pixels, including: Write the rendering data and the at least one individual identifier into the graphics processor's buffer; The vertex shader obtains the at least one individual identifier from the buffer, determines the individual identifier as a discrete attribute and sends it to the pixel shader, wherein the individual identifier is not interpolated; The rendering data is colored by the pixel shader to obtain multiple screen pixels corresponding to the rendering data, and the texture information and the individual identifier corresponding to the screen pixels are written into the geometry buffer. The step of writing the rendering data and the individual identifier into the graphics processor's buffer includes at least one of the following: When the multiple rendering data included in the merged model all correspond to a single entity identifier, the rendering data and the single entity identifier are written into a constant buffer of the graphics processor, wherein the constant buffer is used to store data that remains unchanged during a drawing process; Write at least one single-entity identifier into at least one graph data element of the rendering data, wherein the single-entity identifier corresponds one-to-one with the graph data element; When the rendering data is rendering batch data, the individual identifier is written to the instance buffer, wherein the instance buffer is used to store the data corresponding to a single instance included in the rendering batch data.

8. A rendering apparatus for merging models, characterized in that, include: The acquisition module is used to acquire the merged model indicated by the viewing command and the individual unit mapping table corresponding to the merged model. The merged model is obtained by merging multiple individual unit models. The individual unit mapping table is used to indicate the mapping relationship between the geometric index range of the merged model and the individual unit identifier of the individual unit model. The individual unit identifier is used to indicate the unique identity of the corresponding individual unit before merging. The single-unit identifier determination module is used to determine the rendering index range corresponding to the rendering data of the merged model, and to look up the single-unit mapping table and write at least one single-unit identifier corresponding to the rendering index range into the rendering data. The rendering module is used to render the rendering data to obtain multiple screen pixels, and match the individual identifier corresponding to the rendering index of the screen pixel with the screen pixel.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method of any one of claims 1 to 7.

10. A computing device, characterized in that, include: Memory, used to store computer programs; A processor is configured to execute a computer program stored in the memory, wherein, when the computer program is executed, it implements the method of any one of claims 1 to 7.

Images