Polygon model rendering method, system and equipment and storage medium

Abstract

The invention discloses a polygon model rendering method, system and device and a storage medium, and relates to the technical field of real-time graphic rendering, and the method comprises the steps: obtaining a to-be-rendered polygon mesh model, and carrying out the de-indexing processing of the polygon mesh model, and obtaining an independent triangular surface sequence without a shared vertex; generating a unique point identifier for an independent vertex of each triangular surface in the independent triangular surface sequence, constructing an edge sharing relationship between each triangular surface and an undirected edge, and calculating a normal included angle corresponding to each undirected edge; for any triangular surface, the outer contour edge of the triangular surface is judged based on the edge sharing relation and the normal included angle; and encoding the classification information of the outer contour edges into vertex attributes, and adaptively rendering the encoded polygonal mesh model to a target game engine to realize real-time outer contour stroking. According to the method, the real outer contour and the internal edge generated by model triangulation can be accurately distinguished, wrong stroking is avoided, and the outer contour recognition precision is improved.

Description

Technical Field

[0001] This application relates to the field of real-time graphics rendering technology, and in particular to a polygon model rendering method, system, device and storage medium. Background Technology

[0002] Real-time 3D rendering technology is widely used in various scenarios such as game engines (such as Unity and Unreal Engine), virtual reality (VR), and digital twins. Outline tracing, as a common requirement in non-realistic rendering, can effectively highlight the outline of objects, enhance visual emphasis, or achieve cartoon rendering, and is an important means to improve the quality of visual presentation.

[0003] However, existing technologies face many intractable drawbacks: after the polygon model is automatically triangulated by the engine, internal auxiliary edges are generated. These edges cannot be distinguished from the real outer contour edges, often leading to messy internal lines and incorrect outlines. (See reference...) Figure 1 as well as Figure 2 In the image, polygonal surfaces such as fan shapes may exhibit multiple lines on their inner edges, and existing rendering pipelines lack a native recognition mechanism. Currently, all algorithms are unable to effectively distinguish between "outer / inner edges" at the vertex level. The geometry shader extension method has extremely poor performance and is not supported on mobile devices. Screen space edge detection suffers from excessive noise, severe jitter, and is prone to misjudging internal polylines. The simple Barycentric stroking algorithm completely fails in shared vertex models and cannot filter out internal auxiliary edges. These issues collectively result in poor outer contour stroking effects and insufficient stability, making it difficult to meet the requirements of high-precision rendering. Summary of the Invention

[0004] The main purpose of this application is to provide a polygon model rendering method, system, device and storage medium, which aims to accurately distinguish between the real outer contour and the internal edges generated by model triangulation, avoid erroneous outlining, and improve the accuracy of outer contour recognition.

[0005] To achieve the above objectives, this application proposes a polygon model rendering method, the method comprising: Obtain the polygonal mesh model to be rendered, and perform de-indexing processing on the polygonal mesh model to obtain a sequence of independent triangles without shared vertices; Generate unique point identifiers for the independent vertices of each triangle in the independent triangle face sequence, construct the common edge relationship between each triangle face and the undirected edge, and calculate the included angle of the normal corresponding to each undirected edge; For any of the aforementioned triangular faces, the outer contour edges of the triangular face are determined based on the shared edge relationship and the included angle of the normals; The classification information of the outer contour edges is encoded into the vertex attributes, and the encoded polygon mesh model is adapted and rendered to the target game engine to achieve real-time outlining of the outer contour.

[0006] In one possible implementation, the de-indexing process of the polygonal mesh model to obtain a sequence of independent triangles without shared vertices includes: Traverse all triangular face indices in the polygonal mesh model and identify shared vertices with shared relationships among the triangular face indices; Copy the vertex data corresponding to the shared vertex, and reconstruct a vertex array containing position, normal, and texture coordinates; Based on the reconstructed vertex array, an independent triangle sequence is generated in which each triangle has an independent vertex.

[0007] In one possible implementation, generating unique point identifiers for the independent vertices of each triangle in the sequence of independent triangles, constructing the shared edge relationship between each triangle and the undirected edge, and calculating the included angle of the normal to each undirected edge include: Obtain the spatial coordinate information of each of the independent vertices; Based on the bit pattern of the spatial coordinate information, a unique point identifier is generated for each of the independent vertices, and the undirected edges corresponding to each of the triangular faces are extracted. A unique edge identifier is constructed for each of the undirected edges to build a topology table. A hash table is used to record the triangular face information corresponding to each undirected edge, forming a shared edge relationship; Based on the topology table and the shared edge relationships, the normal vector of each triangle is calculated, and the included angle between the normal vectors of related triangles is calculated.

[0008] In one possible implementation, the triangular face information includes triangular face identifiers and relative vertex identifiers; The step of recording the triangular face information corresponding to each undirected edge through a hash table to form a shared edge relationship includes: Store the unique edge identifier of each undirected edge as a key in a hash table; Store the triangular face identifiers and relative vertex identifiers associated with each of the undirected edges as values ​​in a hash table; By traversing the undirected edges of each triangle, the hash table is constructed, forming a shared edge relationship.

[0009] In one possible implementation, determining the outer contour edge of the triangular face based on the shared edge relationship and the included angle of the normals includes: Determine the number of triangular faces associated with each undirected edge in the shared edge relationship; For any of the undirected edges, if the number of triangles is one, then the undirected edge is determined to be the outer contour edge of the triangle. If there are two triangles, a preset angle threshold is obtained, and the included angle of the normal is compared with the angle threshold. If the included angle of the normals is greater than the angle threshold, then the undirected edge is determined to be the outer contour edge of the triangular face.

[0010] In one possible implementation, encoding the classification information of the outer contour edges into vertex attributes and adapting the encoded polygonal mesh model to the target game engine for real-time outer contour outlining includes: Assign a centroid encoding order to the three vertices of each triangle face, and write the component information corresponding to the centroid encoding order into the texture coordinate attribute of the vertex; Generate an outer contour edge mask and write the outer contour edge mask into the color attribute of the vertex to complete the classification information encoding; Based on the type of the target game engine, export the encoded model file of the encoded polygon mesh model, import the encoded model file into the target game engine, and load the adapted rendering materials; By reading the encoded information in the vertex attributes of the rendering material, identifying the outer contour edge, and adjusting the rendering parameters, the outer contour can be drawn in real time.

[0011] In one possible implementation, exporting the encoded model file of the encoded polygon mesh model according to the type of the target game engine includes: Obtain the model format support information of the target game engine; If the model format support information does not include open-source model formats, then export a description file containing model topology information and encoding information. The description file is used to convert the model into a model file supported by the target game engine through a plugin. If the model format support information includes open-source model formats, then export the open-source format model file containing the encoding information.

[0012] Furthermore, to achieve the above objectives, this application also proposes a polygon model rendering system, which includes: The acquisition module is used to acquire the polygonal mesh model to be rendered and to perform de-indexing processing on the polygonal mesh model to obtain a sequence of independent triangles without shared vertices. The calculation module is used to generate unique point identifiers for the independent vertices of each triangle in the sequence of independent triangles, construct the common edge relationship between each triangle and the undirected edge, and calculate the included angle of the normal corresponding to each undirected edge. The determination module is used to determine the outer contour edge of any of the triangles based on the shared edge relationship and the included angle of the normals. The rendering module is used to encode the classification information of the outer contour edges into vertex attributes, and adapt the encoded polygon mesh model to the target game engine for rendering, so as to realize real-time outlining of the outer contour.

[0013] In addition, to achieve the above objectives, this application also proposes a polygon model rendering device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the polygon model rendering method described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the polygon model rendering method described above.

[0015] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the polygon model rendering method described above.

[0016] This application provides a polygon model rendering method, system, device, and storage medium. The polygon model rendering method obtains a polygon mesh model to be rendered, performs de-indexing processing on the polygon mesh model to obtain a sequence of independent triangles without shared vertices, generates unique point identifiers for the independent vertices of each triangle in the sequence, constructs the common edge relationship between each triangle and an undirected edge, and calculates the normal angle corresponding to each undirected edge. Thus, for any triangle, based on the common edge relationship and the normal angle, the outer contour edge of the triangle is determined, and the classification information of the outer contour edge is encoded to the top. In the point attributes, the encoded polygonal mesh model is adapted and rendered to the target game engine to achieve real-time outline tracing. By de-indexing, an independent triangular face sequence is obtained, avoiding encoding and interpolation errors caused by shared vertices, accurately constructing topological relationships, and determining the outer contour edges by combining the shared edge relationship and the angle between the normals. This can accurately distinguish the real outer contour from the internal edges generated by model triangulation, avoid erroneous outline tracing, effectively filter internal auxiliary edges, and improve the accuracy of outer contour recognition. Furthermore, vertex attributes are embedded through encoded information, which can be directly read by the GPU without relying on special shaders. This is compatible with mainstream game engines and cross-platform scenarios, and can also achieve real-time rendering of the outer contour. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 One of the existing model rendering example diagrams provided for the polygon model rendering method of this application; Figure 2 The second example of existing model rendering provided for the polygon model rendering method of this application; Figure 3 This is a flowchart illustrating an embodiment of the polygon model rendering method of this application. Figure 4 One of the improved model rendering example diagrams provided for the polygon model rendering method of this application; Figure 5 Example diagram of the improved model rendering method provided for the polygon model rendering method of this application (II); Figure 6 A simplified flowchart illustrating the polygon model rendering method of this application; Figure 7 This is a schematic diagram of the module structure of the polygon model rendering system according to an embodiment of this application; Figure 8 This is a schematic diagram of the hardware operating environment involved in the polygon model rendering method in this application embodiment.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0023] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device, big data service platform, or polygon model rendering system capable of the above functions. The following description uses a polygon model rendering system as an example to illustrate this embodiment and the subsequent embodiments.

[0024] Based on this, embodiments of this application provide a polygon model rendering method, referring to... Figure 3 , Figure 3 This is a flowchart illustrating the first embodiment of the polygon model rendering method of this application.

[0025] In this embodiment, the polygon model rendering method includes steps S11 to S14: Step S11: Obtain the polygonal mesh model to be rendered, and perform de-indexing processing on the polygonal mesh model to obtain a sequence of independent triangles without shared vertices. It should be noted that the polygonal mesh model to be rendered refers to a set of 3D model data formed by stitching together multiple polygonal faces. De-indexing refers to the process of removing the shared index relationship of vertices in the polygonal mesh model, so that the vertices of each triangle face are no longer reused by other triangle faces. An independent triangle face sequence without shared vertices refers to an ordered set of multiple triangle faces where each triangle face has its own unique vertex data and there is no vertex reuse.

[0026] The core purpose of this step is to eliminate the interference caused by shared vertices to subsequent encoding, topological relationship construction, and outer contour recognition. By giving each triangle face an independent vertex, the accuracy of subsequent operations such as centroid encoding allocation and edge-face relationship determination is ensured.

[0027] Specifically, refer to steps S21-S23, which will not be repeated here. For example, the system obtains a polygonal mesh model containing 100 triangles. This model uses an indexing mechanism to allow 20 vertices to be shared by multiple triangles. After traversing all triangle indexes, the system identifies these 20 shared vertices and copies the vertex data (including spatial position, normal direction, and texture coordinates) for each shared vertex reference in different triangles. Finally, it generates an independent triangle sequence containing 300 independent vertices (3 independent vertices for each triangle), ensuring that the vertices of each triangle are no longer shared with other triangles.

[0028] Step S12: Generate unique point identifiers for the independent vertices of each triangle in the independent triangle face sequence, construct the common edge relationship between each triangle face and the undirected edge, and calculate the included angle of the normal corresponding to each undirected edge. It should be noted that a unique vertex identifier refers to the unique identification information assigned to each independent vertex within the entire model data, used to accurately distinguish different vertices. An undirected edge refers to an edge structure determined solely by two independent vertices, without distinguishing between start and end points. Shared edge relationships refer to the topological information recording the correspondence between each undirected edge and its associated triangular face. The included normal angle refers to the angle formed between the normal vectors of two associated triangular faces, and is key data for determining whether an edge is an outer contour edge.

[0029] For details, please refer to steps S31-S43, which will not be repeated here.

[0030] Step S13: For any of the triangles, determine the outer contour edges of the triangle based on the shared edge relationship and the included angle of the normals; It should be noted that the outer contour edge refers to the external contour shape that reflects the triangular facets in a polygonal mesh model. The core purpose of this step is to accurately filter out the outer contour edges from all undirected edges, excluding the internal auxiliary edges generated during the model triangulation process. The approach is to combine the number of associated triangular faces of the undirected edge and the angle between the normals to make the judgment. The number of associated triangular faces reflects whether the edge is located on the model boundary, and the angle between the normals reflects the degree of folding on the two sides of the edge. The combination of the two can cover the identification of outer contour edges in different scenarios, ensuring that the identification results are comprehensive and accurate.

[0031] For details, please refer to steps S51-S54, which will not be repeated here.

[0032] Step S14: Encode the classification information of the outer contour edge into the vertex attribute, and adapt and render the encoded polygon mesh model to the target game engine to realize real-time outline drawing of the outer contour.

[0033] It should be noted that the classification information of the outer contour edges refers to the relevant data used to identify whether an undirected edge is an outer contour edge, including information such as the edge's affiliation and status. Encoding refers to the process of converting the classification information of the outer contour edges into a format that can be stored in vertex attributes and writing it into the vertex attributes. Vertex attributes refer to various types of data associated with vertices, including texture coordinate attributes and color attributes. Texture coordinate attributes refer to the coordinate data used to map texture images, and color attributes refer to the numerical data used to define vertex colors. The target game engine refers to the software platform used to implement 3D model rendering, which is the carrier for the final presentation of the model. Adaptive rendering refers to the process of converting the format of the encoded model and configuring its parameters according to the format requirements and rendering rules of the target game engine, so that it can be displayed correctly in the target game engine. Real-time outer contour outlining refers to the real-time identification of the model's outer contour edges and the drawing of lines during the game engine's operation, resulting in a rendering effect where the model's outline is clearly visible.

[0034] The core objective of this step is to embed the recognition results of the outer contour edges into the model data. By adapting to the target game engine, real-time rendering of the outer contour is achieved, ensuring both the compatibility of the encoded information and vertex attributes, as well as the efficiency and cross-platform compatibility of the rendering process, ultimately presenting a clear and stable outer contour outline effect. In one possible implementation, the classification information of the outer contour edges can be encoded into texture coordinate attributes and color attributes respectively through two forms: centroid encoding order and outer contour edge mask. The encoded model file can be exported as an open-source format model file or a description file containing topological and encoded information, depending on the format support of the target game engine.

[0035] For details, please refer to steps S61-S73, which will not be repeated here.

[0036] This embodiment obtains a polygonal mesh model to be rendered and performs de-indexing processing on the polygonal mesh model to obtain a sequence of independent triangles without shared vertices. Then, it generates unique point identifiers for the independent vertices of each triangle in the sequence, constructs the common edge relationship between each triangle and an undirected edge, and calculates the normal angle corresponding to each undirected edge. Thus, for any triangle, based on the common edge relationship and the normal angle, it determines the outer contour edge of the triangle, and encodes the classification information of the outer contour edge into the vertex attributes. The encoded polygonal mesh model is then... Adapting to the target game engine, it enables real-time outlining of the outer contour. By de-indexing, it obtains an independent sequence of triangles, avoiding encoding and interpolation errors caused by shared vertices. It accurately constructs topological relationships and determines the outer contour edges by combining the shared edge relationship and the angle between the normals. This accurately distinguishes the real outer contour from the internal edges generated by model triangulation, avoiding erroneous outlining, effectively filtering internal auxiliary edges, and improving the accuracy of outer contour recognition. Furthermore, it embeds vertex attributes through encoded information, which can be directly read by the GPU without relying on special shaders. It is compatible with mainstream game engines and cross-platform scenarios, and can also achieve real-time rendering of the outer contour.

[0037] In one feasible implementation, the step of de-indexing the polygonal mesh model to obtain a sequence of independent triangles without shared vertices includes: Step S21: Traverse all triangle indices in the polygon mesh model and identify shared vertices with shared relationships in the triangle indices; It's important to note that the triangle face index refers to a set of integer identifiers used to record the position of each triangle face vertex in the vertex array. Each triangle face is mapped to a specific vertex in the vertex array through three consecutive index values. A shared relationship refers to the association state where the same vertex is referenced by two or more triangle faces. The core purpose of this step is to accurately locate vertices that are reused in the model, avoiding data confusion or errors in subsequent topology construction and encoding operations due to vertex sharing, and ensuring that the vertex data of each triangle face is independently controllable.

[0038] In one possible implementation, an index-vertex mapping table can be established to record the vertex identifier corresponding to each index. Then, by counting the number of times the vertex identifier is referenced by the index, if the number of references is greater than 1, the vertex is determined to be a shared vertex with a sharing relationship.

[0039] Specifically, the system first loads the complete data of the polygonal mesh model and extracts an index array storing all triangle face indices. This array defines the vertex index of a triangle face as a group of three integers. The system then sequentially traverses each index value in the index array, while maintaining a temporary storage structure to record the vertex identifier corresponding to each index value and its reference count. During the traversal, for each index value, the system checks if a record corresponding to that index already exists in the temporary storage structure. If it does, the reference count is incremented by 1; otherwise, a new record is created and the reference count is initialized to 1. After the traversal is complete, the system filters out the vertices corresponding to indices with a reference count greater than 1. These vertices are the shared vertices with shared relationships, and all triangle face indices corresponding to each shared vertex are marked.

[0040] For example, given a polygonal mesh model with the index array [0,1,2, 1,2,3, 2,3,4], when the system traverses this array, index 0 is referenced once, index 1 is referenced twice, index 2 is referenced three times, index 3 is referenced twice, and index 4 is referenced once. After statistical analysis using a temporary storage structure, the system determines that the vertices corresponding to indices 1, 2, and 3 are shared vertices, and records that index 1 corresponds to the 1st and 2nd triangles, index 2 corresponds to the 1st, 2nd, and 3rd triangles, and index 3 corresponds to the 2nd and 3rd triangles.

[0041] Step S22: Copy the vertex data corresponding to the shared vertex and reconstruct a vertex array containing position, normal and texture coordinates; It's important to note that vertex data refers to all attribute information related to a vertex and is the core data defining vertex features. Position refers to the vertex's coordinates in 3D space, typically represented by X, Y, and Z axis coordinates, used to determine the vertex's spatial location. Normals refer to the vector information perpendicular to the surface of the triangle containing the vertex, used to calculate the model's lighting effects and influence the shading during rendering. Texture coordinates refer to the 2D coordinate information used to map texture images onto the model's surface, typically represented by U and V values, used to determine the sampling position of the texture image at the vertex. Reconstructing the vertex array refers to generating new vertex entries based on the original vertex data by copying shared vertex data, ultimately forming a new array containing data from all independent vertices.

[0042] The core purpose of this step is to assign a dedicated copy of vertex data to each shared vertex referenced in different triangles, ensuring that each triangle has independent vertex attributes and avoiding rendering errors caused by attribute overlap or conflict between shared vertices. It also provides complete vertex attribute support for subsequent topology construction and outer contour encoding. In one possible implementation, when copying shared vertex data, the original vertex's position, normal, and texture coordinate information can be completely copied to ensure consistency between the copied vertex data and the original data. Alternatively, the normals or texture coordinates can be fine-tuned according to the needs of different triangles to optimize the rendering effect of specific triangles.

[0043] Specifically, the system first extracts the original vertex array from the polygon mesh model, which contains the position, normal, and texture coordinate data of each vertex. Then, for each shared vertex identified in step S21, the system searches for all its corresponding triangle indices. For each shared vertex and its corresponding triangle index, the system reads the complete data (including position, normal, and texture coordinates) of the shared vertex from the original vertex array, copies this data as a new vertex data entry, and stores it in a new vertex array. Simultaneously, the system records the association between each new vertex data entry and its corresponding triangle index, ensuring that subsequent triangles can be correctly associated with the copied independent vertex data. This process is repeated until all the corresponding data for all shared vertices has been copied, ultimately reconstructing a vertex array containing the data of all independent vertices.

[0044] For example, in step S21, the original shared vertex data corresponding to index 1 is identified as (position: (1,0,0), normal: (0,1,0), texture coordinates: (0.2,0.3)), which corresponds to the 1st and 2nd triangle faces. The system copies this vertex data to generate two new vertex entries. The data of new entry 1 is consistent with the original data and associated with the 1st triangle face index; the data of new entry 2 is also consistent with the original data and associated with the 2nd triangle face index. These two new entries are then stored in the reconstructed vertex array.

[0045] Step S23: Based on the reconstructed vertex array, generate an independent triangle sequence in which each triangle has an independent vertex.

[0046] It should be noted that an independent triangle sequence refers to an ordered set of multiple triangles, where each triangle's three vertices are unique and independent, with no vertices shared with other triangles. Each triangle having independent vertices means that the vertex data entries corresponding to the three vertices of each triangle are unique, belonging solely to that triangle and not referenced by any other triangle.

[0047] The core purpose of this step is to re-associate the reconstructed independent vertex data with the triangle face index to form a complete set of triangle faces with independent vertices, completely eliminating the sharing relationship of vertices in the original model, ensuring that the edge attribution of each triangle face is clear, and avoiding edge identification confusion caused by vertex sharing.

[0048] In one possible implementation, the original index of each triangle face can be replaced with the new index of the corresponding independent vertex in the reconstructed vertex array by regenerating the triangle face index, thereby generating an independent triangle face sequence in which each triangle face has an independent vertex.

[0049] Specifically, the system first obtains the reconstructed vertex array, which contains independent data entries for all original vertices and copied shared vertices. Then, the system iterates through each triangle of the original model, checking whether the vertex corresponding to its original index is a shared vertex for each triangle. If the vertex corresponding to the original index is not a shared vertex, the original index is directly mapped to the new index of the corresponding vertex in the reconstructed vertex array. If the vertex corresponding to the original index is a shared vertex, the independent vertex data entry corresponding to the shared vertex for the current triangle is found according to the association recorded in step S22, and its new index in the reconstructed vertex array is obtained. The system assigns three new indices to each triangle, forming an independent index combination for that triangle. Then, all the independent index combinations of triangles are arranged sequentially to generate an independent triangle sequence. Each triangle in this sequence is associated with a dedicated vertex in the reconstructed vertex array through its independent index.

[0050] For example, the reconstructed vertex array contains 5 original vertex entries and 3 copied shared vertex entries, for a total of 8 independent vertex entries. The original index of the first triangle is [0,1,2], where indices 1 and 2 are shared vertices. The system maps index 0 to index 0 of the reconstructed vertex array, maps the copied vertex of the first triangle corresponding to the original index 1 to index 5, and maps the copied vertex of the first triangle corresponding to the original index 2 to index 6, forming a new index combination [0,5,6]. The triangle corresponding to this combination is the triangle with independent vertices. After processing all triangles in this way, a sequence of independent triangles containing all independent triangles is generated.

[0051] This embodiment reconstructs a vertex array containing complete attributes, providing independent and complete basic data for the triangle face. This ensures that there are no missing attributes in the subsequent construction of topological relationships, thereby eliminating interference from shared vertices and avoiding calculation chaos caused by vertex reuse during subsequent centroid encoding allocation and outer contour edge determination. This ensures data accuracy, that is, avoids interpolation errors caused by shared vertices, and ensures that subsequent vertex attribute encoding can accurately correspond to a single triangle face, thus improving the stability of the rendering effect.

[0052] In one feasible implementation, the step of generating unique point identifiers for the independent vertices of each triangle in the sequence of independent triangles, constructing the shared edge relationship between each triangle and the undirected edge, and calculating the included angle of the normal corresponding to each undirected edge includes: Step S31: Obtain the spatial coordinate information of each independent vertex; It should be noted that an independent vertex refers to a vertex that, after de-indexing, belongs solely to a single triangle and is not shared with other triangles. Spatial coordinate information refers to the three-dimensional coordinate data used to describe the position of an independent vertex in three-dimensional space, typically including values ​​in the X, Y, and Z axes. In one embodiment, spatial coordinate information can be directly extracted from the reconstructed vertex array, which, after de-indexing, stores complete attribute data for each independent vertex, including spatial coordinates, normals, texture coordinates, etc. Extraction only requires filtering out the fields related to spatial coordinates.

[0053] Specifically, the system locates the reconstructed vertex array generated after deindexing. This array stores the complete attribute data of each independent vertex in sequence. Then, the system sequentially traverses each vertex entry in the reconstructed vertex array, extracts the X-axis, Y-axis, and Z-axis coordinate values ​​used to represent spatial position from each entry, combines these three values ​​to form the spatial coordinate information of the independent vertex, and establishes the association between the spatial coordinate information and the corresponding independent vertex to ensure that each independent vertex can correspond to a unique set of spatial coordinate information, and finally forms a dataset containing the spatial coordinate information of all independent vertices.

[0054] For example, the reconstructed vertex array contains 36 independent vertex entries. When the system traverses the array, it extracts the coordinate values ​​X=1.0, Y=0.0, Z=0.0 from the first entry and combines them to form the spatial coordinate information of that vertex; it extracts the coordinate values ​​X=1.0, Y=1.0, Z=0.0 from the second entry as the spatial coordinate information of the second independent vertex, and so on, until the spatial coordinate information of all 36 independent vertices has been extracted.

[0055] Step S32: Based on the bit pattern of the spatial coordinate information, generate a unique point identifier for each independent vertex, extract the undirected edges corresponding to each triangle face, and construct a unique edge identifier for each undirected edge to build a topology table; It should be noted that the bit pattern of spatial coordinate information refers to the binary data pattern obtained by converting the floating-point values ​​of spatial coordinates according to a specific standard (such as the IEEE 754 standard). This pattern can accurately reflect the original storage form of floating-point numbers and avoid misjudgments caused by precision errors when directly comparing floating-point numbers. A unique vertex identifier refers to vertex identification information generated based on the spatial coordinate bit pattern, which is unique throughout the entire model data and is used to accurately distinguish different independent vertices. An undirected edge refers to an edge structure determined only by two independent vertices, without distinguishing between start and end points; each triangle contains three undirected edges. A unique edge identifier refers to the unique identification information assigned to each undirected edge, used to distinguish different undirected edges. A topology table refers to the data structure used to store the relationships between independent vertices, undirected edges, and triangles. The core purpose of this step is to generate unique vertex identifiers through the spatial coordinate bit pattern to avoid vertex confusion, while simultaneously extracting undirected edges and constructing unique edge identifiers, ultimately forming complete topological relationship data.

[0056] In one possible implementation, when generating a unique point identifier, the floating-point numbers of the X, Y, and Z axis coordinates can be converted into binary bit patterns respectively, and then the three binary bit patterns can be concatenated and converted into a decimal integer as the unique point identifier of the vertex; when constructing a unique edge identifier, the unique point identifiers of the two vertices of the undirected edge can be concatenated in ascending order to form the unique identifier of the undirected edge.

[0057] Specifically, the system first processes the spatial coordinate information of each independent vertex, converting the floating-point numbers corresponding to the X, Y, and Z axes into binary mode according to the IEEE 754 standard. Then, it concatenates the binary modes of these three directions into a complete binary string, and finally converts this binary string into a decimal integer as the unique identifier of the independent vertex. Next, the system traverses each triangle in the sequence of independent triangles, extracting the three edges of the triangle based on the unique identifiers of the three independent vertices associated with it, and treating each edge as an undirected edge (ignoring vertex order). Then, the system constructs a unique edge identifier for each undirected edge, sorting the unique identifiers of the vertices at both ends of the undirected edge according to a preset rule (e.g., ascending order) and concatenating them to form a unique edge identifier. Finally, the system associates the unique identifiers of the independent vertices, the unique edge identifiers of the undirected edges, and the identifier information of the triangles to construct a topological table recording the relationships between the three.

[0058] For example, if the spatial coordinates of an independent vertex are (1.0, 0.0, 0.0), the system converts its X, Y, and Z axis floating-point numbers into binary format and concatenates them to obtain the binary string "110000000000000000000000000000000...". This string is then converted into a decimal integer 1073741824, which serves as the unique identifier for that vertex. If the unique identifiers of three independent vertices associated with a triangle are 1073741824, 1073741825, and 1073741826, the system extracts three undirected edges. The two endpoints of one of these edges are identified as 1073741824 and 1073741825, which are then sorted in ascending order and concatenated to form "1073741824_1 073741825", serving as the unique identifier for that undirected edge. This information is then entered into the topology table.

[0059] Step S33: Record the triangular face information corresponding to each undirected edge using a hash table to form a shared edge relationship; It's important to note that a hash table is a high-efficiency data structure based on key-value pairs, offering fast querying, insertion, and modification capabilities. Here, it's used to store the mapping between undirected edges and triangle facets. Triangle facet information refers to the data used to identify triangle faces, including at least a triangle facet identifier (uniquely distinguishing different triangle faces) and a relative vertex identifier (information indicating the relative position of an undirected edge within a triangle facet). Shared edge relationships refer to the topological information describing the correspondence between each undirected edge and one or more associated triangle faces. The core objective of this step is to establish a mapping between undirected edges and triangle faces using a hash table, clearly defining which triangle faces share each undirected edge, ensuring efficient and accurate queries of edge-facet relationships.

[0060] In one possible implementation, the key of the hash table is set as the unique edge identifier of the undirected edge, and the value of the hash table is set as a list containing triangular face information. If multiple triangular faces share the same undirected edge, the list corresponding to the undirected edge will store the information of all associated triangular faces.

[0061] Specifically, the system initializes an empty hash table, sets the unique edge identifier of the undirected edge as the key, and sets the information set containing the triangle face identifier and the relative vertex identifier as the value. The system then iterates through each undirected edge in the topology table, finding the corresponding triangle face information based on the relationships recorded in the topology table.

[0062] For each undirected edge, the system checks if a key-value pair corresponding to the edge's unique edge identifier already exists in the hash table. If it doesn't exist, a new key-value pair is created, using the edge's unique edge identifier as the key and the corresponding triangle face information as the value, and stored in the hash table. If it already exists, the current triangle face information is added to the value list corresponding to that key. After traversal, each key-value pair in the hash table corresponds to an undirected edge and all its associated triangle face information, thus forming a shared edge relationship.

[0063] For example, if the unique edge identifier of an undirected edge is "1073741824_1073741825", the identifier of its associated first triangle is "Tri_001", and the identifier of its relative vertex is "V2", the system creates a key-value pair corresponding to this edge identifier in the hash table with the value [{"Tri_001", "V2"}]. When traversing to a point where the undirected edge is also associated with a second triangle (identified as "Tri_002" and its relative vertex as "V3"), the system adds the triangle information to the corresponding value list. At this time, the value of the key becomes [{"Tri_001", "V2"}, {"Tri_002", "V3"}], indicating that the undirected edge is a shared edge of two triangles.

[0064] Step S34: Based on the topology table and the shared edge relationship, calculate the normal vector of each triangle face, and calculate the normal angle between the normal vectors of the associated triangle faces.

[0065] It's important to note that the normal vector refers to the vector perpendicular to the plane containing the triangular face. Its direction is determined by the three vertices of the triangle according to the right-hand rule. It's the core data describing the spatial orientation of the triangular face, typically including components along the X, Y, and Z axes. Associated triangles refer to two triangles sharing the same undirected edge. These triangles with shared edges can be identified through edge-sharing relationships. The included normal angle is the angle formed between the normal vectors of two associated triangles. Its magnitude reflects the degree of folding between the two triangles and is a key quantitative basis for determining whether a shared edge is an outer contour edge. The core purpose of this step is to improve the accuracy of the outer contour edge determination by calculating the normal vectors of the triangles and the included normal angle between the associated triangles, combining the number of shared edges with the degree of folding.

[0066] In one possible implementation, the normal vector can be calculated using the spatial coordinates of the three vertices of the triangle face and the cross product operation; the included angle can be calculated using the normal vectors of two related triangle faces and the dot product operation combined with the inverse cosine function, and the angle result is expressed as an angle value.

[0067] Specifically, the system first obtains the spatial coordinates of the three independent vertices associated with each triangle face based on the topology table. It then arbitrarily selects two coordinates from these three to calculate the direction vectors of the two edges. A cross product is performed on these two direction vectors to obtain a vector perpendicular to the triangle face. This vector is then normalized (making its length 1), ultimately yielding the normal vector of the triangle face. Next, the system iterates through each undirected edge in the shared edge relationships, querying the number of triangle faces associated with that edge. If two triangle faces are associated, they are determined to be associated. The system then extracts the normal vectors of these two associated triangle faces, calculates the dot product of the two normal vectors using vector dot product, and converts the dot product into a corresponding angle value using the inverse cosine function. This angle value is the angle between the normal vectors of the two associated triangle faces.

[0068] For example, the spatial coordinates of the three vertices of a triangle are (1.0, 0.0, 0.0), (1.0, 1.0, 0.0), and (0.0, 1.0, 0.0). The system calculates the direction vectors of the two edges as (0.0, 1.0, 0.0) and (-1.0, 0.0, 0.0), respectively. Performing a cross product on these vectors yields a vector of (0.0, 0.0, -1.0), which, after normalization, becomes the normal vector of the triangle. This triangle shares an undirected edge with another triangle. The system extracts the normal vector of the other triangle as (0.0, 0.0, 1.0), calculates the dot product of the two vectors, and finds -1.0. Transforming this with an inverse cosine function, the angle between the normals is 180 degrees, indicating that the two triangles are parallel in opposite directions.

[0069] This embodiment generates unique point identifiers based on spatial coordinate patterns, which can accurately determine the identity of vertices, avoid topological mismatches caused by floating-point errors, support high-precision model processing, and then use a hash table to record undirected edges and triangular face information, which can quickly query the ownership of edges, efficiently form shared edge relationships, improve the efficiency of edge classification and outer contour recognition, and then accurately quantify the degree of folding between triangular faces by combining the topology table and shared edge relationships to ensure accurate recognition results.

[0070] In one feasible implementation, the triangular face information includes triangular face identifiers and relative vertex identifiers; the step of recording the triangular face information corresponding to each undirected edge through a hash table to form a shared edge relationship includes: Step S41: Store the unique edge identifier of each undirected edge as a key in a hash table; It's important to note that the unique edge identifier of an undirected edge refers to the identification information used to uniquely distinguish each undirected edge. It is typically generated by combining the unique vertex identifiers of the two independent vertices at both ends of the undirected edge according to preset rules, ensuring that each undirected edge has a unique and non-repeating identifier. A hash table is an efficient data structure based on key-value pairs, featuring fast querying, insertion, and matching capabilities, significantly improving data association efficiency. The key value refers to the keyword used to index data in the hash table. Here, the unique edge identifier of the undirected edge is used as the key value to establish a mapping relationship between the undirected edge and the associated triangle information, enabling the corresponding triangle information to be quickly located using the unique edge identifier.

[0071] The core purpose of this step is to build a basic index system for the hash table. Using unique edge identifiers as keys, it lays the foundation for storing triangular face information and establishing shared edge relationships, ensuring efficient querying of edge-face associations. In one possible implementation, when storing data in the hash table, the unique edge identifier can be hashed first, and the resulting hash value can be used as an index to store the corresponding location in the hash table, further improving subsequent query efficiency.

[0072] Specifically, the system first retrieves the unique edge identifiers of all previously constructed undirected edges, ensuring that each identifier is complete and unique. Then, it initializes an empty hash table, setting the key-value type of the hash table to match the type of the unique edge identifier. Next, the system sequentially traverses the unique edge identifiers of all undirected edges. For each identifier, it directly inserts it as the key into the hash table. At this point, the hash table only stores the key; the corresponding value field is temporarily empty, awaiting subsequent steps to supplement the associated triangle face information, ensuring that each unique edge identifier has a corresponding entry in the hash table.

[0073] For example, if the unique edge identifier of an undirected edge is "1073741824_1073741825", when the system traverses to this identifier, it inserts it as a key into the hash table, adding a new entry to the hash table with the key "1073741824_1073741825" and an empty value, thus completing the storage of the undirected edge key.

[0074] Step S42: Store the triangular face identifiers and relative vertex identifiers associated with each of the undirected edges as values ​​in a hash table; It's important to note that the triangle identifier associated with an undirected edge is the unique identification information that distinguishes the triangle to which the undirected edge belongs. Each triangle has a unique identifier to clearly identify which triangle the undirected edge belongs to. The relative vertex identifier refers to the position of the undirected edge relative to the other two vertices within its triangle, used to help determine the specific orientation of the undirected edge within the triangle. The value refers to the associated data in the hash table corresponding to the key value, which here is a combination of the triangle identifier and the relative vertex identifier, forming a correspondence with the previously stored unique edge identifier (key value). The core purpose of this step is to improve the data association in the hash table, binding undirected edges with their corresponding triangle information, so that the associated triangle and its position within the triangle can be quickly retrieved using the unique edge identifier.

[0075] In one possible implementation, the triangle face identifier and the relative vertex identifier can be encapsulated into a data structure (such as a struct, dictionary, etc.), and then the data structure can be stored as a value in a hash table, making the data storage more organized and subsequent retrieval more convenient.

[0076] Specifically, the system first obtains the triangle face identifier and relative vertex identifier corresponding to each undirected edge, ensuring the accuracy of the association between these identifiers and the undirected edges. Then, the system iterates through the unique edge identifier (key value) of each undirected edge already stored in the hash table, and finds the triangle face identifier and relative vertex identifier corresponding to that key value based on the association between the undirected edge and the triangle face. Next, these two identifiers are combined into a complete data unit and stored as the value under the corresponding key value entry in the hash table, so that each key value entry in the hash table corresponds to complete triangle face information, completing the association and binding between key values ​​and values.

[0077] For example, the triangular face associated with the undirected edge corresponding to the key value "1073741824_1073741825" in the hash table is identified as "Tri_001", and the relative vertex is identified as "V2". The system combines these two identifiers into a data unit ("Tri_001", "V2"), and stores this data unit as the value in the entry corresponding to the key value in the hash table, thus completing the value storage.

[0078] Step S43: By traversing the undirected edges of each triangle, the hash table is constructed, forming a shared edge relationship.

[0079] It's important to clarify that traversing the undirected edges of each triangle refers to the system sequentially processing each triangle in the sequence of independent triangles, extracting the three undirected edges contained in each triangle, and performing a hash table storage operation on each undirected edge. The construction of the hash table involves storing keys and corresponding values ​​through the preceding steps, ultimately forming a complete key-value pair mapping relationship, ensuring that each undirected edge can be found in the hash table with its corresponding triangle information. Shared edge relationships refer to using the association information between undirected edges and triangles stored in the hash table to determine which triangles share each undirected edge in the topology.

[0080] The core objective of this step is to ensure that all undirected edges and their associated triangular face information are completely stored in the hash table by comprehensively traversing all undirected edges of the triangles. This forms a complete and comprehensive edge-face association, clarifying the ownership of each edge and providing reliable topological data for subsequent determination of the outer contour edges based on the number of shared edges and the included angle of the normals. In one possible implementation, processed undirected edges can be marked during the traversal to avoid redundant processing and improve construction efficiency. If an undirected edge is shared by multiple triangular faces, when traversing the edge in different triangular faces, the corresponding triangular face information is sequentially added to the list of corresponding values ​​in the hash table.

[0081] Specifically, the system first obtains all triangles in the independent triangle sequence and traverses them in a preset order (e.g., by triangle identifier from smallest to largest). For each triangle, it extracts its three undirected edges, obtaining the unique edge identifier of each undirected edge, the corresponding triangle identifier, and the relative vertex identifier of the undirected edge within that triangle. The system then checks if a key-value entry corresponding to the unique edge identifier of the undirected edge already exists in the hash table: if it does, the current triangle identifier and the relative vertex identifier are added to the value list of that entry; if it does not exist, the unique edge identifier is first stored as a key in the hash table, and then the current triangle identifier and the relative vertex identifier are stored as values ​​in the corresponding entry. This process is repeated until all undirected edges of all triangles have been traversed. Each entry for an undirected edge in the hash table stores information about all its associated triangles, forming a shared edge relationship.

[0082] For example, when the system traverses to the triangle "Tri_002", it extracts the unique edge identifier of its undirected edge as "1073741824_1073741825", thus identifying the triangle as "Tri_002" and its opposite vertex as "V3". The system queries the hash table and finds that this key already exists, and that the corresponding value list already contains ("Tri_001", "V2"). Therefore, it adds ("Tri_002", "V3") to the value list. At this point, the value corresponding to this key is [{"Tri_001", "V2"}, {"Tri_002", "V3"}], clearly indicating that this undirected edge is a shared edge of two triangles, thus completing the construction of the shared edge relationship.

[0083] This embodiment achieves accurate mapping between undirected edges and triangular face information by setting a key-value pair storage structure, resulting in high query efficiency. It traverses the undirected edges of the triangular faces to build a hash table, ensuring no missing associations and comprehensive construction of shared edge relationships.

[0084] In one feasible implementation, determining the outer contour edge of the triangular face based on the shared edge relationship and the included angle of the normals includes: Step S51: Determine the number of triangular faces associated with each undirected edge in the shared edge relationship; It should be noted that the shared edge relationship refers to the correspondence between undirected edges and associated triangles stored in a hash table, including information on all triangles to which each undirected edge belongs. An undirected edge is an edge structure defined by two independent vertices, without distinguishing between a start and end point. The number of associated triangles refers to how many triangles share or belong to each undirected edge, which is one of the core criteria for determining whether an undirected edge is an outer contour edge. By counting the number of triangles associated with each undirected edge, a basic classification standard is provided for subsequent case-by-case determination of outer contour edges, ensuring the orderliness and accuracy of the outer contour edge determination logic and avoiding misjudgments caused by directly applying the same determination rule to all undirected edges. In one possible implementation, the number of triangles associated with each undirected edge can be counted by traversing the list of triangle information corresponding to each undirected edge in the hash table.

[0085] Specifically, the system first obtains the constructed hash table of shared edge relationships. The keys of this hash table are the unique edge identifiers of undirected edges, and the values ​​are lists containing information about associated triangles. The system then sequentially traverses each key-value pair in the hash table. For each unique edge identifier of an undirected edge, it reads its corresponding value list and counts the number of triangle information entries in the list. This count represents the number of triangles associated with that undirected edge. The system associates and stores the unique edge identifier of each undirected edge with the corresponding number of triangles, forming an undirected edge-triangle number mapping table to provide data support for subsequent steps.

[0086] For example, in a hash table, the unique edge identifier of an undirected edge is "1073741824_1073741825", and its corresponding value list contains two triangle face information entries. After counting, the system determines that the number of triangle faces associated with this undirected edge is 2. Another undirected edge has the unique edge identifier "1073741826_1073741827", and its corresponding value list contains only one triangle face information entry. The system determines that the number of triangle faces associated with it is 1.

[0087] Step S52: For any of the undirected edges, if the number of triangles is one, then the undirected edge is determined to be the outer contour edge of the triangle. It should be noted that "one triangle" means that an undirected edge belongs to only one triangle and is not shared by any other triangles. An outer contour edge refers to an undirected edge that represents the external contour of the polygonal mesh model and is located on the boundary of the model surface; it is the target object for subsequent outlining and rendering. The core purpose of this step is to directly determine that undirected edges belonging to only a single triangle are outer contour edges based on the classification of triangle counts. This is because such edges are usually located at the boundary of the model, without being surrounded by other triangles, and are an important part of the model's outer contour. This determination logic is simple and efficient, and can quickly filter out boundary-type outer contour edges. In one possible implementation, after determination, the unique edge identifier of the undirected edge can be marked, or its outer contour edge status can be recorded in the associated data, providing a clear identifier for subsequent coding steps.

[0088] Specifically, the system iterates through each record in the undirected edge-triangle number mapping table. For any undirected edge, it extracts the number of triangles associated with it. If the number is one, it means that the undirected edge belongs to only one triangle, and no other triangles share the edge with it. That is, the edge is located at the boundary of the model and is not occluded by any adjacent triangles. Based on this, the system directly determines that the undirected edge is the outer contour edge of the triangle to which it belongs, and associates and stores this determination result with the unique edge identifier of the undirected edge for subsequent coding.

[0089] For example, when the system traverses to the undirected edge "1073741826_1073741827", the number of associated triangles is 1, and the triangle to which it belongs is identified as "Tri_003". The system directly determines that the undirected edge is the outer contour edge of the "Tri_003" triangle and marks the outer contour edge status of the undirected edge as "yes" in the data.

[0090] Step S53: If the number of triangles is two, obtain a preset angle threshold and compare the included angle of the normal with the angle threshold. It's important to note that having two triangles means that a certain undirected edge is shared by two triangles; it's a common edge of the two triangles. The preset angle threshold refers to a pre-defined angle standard used to determine the degree of folding of triangle faces. This can be adjusted according to different rendering styles and model requirements and is a key parameter for distinguishing between hard-folded edges and smooth edges. The normal angle refers to the angle formed between the normal vectors of the two triangles sharing the undirected edge, reflecting the spatial orientation difference between the two triangles. The core purpose of this step is to further filter the shared undirected edges using the angle dimension. By comparing the normal angle with the angle threshold, it determines whether the edge becomes an outer contour edge due to a large degree of folding, overcoming the limitations of judging solely by the number of triangles and ensuring that hard-folded outer contour edges are not missed.

[0091] In one possible implementation, the angle threshold can be preset to a fixed value such as 15 degrees or 30 degrees, or it can be flexibly configured by the user according to the rendering effect during use. The system stores the configured threshold in the parameter configuration module for this step to call.

[0092] Specifically, the system iterates through the undirected edge-triangle number mapping table. For undirected edges with two triangles, it first obtains a preset angle threshold from the parameter configuration module. Then, based on the unique edge identifier of the undirected edge, it extracts the corresponding normal angle value from the previously stored normal angle data. Finally, the system compares the extracted normal angle value with the preset angle threshold and records the comparison result (greater than, equal to, or less than), providing a basis for subsequent determination of the outer contour edge.

[0093] For example, if the preset angle threshold is 25 degrees, and the included angle of the normal corresponding to the two undirected edges of a triangle is 30 degrees, the system compares 30 degrees with 25 degrees and obtains the comparison result that "the included angle of the normal is greater than the angle threshold"; if the included angle of the normal corresponding to the other undirected edge is 20 degrees, the comparison result is that "the included angle of the normal is less than the angle threshold".

[0094] Step S54: If the included angle of the normals is greater than the angle threshold, then the undirected edge is determined to be the outer contour edge of the triangular face.

[0095] It should be noted that an angle greater than the angle threshold refers to the angle formed by the normal vectors of two triangular faces sharing an undirected edge. If the angle exceeds the preset threshold, it indicates a significant difference in spatial orientation between the two triangular faces, forming a distinct sharp angle. Outer contour edges refer to edges that highlight the model's outline, including both edges at model boundaries and edges at sharp angles on the model's surface. The core purpose of this step is to identify shared edges at sharp angles as outer contour edges. Although these edges are shared by two triangular faces, their high degree of folding creates a visually distinct contour line, forming an important part of the model's outer contour. This determination logic ensures the comprehensiveness and accuracy of outer contour edge identification.

[0096] In one possible implementation, after determination, the system can mark the outer contour edge of the undirected edge as "yes" and associate it with the two triangular face identifiers to which it belongs, so as to ensure that the subsequent encoding can accurately correspond to the relevant triangular face.

[0097] Specifically, the system obtains the comparison result of step S53. For undirected edges with a normal angle greater than a preset angle threshold, the system determines that the undirected edge is the outer contour edge of two shared triangular faces. The system associates the unique edge identifier of the undirected edge with the outer contour edge determination result and synchronously updates it to the undirected edge status data table, thus completing the outer contour edge determination of this type of undirected edge. For undirected edges with a normal angle less than or equal to the angle threshold, the system determines them as internal edges and does not include them in the outer contour edge range.

[0098] For example, if the included angle of the normal of a shared undirected edge is 30 degrees and the preset angle threshold is 25 degrees, since 30 degrees is greater than 25 degrees, the system determines that the undirected edge is the outer contour edge of the two shared triangles "Tri_001" and "Tri_002", and marks the edge as an outer contour edge in the undirected edge status data table; if the included angle of the normal of another shared undirected edge is 20 degrees, which is less than 25 degrees, the system determines that it is an internal edge.

[0099] This embodiment uses a dual judgment based on the number of shared edges and the angle between normals to accurately identify outer contour edges, effectively filter internal auxiliary edges, and has a clear judgment logic that does not require complex calculations, resulting in high execution efficiency and adaptability to real-time rendering requirements. It also covers boundary edges (associated with 1 triangle face) and hard corner edges (associated with 2 triangle faces), providing comprehensive scene recognition.

[0100] In one feasible implementation, encoding the classification information of the outer contour edges into vertex attributes and adapting the encoded polygonal mesh model to the target game engine for real-time outline rendering includes: Step S61: Assign a centroid encoding order to the three vertices of each triangle face, and write the component information corresponding to the centroid encoding order into the texture coordinate attribute of the vertex. It's important to note that the barycentric encoding order refers to the fixed sequence identifier assigned to the three independent vertices of each triangle face, used to accurately identify the edge to which a vertex belongs during rendering. Component information refers to the numerical information corresponding to the barycentric encoding order, representing the specific data of the barycentric encoding order. Vertex texture coordinate attributes refer to the attribute data used to define the sampling position of the vertex on the texture image; it is an important component of vertex attributes and supports native reading by the game engine. The core purpose of this step is to establish the correspondence between vertices and edges by assigning a fixed barycentric encoding order to the vertices and writing it into the texture coordinate attributes. This provides a readable positional reference for subsequent rendering material identification of the outer contour edges, ensuring accurate positioning of the outer contour edges. Simultaneously, leveraging the native compatibility of texture coordinate attributes ensures the stability of cross-platform rendering.

[0101] In one possible implementation, the centroid encoding order can be set to three fixed sets of values: (1,0,0), (0,1,0), and (0,0,1), which correspond to the three vertices of the triangle face respectively. The component information can be written into different channels of the texture coordinate attribute (such as TEXCOORD_0 and TEXCOORD_1) according to preset rules.

[0102] Specifically, the system traverses each triangle in the sequence of independent triangles and assigns a fixed centroid encoding order to the three independent vertices of each triangle. For example, the three independent vertices of a triangle are assigned the centroid encoding orders (1,0,0), (0,1,0), and (0,0,1). The system writes the component information (1,0) of the first vertex into the TEXCOORD_0 attribute and (0) into the TEXCOORD_1 attribute; (0,1) of the second vertex into the TEXCOORD_0 attribute and (0) into the TEXCOORD_1 attribute; and (0,0) of the third vertex into the TEXCOORD_0 attribute and (1) into the TEXCOORD_1 attribute, thus realizing the storage of the centroid encoded component information.

[0103] Step S62: Generate an outer contour edge mask and write the outer contour edge mask into the color attribute of the vertex to complete the classification information encoding; It's important to note that the outer contour edge mask refers to binary identifier data used to determine whether the edge corresponding to a vertex is an outer contour edge; it's the core carrier of outer contour edge classification information. Vertex color attributes refer to attribute data used to define vertex colors, which can be natively read by game engines and directly recognized by rendering materials. Classification information encoding refers to the process of embedding the classification result of the outer contour edge (whether it's an outer contour edge) into the vertex attributes through a mask. The core purpose of this step is to clearly define the outer contour state of the edge corresponding to a vertex through the outer contour edge mask. Combined with the centroid encoding order, this provides a complete basis for outer contour edge identification for rendering materials. Simultaneously, by leveraging the compatibility of color attributes, it ensures that the encoded information can be read in different game engines, completing the standardized storage of outer contour edge classification information.

[0104] In one possible implementation, the outer contour edge mask can use 0 and 1 as identifier values, where 1 indicates that the corresponding edge is an outer contour edge and 0 indicates that it is an inner edge. The mask information can be written into the RGB channel of the color attribute (such as the r, g, and b components of the COLOR_0 attribute).

[0105] Specifically, based on the previous outer contour edge determination results, the system generates a corresponding outer contour edge mask for each edge of each triangle face. For edges determined to be outer contour edges, their corresponding mask values ​​are set to a preset identifier (e.g., 1); for internal edges, the mask value is set to another identifier (e.g., 0). Subsequently, the system determines the mask values ​​of the two edges corresponding to each vertex based on its position within the triangle face. These two mask values, along with the mask value of the third edge, are written into the three channels of the vertex's color attribute (e.g., r, g, b components), ensuring that the color attribute of each vertex includes the corresponding outer contour edge mask information, thus completing the classification information encoding. For example, if two of the three edges of a triangle face are outer contour edges with a corresponding mask value of 1, and one is an internal edge with a mask value of 0. Based on the positions of the three vertices of the triangle, the system writes the mask value 1 of the first edge into the r component of the color attribute of the first vertex, the mask value 1 of the second edge into the g component, and the mask value 0 of the third edge into the b component. Finally, the COLOR_0 attribute value of the vertex is (1,1,0), thus clarifying the outer contour state of its corresponding edge.

[0106] Step S63: According to the type of the target game engine, export the encoded model file of the encoded polygon mesh model, import the encoded model file into the target game engine, and load the adapted rendering materials; It's important to note that the encoded model file refers to the model file containing centroid encoding information and outer contour edge mask information; it serves as the carrier of the encoded model data. The adapted rendering material refers to a material file developed according to the rendering rules of the target game engine, capable of reading the encoded information in vertex attributes and implementing the outer contour outlining logic. The core purpose of this step is to export the corresponding encoded model file according to the format requirements of the target game engine, ensuring that the model data can be correctly parsed in the engine. Simultaneously, by loading the adapted rendering material, the encoded information and the engine rendering are seamlessly integrated.

[0107] For details, please refer to steps S71-S73, which will not be repeated here.

[0108] Step S64: Read the encoded information in the vertex attributes through the rendering material, identify the outer contour edge and adjust the rendering parameters to achieve real-time outlining of the outer contour.

[0109] It's important to note that rendering materials refer to resource files containing outer contour recognition and stroke rendering logic; they are the core carrier connecting encoded information and rendering effects. The encoded information in vertex attributes refers to the previously written centroid encoded component information and outer contour edge mask information, serving as the basis for identifying outer contour edges. Rendering parameters refer to parameters used to adjust the outer contour stroke effect, including contour width, glow intensity, and contour color, which can be flexibly configured according to rendering needs. Real-time outer contour stroke refers to the rendering effect of recognizing the model's outer contour edges and drawing lines in real time during game engine operation; it is the final presentation of the entire technical solution. The core purpose of this step is to accurately identify outer contour edges by parsing the encoded information through rendering materials, and then achieve personalized stroke effects by adjusting rendering parameters, ensuring the real-time performance and stability of the stroke, while avoiding reliance on inefficient solutions such as geometry shaders, thus improving rendering performance.

[0110] In one possible implementation, the rendering material can extract encoded information by sampling the texture coordinates and color attributes of vertices, identify the outer contour edges by combining interpolation operations, and then flexibly adjust the rendering parameters by adjusting the values ​​of parameter nodes.

[0111] Specifically, when the rendering material runs in the target game engine, it first reads the texture coordinates (TEXCOORD_0, TEXCOORD_1) and color (COLOR_0) of the vertices, extracting the centroid encoding component information and the outer contour edge mask information. Then, through internal material logic operations, the edge to which the vertex belongs is determined by the centroid encoding, and the outer contour edge is identified based on the outer contour edge mask. Next, the user or system adjusts the rendering parameters (e.g., setting the contour width to 2 pixels, the glow intensity to 0.8, and the contour color to red). The rendering material then draws the identified outer contour edges in real time according to the adjusted parameters, ultimately presenting a clear outer contour outline effect in the game engine.

[0112] In one embodiment, the ShellOutlineUE material in Unreal Engine reads the TEXCOORD_0 and TEXCOORD_1 attributes of the vertices to obtain the centroid encoded components, reads the COLOR_0 attribute to obtain the outer contour edge mask, and identifies the outer contour edge through node operations in the material graph. The user adjusts the OutlineWidth parameter to 1.5, the GlowIntensity parameter to 1.0, and the LineColor parameter to blue in the material instance. The material sphere draws the outer contour edge in real time based on these parameters, ultimately presenting a blue, glowing 1.5-pixel wide outer contour outline in the scene. (See reference...) Figure 4 as well as Figure 5 It has only an outer outline and no inner edges.

[0113] This embodiment combines the centroid encoding order with texture coordinate attributes to provide a precise positional reference for outer contour edge recognition. Simultaneously, the outer contour edge mask is written into the color attribute, allowing the encoded information to be natively read by the game engine without additional adaptation. The corresponding file is then exported based on the target game engine type, demonstrating strong adaptability and stable use across multiple platforms including Unity, Unreal Engine, and mobile devices. During rendering, the rendering material can directly read the encoded information from the vertex attributes without relying on geometry shaders, significantly improving rendering performance. Furthermore, it supports flexible adjustment of rendering parameters such as contour width, glow intensity, and color, adapting to different styles of outer contour stroking requirements. Therefore, the complete encoding process ensures the accuracy of outer contour edge recognition, effectively filtering out internal auxiliary edges generated by model triangulation, ultimately presenting a clear, noise-free outer contour stroking effect.

[0114] In one feasible implementation, exporting the encoded model file of the encoded polygon mesh model according to the type of the target game engine includes: Step S71: Obtain the model format support information of the target game engine; It's important to note that the target game engine refers to the software platform used for rendering 3D models, such as Unity or Unreal Engine; it's the carrier on which the model is ultimately presented. Model format support information refers to information about the model file formats that the target game engine can directly recognize, parse, and load, including supported format types, compatible versions, and the ability to read corresponding attributes. The core purpose of this step is to clarify the target game engine's compatibility with model file formats, providing a basis for selecting an appropriate model file export method, ensuring that the exported model file can be parsed correctly in the target game engine without losing encoding information, and guaranteeing the cross-platform adaptability of the entire outer contour outlining scheme.

[0115] In one possible implementation, the list of supported model formats and related attributes can be obtained by querying the official documentation of the target game engine, calling the format detection interface provided by the engine, or based on a preset engine format support library.

[0116] Specifically, the system first identifies the target game engine type specified by the user (such as Unity or Unreal Engine), and then obtains a list of model formats supported by that engine through the built-in engine format support library or by querying official data online. Simultaneously, the system also confirms whether each supported format has the ability to read encoded information from vertex attributes (such as texture coordinates and color attributes), ultimately integrating this information to form model format support information that includes supported format types, compatible versions, and the ability to read encoded information, providing a basis for decision-making in subsequent export steps.

[0117] For example, if the user specifies Unreal Engine as the target game engine, the system will find out that the engine natively supports the GLB open-source model format and can directly read the texture coordinates and color attributes of vertices in the format. If the target game engine is Unity, the system will find out that it does not directly support reading the encoding information of the GLB format and needs to be converted through a plugin to obtain the complete model format support information.

[0118] Step S72: If the model format support information does not include open source model formats, then export a description file containing model topology information and encoding information. The description file is used to convert the model into a model file supported by the target game engine through a plugin. It's important to note that open-source model formats refer to widely supported and publicly usable model file formats, such as the GLB format, which features standardized structure and strong cross-platform compatibility. Model topology information refers to the relationship data between vertices, edges, and triangles in the model, serving as the core basis for reconstructing the model's geometry. Encoding information refers to the centroid encoding component information and outer contour edge mask information previously written into vertex attributes, which is crucial data for outer contour recognition. A description file is a text file, such as a JSON file, used to store model topology and encoding information. Its concise format and ease of parsing make it suitable as an intermediate data carrier for plugin conversion. A plugin refers to an auxiliary tool developed to adapt to the target game engine, capable of reading data from the description file and converting it into a model file format supported by the engine.

[0119] The core purpose of this step is to preserve complete model data and encoding information by exporting a description file for game engines that do not support open-source model formats. Then, a plugin is used to perform format conversion, ensuring the model can be loaded correctly in the target engine without losing encoding information, thus guaranteeing the proper implementation of the outer contour outline effect. In one possible implementation, the description file can be in JSON format, storing the model's vertex attributes, triangle indices, topological relationships, and encoding information according to a preset data structure. The plugin parses this file, reconstructs the model, and generates a model file supported by the target engine (such as a Mesh file supported by Unity).

[0120] Specifically, after confirming that the target game engine's model format support information does not include open-source model formats, the system initiates the description file export process. First, it extracts the complete data of the encoded polygonal mesh model, including vertex spatial coordinates, normals, texture coordinates, color attributes (including encoded information), triangle indices, and vertex-edge-face topological relationships. Then, following a preset JSON data structure, this data is categorized, organized, and written into the description file, ensuring the complete storage of model topological and encoded information. After export, this description file can be read by a dedicated plugin adapted to the target game engine. The plugin reconstructs the model's geometry based on the data in the description file and embeds the encoded information into the engine-supported model file, achieving format conversion.

[0121] For example, if the target game engine is Unity, it does not directly support reading the encoding information of the GLB open-source model format. The system exports a JSON description file containing model topology information (vertex relationships, triangle indices) and encoding information (centroid encoding components, outer contour edge masks). After the user imports this JSON file along with the corresponding GLB file into Unity, the ShellOutlineHelper.unity package plugin parses the JSON file, reconstructs the Unity-supported Mesh model file, and retains the encoding information to ensure that subsequent rendered materials can be read correctly.

[0122] Step S73: If the model format support information includes an open-source model format, then export the open-source format model file containing the encoding information.

[0123] It's important to note that open-source format model files refer to model files stored in an open-source model format (such as GLB) that contain centroid encoding component information and outer contour edge mask information. The encoded information refers to the outer contour edge classification data previously written into vertex texture coordinate attributes and color attributes; it is the core basis for identifying outer contour edges during rendering. The core purpose of this step is to directly export open-source format model files containing encoded information for target game engines that support open-source model formats, eliminating the need for additional format conversion steps, simplifying the operation process. Simultaneously, leveraging the standardized characteristics of open-source formats ensures the integrity and compatibility of the encoded information and model data, enabling target game engines to directly read the encoded information and improving development efficiency.

[0124] In one possible implementation, the open-source model file can adopt the GLB format, which supports storing various attribute information of vertices and is natively supported by mainstream engines such as Unreal Engine. When exporting, the encoded information, vertex attributes, and geometric data of the model are encapsulated together in the GLB file.

[0125] Specifically, after confirming that the target game engine supports open-source model formats, the system directly exports the encoded polygonal mesh model as an open-source format (such as GLB) model file. During the export process, the system encapsulates the model's geometric data (vertex coordinates, triangle indices, normals), vertex attributes (centroid encoded components in texture coordinate attributes, outer contour edge masks in color attributes), and related metadata according to the standard structure of the open-source model format, ensuring that the encoded information is tightly bound to the model data and is not lost or damaged. After export, the open-source format model file can be directly imported and parsed by the target game engine. The engine can natively read the encoded information in the vertex attributes, providing data support for subsequent outer contour rendering. The overall implementation process can be found in [reference needed]. Figure 6 .

[0126] For example, the target game engine is Unreal Engine, which supports the GLB open-source model format. The system encapsulates the model data, including the centroid encoding components (stored in TEXCOORD_0 and TEXCOORD_1) and the outer contour edge mask (stored in COLOR_0), according to the GLB format standard and exports it as a GLB file. After the user directly imports this file into Unreal Engine, the engine can natively read the encoding information in the vertex attributes without additional conversion, and load the appropriate rendering materials to achieve real-time outer contour outlining.

[0127] This embodiment adapts to the format differences of different game engines, ensuring that the encoded model can be used across platforms. Open-source formats are exported directly without additional conversion, improving development efficiency. Non-open-source formats are converted using description files and plugins, ensuring no loss of encoded information. Furthermore, model topology information is bound to the encoded information during export, ensuring data integrity during engine-side rendering. It is compatible with mainstream game engines (Unity / Unreal, etc.), expanding the applicability of the technical solution.

[0128] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0129] This application also provides a polygon model rendering system; please refer to... Figure 7 The polygon model rendering system includes: The acquisition module 71 is used to acquire the polygonal mesh model to be rendered and to perform de-indexing processing on the polygonal mesh model to obtain a sequence of independent triangles without shared vertices. The calculation module 72 is used to generate unique point identifiers for the independent vertices of each triangle in the independent triangle sequence, construct the common edge relationship between each triangle and the undirected edge, and calculate the included angle of the normal corresponding to each undirected edge. The determination module 73 is used to determine the outer contour edge of any of the triangles based on the shared edge relationship and the included angle of the normals. The rendering module 74 is used to encode the classification information of the outer contour edge into the vertex attributes, and adapt the encoded polygon mesh model to the target game engine for rendering, so as to realize the real-time outlining of the outer contour.

[0130] The polygon model rendering system provided in this application, employing the polygon model rendering method in the above embodiments, can solve the technical problems in the background art. Compared with the prior art, the beneficial effects of the polygon model rendering system provided in this application are the same as those of the polygon model rendering method provided in the above embodiments, and other technical features of the polygon model rendering system are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0131] This application provides a polygon model rendering device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the polygon model rendering method in the above embodiment 1.

[0132] The following is for reference. Figure 8 This document illustrates a structural schematic diagram of a polygon model rendering device suitable for implementing embodiments of this application. The polygon model rendering device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 8 The polygon model rendering device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0133] like Figure 8As shown, the polygon model rendering device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the polygon model rendering device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touch screen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. The communication device 1009 allows the polygon model rendering device to communicate wirelessly or wiredly with other devices to exchange data. Although polygon model rendering devices with various systems are shown in the figures, it should be understood that it is not required to implement or possess all of the systems shown. More or fewer systems may be implemented alternatively.

[0134] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0135] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0136] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the polygon model rendering methods provided by the methods described above.

[0137] The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0138] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0139] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for rendering polygonal models, characterized in that, include: Obtain the polygonal mesh model to be rendered, and perform de-indexing processing on the polygonal mesh model to obtain a sequence of independent triangles without shared vertices; Generate unique point identifiers for the independent vertices of each triangle in the independent triangle face sequence, construct the common edge relationship between each triangle face and the undirected edge, and calculate the included angle of the normal corresponding to each undirected edge; For any of the aforementioned triangular faces, the outer contour edges of the triangular face are determined based on the shared edge relationship and the included angle of the normals; The classification information of the outer contour edges is encoded into the vertex attributes, and the encoded polygon mesh model is adapted and rendered to the target game engine to achieve real-time outlining of the outer contour.

2. The polygon model rendering method as described in claim 1, characterized in that, The process of de-indexing the polygonal mesh model to obtain a sequence of independent triangles without shared vertices includes: Traverse all triangular face indices in the polygonal mesh model and identify shared vertices with shared relationships among the triangular face indices; Copy the vertex data corresponding to the shared vertex, and reconstruct a vertex array containing position, normal, and texture coordinates; Based on the reconstructed vertex array, an independent triangle sequence is generated in which each triangle has an independent vertex.

3. The polygon model rendering method as described in claim 1, characterized in that, The process involves generating unique vertex identifiers for each independent vertex of the independent triangular face sequence, constructing the shared edge relationship between each triangular face and the undirected edge, and calculating the included angle of the normal to each undirected edge, including: Obtain the spatial coordinate information of each of the independent vertices; Based on the bit pattern of the spatial coordinate information, a unique point identifier is generated for each of the independent vertices, and the undirected edges corresponding to each of the triangular faces are extracted. A unique edge identifier is constructed for each of the undirected edges to build a topology table. A hash table is used to record the triangular face information corresponding to each undirected edge, forming a shared edge relationship; Based on the topology table and the shared edge relationships, the normal vector of each triangle is calculated, and the included angle between the normal vectors of related triangles is calculated.

4. The polygon model rendering method as described in claim 3, characterized in that, The triangular face information includes triangular face identifiers and relative vertex identifiers; The step of recording the triangular face information corresponding to each undirected edge through a hash table to form a shared edge relationship includes: Store the unique edge identifier of each undirected edge as a key in a hash table; Store the triangular face identifiers and relative vertex identifiers associated with each of the undirected edges as values ​​in a hash table; By traversing the undirected edges of each triangle, the hash table is constructed, forming a shared edge relationship.

5. The polygon model rendering method as described in claim 1, characterized in that, The determination of the outer contour edges of the triangular face based on the shared edge relationship and the included angle of the normals includes: Determine the number of triangular faces associated with each undirected edge in the shared edge relationship; For any of the undirected edges, if the number of triangles is one, then the undirected edge is determined to be the outer contour edge of the triangle. If there are two triangles, a preset angle threshold is obtained, and the included angle of the normal is compared with the angle threshold. If the included angle of the normals is greater than the angle threshold, then the undirected edge is determined to be the outer contour edge of the triangular face.

6. The polygon model rendering method as described in claim 1, characterized in that, The step of encoding the classification information of the outer contour edges into vertex attributes and adapting the encoded polygonal mesh model to the target game engine for real-time outline rendering includes: Assign a centroid encoding order to the three vertices of each triangle face, and write the component information corresponding to the centroid encoding order into the texture coordinate attribute of the vertex; Generate an outer contour edge mask and write the outer contour edge mask into the color attribute of the vertex to complete the classification information encoding; Based on the type of the target game engine, export the encoded model file of the encoded polygon mesh model, import the encoded model file into the target game engine, and load the adapted rendering materials; By reading the encoded information in the vertex attributes of the rendering material, identifying the outer contour edge, and adjusting the rendering parameters, the outer contour can be drawn in real time.

7. The polygon model rendering method as described in claim 6, characterized in that, The step of exporting the encoded model file of the encoded polygon mesh model according to the type of the target game engine includes: Obtain the model format support information of the target game engine; If the model format support information does not include open-source model formats, then export a description file containing model topology information and encoding information. The description file is used to convert the model into a model file supported by the target game engine through a plugin. If the model format support information includes open-source model formats, then export the open-source format model file containing the encoding information.

8. A polygon model rendering system, characterized in that, include: The acquisition module is used to acquire the polygonal mesh model to be rendered and to perform de-indexing processing on the polygonal mesh model to obtain a sequence of independent triangles without shared vertices. The calculation module is used to generate unique point identifiers for the independent vertices of each triangle in the sequence of independent triangles, construct the common edge relationship between each triangle and the undirected edge, and calculate the included angle of the normal corresponding to each undirected edge. The determination module is used to determine the outer contour edge of any of the triangles based on the shared edge relationship and the included angle of the normals. The rendering module is used to encode the classification information of the outer contour edges into vertex attributes, and adapt the encoded polygon mesh model to the target game engine for rendering, so as to realize real-time outlining of the outer contour.

9. A polygon model rendering device, characterized in that, The polygon model rendering device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the polygon model rendering method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the polygon model rendering method as described in any one of claims 1 to 7.

Images